From fred@cisco.com Tue Jan 1 11:00:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F9921F8AB8 for ; Tue, 1 Jan 2013 11:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.502 X-Spam-Level: X-Spam-Status: No, score=-110.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siI-3bUZUHnK for ; Tue, 1 Jan 2013 11:00:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD9A21F8AB0 for ; Tue, 1 Jan 2013 11:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1986; q=dns/txt; s=iport; t=1357066811; x=1358276411; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lsqCutMFMXd9cJY2s3IM2ZdDDn4f7Qg7Syg7bn0hbNU=; b=M5XHgpJrdrAJ0kG25Fr9T7EM0QPIO0je80G6fCx5AclUdgkGyPOLi+3l yGMAP1+OoE7QshwtjdB4oESRFpDJK73MBcWgx9/7BFMSo9yT1eTC6U8Wt UBRB5zpLb6S4o7c1cogbz2U8qcEdzmp120TnVCjX9CFLL91Y4/+ydK0IR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncPADEx41CtJXG+/2dsb2JhbAArEAqBf7tYFnOCIAEEOj8SASoUQicEDg0BiAoMLKlGji6MaINRYQOmVIJ0eIEu X-IronPort-AV: E=Sophos;i="4.84,391,1355097600"; d="scan'208";a="157673386" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jan 2013 19:00:11 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r01J0B8D013310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jan 2013 19:00:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 1 Jan 2013 13:00:10 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: RFC 4890 ICMPv6 Filtering Recommendations to BCP? Thread-Index: AQHN6FI4LAWv7zEomU+ptEdjqg27hg== Date: Tue, 1 Jan 2013 19:00:10 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B72A35D@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <8157129E7AF73F4285C2008A47DE01BE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] RFC 4890 ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 19:00:12 -0000 This is to open a discussion regarding the promotion of RFC 4890 (https://t= ools.ietf.org/html/rfc4890) to BCP. It is not a true working group last cal= l; it may be a lead-in to a relatively quick RFC 4890 bis. There are three edits that would need to be made:=20 - the document states, on its title page, that it is "informational", and n= eeds to state that it is "best current practice".=20 - There is also one erratum (http://www.rfc-editor.org/errata_search.php?rf= c=3D4890).=20 - There have been several new ICMPv6 message types defined since it was wri= tten. On the third point, I will forward a brief interchange I had with Ralph Dro= ms. I would like everyone, please, to read the RFC, my interchange with Ralph, = and the documents he points to, and comment on three questions: 1) Do you, or do you not, agree that this document should be promoted to BC= P from a status perspective? (not from a "who cares" perspective - those th= at care, care, and those that don't, don't). 2) Do you believe that there are additional changes that should be made in = such advice, especially regarding the points Ralph raises? If so, please id= entify them and suggest text or support text someone else proposes. 3) On Ralph's point regarding putting filtering advice in the IANA registry= (http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml),= any way we record them, there needs to be guidance to the effect that RFC = 4890bis needs to be updated whenever someone creates a new ICMPv6 message t= ype. That could be done in an RFC, the indicated IANA registry, some other = registry, a wiki, or something else. What is this working group's opinion o= n maintaining the currency of the advice? This discussion ends on February 1. At the end of that, I hope to be able t= o say what the recommendations of this working group are. What we will need= then, or by then, is a document editor for the indicated document.=20 From fred@cisco.com Tue Jan 1 11:02:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C8921E803F for ; Tue, 1 Jan 2013 11:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnM-Ao68hQ2E for ; Tue, 1 Jan 2013 11:02:46 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B99F31F0CE7 for ; Tue, 1 Jan 2013 11:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3869; q=dns/txt; s=iport; t=1357066966; x=1358276566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H5RRyG52caJpaT6E/0AGhQr1eAsSOErVzQh2rUeS77c=; b=eMZVb9ihF7aBbJyKtJIYFLbBXzLGLxda9acxOMzZbuxXAsbS/x7hrdQx ca94bpplqn8/w4uAfu3ZwsJbg0FNp8rNcjMwI13vcX1+PuqPdMCcxkSea tVWPOZUqDFgUtLPa9G2AjkOXd/diSnF2V32GDCzTYCPeud40TZgH1yLYK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkPAIsy41CtJXG//2dsb2JhbABFgX+7WBZzgh4BAQEEGCI/EAIBCBgKFBAhESUCBA4FCAGHeAMPDKlzhWANiECLbWqDYmEDlDaNDYURgnSCJg X-IronPort-AV: E=Sophos;i="4.84,392,1355097600"; d="scan'208";a="157932095" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 01 Jan 2013 19:02:46 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r01J2kom030237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jan 2013 19:02:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 1 Jan 2013 13:02:46 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org Operations" Thread-Topic: Promoting RFC 4890 Thread-Index: AQHN6FKVY/x9w3NuC0CpPIpiGLijzg== Date: Tue, 1 Jan 2013 19:02:45 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B72A3C6@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501DF6B10@BY2PRD0512MB653.namprd05.prod.outlook.com> <50DC6D13.1090505@qti.qualcomm.com> <2CF4CB03E2AA464BA0982EC92A02CE2501DF6BBC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20121227162102.GA20848@rfc-editor.org> <50DC78A3.9010106@rfc-editor.org> <8C48B86A895913448548E6D15DA7553B726DEE@xmb-rcd-x09.cisco.com> <50DDA97A.5060500@ieca.com> <30CB2C02-7BB7-433C-804A-3D38CABC7DED@gmail.com> <8C48B86A895913448548E6D15DA7553B727526@xmb-rcd-x09.cisco.com> <291F0D3A-8582-4CBC-BF1C-8D78A139FE10@gmail.com> In-Reply-To: <291F0D3A-8582-4CBC-BF1C-8D78A139FE10@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ralph Droms Subject: Re: [v6ops] Promoting RFC 4890 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 19:02:47 -0000 A thread between the chairs and the IESG, and a specific comment from Ralph= that needs to be addressed. On Dec 28, 2012, at 2:39 PM, Ralph Droms wrote: > On Dec 28, 2012, at 3:53 PM, "Fred Baker (fred)" wrote: >> On Dec 28, 2012, at 6:29 AM, Ralph Droms wrote: >>>=20 >>> Fred - there will likely be discussion about ICMP types that have been = assigned since RFC 4890 was published and that are not mentioned explicitly= in RFC 4890: >>>=20 >>> 154 FMIPv6 Messages [RFC5568] >>> 155 RPL Control Message [RFC6550] >>> 156 ILNPv6 Locator Update Message [RFC6743] >>> 157 Duplicate Address Request [RFC-ietf-6lowpan-nd-21] >>> 158 Duplicate Address Confirmation [RFC-ietf-6lowpan-nd-21] >>>=20 >>> My personal opinion is that the current text in RFC 4890 covers these t= ypes; e.g.: >>>=20 >>> 4.4.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made >>=20 >> Implicit in that assumption is a model of the network. I would expect th= at if an ILNP host changes its locator, it will want its peer to know. Filt= ering that message breaks ILNP as much as filtering "too big" breaks PMTU. = Filtering a DAD request or response makes it possible to have undetected du= plicate addresses - assuming the 6lowpan network straddles a firewall. Pers= onally, I think I would err on the side of preserving them unless a case ca= n be made, not dropping them unless a case can be made. I might give guidan= ce on how that case might be made; if no 6lowpan domain crosses a firewall,= dropping the 6lowpan messages is probably a reasonable security precaution= . >=20 > OK, then it seems there should be a discussion of the new options with up= dates in 4890bis. >=20 >>> Thinking orthogonally (and in an admittedly process-heavy way), would i= t make sense to consider, instead, an update to the registry and process th= at encodes the RFC 4890 filtering classification? =20 >>=20 >> Are you talking about http://www.iana.org/assignments/icmpv6-parameters/= icmpv6-parameters.xml? It's a registry for ICMP messages, but doesn't encod= e filtering recommendations. I could imagine adding a table with references= ("MAY" or "SHOULD NOT" be filtered, mitigating issues, RFC reference), and= asking the working groups that designed those messages to offer operationa= l guidance on filtering them in appropriate RFCs. I'd be a little concerned= about the volume of text implied in summarizing a 38 page RFC into a table= . >=20 > I'm thinking of a 4890bis that retains the explanations of the recommenda= tions, adds the filtering recommendations to the icmpv6-parameters registry= , and requires future additions to the registry to include a justified filt= ering recommendation to be included in the registry. >=20 >> We're now getting into the discussion that v6ops proposes to have in Jan= uary. >=20 > Understood. In my opinion, the document needs at least the review of the= more recent options in addition to the errata and new boilerplate, all of = which really ought to have WG discussion. >=20 >> BTW, it's not entirely accurate to say that v6ops has developed a consen= sus towards advancing RFC 4890; several of us are in favor of doing so, and= Lee thinks it's a pointless activity, but we have not actually measured th= e degree to which we have consensus. What I plan to do is host a discussio= n on the list in january asking everyone to read the document and comment o= n it. >=20 > Returning to the registry briefly, if RFC 4890 has been useful, I see a n= eed for a way to update the filtering rules for new ICMP types. >=20 >> I could imagine a survey monkey poll to get specific levels of support o= n different recommendations... >=20 > - Ralph >=20 >=20 From rbonica@juniper.net Tue Jan 1 11:28:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76C821E803F for ; Tue, 1 Jan 2013 11:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.329 X-Spam-Level: X-Spam-Status: No, score=-103.329 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbCr0pZTseH7 for ; Tue, 1 Jan 2013 11:28:54 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEC321E8044 for ; Tue, 1 Jan 2013 11:28:54 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUOM49dhjXTGrkNL2JIA/P00FpJl6xp6g@postini.com; Tue, 01 Jan 2013 11:28:54 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 1 Jan 2013 11:28:52 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 1 Jan 2013 11:28:51 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 1 Jan 2013 11:37:09 -0800 Received: from mail160-co1-R.bigfish.com (10.243.78.221) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Tue, 1 Jan 2013 19:28:50 +0000 Received: from mail160-co1 (localhost [127.0.0.1]) by mail160-co1-R.bigfish.com (Postfix) with ESMTP id CF2A3800165 for ; Tue, 1 Jan 2013 19:28:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz1432Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail160-co1 (localhost.localdomain [127.0.0.1]) by mail160-co1 (MessageSwitch) id 1357068528253564_10076; Tue, 1 Jan 2013 19:28:48 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.215]) by mail160-co1.bigfish.com (Postfix) with ESMTP id 3B782A0004B; Tue, 1 Jan 2013 19:28:48 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 1 Jan 2013 19:28:48 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.183]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0245.002; Tue, 1 Jan 2013 19:28:46 +0000 From: Ronald Bonica To: Marc Blanchet , "EXT - joelja@bogus.com" Thread-Topic: [v6ops] ICMPv6 Filtering Recommendations to BCP? Thread-Index: AQHN3oh+uJ7baeRkfUKfehxD5cOcJZghVmuAgAAIwwCACs8qAIAAyoqAgAAF3wCAABB9gIAA2QgAgALW/4CAAMYrgIADaanQ Date: Tue, 1 Jan 2013 19:28:45 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E0214E@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> <50DC8AED.9050009@bogus.com> <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> <457F60F8-6319-40C2-8C50-A0F78A601470@viagenie.ca> <50DD53BE.5080303@gmail.com> <50DFB597.1040902@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%VIAGENIE.CA$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%BONICA.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 19:28:54 -0000 That's certainly less effort for me. Ron >=20 > I agree with Joel. Looks better to write new version of the document, > target as BCP and obsolete the previous one. That way there is an > incentive to move the new one forward and we accomplish all this with > the "least" amount of efforts (procedurally). >=20 From Fred.L.Templin@boeing.com Thu Jan 3 08:15:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8021F8C49 for ; Thu, 3 Jan 2013 08:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9Ss7q2paQDs for ; Thu, 3 Jan 2013 08:15:34 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id A31A921F8C13 for ; Thu, 3 Jan 2013 08:15:34 -0800 (PST) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r03GFXc9028623 for ; Thu, 3 Jan 2013 08:15:33 -0800 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r03GFXS1028620 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 3 Jan 2013 08:15:33 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 3 Jan 2013 08:15:33 -0800 From: "Templin, Fred L" To: "Fred Baker (fred)" , "v6ops@ietf.org" Date: Thu, 3 Jan 2013 08:15:32 -0800 Thread-Topic: RFC 4890 ICMPv6 Filtering Recommendations to BCP? Thread-Index: AQHN6FI4LAWv7zEomU+ptEdjqg27hpg3xfjg Message-ID: References: <8C48B86A895913448548E6D15DA7553B72A35D@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B72A35D@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] RFC 4890 ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:15:35 -0000 Fred, Something that has always bothered me about RFC4890 is the following text of Section A.2: "If a network chooses to generate packets that are no larger than the Guaranteed Minimum MTU (1280 octets) and the site's links to the wider Internet have corresponding MTUs, Packet Too Big messages should not be expected at the firewall and could be dropped if they arrive." This seems to preclude PTB messages reporting a size smaller than 1280, which are necessary to ensure proper operation of IPv6, e.g., per the final paragraph of RFC2460, Section 5. My recommendation is that the RFC4890, Section A.2 text be dropped when preparing the (bis) version for publication as a BCP. Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: Tuesday, January 01, 2013 11:00 AM > To: v6ops@ietf.org > Subject: [v6ops] RFC 4890 ICMPv6 Filtering Recommendations to BCP? >=20 > This is to open a discussion regarding the promotion of RFC 4890 > (https://tools.ietf.org/html/rfc4890) to BCP. It is not a true working > group last call; it may be a lead-in to a relatively quick RFC 4890 bis. >=20 > There are three edits that would need to be made: > - the document states, on its title page, that it is "informational", and > needs to state that it is "best current practice". > - There is also one erratum (http://www.rfc- > editor.org/errata_search.php?rfc=3D4890). > - There have been several new ICMPv6 message types defined since it was > written. >=20 > On the third point, I will forward a brief interchange I had with Ralph > Droms. >=20 > I would like everyone, please, to read the RFC, my interchange with Ralph= , > and the documents he points to, and comment on three questions: >=20 > 1) Do you, or do you not, agree that this document should be promoted to > BCP from a status perspective? (not from a "who cares" perspective - thos= e > that care, care, and those that don't, don't). >=20 > 2) Do you believe that there are additional changes that should be made i= n > such advice, especially regarding the points Ralph raises? If so, please > identify them and suggest text or support text someone else proposes. >=20 > 3) On Ralph's point regarding putting filtering advice in the IANA > registry (http://www.iana.org/assignments/icmpv6-parameters/icmpv6- > parameters.xml), any way we record them, there needs to be guidance to th= e > effect that RFC 4890bis needs to be updated whenever someone creates a ne= w > ICMPv6 message type. That could be done in an RFC, the indicated IANA > registry, some other registry, a wiki, or something else. What is this > working group's opinion on maintaining the currency of the advice? >=20 > This discussion ends on February 1. At the end of that, I hope to be able > to say what the recommendations of this working group are. What we will > need then, or by then, is a document editor for the indicated document. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sander@steffann.nl Thu Jan 3 08:26:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6B821F8610 for ; Thu, 3 Jan 2013 08:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.976 X-Spam-Level: X-Spam-Status: No, score=0.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztP5kmhPHfD4 for ; Thu, 3 Jan 2013 08:26:20 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8040621F872D for ; Thu, 3 Jan 2013 08:26:20 -0800 (PST) Received: from [172.20.10.2] (unknown [62.140.137.93]) by mail.sintact.nl (Postfix) with ESMTP id ECDD7200A; Thu, 3 Jan 2013 17:26:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Thu, 3 Jan 2013 17:26:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9FA4069A-FE71-4391-879B-BC996E7092BF@steffann.nl> References: <8C48B86A895913448548E6D15DA7553B72A35D@xmb-rcd-x09.cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 4890 ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:26:21 -0000 Hi, > Something that has always bothered me about RFC4890 is the > following text of Section A.2: >=20 > "If a network chooses to generate packets that are no larger than = the > Guaranteed Minimum MTU (1280 octets) and the site's links to the > wider Internet have corresponding MTUs, Packet Too Big messages > should not be expected at the firewall and could be dropped if they > arrive." >=20 > This seems to preclude PTB messages reporting a size smaller > than 1280, which are necessary to ensure proper operation of > IPv6, e.g., per the final paragraph of RFC2460, Section 5. >=20 > My recommendation is that the RFC4890, Section A.2 text be dropped > when preparing the (bis) version for publication as a BCP. +1 This advise will cause problems with (atomic) fragment requirement in = RFC2460 section 5, so it should not be in a BCP. Sander From jess8882003@yahoo.com Tue Jan 8 05:58:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B1E21F876E for ; Tue, 8 Jan 2013 05:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.89 X-Spam-Level: *** X-Spam-Status: No, score=3.89 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVpWF10Agz71 for ; Tue, 8 Jan 2013 05:58:51 -0800 (PST) Received: from nm33.bullet.mail.bf1.yahoo.com (nm33.bullet.mail.bf1.yahoo.com [72.30.238.133]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8021F8758 for ; Tue, 8 Jan 2013 05:58:51 -0800 (PST) Received: from [98.139.214.32] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jan 2013 13:58:50 -0000 Received: from [98.139.212.248] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jan 2013 13:58:50 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 08 Jan 2013 13:58:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 544904.13264.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 78418 invoked by uid 60001); 8 Jan 2013 13:58:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357653530; bh=iLz1/jA2vY/rIpaFiw5Q/qD/aMmP5IO3lYkGAWzEYwM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=bBiu0AijbLDkMpXV+NYArHbx+wL5kVW5rXgV/QTvcLYm6VXRqMqXQCutwcEJiRBpxxRGxA74NpRl6jkqIah0jOdgYjaLfT+TMK/awHCeiQcWdV5BKambNV5iFXBiEtjjEe466SjhhO7A7OntHvzvb4dph/QEERg/VsQykNRN56M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=2taoFvAiidI7YTHsaPVxK+Opfzqj8ugMcqFNSQvGORA8ziwk2b3hypZCZE9NfSSUSVmtt7tOtJiF7whKDZsAooc1yd+SunkVPK0PtjhDBovPCkmghDNS1YYgEX2e5cxtBECTRKNhTZwBbcIdVPeok3MxeNZLWdCn5bVrACmqHzI=; X-YMail-OSG: KM4NATwVM1nOWaCtRZvA4PCjNhlD8lXfstuU3f6Nirr.dI3 1xoQjKECgjh774.Gcn0dE_0hEhm3ddqpS9Uumh4yL41EFU5nrGAHK21qc14B iVF66yKra_qbx5zM.9u2b2EhLGak9.KmkCymaiv4tfKGZCWGc304B9zeEa.i gWvtsW5CNpYtlTiQCC0Ep_viygGaLc3JRJQqLwAUtt0Sdc7RfTNPT.lzA9Fp gEsGXwIpeResJog63oRdhODbt5HKoyylq_wm52laZj1r4pXdSeCnwxbZj6nr wVl2U4IS9SHtfG0tiuW7aUa7VKiL6cSZXdP.5q42JL42lOErXis45IAjuqFm eInSpGI.Ytgvmp21RlUvW_vbyJ54nflJZ9KD__ORNL1KTNyQb0mKYW77LDZ5 LlXAvrlJs6FBe8ROU8q59k9BQmQImCdENpk8AQXhyr22ELoRFNjgqNGavMGK TlNXz04VvweHvP7kCDaoRwoCJ0z6ZKbEiMutCDh3NVFHhuMw_ryQMlj5xOsf .R0p2KCEKwg6sEI4k7AEp.wclqdEqFhYnZa35_5PAQzSB.u3.hxfjvOiChJu .XBxjKSPCBUiWUS6UMIjWn.DoGso5mtqM8ZIkTw-- Received: from [210.191.140.230] by web161805.mail.bf1.yahoo.com via HTTP; Tue, 08 Jan 2013 05:58:50 PST X-Rocket-MIMEInfo: 001.001, aHR0cDovL3d3dy5jbXMtd2Vya3N0YXR0LmRlL2ltYWdlcy9zdG9yaWVzL2RzcHZzLnBocAEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.130.494 Message-ID: <1357653530.75339.YahooMailNeo@web161805.mail.bf1.yahoo.com> Date: Tue, 8 Jan 2013 05:58:50 -0800 (PST) From: Jess Ger To: windmediainc@hotmail.com, wenchungw@yahoo.com, seek_and_hide@yahoo.com, murphymike@foothill.edu, jhenspen@cisco.com, iperf-users@dast.nlanr.net, v6ops@ietf.org, phil_chan@yahoo.com, kpassoubady@gmail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-337026386-259790727-1357653530=:75339" Subject: [v6ops] (no subject) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jess Ger List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 13:58:52 -0000 ---337026386-259790727-1357653530=:75339 Content-Type: text/plain; charset=us-ascii http://www.cms-werkstatt.de/images/stories/dspvs.php ---337026386-259790727-1357653530=:75339 Content-Type: text/html; charset=us-ascii ---337026386-259790727-1357653530=:75339-- From rbonica@juniper.net Thu Jan 10 09:32:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5986E21F8797 for ; Thu, 10 Jan 2013 09:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.982 X-Spam-Level: X-Spam-Status: No, score=-102.982 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ2Z070XWIdp for ; Thu, 10 Jan 2013 09:32:39 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id DF68D21F876E for ; Thu, 10 Jan 2013 09:32:38 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUO77NoohYAmlbBC5bNcbDHej6WtJbFct@postini.com; Thu, 10 Jan 2013 09:32:38 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 10 Jan 2013 09:31:03 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 10 Jan 2013 09:31:03 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.141) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 Jan 2013 09:33:05 -0800 Received: from mail71-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 10 Jan 2013 17:31:00 +0000 Received: from mail71-db3 (localhost [127.0.0.1]) by mail71-db3-R.bigfish.com (Postfix) with ESMTP id F33AA4C02BC for ; Thu, 10 Jan 2013 17:30:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dh18602ehz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail71-db3 (localhost.localdomain [127.0.0.1]) by mail71-db3 (MessageSwitch) id 1357839057419304_27402; Thu, 10 Jan 2013 17:30:57 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.229]) by mail71-db3.bigfish.com (Postfix) with ESMTP id 5A8448005F for ; Thu, 10 Jan 2013 17:30:57 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 10 Jan 2013 17:30:56 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.240]) by BY2PRD0512HT001.namprd05.prod.outlook.com ([10.255.243.34]) with mapi id 14.16.0257.004; Thu, 10 Jan 2013 17:30:54 +0000 From: Ronald Bonica To: IPv6 Operations Thread-Topic: Mail regarding draft-ietf-v6ops-464xlat Thread-Index: Ac3vWD2oX+jwqLZ3Tcq/T8uiYQotag== Date: Thu, 10 Jan 2013 17:30:54 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 17:32:40 -0000 Folks, Draft-ietf-v6ops-464xlat is nearly ready for IESG approval. However, severa= l IESG members, including me, are concerned that the WG has not yet conside= red the IPR declaration attached to this document. So, I will wait one more week before approving this document. If you are co= ncerned about the IPR declaration, please post a message describing your co= ncerns to the list. If no such concerns are posted, I will approve the draf= t on January 17. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From randy@psg.com Thu Jan 10 16:41:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06AD21F885C for ; Thu, 10 Jan 2013 16:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgk9slBcQORJ for ; Thu, 10 Jan 2013 16:41:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8776A21F8869 for ; Thu, 10 Jan 2013 16:41:33 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TtSgd-000OY0-Pa; Fri, 11 Jan 2013 00:41:32 +0000 Date: Fri, 11 Jan 2013 09:41:30 +0900 Message-ID: From: Randy Bush To: Ronald Bonica In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 00:41:34 -0000 thanks for the flag, ron. imiho "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee." is a pretty much a show-stopper randy From rajiva@cisco.com Thu Jan 10 16:51:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D9621F8546 for ; Thu, 10 Jan 2013 16:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.466 X-Spam-Level: X-Spam-Status: No, score=-9.466 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SJbjHYf851s for ; Thu, 10 Jan 2013 16:51:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D6BE721F8651 for ; Thu, 10 Jan 2013 16:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=492; q=dns/txt; s=iport; t=1357865515; x=1359075115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=29Epw8NM1xnQiz2APWA5GDL7Q68CD+fM1mloEqorLo8=; b=dC5xUvHu0bnoEWMff3As3Aknen8kKT4R5SRpqV2xiaYw+8f+4PkXv+Am /U/vwGfOnIlUeerkzf/P2IIZXLUs00JWMXgLxQK/OWXr7PiRYoyKqSqVR U3X3v80qS7G3JtoVkC+bI8RmcaAi/SNSxMO4a0t//cUF+OGtTB38CQ38o o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0IAMBg71CtJV2c/2dsb2JhbABEg0eCK7gEFnOCHgEBAQMBAQEBNzQLBQsCAQg2ECcLJQEBBA4FiBMGDLRsBIx3g0dhA5YKkEmCdYFv X-IronPort-AV: E=Sophos;i="4.84,447,1355097600"; d="scan'208";a="161189052" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jan 2013 00:51:55 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0B0ptLG030265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jan 2013 00:51:55 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 18:51:55 -0600 From: "Rajiv Asati (rajiva)" To: Randy Bush Thread-Topic: [v6ops] Mail regarding draft-ietf-v6ops-464xlat Thread-Index: Ac3vWD2oX+jwqLZ3Tcq/T8uiYQotagAbnJkA//+eU70= Date: Fri, 11 Jan 2013 00:51:54 +0000 Message-ID: <88E53AB7-7678-4971-AA73-DDCF8543E9BB@cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 00:51:56 -0000 Oops. I agree with Randy to this being a no-go. Cheers, Rajiv Sent from my Phone On Jan 10, 2013, at 7:41 PM, "Randy Bush" wrote: > thanks for the flag, ron. imiho >=20 > "Reasonable and Non-Discriminatory License to All Implementers with > Possible Royalty/Fee." >=20 > is a pretty much a show-stopper >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Thu Jan 10 17:23:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B3F21F8920 for ; Thu, 10 Jan 2013 17:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThrOFfRqEJdo for ; Thu, 10 Jan 2013 17:23:06 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 606C421F8917 for ; Thu, 10 Jan 2013 17:23:06 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id ep20so1263136lab.4 for ; Thu, 10 Jan 2013 17:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KSP+zIcibQmkt8c6lPI0vDZgChYAL8qqAzo7LA9rVmU=; b=jSbiB0IjiKl/B+NWO7b6BUD5rEjW1Ijj/GGKQw5mbhlaKGEQIo3Cck6ZSYeFFAch7I aYRp/jdbf9tTcNJTcD4zkQqx2R01IqMoMIHOZw1KdcNX+tCfKG6/3C/NuVv9O8ULzpY7 e3CZwYFhzJnoCY52Tw5jAh/+W6QXGVMHw1dQpWySHbiC9TKwDiMO1H2fR4d1Dlawnk4w m9TmOdWGIcpU1Rs/JnyWbX8QOemqBg8SZgpK1zw7mBMkNSb08eamI+lF2IuxRf0Z5SuN FuPFOL4KLxQUJnOus38mJw3Xqo8y9ZRjftKMGZLCDBWDfZ6RN7dZoCKbCQs1QCG5kBNg d/jA== MIME-Version: 1.0 Received: by 10.152.111.102 with SMTP id ih6mr11958836lab.20.1357867385271; Thu, 10 Jan 2013 17:23:05 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 10 Jan 2013 17:23:05 -0800 (PST) In-Reply-To: References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Thu, 10 Jan 2013 17:23:05 -0800 Message-ID: From: Cameron Byrne To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , Hui Deng Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 01:23:07 -0000 Hui, Deng and v6ops, On Thu, Jan 10, 2013 at 4:41 PM, Randy Bush wrote: > thanks for the flag, ron. imiho > > "Reasonable and Non-Discriminatory License to All Implementers with > Possible Royalty/Fee." > > is a pretty much a show-stopper > As you can see, we have a problem. The IESG only has this final IPR issue to resolve before publishing 464XLAT. I see a few ways forward: 1. China Mobile can grant free use for the benefit of the IETF and the benefit of global IPv6 adoption and on-going evolution of the Internet 2. The IETF can move forward on the basis that the IPR claim is invalid*. 3. Other options??? Regards, CB *I am not a lawyer, but the 464XLAT draft is just a combination of existing technologies, none of which has IPR. And, AFAIK [1], it is not legitimate to patent a combination of existing technologies .... which is what the IPR claim is. NAT-PT goes back to the year 2000 as prior art. So, simple analysis, says this patent is not valid. Yet, we have this claim. CB [1] -- http://www.nolo.com/legal-encyclopedia/combination-invention-patentable-patents-29891.html From joelja@bogus.com Thu Jan 10 18:03:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3721F8931 for ; Thu, 10 Jan 2013 18:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.799 X-Spam-Level: X-Spam-Status: No, score=-100.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO6VvUqPPvbE for ; Thu, 10 Jan 2013 18:03:57 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5521F8930 for ; Thu, 10 Jan 2013 18:03:57 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0B23jFG087835 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 11 Jan 2013 02:03:47 GMT (envelope-from joelja@bogus.com) Message-ID: <50EF72FB.9040009@bogus.com> Date: Thu, 10 Jan 2013 18:03:39 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Cameron Byrne References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 11 Jan 2013 02:03:47 +0000 (UTC) Cc: IPv6 Operations , Hui Deng Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 02:03:58 -0000 On 1/10/13 17:23 , Cameron Byrne wrote: > Hui, Deng and v6ops, > > On Thu, Jan 10, 2013 at 4:41 PM, Randy Bush wrote: >> thanks for the flag, ron. imiho >> >> "Reasonable and Non-Discriminatory License to All Implementers with >> Possible Royalty/Fee." >> >> is a pretty much a show-stopper >> > > > As you can see, we have a problem. The IESG only has this final IPR > issue to resolve before publishing 464XLAT. > > I see a few ways forward: > > 1. China Mobile can grant free use for the benefit of the IETF and > the benefit of global IPv6 adoption and on-going evolution of the > Internet > > 2. The IETF can move forward on the basis that the IPR claim is invalid*. So I'm curious given that there are china mobile participants in softwire and certainly were in 2010 why this ipr disclosure would not also be lodged against RFC 6147 which is the source of the method in the first place. I'm not in a position to evaluate the claim in the patent but I can trace the history of the work back through the document series, and elsewhere (in code that I used)at least back to 1999 with totd/faithd for application/host proxy and totd/nat-pt for v6only hosts. > 3. Other options??? > > Regards, > > CB > > *I am not a lawyer, but the 464XLAT draft is just a combination of > existing technologies, none of which has IPR. And, AFAIK [1], it is > not legitimate to patent a combination of existing technologies .... > which is what the IPR claim is. NAT-PT goes back to the year 2000 as prior art. > > So, simple analysis, says this patent is not valid. Yet, we have this claim. > > CB > > [1] -- http://www.nolo.com/legal-encyclopedia/combination-invention-patentable-patents-29891.html > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From denghui02@gmail.com Thu Jan 10 23:53:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE7321F8949 for ; Thu, 10 Jan 2013 23:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.814 X-Spam-Level: X-Spam-Status: No, score=-101.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4evzsFaDryK for ; Thu, 10 Jan 2013 23:53:49 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBF221F8A3F for ; Thu, 10 Jan 2013 23:53:49 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id j3so933596qcs.6 for ; Thu, 10 Jan 2013 23:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fxfl42gBsgjsBwOZUdMcMrhN3jfQ5VC65DEz12MAkl0=; b=Zj21EdYqaslFxIpLVXNxXsV53n16OOtwZ4CKAD8xJvdwbb4duBw9rI3BEZ4Af/YvXT hENZynTanmocBLl50UUQDqr71wq42WZvy4784sCFWWy++OZl4iwR7g/aHSMN1TNYxPDC D+/Y/i1IW7EjfibmGXIWxelBm7MWxtZXKCHL437PexC5h/wqnnLils7f87K6sxrcZVQh VpLm4g9z1KCYU8pX6g2wSmEsiO5/7Etot6uHkb3OhyWBMtE5cBJRO1u3sDGZs1Ypfsm5 kSA/KdjBJilwlfezg063a9P3QxuqTpf6LE6r7rtTjXU78vsPOFk+Pj22eREtCAOq9pWh U2Sw== MIME-Version: 1.0 Received: by 10.229.69.100 with SMTP id y36mr14116713qci.34.1357890828456; Thu, 10 Jan 2013 23:53:48 -0800 (PST) Received: by 10.49.97.193 with HTTP; Thu, 10 Jan 2013 23:53:48 -0800 (PST) In-Reply-To: References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Fri, 11 Jan 2013 15:53:48 +0800 Message-ID: From: Hui Deng To: Cameron Byrne , wangzhenkai@chinamobile.com, =?GB2312?B?s8K41Q==?= Content-Type: multipart/alternative; boundary=00032557adae7953b904d2fe9897 Cc: IPv6 Operations , Hui Deng Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:53:50 -0000 --00032557adae7953b904d2fe9897 Content-Type: text/plain; charset=ISO-8859-1 Cameron As an individual participant of IETF, I am not the right people to answer this, it says the contact from the below link: https://datatracker.ietf.org/ipr/1730/ so I am cc to him now. Best regards, -Hui 2013/1/11 Cameron Byrne > Hui, Deng and v6ops, > > On Thu, Jan 10, 2013 at 4:41 PM, Randy Bush wrote: > > thanks for the flag, ron. imiho > > > > "Reasonable and Non-Discriminatory License to All Implementers with > > Possible Royalty/Fee." > > > > is a pretty much a show-stopper > > > > > As you can see, we have a problem. The IESG only has this final IPR > issue to resolve before publishing 464XLAT. > > I see a few ways forward: > > 1. China Mobile can grant free use for the benefit of the IETF and > the benefit of global IPv6 adoption and on-going evolution of the > Internet > > 2. The IETF can move forward on the basis that the IPR claim is invalid*. > > 3. Other options??? > > Regards, > > CB > > *I am not a lawyer, but the 464XLAT draft is just a combination of > existing technologies, none of which has IPR. And, AFAIK [1], it is > not legitimate to patent a combination of existing technologies .... > which is what the IPR claim is. NAT-PT goes back to the year 2000 as > prior art. > > So, simple analysis, says this patent is not valid. Yet, we have this > claim. > > CB > > [1] -- > http://www.nolo.com/legal-encyclopedia/combination-invention-patentable-patents-29891.html > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00032557adae7953b904d2fe9897 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Cameron
 
As an individual participant of IET= F, I am not the right people to answer this,
it says the contact = from the below link:
 

https://datatracker.ietf.o= rg/ipr/1730/


so I am cc to him now.
 
Best regards,<= /div>
 
-Hui

 
2013/1/11 Cameron Byrne <cb.list6@gmail.com>
Hui, Deng and v6ops,

On Thu, Jan 10, 2013 at 4:41 PM, Randy Bush <randy@psg.com> wrote:
> thanks for the flag, ron.  imiho
>
> "Reasonable and Non-Discriminatory License to All Implementers wi= th
> Possible Royalty/Fee."
>
> is a pretty much a show-stopper
>


As you can see, we have a problem.  The IESG only has this final= IPR
issue to resolve before publishing 464XLAT.

I see a few ways forward:

1.  China Mobile can grant free use for the benefit of the IETF and the benefit of global IPv6 adoption and on-going evolution of the
Internet

2.  The IETF can move forward on the basis that the IPR claim is inval= id*.

3.  Other options???

Regards,

CB

*I am not a lawyer, but the 464XLAT draft is just a combination of
existing technologies, none of which has IPR.  And, AFAIK [1], it is not legitimate to patent a combination of existing technologies ....
which is what the IPR claim is.  NAT-PT goes back to the year 2000 as = prior art.

So, simple analysis, says this patent is not valid.  Yet, we have this= claim.

CB

[1] -- http://www.nolo.com/le= gal-encyclopedia/combination-invention-patentable-patents-29891.html
___________________________________= ____________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--00032557adae7953b904d2fe9897-- From brian.e.carpenter@gmail.com Fri Jan 11 00:55:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2961821F87A4 for ; Fri, 11 Jan 2013 00:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.174 X-Spam-Level: X-Spam-Status: No, score=-101.174 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-UccJ8ssigC for ; Fri, 11 Jan 2013 00:55:31 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1790621F87A3 for ; Fri, 11 Jan 2013 00:55:30 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id r1so735997wey.29 for ; Fri, 11 Jan 2013 00:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dVx0uwQQDxWV4SwadKHFpR1IrKcXQaB6KLoXXPrJ1jM=; b=nYv4nOYS7EmS86TUbBy6Lup2oau0FUYcQwIkhLF30PqiBIIYwqRI8lpWQVimf4SZHP pnS0Q4mo3RK6nFMT9+QCjGI5T9uSrRQmwl344mTP9lciXo16l0RzMS2NZjyMqPS3KURP oyy/om1AAbpO8W67l7nwG16HIAAKLuFcjXATlPTVXH9KJEis9sYBYY5NjbiavSE0JIox esNVH0vCwFw5/vkzJDU3dYVJA0lAAMQ47UQerhHlwj8OJo9kjHHZPZIToCAKXPOo684L MmKwbLVvqBisT90golIUaHZ0TvNrVhXYXgQ7AiSotmF8ADUcpWNSnQPVNBSfmovhfU9l pikA== X-Received: by 10.195.12.42 with SMTP id en10mr15821646wjd.24.1357894530167; Fri, 11 Jan 2013 00:55:30 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-120.as13285.net. [2.102.216.120]) by mx.google.com with ESMTPS id l5sm6195872wia.10.2013.01.11.00.55.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 00:55:29 -0800 (PST) Message-ID: <50EFD38E.10901@gmail.com> Date: Fri, 11 Jan 2013 08:55:42 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Hui Deng Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:55:32 -0000 On 11/01/2013 01:23, Cameron Byrne wrote: > Hui, Deng and v6ops, > > On Thu, Jan 10, 2013 at 4:41 PM, Randy Bush wrote: >> thanks for the flag, ron. imiho >> >> "Reasonable and Non-Discriminatory License to All Implementers with >> Possible Royalty/Fee." >> >> is a pretty much a show-stopper >> > > > As you can see, we have a problem. The IESG only has this final IPR > issue to resolve before publishing 464XLAT. > > I see a few ways forward: > > 1. China Mobile can grant free use for the benefit of the IETF and > the benefit of global IPv6 adoption and on-going evolution of the > Internet > > 2. The IETF can move forward on the basis that the IPR claim is invalid*. > > 3. Other options??? 4. The IETF can move forward because its rules allow RAND conditions. There are innumerable IETF standards with RAND disclosures against them. We may not like it, but we do it all the time. The summary of the claims (http://ip.com/patfam/en/43370583) is very broad. Judging by that, if this disclosure was required, a disclosure against draft-huang-behave-bih or RFC 6535 would also have been required. However, the prior art for that goes back to RFC 2767, which is way before this recent patent. It isn't the IETF's job to determine whether a patent is valid. But if we have a strong inclination to believe it's invalid, and the disclosure in any case meets our rules, we can . It's then for implementors to decide what to do. Brian > > Regards, > > CB > > *I am not a lawyer, but the 464XLAT draft is just a combination of > existing technologies, none of which has IPR. And, AFAIK [1], it is > not legitimate to patent a combination of existing technologies .... > which is what the IPR claim is. NAT-PT goes back to the year 2000 as prior art. > > So, simple analysis, says this patent is not valid. Yet, we have this claim. > > CB > > [1] -- http://www.nolo.com/legal-encyclopedia/combination-invention-patentable-patents-29891.html > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ietfc@btconnect.com Fri Jan 11 01:58:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6383521F882D for ; Fri, 11 Jan 2013 01:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.086 X-Spam-Level: X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78LAUga90S4W for ; Fri, 11 Jan 2013 01:58:40 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id B28A021F882B for ; Fri, 11 Jan 2013 01:58:39 -0800 (PST) Received: from mail29-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 11 Jan 2013 09:58:38 +0000 Received: from mail29-am1 (localhost [127.0.0.1]) by mail29-am1-R.bigfish.com (Postfix) with ESMTP id 5D12540090 for ; Fri, 11 Jan 2013 09:58:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz9371I542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dh8275ch1033IL18602ehz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh304l1155h) Received: from mail29-am1 (localhost.localdomain [127.0.0.1]) by mail29-am1 (MessageSwitch) id 1357898316457905_26534; Fri, 11 Jan 2013 09:58:36 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.254]) by mail29-am1.bigfish.com (Postfix) with ESMTP id 6BBC2240081; Fri, 11 Jan 2013 09:58:36 +0000 (UTC) Received: from AMXPRD0711HT003.eurprd07.prod.outlook.com (157.56.250.69) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 11 Jan 2013 09:58:36 +0000 Received: from DBXPRD0411HT001.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.242.9.164) with Microsoft SMTP Server (TLS) id 14.16.257.4; Fri, 11 Jan 2013 09:58:35 +0000 Message-ID: <003401cdefe1$e58cc360$4001a8c0@gateway.2wire.net> From: t.petch To: Ronald Bonica , IPv6 Operations References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Fri, 11 Jan 2013 09:56:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.165] X-FOPE-CRA-Verdict: 157.56.250.69$juniper.net%12218%4%btconnect.com%False%False%0$ X-OriginatorOrg: btconnect.com Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:58:41 -0000 Ron I did look at it and it seems odd. It describes a method of a v4 application generating a v4 DNS request on an IPv6 host which translates the request into a v6 request across the v6 network. The v4 application then uses the v4 address obtained to generate a v4 packet which the v6 host translates into a v6 packet for transmission across the v6 network to a NAT device which translates the packet into a v4 packet and sends it on to the v4 opposite end. Obviously it is in the same ball park as 464 but seems not to overlap. I note that the patent dates from 2009, the IPR disclosure was raised against 464xlat-01, by Chen Gang of ChinaMobile, and has not been raised against subsequent versions. This is, to me, unusual - I usually see the same claim raised against each and every version, up to and including the RFC. Based on this, my lay view is the patent is not relevant but, as you always say, every one has to make up their own mind on this. Tom Petch ----- Original Message ----- From: "Ronald Bonica" To: "IPv6 Operations" Sent: Thursday, January 10, 2013 5:30 PM Subject: [v6ops] Mail regarding draft-ietf-v6ops-464xlat > Folks, > > Draft-ietf-v6ops-464xlat is nearly ready for IESG approval. However, several IESG members, including me, are concerned that the WG has not yet considered the IPR declaration attached to this document. > > So, I will wait one more week before approving this document. If you are concerned about the IPR declaration, please post a message describing your concerns to the list. If no such concerns are posted, I will approve the draft on January 17. > > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf From sm@resistor.net Fri Jan 11 01:59:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502AF21F8845 for ; Fri, 11 Jan 2013 01:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38pM9haO52OD for ; Fri, 11 Jan 2013 01:59:00 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3CB21F884F for ; Fri, 11 Jan 2013 01:59:00 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0B9wsuc011168; Fri, 11 Jan 2013 01:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357898338; bh=ol1l5rOfKbkCOYNnl5LYD8bpdGRZTvTyva7j8og7c+4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MlV/r5kEpceDRJm6p5pkOiYtCW/edfHKVA5InID6LWnD4Nx1YkFmKn8aqrkpXIf+Y xB2A+LdZ0wtjSftHh4Dl3EUarMi4/YFF1yST4mGahAyKNnpSe05VD8InikuTv2z1fU RmhH++cDp0YYYb/RC2NR7AgWUHxDvD47622t8N9M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357898338; i=@resistor.net; bh=ol1l5rOfKbkCOYNnl5LYD8bpdGRZTvTyva7j8og7c+4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ititr3SLRhzlEXesg/yEb2MZybs1f+G8Ks1bbfmCpG2pE4zWMlIuzDe3E29ayR2d2 lARd3GHF2tntJFUyn6QZyfthrYnIDPS1bknTFNM1D7GiamVLPXbizaUr1DwCVDfrrG +/doOnoKxG+DPBUB1L4r64n8zpTxmEHFoijDLVwo= Message-Id: <6.2.5.6.2.20130110232419.0a313a48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Jan 2013 23:38:31 -0800 To: Ronald Bonica From: SM In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.n amprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:59:02 -0000 At 09:30 10-01-2013, Ronald Bonica wrote: >So, I will wait one more week before approving this document. If you >are concerned about the IPR declaration, please post a message >describing your concerns to the list. If no such concerns are >posted, I will approve the draft on January 17. The IPR disclosure at https://datatracker.ietf.org/ipr/1730/ is not IETF-friendly [1]. It's an incentive to avoid draft-ietf-v6ops-464xlat-08. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg76730.html From internet-drafts@ietf.org Fri Jan 11 02:32:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2547621F870E; Fri, 11 Jan 2013 02:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rod0Uv0QQljT; Fri, 11 Jan 2013 02:32:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6935521F8233; Fri, 11 Jan 2013 02:32:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130111103213.31931.90112.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 02:32:13 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:32:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Guidance for Internet Content and Application Servi= ce Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-v6ops-icp-guidance-05.txt Pages : 25 Date : 2013-01-11 Abstract: This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers, or to any enterprise network preparing for IPv6 users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-icp-guidance-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Fri Jan 11 02:36:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8435521F88C7 for ; Fri, 11 Jan 2013 02:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.085 X-Spam-Level: X-Spam-Status: No, score=-100.085 tagged_above=-999 required=5 tests=[AWL=-1.164, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLVqqqmHE3Hs for ; Fri, 11 Jan 2013 02:36:42 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BC52E21F88BD for ; Fri, 11 Jan 2013 02:36:41 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so1881752wib.1 for ; Fri, 11 Jan 2013 02:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hf3N9tai5ZKabb+/49sxVLy728eYZAoByH7BdLfSRRM=; b=befriRi49rg/stxemDOjCnEyi1XlwDDIsCxrqsXJBMNa2/1GjH21Jph4RFDdiTCcQd jU2M9Th/Rar7DhESZrh3jxiITCbYuiM/Kh0IzYTzmizVwRb8faU0b8yMM8YsChG0IZkt qxY3zUEEzFDnEBgsaTI3Te9TnuAx0D6dc/0b8SQu1raE6dBnIkL91x7ry6jVEoNp679m rJo9y5ubzWnpfcTqAOG0Et0qVEVxdQ8HMkANBvZK65M9WDIvwzcFKlLaZGC6UYBHHPCY sUk8giCmnfckpzssVE+P+PNfh36y89rbV5HJu245glGhua/8E4AmBk3jrs8WZyhV9krb x5rA== X-Received: by 10.180.109.201 with SMTP id hu9mr14221526wib.32.1357900600659; Fri, 11 Jan 2013 02:36:40 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-120.as13285.net. [2.102.216.120]) by mx.google.com with ESMTPS id fv2sm12239353wib.4.2013.01.11.02.36.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 02:36:39 -0800 (PST) Message-ID: <50EFEB44.1000209@gmail.com> Date: Fri, 11 Jan 2013 10:36:52 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <20130111103213.31931.90112.idtracker@ietfa.amsl.com> In-Reply-To: <20130111103213.31931.90112.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:36:42 -0000 This version has minor updates following IESG review. Regards Brian On 11/01/2013 10:32, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : IPv6 Guidance for Internet Content and Application Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-v6ops-icp-guidance-05.txt > Pages : 25 > Date : 2013-01-11 > > Abstract: > This document provides guidance and suggestions for Internet Content > Providers and Application Service Providers who wish to offer their > service to both IPv6 and IPv4 customers. Many of the points will > also apply to hosting providers, or to any enterprise network > preparing for IPv6 users. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From warren@kumari.net Fri Jan 11 07:24:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5BD21F896B for ; Fri, 11 Jan 2013 07:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqAzQvVsvh3E for ; Fri, 11 Jan 2013 07:24:55 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCA721F8949 for ; Fri, 11 Jan 2013 07:24:54 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 8B75F1B407DD; Fri, 11 Jan 2013 10:24:53 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <50EFD38E.10901@gmail.com> Date: Fri, 11 Jan 2013 10:24:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> <50EFD38E.10901@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations , Hui Deng Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:24:55 -0000 On Jan 11, 2013, at 3:55 AM, Brian E Carpenter = wrote: > On 11/01/2013 01:23, Cameron Byrne wrote: >> Hui, Deng and v6ops, >>=20 >> On Thu, Jan 10, 2013 at 4:41 PM, Randy Bush wrote: >>> thanks for the flag, ron. imiho >>>=20 >>> "Reasonable and Non-Discriminatory License to All Implementers with >>> Possible Royalty/Fee." >>>=20 >>> is a pretty much a show-stopper >>>=20 >>=20 >>=20 >> As you can see, we have a problem. The IESG only has this final IPR >> issue to resolve before publishing 464XLAT. >>=20 >> I see a few ways forward: >>=20 >> 1. China Mobile can grant free use for the benefit of the IETF and >> the benefit of global IPv6 adoption and on-going evolution of the >> Internet >>=20 >> 2. The IETF can move forward on the basis that the IPR claim is = invalid*. >>=20 >> 3. Other options??? >=20 > 4. The IETF can move forward because its rules allow RAND conditions. Yes, the IETF *can* move forward, but *can* also decide that the IPR is = annoying, discourages implementation, and makes possible risks for = implements, and so it *can* (I believe) decide not to move forward. Not saying that it should do this, but.. >=20 > There are innumerable IETF standards with RAND disclosures against = them. > We may not like it, but we do it all the time. >=20 Yes, yes we do. We also sometimes decide to choose other, non-encumbered = options. > The summary of the claims (http://ip.com/patfam/en/43370583) is > very broad. Judging by that, if this disclosure was required, a = disclosure > against draft-huang-behave-bih or RFC 6535 would also have been = required. > However, the prior art for that goes back to RFC 2767, which is way = before > this recent patent. >=20 > It isn't the IETF's job to determine whether a patent is valid. But if > we have a strong inclination to believe it's invalid, and the = disclosure > in any case meets our rules, we can . It's then for = implementors > to decide what to do. >=20 > Brian IANAL, nor do I pretend to play one on TV,=20 W >=20 >>=20 >> Regards, >>=20 >> CB >>=20 >> *I am not a lawyer, but the 464XLAT draft is just a combination of >> existing technologies, none of which has IPR. And, AFAIK [1], it is >> not legitimate to patent a combination of existing technologies .... >> which is what the IPR claim is. NAT-PT goes back to the year 2000 as = prior art. >>=20 >> So, simple analysis, says this patent is not valid. Yet, we have = this claim. >>=20 >> CB >>=20 >> [1] -- = http://www.nolo.com/legal-encyclopedia/combination-invention-patentable-pa= tents-29891.html >> _______________________________________________ >> 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 I had no shoes and wept. Then I met a man who had no feet. So I said, = "Hey man, got any shoes you're not using?"=20 From rbonica@juniper.net Fri Jan 11 08:11:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B669321F88BC for ; Fri, 11 Jan 2013 08:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.981 X-Spam-Level: X-Spam-Status: No, score=-102.981 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAaD+2P79Fge for ; Fri, 11 Jan 2013 08:11:24 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8973421F88B9 for ; Fri, 11 Jan 2013 08:11:14 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUPA5ohm0EWdFvEZFjdsWYtYZ+mAus3Ck@postini.com; Fri, 11 Jan 2013 08:11:14 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 11 Jan 2013 08:07:39 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 11 Jan 2013 08:07:38 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.142) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 11 Jan 2013 08:09:39 -0800 Received: from mail76-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 11 Jan 2013 16:07:36 +0000 Received: from mail76-db3 (localhost [127.0.0.1]) by mail76-db3-R.bigfish.com (Postfix) with ESMTP id 891832003A1 for ; Fri, 11 Jan 2013 16:07:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zz9371I542I1432I1447Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail76-db3 (localhost.localdomain [127.0.0.1]) by mail76-db3 (MessageSwitch) id 1357920455294961_6223; Fri, 11 Jan 2013 16:07:35 +0000 (UTC) Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.240]) by mail76-db3.bigfish.com (Postfix) with ESMTP id 3E6ED80045; Fri, 11 Jan 2013 16:07:35 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 11 Jan 2013 16:07:35 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.240]) by BY2PRD0512HT001.namprd05.prod.outlook.com ([10.255.243.34]) with mapi id 14.16.0257.004; Fri, 11 Jan 2013 16:07:34 +0000 From: Ronald Bonica To: Randy Bush , IPv6 Operations Thread-Topic: [v6ops] Mail regarding draft-ietf-v6ops-464xlat Thread-Index: Ac3vWD2oX+jwqLZ3Tcq/T8uiYQotagAPCfMAACBOLHA= Date: Fri, 11 Jan 2013 16:07:33 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E2FA9E@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%PSG.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:11:25 -0000 Randy, Ack. I will hold my DISCUSS on this document until the issue is resolved. Ron > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, January 10, 2013 7:41 PM > To: Ronald Bonica > Cc: IPv6 Operations > Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat >=20 > thanks for the flag, ron. imiho >=20 > "Reasonable and Non-Discriminatory License to All Implementers with > Possible Royalty/Fee." >=20 > is a pretty much a show-stopper >=20 > randy From fgont@si6networks.com Fri Jan 11 08:54:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91B721F8838 for ; Fri, 11 Jan 2013 08:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTC2nb8W8a9Z for ; Fri, 11 Jan 2013 08:54:58 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id A619721F88E2 for ; Fri, 11 Jan 2013 08:54:56 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TthsW-0007t3-7G; Fri, 11 Jan 2013 17:54:48 +0100 Message-ID: <50F043D0.9020703@si6networks.com> Date: Fri, 11 Jan 2013 13:54:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPv6 Operations References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> In-Reply-To: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:54:59 -0000 Folks, We have published a revision of our I-D entitled "Security Implications of IPv6 options of Type 10xxxxxx", about IPv6 smurf amplifiers. The I-D is available at: . The I-D is targeted at the 6man wg, but I thought it might be of interest to v6ops folks, too. Any comments will be very appreciated. Thanks! Best regards, Fernando -------- Original Message -------- From: - Fri Jan 11 13:40:47 2013 From: internet-drafts@ietf.org To: fgont@si6networks.com Cc: liushucheng@huawei.com Subject: New Version Notification for draft-gont-6man-ipv6-smurf-amplifier-01.txt Message-ID: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 08:40:12 -0800 A new version of I-D, draft-gont-6man-ipv6-smurf-amplifier-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-ipv6-smurf-amplifier Revision: 01 Title: Security Implications of IPv6 options of Type 10xxxxxx Creation date: 2013-01-11 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-01.txt Status: http://datatracker.ietf.org/doc/draft-gont-6man-ipv6-smurf-amplifier Htmlized: http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-smurf-amplifier-01 Abstract: When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector. The IETF Secretariat From sarikaya2012@gmail.com Fri Jan 11 13:42:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7202F21F8956 for ; Fri, 11 Jan 2013 13:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T15hndm8aZZQ for ; Fri, 11 Jan 2013 13:42:10 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 89ACB21F894C for ; Fri, 11 Jan 2013 13:42:05 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so2243704lab.15 for ; Fri, 11 Jan 2013 13:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ChVE3IWrFznfHk9thnQi7jx9fAdwBFi1+rT+hxehMBw=; b=QzRNdLN2/+DinTr4j+hOjO8oxZXZWfClfyMrmsYwXcBpuR/x4Ll0Mn1wvG2d99cv0w ofzRoZcFDeX7R/Ji1yt6trI5vCMxei/VLDU4pQZVSnzR5srqjOSOsMZR8WZH5TqYHANL mbTawXT2wNaYjAc9UG7Ep8oFyhYkPSZSlFU79GIglTQe4+uXbGweRTrFOPToX+HNciPR WzszSb7kJ6HaAe8njq6WTcRijGIvUYY686I5KuoIpVkVFa7AlEn1JNEEAZDX6V4BT8HX 1cJVP/LatClmQW4dnP5ck92P2Z5uvT1LulizsxGwfZcfE954XfzQNmoTQUbGXCm68WQa bPYg== MIME-Version: 1.0 Received: by 10.152.162.1 with SMTP id xw1mr74742428lab.3.1357940524341; Fri, 11 Jan 2013 13:42:04 -0800 (PST) Received: by 10.114.78.37 with HTTP; Fri, 11 Jan 2013 13:42:04 -0800 (PST) In-Reply-To: <50EFD38E.10901@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> <50EFD38E.10901@gmail.com> Date: Fri, 11 Jan 2013 15:42:04 -0600 Message-ID: From: Behcet Sarikaya To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d042ef4a594588a04d30a2a09 Cc: IPv6 Operations Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:42:12 -0000 --f46d042ef4a594588a04d30a2a09 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 11, 2013 at 2:55 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > It isn't the IETF's job to determine whether a patent is valid. But if > we have a strong inclination to believe it's invalid, and the disclosure > in any case meets our rules, we can . It's then for implementors > to decide what to do. > > + 1 Behcet --f46d042ef4a594588a04d30a2a09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 11, 2013 at 2:55 AM, Brian E= Carpenter <brian.e.carpenter@gmail.com> wrote:

It isn't the IETF's job to determine whether a patent is valid. But= if
we have a strong inclination to believe it's invalid, and the disclosur= e
in any case meets our rules, we can <shrug>. It's then for implem= entors
to decide what to do.


+ 1

Behcet
--f46d042ef4a594588a04d30a2a09-- From joelja@bogus.com Sat Jan 12 07:28:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E90421F84C2 for ; Sat, 12 Jan 2013 07:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvPf4MGpanEq for ; Sat, 12 Jan 2013 07:28:01 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F2CCD21F84BA for ; Sat, 12 Jan 2013 07:28:00 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0CFRucX011739 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 12 Jan 2013 15:27:56 GMT (envelope-from joelja@bogus.com) Message-ID: <50F180F7.5090602@bogus.com> Date: Sat, 12 Jan 2013 07:27:51 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20130111103213.31931.90112.idtracker@ietfa.amsl.com> <50EFEB44.1000209@gmail.com> In-Reply-To: <50EFEB44.1000209@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 Jan 2013 15:27:56 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 15:28:01 -0000 No major complaints... I would note that the section: Is extra memory or ternary content-addressable memory (TCAM) space needed to accommodate both IPv4 and IPv6 tables? To answer these questions, the ICP will need a projected model for the amount of IPv6 traffic expected initially, and its likely rate of increase. Appears If I'm reading it correctly to conflate fib memory with traffic volume, when in fact it's prefix count that's the issue for fib sizing. On 1/11/13 2:36 AM, Brian E Carpenter wrote: > This version has minor updates following IESG review. > > Regards > Brian > > On 11/01/2013 10:32, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working Group of the IETF. >> >> Title : IPv6 Guidance for Internet Content and Application Service Providers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-ietf-v6ops-icp-guidance-05.txt >> Pages : 25 >> Date : 2013-01-11 >> >> Abstract: >> This document provides guidance and suggestions for Internet Content >> Providers and Application Service Providers who wish to offer their >> service to both IPv6 and IPv4 customers. Many of the points will >> also apply to hosting providers, or to any enterprise network >> preparing for IPv6 users. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-05 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-05 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sat Jan 12 07:45:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11F821F881A for ; Sat, 12 Jan 2013 07:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-Iz0oJb3amg for ; Sat, 12 Jan 2013 07:45:44 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 68EC021F8816 for ; Sat, 12 Jan 2013 07:45:44 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0CFjhZl011928 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 12 Jan 2013 15:45:43 GMT (envelope-from joelja@bogus.com) Message-ID: <50F18523.2000208@bogus.com> Date: Sat, 12 Jan 2013 07:45:39 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 Jan 2013 15:45:44 +0000 (UTC) Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] Meetecho at V6OPS meetings? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 15:45:45 -0000 On 11/8/12 1:16 PM, Philip Matthews wrote: > At the Large Interim Meeting, there was Meetecho support for the V6OPS session, and I used it and found it fairly easy to use to follow the meeting. (As well as anyone can follow a meeting remotely). > > I notice that there is no support for the Atlanta sessions. > > I don't know what is involved, but I am just wondering if we could get Meetecho support for the V6OPS Orlando meeting? I will request this. > - Philip > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sat Jan 12 08:46:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D869321F8790 for ; Sat, 12 Jan 2013 08:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1oP-Ju3PUqp for ; Sat, 12 Jan 2013 08:46:07 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18721F8765 for ; Sat, 12 Jan 2013 08:46:06 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id x10so1352715wey.19 for ; Sat, 12 Jan 2013 08:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9e/XTqcZr7Gc4fnio7417YSG2iyXsh2JdeTkvPS2HlI=; b=XYFlnC0l1YH86lRxpAxKuP++EHknzGrD5DJemYD1J8fkgo2IMLsKDUcUBRHe1TjWRQ fnUsDhe6O9WovoANwf1LTRm8omKQGqNQY0HqgFhnS6kmO2ji+jv+CfFYXLiacl8hHAmB 3PqejnqUqyG4BCF0reACoTUl7ZKy+4kn6dWQ0sbI+T8eH4Nlv3Qk2HzMNKK8+jlzYsmz sfyK3L4RiV6dBcC6Y6I9aU8ALoNMBaGir2UnMvw7MclVUUEYoHiMaU3O2Mk8UYxamBLd +GQ03N92oDX/0S7mRb8WMJwaaT7W9Jt6c+xjkUp/1/9qjLEl1OXibJJ6CA53YcBrY83J ymTA== X-Received: by 10.194.9.197 with SMTP id c5mr127154688wjb.20.1358009165643; Sat, 12 Jan 2013 08:46:05 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-89.as13285.net. [2.101.188.89]) by mx.google.com with ESMTPS id w5sm4367753wif.11.2013.01.12.08.46.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jan 2013 08:46:04 -0800 (PST) Message-ID: <50F1935C.9070103@gmail.com> Date: Sat, 12 Jan 2013 16:46:20 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <20130111103213.31931.90112.idtracker@ietfa.amsl.com> <50EFEB44.1000209@gmail.com> <50F180F7.5090602@bogus.com> In-Reply-To: <50F180F7.5090602@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 16:46:08 -0000 On 12/01/2013 15:27, joel jaeggli wrote: > No major complaints... > > I would note that the section: > > Is > extra memory or ternary content-addressable memory (TCAM) space > needed to accommodate both IPv4 and IPv6 tables? To answer these > questions, the ICP will need a projected model for the amount of IPv6 > traffic expected initially, and its likely rate of increase. > > > Appears If I'm reading it correctly to conflate fib memory with traffic > volume, when in fact it's prefix count that's the issue for fib sizing. Hmm. The diffs don't necessarily make this very clear to read. "These questions" is supposed to refer back to the two previous questions about performance. I'll make a note to fix this by re-ordering the sentences at AUTH48. Thanks Brian > > On 1/11/13 2:36 AM, Brian E Carpenter wrote: >> This version has minor updates following IESG review. >> >> Regards >> Brian >> >> On 11/01/2013 10:32, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IPv6 Operations Working Group of >>> the IETF. >>> >>> Title : IPv6 Guidance for Internet Content and >>> Application Service Providers >>> Author(s) : Brian Carpenter >>> Sheng Jiang >>> Filename : draft-ietf-v6ops-icp-guidance-05.txt >>> Pages : 25 >>> Date : 2013-01-11 >>> >>> Abstract: >>> This document provides guidance and suggestions for Internet Content >>> Providers and Application Service Providers who wish to offer their >>> service to both IPv6 and IPv4 customers. Many of the points will >>> also apply to hosting providers, or to any enterprise network >>> preparing for IPv6 users. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-05 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-05 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From markzzzsmith@yahoo.com.au Mon Jan 14 11:09:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959E921F8B02 for ; Mon, 14 Jan 2013 11:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYqPoj9XP5VS for ; Mon, 14 Jan 2013 11:09:39 -0800 (PST) Received: from nm2.bullet.mail.bf1.yahoo.com (nm2.bullet.mail.bf1.yahoo.com [98.139.212.161]) by ietfa.amsl.com (Postfix) with SMTP id 70EF821F8AE0 for ; Mon, 14 Jan 2013 11:09:39 -0800 (PST) Received: from [98.139.212.144] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jan 2013 19:09:38 -0000 Received: from [98.139.212.196] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jan 2013 19:09:38 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 14 Jan 2013 19:09:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 660082.27746.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 44853 invoked by uid 60001); 14 Jan 2013 19:09:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1358190578; bh=V+0lFHGE3WoiYV9/sq5uUzDkaKZzbAqwY1UBuYShZdQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DVrXShNthAjERLRUuk+oMpP3jRBZLtTPOpyylJ9uF0xbJ+iCbL8UX6quHV1I6ocI1C9ssW/GX6CiaZ4DUc0cgksOc8iypXr2iUSaxZJ7foXhjO+qURDRTJZrGQPrkUTJMKdT1iM2lWQm4JDC/waRidpyY27TX6Eglk7BDqWMt3s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FkAqCTWCc+5zWFzK9YHLuLb1Og04zYMQ+HWxm6LhhniY2jgOXUDOU8nrq3En1Tn6lZ0Pr+gvbiZ9GvXSSLP5c/bdaMfMbjVMve+X4A8bZJUYMoxw9pfnv6xmZtMq3EsmwqVCjOQw0e0xa4w4i8PWCjm0VSGxPkvfFEdJN4Kejb4=; X-YMail-OSG: hsDZ.F4VM1mQ65gU5Mn2OIrObLwiOQ.Cg3dDJ4RED2thX1N yE3u_bIGvCYIqOM1ywBxAF234JvMWee2uQBSaKCVLnVHzBz7NMn6I8wv67Hh sM81Ddh2b3avx1S_oK2WvCtyab6Oy.Tnn3J.DvrLABq4c9_AVBkRG7njdV34 gG5pYJSoFyqfc4Slcz3YNGOoRmNoOR8BXCwR6qCtFcmOYViBaGQr1SQZZNfj wZu4Bo0msMufcPyffkTfDUAfFOIjxllfp33MZtpdAci_Pfboa5KH.iFT8boN rFXaarWp412R5fPmwI2ZmQm_AxMhm7Ei.87ytRIdLImGE9ikQyIe80WcElm_ L5ghNyhDCIpJx_AOHxN8yYlQ8Y5luQGw0zhJ_yIDMRZyR3JO576B9_21p8Lc nXztpIa80y.jdjCKJwC1WIrXq7rUbRhoGhBYHQnO2.0XQNpjNgDFaF0w4tgB UmqADIv887TrTidJ6IKXAj6JZfwD4BRDz73OpPsk1wSGkF5jACPjr43NwS0R fvdND9jwLZ8_y.EDByxG_Tm._ Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Mon, 14 Jan 2013 11:09:38 PST X-Rocket-MIMEInfo: 001.001, SGksCgpJJ3ZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgbXkgbGFyZ2VyIGxvb3BiYWNrIHByZWZpeCBmb3IgSVB2NiBkcmFmdC4KCkNoYW5nZXMgc2luY2UgdGhlIHByZXZpb3VzIHZlcnNpb246CgrCoCDCoG8gwqBjbGFyaWZpY2F0aW9uIHRoYXQgdGhlIGxhcmdlciBsb29wYmFjayBwcmVmaXggc2hvdWxkIGZhbGwgd2l0aGluCsKgIMKgIMKgIDo6LzgsIHRoZSBwYXJlbnQgcHJlZml4IG9mIDo6LzEyOCBhbmQgOjoxLzEyOAoKwqAgwqBvIMKgQ2hhbmdlIGZyb20gMTo6LzQ4IHRvIDE6Oi8zMgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <20130114190136.19933.71277.idtracker@ietfa.amsl.com> Message-ID: <1358190578.44544.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 14 Jan 2013 11:09:38 -0800 (PST) From: Mark Smith To: v6ops v6ops WG In-Reply-To: <20130114190136.19933.71277.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:09:40 -0000 Hi,=0A=0AI've just submitted a new version of my larger loopback prefix for= IPv6 draft.=0A=0AChanges since the previous version:=0A=0A=A0 =A0o =A0clar= ification that the larger loopback prefix should fall within=0A=A0 =A0 =A0 = ::/8, the parent prefix of ::/128 and ::1/128=0A=0A=A0 =A0o =A0Change from = 1::/48 to 1::/32=0A=0A=A0 =A0o =A0text about logically assigning addresses = to interface(s), as per=0A=A0 =A0 =A0 IPv6 addressing model=0A=0A=A0 =A0o = =A0automatic loopback address configuration to multiple loopback=0A=A0 =A0 = =A0 interfaces=0A=0A=A0 =A0o =A0local serving of 0.0.0.1.0.0.0.IP6.ARPA zon= e in DNS=0A=0AMy thanks to the various reviewers and commenters on the prev= ious versions. Further review and comments much appreciated.=0A=0A=0AThanks= ,=0AMark.=0A=0A=0A=0A----- Forwarded Message -----=0A> From: "internet-draf= ts@ietf.org" =0A> To: markzzzsmith@yahoo.com.au= =0A> Cc: =0A> Sent: Tuesday, 15 January 2013 6:01 AM=0A> Subject: New Versi= on Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-02.txt=0A= > =0A> =0A> A new version of I-D, draft-smith-v6ops-larger-ipv6-loopback-pr= efix-02.txt=0A> has been successfully submitted by Mark Smith and posted to= the=0A> IETF repository.=0A> =0A> Filename:=A0=A0=A0 draft-smith-v6ops-la= rger-ipv6-loopback-prefix=0A> Revision:=A0=A0=A0 02=0A> Title:=A0=A0=A0 = =A0=A0=A0 A Larger Loopback Prefix for IPv6=0A> Creation date:=A0=A0=A0 2= 013-01-14=0A> WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission=0A> Number o= f pages: 10=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/intern= et-drafts/draft-smith-v6ops-larger-ipv6-loopback-prefix-02.txt=0A> Status:= =A0 =A0 =A0 =A0 =A0 =0A> http://datatracker.ietf.org/doc/draft-smith-v6ops-= larger-ipv6-loopback-prefix=0A> Htmlized:=A0 =A0 =A0 =A0 =0A> http://tools.= ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-02=0A> Diff:=A0= =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6= ops-larger-ipv6-loopback-prefix-02=0A> =0A> Abstract:=0A> =A0 During the d= evelopment and testing of a network application, it can=0A> =A0 be useful = to run multiple instances of the application using the same=0A> =A0 transp= ort layer protocol port on the same development host, while=0A> =A0 also h= aving network access to the application instances limited to=0A> =A0 the l= ocal host.=A0 Under IPv4, this has been possible by using=0A> =A0 differen= t loopback addresses within 127/8.=A0 It is not possible under=0A> =A0 IPv= 6, as the loopback prefix of ::1/128 only provides a single=0A> =A0 loopba= ck address.=A0 This memo proposes a new larger loopback prefix=0A> =A0 tha= t will provide many loopback IPv6 addresses.=0A> =0A> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 = =0A> =0A> =0A> The IETF Secretariat=0A> From iesg-secretary@ietf.org Mon Jan 14 12:23:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2A721F86C4; Mon, 14 Jan 2013 12:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgbTXraQF-tE; Mon, 14 Jan 2013 12:23:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE4E21F8906; Mon, 14 Jan 2013 12:23:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114202303.6130.49369.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 12:23:03 -0800 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'IPv6 Guidance for Internet Content and Application Service Providers' to Informational RFC (draft-ietf-v6ops-icp-guidance-05.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:23:04 -0000 The IESG has approved the following document: - 'IPv6 Guidance for Internet Content and Application Service Providers' (draft-ietf-v6ops-icp-guidance-05.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance/ Technical Summary: This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers, or to any enterprise network preparing for IPv6 users. Working Group Summary: The working group, while it made comments that improved the document, found it uncontroversial. Document Quality: The document is a set of recommendations. It has the support of the operators in the working group. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? The document shepherd is Joel Jaeggli. The area director is Ron Bonica. From joelja@bogus.com Wed Jan 16 15:14:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96BA11E80EC for ; Wed, 16 Jan 2013 15:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anudEk5swMQs for ; Wed, 16 Jan 2013 15:14:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5D011E809A for ; Wed, 16 Jan 2013 15:14:37 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0GNEajg075733 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 16 Jan 2013 23:14:37 GMT (envelope-from joelja@bogus.com) Message-ID: <50F73457.6030107@bogus.com> Date: Wed, 16 Jan 2013 15:14:31 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 16 Jan 2013 23:14:37 +0000 (UTC) Subject: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:14:38 -0000 So, previously on v6ops https://datatracker.ietf.org/ipr/1730/ Was asserted prior to WGLC on https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ Commentary prior to the WGLC was largely limited to not being able to reasonably evaluate the assertions made in the disclosure. In the IESG evaluation the question of whether that is sufficent came up. Reexamining this issue reveals a greater diversity of opinions my own included than are represented prior to or during the WGLC or the document shepherds reports. To paraphrase the opinions I heard, our options look like: 1. The assertion is problematic, particulary with the terms applied and the draft should therefore be abandoned unless something changes. 2. We belive that the ipr assertion is invalid, either on the basis of the claims, or the existance of prior art, and it's existance is not therefore problematic. There are probably variations of number 2 (the question of is there new IPR at all in 464xlat for example) but making it binary I think is important given that the decision is whether to publish or not. We had a strong concensus to send this to the IESG, I would appreciate more input for or against this proposition. Thanks joel From Ted.Lemon@nominum.com Wed Jan 16 15:23:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA311E80E2 for ; Wed, 16 Jan 2013 15:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kXsnzG1zFh5 for ; Wed, 16 Jan 2013 15:23:26 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5F711E809C for ; Wed, 16 Jan 2013 15:23:26 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUPc2brh2nEThXNOCOVfml/dGZQs2jBbw@postini.com; Wed, 16 Jan 2013 15:23:26 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EAA581B8236 for ; Wed, 16 Jan 2013 15:23:23 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E02CC190052; Wed, 16 Jan 2013 15:23:23 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 15:23:24 -0800 From: Ted Lemon To: joel jaeggli Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. Thread-Index: AQHN9D9IDDGxdgTCH0a8nwTDd14C+phNHpKA Date: Wed, 16 Jan 2013 23:23:23 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com> References: <50F73457.6030107@bogus.com> In-Reply-To: <50F73457.6030107@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <09FD657073DEAE468FD3F07466F0D5CC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:23:28 -0000 On Jan 16, 2013, at 3:14 PM, joel jaeggli wrote: > 2. We belive that the ipr assertion is invalid, either on the basis of th= e claims, or the existance of prior art, and it's existance is not therefo= re problematic. This is just bad reasoning. If someone has asserted IPR under unacceptabl= e terms (which I am not claiming to judge), then it doesn't matter whether = the IPR in question is potentially invalidatable until someone spends the m= oney to invalidate it. Until then, bogus though it may be, we (the IETF) = have to treat it as if it were enforceable, because history has shown us th= at it probably is. From joelja@bogus.com Wed Jan 16 15:42:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAC511E80E2 for ; Wed, 16 Jan 2013 15:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SyZNPvV8ipR for ; Wed, 16 Jan 2013 15:42:34 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A651511E809C for ; Wed, 16 Jan 2013 15:42:34 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0GNgXdF076079 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 16 Jan 2013 23:42:34 GMT (envelope-from joelja@bogus.com) Message-ID: <50F73AE4.4010203@bogus.com> Date: Wed, 16 Jan 2013 15:42:28 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Ted Lemon References: <50F73457.6030107@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 16 Jan 2013 23:42:34 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:42:35 -0000 On 1/16/13 3:23 PM, Ted Lemon wrote: > On Jan 16, 2013, at 3:14 PM, joel jaeggli wrote: >> 2. We belive that the ipr assertion is invalid, either on the basis of the claims, or the existance of prior art, and it's existance is not therefore problematic. > This is just bad reasoning. If someone has asserted IPR under unacceptable terms (which I am not claiming to judge), then it doesn't matter whether the IPR in question is potentially invalidatable until someone spends the money to invalidate it. The opinion of potential implementers or consumers is certainly Germain. I am not in a position to usefully evaluate the merit of the claim. > Until then, bogus though it may be, we (the IETF) have to treat it as if it were enforceable, because history has shown us that it probably is. In fact the question of whether or not it is enforceable is something that implementers or consumers of the technology have to consider. If it is then it certainly has implications for other ietf documents for which IPR disclusures have not be asserted, RFC 6145/6/7 which are the source material for draft-ietf-v6ops-464xlat for example. > > From brian.e.carpenter@gmail.com Wed Jan 16 23:55:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D737A21F8959 for ; Wed, 16 Jan 2013 23:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.091 X-Spam-Level: X-Spam-Status: No, score=-100.091 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOj6dEdEyEVn for ; Wed, 16 Jan 2013 23:55:00 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA5F21F8951 for ; Wed, 16 Jan 2013 23:54:59 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hq12so4341881wib.0 for ; Wed, 16 Jan 2013 23:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VHnpb4fqCvkA+pGru1D9bPpqmRaiunbXdOg6hWpBhI0=; b=JlR7rgS4jY3RAFSB6ieRZHah+bilesOB3clyuBK0kCX+/D14mgrYM5YE+S1iKpHyHd 6Mb482VFbJOLeEeHVtSkqCDqRkJy7RboOWWLxZW5+Fk+TAqHv9pyH2+y96qjMNHIloS+ 7nOTy5r2nZh8Vo6W87Esbk0Bb6mS+tDHX6GBm9MhMYpteVMwkWK+72VtceIJdIlAT9nk acH1AfdPiCI9O/nPgjKNbWkyHq6WBU8ABJgsHXnU2HEB10p3joCT31ewh5slUZBu08EF v8dMsElGwZdJtxgCRoNcr61b5rKCYAAh3zBaY8crV0TSyFJgyq2AAjio4ziRQmyzq/QJ RhFQ== X-Received: by 10.180.107.97 with SMTP id hb1mr14237531wib.4.1358409299315; Wed, 16 Jan 2013 23:54:59 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-247.as13285.net. [2.102.219.247]) by mx.google.com with ESMTPS id hg17sm11776628wib.1.2013.01.16.23.54.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 23:54:58 -0800 (PST) Message-ID: <50F7AE5B.1020208@gmail.com> Date: Thu, 17 Jan 2013 07:55:07 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <50F73457.6030107@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 07:55:00 -0000 On 16/01/2013 23:23, Ted Lemon wrote: > On Jan 16, 2013, at 3:14 PM, joel jaeggli wrote: >> 2. We belive that the ipr assertion is invalid, either on the basis of the claims, or the existance of prior art, and it's existance is not therefore problematic. > > This is just bad reasoning. If someone has asserted IPR under unacceptable terms (which I am not claiming to judge), then it doesn't matter whether the IPR in question is potentially invalidatable until someone spends the money to invalidate it. Until then, bogus though it may be, we (the IETF) have to treat it as if it were enforceable, because history has shown us that it probably is. That's correct. The question is more whether the WG is OK with the RAND conditions attached to the claimed IPR. Personally I think that there is no particular reason to block the document, because (a) the IETF often accepts RAND conditions and (b) this technology is one among many IPv4/IPv6 coexistence solutions, so this is not a blocking problem anyway. The fact that the IPR looks flaky to some of us is an added argument, but not the main one. Brian From tjc@ecs.soton.ac.uk Thu Jan 17 02:20:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3121F8933 for ; Thu, 17 Jan 2013 02:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VaDgen5CFWJ for ; Thu, 17 Jan 2013 02:20:54 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 302BB21F892D for ; Thu, 17 Jan 2013 02:20:54 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r0HAKo0D029504 for ; Thu, 17 Jan 2013 10:20:50 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r0HAKo0D029504 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1358418050; bh=pH9wZRJ1CGA5O/6L6fHim+jTAxg=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=1Q2WjGuyIQF6YaxKPUjnJpuu2qFTXBrAASL/hBukWCV9X1TZY+dpKSAfbqeTNVPuh MGpCjZhcr3pigQFF2FhJrQaoGkqbyHK9WnJfZgCKnTDur/+WLLvXgP6TEP2As2/zOl WEtrYFWsaxjrofw5OXNw3FaBheXyVneOwUlrb6VE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p0GAKo0430663699EA ret-id none; Thu, 17 Jan 2013 10:20:50 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r0HAKlLF007802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Jan 2013 10:20:47 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <50F7AE5B.1020208@gmail.com> Date: Thu, 17 Jan 2013 10:20:49 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50F73457.6030107@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com> <50F7AE5B.1020208@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p0GAKo043066369900; tid=p0GAKo0430663699EA; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r0HAKo0D029504 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:20:56 -0000 On 17 Jan 2013, at 07:55, Brian E Carpenter = wrote: > On 16/01/2013 23:23, Ted Lemon wrote: >> On Jan 16, 2013, at 3:14 PM, joel jaeggli wrote: >>> 2. We belive that the ipr assertion is invalid, either on the basis = of the claims, or the existance of prior art, and it's existance is not = therefore problematic. >>=20 >> This is just bad reasoning. If someone has asserted IPR under = unacceptable terms (which I am not claiming to judge), then it doesn't = matter whether the IPR in question is potentially invalidatable until = someone spends the money to invalidate it. Until then, bogus though it = may be, we (the IETF) have to treat it as if it were enforceable, = because history has shown us that it probably is. >=20 > That's correct. The question is more whether the WG is OK with the = RAND conditions > attached to the claimed IPR. Personally I think that there is no = particular > reason to block the document, because (a) the IETF often accepts RAND = conditions > and (b) this technology is one among many IPv4/IPv6 coexistence = solutions, > so this is not a blocking problem anyway. >=20 > The fact that the IPR looks flaky to some of us is an added argument, = but > not the main one. This is also a BCP, rather than a protocol. It's a 'common practice' = that I believe a number of ISPs are already using, and have done so for = a while. Thus this is perhaps a little different in that it's = documenting what ISPs are already doing. Tim= From Ted.Lemon@nominum.com Thu Jan 17 06:38:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F89121F84DE for ; Thu, 17 Jan 2013 06:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scb306QDQmpk for ; Thu, 17 Jan 2013 06:38:03 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id AA8F921F8425 for ; Thu, 17 Jan 2013 06:38:03 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUPgMy31oPFZ5l0zX8uif00iqJORXOMZU@postini.com; Thu, 17 Jan 2013 06:38:03 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B9D9D1B8176 for ; Thu, 17 Jan 2013 06:38:02 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AAFD2190060; Thu, 17 Jan 2013 06:38:02 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 06:38:02 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. Thread-Index: AQHN9D9IDDGxdgTCH0a8nwTDd14C+phNHpKAgACO+oD//+pF4Q== Date: Thu, 17 Jan 2013 14:38:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747469934@mbx-01.win.nominum.com> References: <50F73457.6030107@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com>, <50F7AE5B.1020208@gmail.com> In-Reply-To: <50F7AE5B.1020208@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:38:04 -0000 > That's correct. The question is more whether the WG is OK with the RAND c= onditions=0A= > attached to the claimed IPR. Personally I think that there is no particul= ar=0A= > reason to block the document, because (a) the IETF often accepts RAND con= ditions=0A= > and (b) this technology is one among many IPv4/IPv6 coexistence solutions= ,=0A= > so this is not a blocking problem anyway.=0A= =0A= I certainly don't see any reason to oppose this in the case of a BCP.= From joelja@bogus.com Thu Jan 17 08:10:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694CC21F85C2 for ; Thu, 17 Jan 2013 08:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC2FqClUafOZ for ; Thu, 17 Jan 2013 08:10:07 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A1DA921F8609 for ; Thu, 17 Jan 2013 08:10:07 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0HG9XEm085645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 17 Jan 2013 16:09:34 GMT (envelope-from joelja@bogus.com) Message-ID: <50F82238.70103@bogus.com> Date: Thu, 17 Jan 2013 08:09:28 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Tim Chown References: <50F73457.6030107@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074746978F@mbx-01.win.nominum.com> <50F7AE5B.1020208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 17 Jan 2013 16:09:34 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:10:08 -0000 On 1/17/13 2:20 AM, Tim Chown wrote: > On 17 Jan 2013, at 07:55, Brian E Carpenter wrote: > >> >> The fact that the IPR looks flaky to some of us is an added argument, but >> not the main one. > This is also a BCP, rather than a protocol. It's a 'common practice' that I believe a number of ISPs are already using, and have done so for a while. Thus this is perhaps a little different in that it's documenting what ISPs are already doing. the protocol work was already done. effectively that was one the tests applied to the question of is this appropriate for v6ops or not. > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From randy@psg.com Thu Jan 17 09:16:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4140B21F8792 for ; Thu, 17 Jan 2013 09:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWgu1iIJCrF2 for ; Thu, 17 Jan 2013 09:16:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEDF21F8684 for ; Thu, 17 Jan 2013 09:16:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tvt4W-0001am-FW; Thu, 17 Jan 2013 17:16:12 +0000 Date: Thu, 17 Jan 2013 07:16:11 -1000 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <50F73457.6030107@bogus.com> References: <50F73457.6030107@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:16:14 -0000 > 2. We belive that the ipr assertion is invalid we are not lawyers. our opinions are not valid. randy From joelja@bogus.com Thu Jan 17 09:43:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7421F86A3 for ; Thu, 17 Jan 2013 09:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8bDcTM4txme for ; Thu, 17 Jan 2013 09:43:18 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3221F860A for ; Thu, 17 Jan 2013 09:43:18 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0HHhHxw086673 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 17 Jan 2013 17:43:18 GMT (envelope-from joelja@bogus.com) Message-ID: <50F83830.5040806@bogus.com> Date: Thu, 17 Jan 2013 09:43:12 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Randy Bush References: <50F73457.6030107@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 17 Jan 2013 17:43:18 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:43:19 -0000 On 1/17/13 9:16 AM, Randy Bush wrote: >> 2. We belive that the ipr assertion is invalid > we are not lawyers. our opinions are not valid. as an individual you make decisions on your own behalf without legal consultation all the time. I believe that your previously expressed position is adequately captured by the first bullet is it not? > randy > From randy@psg.com Thu Jan 17 09:54:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124E721F8794 for ; Thu, 17 Jan 2013 09:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK2NQgzaxd30 for ; Thu, 17 Jan 2013 09:54:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A3F6321F872D for ; Thu, 17 Jan 2013 09:54:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TvtfC-0001hm-1u; Thu, 17 Jan 2013 17:54:06 +0000 Date: Thu, 17 Jan 2013 07:54:05 -1000 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <50F83830.5040806@bogus.com> References: <50F73457.6030107@bogus.com> <50F83830.5040806@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:54:07 -0000 >>> 2. We belive that the ipr assertion is invalid >> we are not lawyers. our opinions are not valid. > as an individual you make decisions on your own behalf without legal > consultation all the time. as an individual, i drink coffee. when participating in a group which is concerned about intake, i do not foist my preference on the group. observe the discussion about frelling cookies. if an individual chooses to use/implement encumbered technology, that is indeed their prerogative. whether the _ietf_ says doing so is a *best* practice should be done a bit more cautiously. > I believe that your previously expressed position is adequately > captured by the first bullet is it not? yes. so? i am questioning the advisability of the second position. randy From joelja@bogus.com Thu Jan 17 10:24:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E5D21F883E for ; Thu, 17 Jan 2013 10:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN9LJEEk+wyt for ; Thu, 17 Jan 2013 10:24:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C787021F87FB for ; Thu, 17 Jan 2013 10:24:27 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0HIOR0M087236 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 17 Jan 2013 18:24:27 GMT (envelope-from joelja@bogus.com) Message-ID: <50F841D6.4090504@bogus.com> Date: Thu, 17 Jan 2013 10:24:22 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Randy Bush References: <50F73457.6030107@bogus.com> <50F83830.5040806@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 17 Jan 2013 18:24:27 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:24:28 -0000 On 1/17/13 9:54 AM, Randy Bush wrote: >>>> 2. We belive that the ipr assertion is invalid >>> we are not lawyers. our opinions are not valid. >> as an individual you make decisions on your own behalf without legal >> consultation all the time. > as an individual, i drink coffee. when participating in a group which > is concerned about intake, i do not foist my preference on the group. > observe the discussion about frelling cookies. The decision to publish or not as a working group document requires the accumulation of individual preferences, without them it isn't consensus. I believed the issue had not been adequately aired out, so here we are. > if an individual chooses to use/implement encumbered technology, that is > indeed their prerogative. whether the _ietf_ says doing so is a *best* > practice should be done a bit more cautiously. Indeed, one can perhaps enumerate multiple rationals for why it should be published the decision-point however is binary. >> I believe that your previously expressed position is adequately >> captured by the first bullet is it not? > yes. so? i am questioning the advisability of the second position. if they are: 1. don't publish 2. publish That doesn't change the nature of the second position imho. > randy > From jhw@apple.com Thu Jan 17 12:03:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5847621F87FD for ; Thu, 17 Jan 2013 12:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8UcomewzN1V for ; Thu, 17 Jan 2013 12:03:47 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id BE9FA21F89CB for ; Thu, 17 Jan 2013 12:03:47 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MGS000B4D15FKD3@mail-out.apple.com> for v6ops@ietf.org; Thu, 17 Jan 2013 12:03:47 -0800 (PST) X-AuditID: 11807136-b7f5e6d000000e0b-6e-50f8673264a1 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 7F.AF.03595.23768F05; Thu, 17 Jan 2013 13:03:47 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MGS0012KD2AX060@aniseed.apple.com> for v6ops@ietf.org; Thu, 17 Jan 2013 12:03:47 -0800 (PST) From: james woodyatt In-reply-to: <50F73457.6030107@bogus.com> Date: Thu, 17 Jan 2013 12:03:46 -0800 Message-id: References: <50F73457.6030107@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1502) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FAsrmuc/iPA4MF9RovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48DLZ6wFa9krLq1ZydTA+Ja1i5GTQ0LAROLT9W5mCFtM4sK9 9WxdjFwcQgJTmCS+npvLCuHMYJL4fWg+G0gVs4CWxPqdx5lAbF4BPYm3h9+CdQsLuEvMX7se LM4moCLx7fJdMJtTQFNi1cOtYDUsAqoSe348ZoaYoy3x5N0FVog5NhJt/9+DxYUENCSmbpkI 1isioCCx4/9OJojrZCUmLDzNPoGRfxaSM2YhOWMWkrELGJlXMQoWpeYkVhqa6iUWFOSk6iXn 525iBAdZodkOxh1/5Q4xCnAwKvHwHjb6ESDEmlhWXJl7iFGCg1lJhPcVC1CINyWxsiq1KD++ qDQntfgQozQHi5I4r40rUEogPbEkNTs1tSC1CCbLxMEp1cC4on1K5w+vGX9mPJqWEcB39ZVF ne3X3VaHJm+zy5I3YO6Zfvaa/nKLJR8+hMTkiT2u++izKPhkf1F549zsC8yy117PzNl8kd3l gmOSt8OPJxkXouo+fbDeV6NU6ri7Z2em8yuZ64wJe8JV9ac0i5kerkiW/ROlvkxgNe8N4+Cy b5PX7p1Tx+uuxFKckWioxVxUnAgAes0Rby4CAAA= Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 20:03:48 -0000 On Jan 16, 2013, at 15:14 , joel jaeggli wrote: > > 1. The assertion is problematic, particulary with the terms applied and the draft should therefore be abandoned unless something changes. p1. As a rule, I don't read patents or patent applications unless my lawyer instructs me to do so. Therefore, I have not, and I will not, evaluate the IPR claim in this case. p2. For a variety of reasons I will decline to state, I think publishing this draft is a reasonable thing to do, but I'm not sure that I agree with the position that IETF should bless it as Best Current Practice when it might require paying a royalty to license the IPR involved. Perhaps another option that could be on the table is a variant of option one above: "...the draft should therefore be categorized as Informational prior to its publication..." -- james woodyatt core os networking From fred@cisco.com Thu Jan 17 13:51:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D9921F892F for ; Thu, 17 Jan 2013 13:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxtdZ3jb0ZuL for ; Thu, 17 Jan 2013 13:51:17 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1994B21F88C4 for ; Thu, 17 Jan 2013 13:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1322; q=dns/txt; s=iport; t=1358459477; x=1359669077; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UT8hgoePDw0FHB0SQnLzXAFL9rIT0DW6QxM8XTxB+jI=; b=PUFi+Go9DxOpIuMAkluDb2a2chcg00ukI7t8kPSA8eN5ZqPp5+HPLUla 3clhm8ww4DjOiiQe5HCCmo5rae4Usm65goEqDrx+bf03XoVhN6OZTg/FJ RoSGCKZ0N5L45IQ2YE3/qZcZ2JAYEqvo2bbrprffX0ILm/+z1/mENPvvM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAApx+FCtJXG+/2dsb2JhbABFvjMWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCIgLBgy7QwSQWGEDplWCdYIk X-IronPort-AV: E=Sophos;i="4.84,488,1355097600"; d="scan'208";a="164095562" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jan 2013 21:51:16 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0HLpG16025839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 21:51:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 15:51:16 -0600 From: "Fred Baker (fred)" To: james woodyatt Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. Thread-Index: AQHN9PzGmsNgI4+1l0q4+BWbaOsxtw== Date: Thu, 17 Jan 2013 21:51:15 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B751A05@xmb-rcd-x09.cisco.com> References: <50F73457.6030107@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:51:18 -0000 Restating, I think you just said that a "Best Current Practice" is by defin= ition unencumbered. Is that a correct restatement? On Jan 17, 2013, at 12:03 PM, james woodyatt wrote: > On Jan 16, 2013, at 15:14 , joel jaeggli wrote: >>=20 >> 1. The assertion is problematic, particulary with the terms applied and = the draft should therefore be abandoned unless something changes. >=20 > p1. As a rule, I don't read patents or patent applications unless my lawy= er instructs me to do so. Therefore, I have not, and I will not, evaluate t= he IPR claim in this case. >=20 > p2. For a variety of reasons I will decline to state, I think publishing = this draft is a reasonable thing to do, but I'm not sure that I agree with = the position that IETF should bless it as Best Current Practice when it mig= ht require paying a royalty to license the IPR involved. >=20 > Perhaps another option that could be on the table is a variant of option = one above: "...the draft should therefore be categorized as Informational p= rior to its publication..." >=20 >=20 > -- > james woodyatt > core os networking >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Thu Jan 17 18:18:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536C821F8B29 for ; Thu, 17 Jan 2013 18:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88tPtqaXAx2S for ; Thu, 17 Jan 2013 18:18:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6D21F8B2F for ; Thu, 17 Jan 2013 18:18:27 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tw1XD-0003Tr-2l; Fri, 18 Jan 2013 02:18:23 +0000 Date: Thu, 17 Jan 2013 16:18:19 -1000 Message-ID: From: Randy Bush To: james woodyatt In-Reply-To: References: <50F73457.6030107@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 02:18:28 -0000 > Perhaps another option that could be on the table is a variant of > option one above: "...the draft should therefore be categorized as > Informational prior to its publication..." we often publish "The Foo Company Way to Do X" randy From joelja@bogus.com Thu Jan 17 20:28:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6992921F8432 for ; Thu, 17 Jan 2013 20:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o13JbKXUWTsg for ; Thu, 17 Jan 2013 20:28:02 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0E42F21F8431 for ; Thu, 17 Jan 2013 20:28:01 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0I4RxI6093185 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 18 Jan 2013 04:28:00 GMT (envelope-from joelja@bogus.com) Message-ID: <50F8CF4A.8080501@bogus.com> Date: Thu, 17 Jan 2013 20:27:54 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Randy Bush References: <50F73457.6030107@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 18 Jan 2013 04:28:00 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 04:28:02 -0000 On 1/17/13 6:18 PM, Randy Bush wrote: >> Perhaps another option that could be on the table is a variant of >> option one above: "...the draft should therefore be categorized as >> Informational prior to its publication..." In the the story arc of publish or not publish that falls on the side of publish it. > we often publish "The Foo Company Way to Do X" http://www.ietf.org/rfc/rfc3954.txt is something I use daily from at least three vendors that aren't cisco. > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Fri Jan 18 00:26:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4873721F89CB for ; Fri, 18 Jan 2013 00:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.056 X-Spam-Level: X-Spam-Status: No, score=-100.056 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxgLsayuNgbp for ; Fri, 18 Jan 2013 00:26:12 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A57CF21F89AE for ; Fri, 18 Jan 2013 00:26:12 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so721404wey.3 for ; Fri, 18 Jan 2013 00:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mGmNrP1vD8vKGkhn+iD+uISgD1+dP8BKWopbvX0QacA=; b=bVEqRn8/iMl5/84F18nWJPVEADRKR3fzjaEaQtZYJDsBslye+hP7kQYphAe92pltvB RDp61JhtcCAGuLME6VW6+84ahj1Uy2P2aCGJFrJNhI8Tdt3jg3j78kJMAuY5tp16VD6V yYxJCAHRHv2PyDksm1pPvAXi4ts3UAj3xRsSUwd9Nnlq11QPXuLBafcV9MjXJ1FJ1+3q vrZrJrlsc4eQ23yEFFC6ZZlGXcTzA62hsqi6mBoETRNdfp/0Z06cuO18EOZHsZ/HcU60 LFpTByTkmgrfnmkbwmOqxxTKFTrbMHZtVwMi+e0i5FxC4YM8Qdc7pQO5FGM00a3cspzl 5Mxg== X-Received: by 10.180.14.2 with SMTP id l2mr2176324wic.2.1358497570489; Fri, 18 Jan 2013 00:26:10 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-196.as13285.net. [2.102.219.196]) by mx.google.com with ESMTPS id hu8sm2353352wib.6.2013.01.18.00.26.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 00:26:09 -0800 (PST) Message-ID: <50F9072F.2080107@gmail.com> Date: Fri, 18 Jan 2013 08:26:23 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <50F73457.6030107@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat - IPR discussion summary. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 08:26:13 -0000 On 18/01/2013 02:18, Randy Bush wrote: >> Perhaps another option that could be on the table is a variant of >> option one above: "...the draft should therefore be categorized as >> Informational prior to its publication..." > > we often publish "The Foo Company Way to Do X" We do, but generally these days they are Independent Submissions rather than IETF Stream. But there is nothing that says we can't publish a BCP with IPR, if we choose to. Brian From cb.list6@gmail.com Sat Jan 19 17:47:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69B21F879A for ; Sat, 19 Jan 2013 17:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.773 X-Spam-Level: X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcJbQF-8Jnj0 for ; Sat, 19 Jan 2013 17:47:42 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id C268621F8797 for ; Sat, 19 Jan 2013 17:47:41 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id ej20so4956396lab.7 for ; Sat, 19 Jan 2013 17:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=vDhHsOqXn7xayTvXGKjab/pZ7IFW+VITVX5vm/8QOOw=; b=hK5ND4sWNfZNowUDXLqqTzRGd8pmEZMLi5ie7nPNO6+edN+CmdvIPLWQXkP65pJa39 Nyqchi42ok5eq7o4/JF2HWm4z6GJzrzSzkMeCDHMSSiWqr9SDsgn3jedJbHw8G+Iat1z Qu0RS8pR1Ah6hRy5bb8TdSmvhqiBA6NDoDB27UjRaYU7/zzmaVhQsWmSxSTkiNrMOK2F tZbT2a7uYtI1JGkWN4bOmp55DjoOr9md+3nYC0EhKzZGqvYTRBX5zdmXiOeUfQ96zLxN HuNmDI6HVQui+msnZUBlLc8dr4lcQvcNK7zuClDSrrivhR+EdiT7UKfhwD+spvNv61w6 VpvQ== MIME-Version: 1.0 X-Received: by 10.152.124.15 with SMTP id me15mr13195252lab.5.1358645031321; Sat, 19 Jan 2013 17:23:51 -0800 (PST) Received: by 10.112.44.36 with HTTP; Sat, 19 Jan 2013 17:23:50 -0800 (PST) Received: by 10.112.44.36 with HTTP; Sat, 19 Jan 2013 17:23:50 -0800 (PST) Date: Sat, 19 Jan 2013 17:23:50 -0800 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=f46d0437458177bfd504d3ae329e Subject: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 01:47:45 -0000 --f46d0437458177bfd504d3ae329e Content-Type: text/plain; charset=ISO-8859-1 Hi, I posted this update as a WG draft http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 Please take the time to review this update and share your feedback. I hoping that a clearly defined scope, clear need for this work, as well running code will make it easy to advance. I am now aware of 3 implementations that approximately use this method (ios6, an LTE mifi router, and Dan Drown's Android submission) CB Sent from ipv6-only Android --f46d0437458177bfd504d3ae329e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I posted this update as a WG draft

http://tools.ietf.org/html/draft-ietf-v6ops-64share-00

Please take the time to review this update and share your fe= edback.=A0 I hoping that a clearly defined scope, clear need for this work,= =A0 as well running code will make it easy to advance. I am now aware of 3 = implementations that approximately use this method (ios6, an LTE mifi route= r, and Dan Drown's Android submission)

CB

Sent from ipv6-only Android

--f46d0437458177bfd504d3ae329e-- From markzzzsmith@yahoo.com.au Sun Jan 20 03:31:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81C121F84F8 for ; Sun, 20 Jan 2013 03:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VphXW1ezY0A2 for ; Sun, 20 Jan 2013 03:31:32 -0800 (PST) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by ietfa.amsl.com (Postfix) with SMTP id A7A2F21F84EB for ; Sun, 20 Jan 2013 03:31:32 -0800 (PST) Received: from [98.139.212.145] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jan 2013 11:31:31 -0000 Received: from [98.139.212.228] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jan 2013 11:31:31 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 20 Jan 2013 11:31:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 851605.68618.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 46890 invoked by uid 60001); 20 Jan 2013 11:31:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1358681491; bh=tSCLLAlghdglB17u6ow6L2OaWMOyMj9Pupj9E5wnPpw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wVhILhCa9prJhJrPSzCJk8PxmvV1SOKpLLorzBKNX4E3UHW/M/I0YT+TauBTJ1KL+1HjrLJIZCVGfQNKKp6WZQNVvoEmYUXyDqKSRKcNZ93y+wEcETFLvyi8DXHrEOe4JyP6s/+qotga3dEX+Nx/vm+v/xJM6kMxir4eREf04X4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HRtwO+ts5oYNX1fhwnoI+4dI6lY7sOxD9ZC4BNINK/ffs/Pg7A8wiAQ1Qike2pKy6jzV+EpqQ4MLG6kqv4UiXPWIBu6YW6jcYuRWRHmeMdtYJlLNTAyVHZFYrcgYE1ZNgBkPd4kbemX8pn5XJy6YSMGuXgWiMc3XkkkoRPR04mY=; X-YMail-OSG: 3H3wQ9MVM1nwrhmt8auhQp_0dOtqaqLdje03eoNoEw0kJa7 LOzj4AKqsBEpiPiO.W1ui5Cc3ZDJRtGBjHoj2BFXH1Arez50ETJotKruMtcj pUtAIpzDfJi4O639YnOhqbKNJ0Bw6BWWrOOub669wkPKc7Eu23yLHKcImqIQ WDPBhBrALE4ZQC0hRopagXDWZ83e_bhWnWfMZ0aBBdoj_Sem_IJdwyfc83AF 38Du0UijOaoTOKicqvjm7IF9mQmUAKATnU3dw4B.AQyj6u2mlewTe1q9tK3y UuAPo7tTO_9LIAY652_gk84UBFlj_oLfoGzrIVOLt0xDxF8BJPHKvDzlt1de sJ8JMPuo69PsC72YpeUr8FjPdLpbT0ibDqJgBkZnt3EVDKkYmIg6LOM4RBbl gD2LfzFO..YqGyKyqbI1x_HJYRPXxJQkZ9sWREo065wTnmbyGjT5oXmOIa_g jNyO4crk9vhV2Ku28mh5KoFAIm.ywRXBOy2Ylh5eCwMSVpPMS03WzheXZTLu UyFM2Wf3HJIs6a12UMvQvqjuH Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Sun, 20 Jan 2013 03:31:31 PST X-Rocket-MIMEInfo: 001.001, SGksCgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogQ2FtZXJvbiBCeXJuZSA8Y2IubGlzdDZAZ21haWwuY29tPgo.VG86IHY2b3BzQGlldGYub3JnIAo.U2VudDogU3VuZGF5LCAyMCBKYW51YXJ5IDIwMTMgMTI6MjMgUE0KPlN1YmplY3Q6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02NHNoYXJlCj4gCj4KPkhpLAo.SSBwb3N0ZWQgdGhpcyB1cGRhdGUgYXMgYSBXRyBkcmFmdAo.aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy02NHNoYXJlLTAwCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: Message-ID: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Sun, 20 Jan 2013 03:31:31 -0800 (PST) From: Mark Smith To: Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 11:31:33 -0000 Hi,=0A=0A=0A>________________________________=0A> From: Cameron Byrne =0A>To: v6ops@ietf.org =0A>Sent: Sunday, 20 January 2013 12:= 23 PM=0A>Subject: [v6ops] draft-ietf-v6ops-64share=0A> =0A>=0A>Hi,=0A>I pos= ted this update as a WG draft=0A>http://tools.ietf.org/html/draft-ietf-v6op= s-64share-00=0A>Please take the time to review this update and share your f= eedback.=A0 I hoping that a clearly defined scope, clear need for this work= ,=A0 as well running code will make it easy to advance. I am now aware of 3= implementations that approximately use this method (ios6, an LTE mifi rout= er, and Dan Drown's Android submission)=0A=0ARegarding this text,=A0=0A=0A= =A09. =A0Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is the=0A= =A0 =A0 =A0 =A0only instance of the assigned /64 on the 3GPP interface, the= re is=0A=A0 =A0 =A0 =A0no chance of an address conflict on that interface. = =A0On the LAN=0A=A0 =A0 =A0 =A0interface, there is no chance of address con= flict since the=0A=0A=0A=0AByrne =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Exp= ires June 17, 2013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 4]=0A=A0=0AV6OP= S Working Group =A0 draft-ietf-v6ops-64share-00 =A0 =A0 =A0December 14, 201= 2=0A=0A=0A=A0 =A0 =A0 =A0address is defended using Duplicate Address Detect= ion (DAD).=0A=0AI'd suggest adding something like "address is defended usin= g Duplicate Address Detection (DAD), as the LAN interface is also assigned = the address in use on the 3GPP interface."=0A=0AI struggled a bit with work= ing out what was going on until it became clear that the 3GPP and LAN inter= faces are using the same global unicast address.=0A=0AI also think it would= be better to be clearer about the type of IPv6 address and also cover that= their may be multiple IPv6 addresses, such as privacy addresses on the 3GP= P/LAN interface. For example, in=A03. Method for Sharing the 3GPP Interface= /64 to the Tethered LAN,=A0=0A=0A"The UE checks to make sure the 3GPP inte= rfaces is active and has=0A=A0 =A0 =A0 =A0an IPv6 address. =A0If the interf= ace does not have an IPv6 address,=0A=A0 =A0 =A0 =A0an attempt will be made= to acquire one, or else the procedure=0A=A0 =A0 =A0 =A0will terminate."=0A= =0AStrictly, the 3GPP interface always has an IPv6 address because it alway= s has a link local address, so the above would be better if it clarified th= at the type of address to check for is a global IPv6 address.=0A=0AI'll hav= e to do some digging, however I'm wondering if the sockets API might have a= n assumption that an individual IPv6 address is only assigned to a single i= nterface.=A0=0A=0AActually, reviewing the IPv6 Addressing Model in RFC4291,= it says, "An IPv6 unicast address refers to a single interface."=A0=0A=0AW= as a translational bridge model considered? That is, the 3GPP and LAN inter= faces are part of a bridge instance, and a single bridge virtual layer 2/3 = interface is assigned the UE's global unicast address within the /64, with = a /64 prefix length. Enabling or disabling tethering would be a simple matt= er of administratively enabling/disabling the LAN interface.=0A=0ARegards,= =0AMark. From cb.list6@gmail.com Sun Jan 20 08:53:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D87021F84D1 for ; Sun, 20 Jan 2013 08:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF+1Ebh30+lF for ; Sun, 20 Jan 2013 08:53:22 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFCB21F84D0 for ; Sun, 20 Jan 2013 08:53:21 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id ep20so5399037lab.32 for ; Sun, 20 Jan 2013 08:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zXG/j+7YsRiJozEjdHOBr/La2rE9pBoSjkuXXNnCqhQ=; b=HXqZRG2+ketROmQfY+pKt7yXCu/lh8r/zSIbAevakjn7iFSfAzl88bnfTpTR7Bj3Rf 4g/2ZeqymrkgGQSbaQ+Cc+t/1nMsSCd5nwyz84mN9/h1VdbAcdTakErUIltdiPt3QOOP 18qCeAJ38snVB3nhPLZwNbrty/s6MJhhkBFFD7Hh9Z9SNEdSoxdZviy7qhr7f0iB2LVa 2hbrsl48vu+YUegb3r8NPFGSYODwUpg6TOk4jwMBO81jmhctjYs4hLXXWccryJd6SKyQ /G8/aYPlW+giHJdcIjxcJVwSnbNF1kIEEqAhX/syEBoUmjnhqD0LH6heyzktAbYobSWw /xyQ== MIME-Version: 1.0 X-Received: by 10.112.46.199 with SMTP id x7mr6351565lbm.109.1358700800857; Sun, 20 Jan 2013 08:53:20 -0800 (PST) Received: by 10.112.44.36 with HTTP; Sun, 20 Jan 2013 08:53:20 -0800 (PST) Received: by 10.112.44.36 with HTTP; Sun, 20 Jan 2013 08:53:20 -0800 (PST) In-Reply-To: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Sun, 20 Jan 2013 08:53:20 -0800 Message-ID: From: Cameron Byrne To: Mark Smith Content-Type: multipart/alternative; boundary=bcaec55405689755de04d3bb2e46 Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 16:53:23 -0000 --bcaec55405689755de04d3bb2e46 Content-Type: text/plain; charset=ISO-8859-1 Mark, Sent from ipv6-only Android On Jan 20, 2013 3:31 AM, "Mark Smith" wrote: > > Hi, > > > >________________________________ > > From: Cameron Byrne > >To: v6ops@ietf.org > >Sent: Sunday, 20 January 2013 12:23 PM > >Subject: [v6ops] draft-ietf-v6ops-64share > > > > > >Hi, > >I posted this update as a WG draft > >http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 > >Please take the time to review this update and share your feedback. I hoping that a clearly defined scope, clear need for this work, as well running code will make it easy to advance. I am now aware of 3 implementations that approximately use this method (ios6, an LTE mifi router, and Dan Drown's Android submission) > > Regarding this text, > > 9. Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is the > only instance of the assigned /64 on the 3GPP interface, there is > no chance of an address conflict on that interface. On the LAN > interface, there is no chance of address conflict since the > > > > Byrne Expires June 17, 2013 [Page 4] > > V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 2012 > > > address is defended using Duplicate Address Detection (DAD). > > I'd suggest adding something like "address is defended using Duplicate Address Detection (DAD), as the LAN interface is also assigned the address in use on the 3GPP interface." > > I struggled a bit with working out what was going on until it became clear that the 3GPP and LAN interfaces are using the same global unicast address. > The DAD procedure on the LAN is only scoped for the LAN. For the 3gpp link, it is the fact that only 1 off-link address is architecturally permitted by 3gpp that ensures no collision. Did I parse your concern correctly? > I also think it would be better to be clearer about the type of IPv6 address and also cover that their may be multiple IPv6 addresses, such as privacy addresses on the 3GPP/LAN interface. For example, in 3. Method for Sharing the 3GPP Interface /64 to the Tethered LAN, > > "The UE checks to make sure the 3GPP interfaces is active and has > an IPv6 address. If the interface does not have an IPv6 address, > an attempt will be made to acquire one, or else the procedure > will terminate." > > Strictly, the 3GPP interface always has an IPv6 address because it always has a link local address, so the above would be better if it clarified that the type of address to check for is a global IPv6 address. > Ack. I will change it to "globally scoped address" > I'll have to do some digging, however I'm wondering if the sockets API might have an assumption that an individual IPv6 address is only assigned to a single interface. > > Actually, reviewing the IPv6 Addressing Model in RFC4291, it says, "An IPv6 unicast address refers to a single interface." > > Was a translational bridge model considered? That is, the 3GPP and LAN interfaces are part of a bridge instance, and a single bridge virtual layer 2/3 interface is assigned the UE's global unicast address within the /64, with a /64 prefix length. Enabling or disabling tethering would be a simple matter of administratively enabling/disabling the LAN interface. > Is there an ietf doc on what a translational bridge is? We considered ndproxy but that method was deemed unfit due to insufficient loop prevention. CB > Regards, > Mark. --bcaec55405689755de04d3bb2e46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Mark,

Sent from ipv6-only Android
On Jan 20, 2013 3:31 AM, "Mark Smith" <markzzzsmith@yahoo.com.au> wrote:
>
> Hi,
>
>
> >________________________________
> > From: Cameron Byrne <cb.= list6@gmail.com>
> >To: v6ops@ietf.org
> >Sent: Sunday, 20 January 2013 12:23 PM
> >Subject: [v6ops] draft-ietf-v6ops-64share
> >
> >
> >Hi,
> >I posted this update as a WG draft
> >http://tools.ietf.org/html/draft-ietf-v6ops-64share-00
> >Please take the time to review this update and share your feedback= .=A0 I hoping that a clearly defined scope, clear need for this work,=A0 as= well running code will make it easy to advance. I am now aware of 3 implem= entations that approximately use this method (ios6, an LTE mifi router, and= Dan Drown's Android submission)
>
> Regarding this text,=A0
>
> =A09. =A0Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is the=
> =A0 =A0 =A0 =A0only instance of the assigned /64 on the 3GPP interface= , there is
> =A0 =A0 =A0 =A0no chance of an address conflict on that interface. =A0= On the LAN
> =A0 =A0 =A0 =A0interface, there is no chance of address conflict since= the
>
>
>
> Byrne =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Expires June 17, 2013 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 4]
> =A0
> V6OPS Working Group =A0 draft-ietf-v6ops-64share-00 =A0 =A0 =A0Decembe= r 14, 2012
>
>
> =A0 =A0 =A0 =A0address is defended using Duplicate Address Detection (= DAD).
>
> I'd suggest adding something like "address is defended using = Duplicate Address Detection (DAD), as the LAN interface is also assigned th= e address in use on the 3GPP interface."
>
> I struggled a bit with working out what was going on until it became c= lear that the 3GPP and LAN interfaces are using the same global unicast add= ress.
>

The DAD procedure on the LAN is only scoped for the LAN. For= the 3gpp link, it is the fact that only 1 off-link address is architectura= lly permitted by 3gpp that ensures no collision.

Did I parse your concern correctly?

> I also think it would be better to be clearer about the= type of IPv6 address and also cover that their may be multiple IPv6 addres= ses, such as privacy addresses on the 3GPP/LAN interface. For example, in= =A03. Method for Sharing the 3GPP Interface /64 to the Tethered LAN,=A0
>
> "The UE checks to make sure the 3GPP interfaces is active and has=
> =A0 =A0 =A0 =A0an IPv6 address. =A0If the interface does not have an I= Pv6 address,
> =A0 =A0 =A0 =A0an attempt will be made to acquire one, or else the pro= cedure
> =A0 =A0 =A0 =A0will terminate."
>
> Strictly, the 3GPP interface always has an IPv6 address because it alw= ays has a link local address, so the above would be better if it clarified = that the type of address to check for is a global IPv6 address.
>

Ack. I will change it to "globally scoped address"=

> I'll have to do some digging, however I'm wonde= ring if the sockets API might have an assumption that an individual IPv6 ad= dress is only assigned to a single interface.=A0
>
> Actually, reviewing the IPv6 Addressing Model in RFC4291, it says, &qu= ot;An IPv6 unicast address refers to a single interface."=A0
>
> Was a translational bridge model considered? That is, the 3GPP and LAN= interfaces are part of a bridge instance, and a single bridge virtual laye= r 2/3 interface is assigned the UE's global unicast address within the = /64, with a /64 prefix length. Enabling or disabling tethering would be a s= imple matter of administratively enabling/disabling the LAN interface.
>

Is there an ietf doc on what a translational bridge is? We c= onsidered ndproxy but that method was deemed unfit due to insufficient loop= prevention.

CB

> Regards,
> Mark.

--bcaec55405689755de04d3bb2e46-- From cb.list6@gmail.com Sun Jan 20 09:07:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD8D21F84E9 for ; Sun, 20 Jan 2013 09:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsXRaUwwufxQ for ; Sun, 20 Jan 2013 09:07:41 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4621F84DD for ; Sun, 20 Jan 2013 09:07:41 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so2640764lbo.0 for ; Sun, 20 Jan 2013 09:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hpyC2jYcfr/tbim21t5eIqCQ/Z7+p2l+l1kMkW2Sjcw=; b=x77Yyh6GMYzBVJ6YjawxmE7oTCN2IYIz2ckWfkoPxYvXtziWHmQXdI4YTbloEdzoIj HJQgW/tW6flhuxDodHB0nwefZnvhGC2eypOEj/+/x/1WfqRchcNUG8PMABNtmZVU3fxN xBFUr1DUBF7zyj2avJriYJa/XV3U5121f1V2x0ns/aWsukZqtCDyXjAxLWTo+4EGjb56 B1uo+Q523hKwdS6KWp2DW6FkqLty0ID8X6gro9gNeYukzaO9DDWjg1A34gFGAP+ck79s tY7aRMwosC/Pvx7QmypypUgdhMI7OL1eGKbz1we1c3mpdwEpnn0shywaECpSMqLba6vQ owhQ== MIME-Version: 1.0 X-Received: by 10.112.38.67 with SMTP id e3mr6264618lbk.105.1358701660299; Sun, 20 Jan 2013 09:07:40 -0800 (PST) Received: by 10.112.44.36 with HTTP; Sun, 20 Jan 2013 09:07:40 -0800 (PST) Received: by 10.112.44.36 with HTTP; Sun, 20 Jan 2013 09:07:40 -0800 (PST) In-Reply-To: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Sun, 20 Jan 2013 09:07:40 -0800 Message-ID: From: Cameron Byrne To: Mark Smith Content-Type: multipart/alternative; boundary=e0cb4efe2c24d1613a04d3bb61e8 Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 17:07:42 -0000 --e0cb4efe2c24d1613a04d3bb61e8 Content-Type: text/plain; charset=ISO-8859-1 Mark, Just on the this one topic > Actually, reviewing the IPv6 Addressing Model in RFC4291, it says, "An IPv6 unicast address refers to a single interface." > Should we explicitly call it anycast then? Is that worth noting in the draft, citing tools.ietf.org/html/rfc4291#section-2.6 CB --e0cb4efe2c24d1613a04d3bb61e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Mark,

Just on the this one topic

<Snip>

> Actually, reviewing the IPv6 Addressing Model in RFC429= 1, it says, "An IPv6 unicast address refers to a single interface.&quo= t;=A0
>

Should we explicitly call it anycast then? Is that worth not= ing in the draft, citing=A0 tools.ietf.org/html/rfc4291#section-2.6

CB

--e0cb4efe2c24d1613a04d3bb61e8-- From rajiva@cisco.com Sun Jan 20 13:00:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D3C21F8795 for ; Sun, 20 Jan 2013 13:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mMLOE8THKXv for ; Sun, 20 Jan 2013 13:00:23 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E673521F8722 for ; Sun, 20 Jan 2013 13:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5002; q=dns/txt; s=iport; t=1358715623; x=1359925223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E9gUKj56sxyABu59OwwxpECKkro74VnleDK33iFz/+U=; b=WE4fjtzfopRD8KiqPwgi+1YfQq7wAtgiBia+zhYA3nB5xQtvKXPa/eUI VyhzRq6zPFd9gWJ0FJK29NHCDfnmg0lkbW2LlXIlTMEIIM7YZ+UjEEIMH ATFI2X6OH7mW8y5uohXS4EZgNDzjO+Y/hdHOPGh1gCJ+VGPhpi6amWCus I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALZa/FCtJV2d/2dsb2JhbABEvjcWc4IeAQEBAwE6PwUHBAIBCA4DBAEBAQoUCQchERQJCAIEAQ0FCId/AwkGDLIXDYhmjAltg2JhA5Q2BIJuihuFEoJ1giQ X-IronPort-AV: E=Sophos;i="4.84,501,1355097600"; d="scan'208";a="165021574" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 20 Jan 2013 21:00:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0KL0Ira032640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 21:00:18 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 15:00:18 -0600 From: "Rajiv Asati (rajiva)" To: Cameron Byrne , Mark Smith Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: AQHN9rAv6ksovCUlQUORbevJhQ4wYphSepiAgABZ6gD//9xtQA== Date: Sun, 20 Jan 2013 21:00:17 +0000 Message-ID: References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.83.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 21:00:23 -0000 Hi Cameron, It wasn't crystal clear that LAN side and WAN side interfaces were using th= e same IPv6 address. So, Mark's suggested text will make it clear. You might also want to mention 'no DAD on WAN interface (i.e. 3GPP interfac= e)' before mentioning DAD on LAN interface.=20 Wrt assigning the same IP address on two different (IP-enabled) interfaces,= I can only think of 'IP unnumbered' model and it might be worth mentioning= . Else, what could it be? What's implemented in iOS? > Is there an ietf doc on what a translational bridge is? We considered I don't think so, but there are number of RFCs that refer to IEEE specifica= tion for bridging. Check out the L2VPN WG. Lastly, I would suggest to prepend 3GPP before UE below (to differentiate f= rom UEs attaching on the LAN): > > "The UE checks to make sure the 3GPP interfaces is active and has Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Cameron Byrne > Sent: Sunday, January 20, 2013 11:53 AM > To: Mark Smith > Cc: v6ops v6ops WG > Subject: Re: [v6ops] draft-ietf-v6ops-64share >=20 > Mark, >=20 > Sent from ipv6-only Android > On Jan 20, 2013 3:31 AM, "Mark Smith" > wrote: > > > > Hi, > > > > > > >________________________________ > > > From: Cameron Byrne > > >To: v6ops@ietf.org > > >Sent: Sunday, 20 January 2013 12:23 PM > > >Subject: [v6ops] draft-ietf-v6ops-64share > > > > > > > > >Hi, > > >I posted this update as a WG draft > > >http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 > > >Please take the time to review this update and share your feedback. I > hoping that a clearly defined scope, clear need for this work, as well > running code will make it easy to advance. I am now aware of 3 > implementations that approximately use this method (ios6, an LTE mifi > router, and Dan Drown's Android submission) > > > > Regarding this text, > > > > 9. Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is the > > only instance of the assigned /64 on the 3GPP interface, there i= s > > no chance of an address conflict on that interface. On the LAN > > interface, there is no chance of address conflict since the > > > > > > > > Byrne Expires June 17, 2013 [Page 4= ] > > > > V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 201= 2 > > > > > > address is defended using Duplicate Address Detection (DAD). > > > > I'd suggest adding something like "address is defended using Duplicate > Address Detection (DAD), as the LAN interface is also assigned the addres= s > in use on the 3GPP interface." > > > > I struggled a bit with working out what was going on until it became cl= ear > that the 3GPP and LAN interfaces are using the same global unicast addres= s. > > >=20 > The DAD procedure on the LAN is only scoped for the LAN. For the 3gpp lin= k, > it is the fact that only 1 off-link address is architecturally permitted = by 3gpp > that ensures no collision. >=20 > Did I parse your concern correctly? >=20 > > I also think it would be better to be clearer about the type of IPv6 ad= dress > and also cover that their may be multiple IPv6 addresses, such as privacy > addresses on the 3GPP/LAN interface. For example, in 3. Method for Sharin= g > the 3GPP Interface /64 to the Tethered LAN, > > > > "The UE checks to make sure the 3GPP interfaces is active and has > > an IPv6 address. If the interface does not have an IPv6 address= , > > an attempt will be made to acquire one, or else the procedure > > will terminate." > > > > Strictly, the 3GPP interface always has an IPv6 address because it alwa= ys > has a link local address, so the above would be better if it clarified th= at the > type of address to check for is a global IPv6 address. > > >=20 > Ack. I will change it to "globally scoped address" >=20 > > I'll have to do some digging, however I'm wondering if the sockets API > might have an assumption that an individual IPv6 address is only assigned= to > a single interface. > > > > Actually, reviewing the IPv6 Addressing Model in RFC4291, it says, "An = IPv6 > unicast address refers to a single interface." > > > > Was a translational bridge model considered? That is, the 3GPP and LAN > interfaces are part of a bridge instance, and a single bridge virtual lay= er 2/3 > interface is assigned the UE's global unicast address within the /64, wit= h a > /64 prefix length. Enabling or disabling tethering would be a simple matt= er > of administratively enabling/disabling the LAN interface. > > >=20 > Is there an ietf doc on what a translational bridge is? We considered > ndproxy but that method was deemed unfit due to insufficient loop > prevention. >=20 > CB >=20 > > Regards, > > Mark. >=20 From internet-drafts@ietf.org Mon Jan 21 16:09:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2295421F8A3E; Mon, 21 Jan 2013 16:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3mCsmFrYkZr; Mon, 21 Jan 2013 16:09:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A90921F8948; Mon, 21 Jan 2013 16:09:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122000954.31085.69460.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 16:09:54 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 00:09:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-09.txt Pages : 16 Date : 2013-01-21 Abstract: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kawashimam@vx.jp.nec.com Mon Jan 21 16:14:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0303221F8460 for ; Mon, 21 Jan 2013 16:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDv2NphLWxGH for ; Mon, 21 Jan 2013 16:14:56 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by ietfa.amsl.com (Postfix) with ESMTP id C536821F845E for ; Mon, 21 Jan 2013 16:14:54 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id r0M0EoQL005396 for ; Tue, 22 Jan 2013 09:14:50 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id r0M0EoY10081 for v6ops@ietf.org; Tue, 22 Jan 2013 09:14:50 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id r0M0Eogf010259 for ; Tue, 22 Jan 2013 09:14:50 +0900 (JST) Received: from shikibu.jp.nec.com ([10.26.220.2] [10.26.220.2]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-1286588; Tue, 22 Jan 2013 09:13:53 +0900 Received: from siznecatg141003 ([10.3.141.3] [10.3.141.3]) by mail.jp.nec.com with ESMTP; Tue, 22 Jan 2013 09:13:53 +0900 To: v6ops@ietf.org In-reply-to: <20130122000954.31085.69460.idtracker@ietfa.amsl.com> Message-Id: <20130122091351kawashimam@mail.jp.nec.com> References: <20130122000954.31085.69460.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.68 Step12] From: KAWASHIMA Masanobu Date: Tue, 22 Jan 2013 09:13:51 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 00:14:57 -0000 Folks, We authors have published a new version of draft-ietf-v6ops-464xlat that was incorporated the comments from IESG. Regards, Masanobu > >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 : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-09.txt > Pages : 16 > Date : 2013-01-21 > >Abstract: > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-09 > > >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 ==================================== NEC AccessTechnica, Ltd. Marketing Promotion Department and Product Development Department KAWASHIMA Masanobu kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ==================================== From alexandru.petrescu@gmail.com Tue Jan 22 00:34:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305B721F84E8 for ; Tue, 22 Jan 2013 00:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eL2cf1XoBFz for ; Tue, 22 Jan 2013 00:34:45 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 138D521F8586 for ; Tue, 22 Jan 2013 00:34:44 -0800 (PST) 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 r0M8Yhxk025087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 22 Jan 2013 09:34:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0M8Yh6B023690 for ; Tue, 22 Jan 2013 09:34:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0M8YQfA023166 for ; Tue, 22 Jan 2013 09:34:42 +0100 Message-ID: <50FE4F11.3050800@gmail.com> Date: Tue, 22 Jan 2013 09:34:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 08:34:46 -0000 Le 20/01/2013 18:07, Cameron Byrne a écrit : > Mark, > > Just on the this one topic > > > >> Actually, reviewing the IPv6 Addressing Model in RFC4291, it says, >> > "An IPv6 unicast address refers to a single interface." >> > > Should we explicitly call it anycast then? Is that worth noting in > the draft, citing tools.ietf.org/html/rfc4291#section-2.6 > But that sense of anycast has a notion of 'neareast', whereas here they'd be equally distant (on same computer) and hence the decision to route it would be guided by an unknown rule. Instead of calling it anycast, one alternative is to remove it from the cellular interface (ifconfig del), and then assign it to the WLAN interface. In this way there would be no worry about same address on two different interfaces. Alex > > CB > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From markzzzsmith@yahoo.com.au Tue Jan 22 11:38:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3FB21F8A9B for ; Tue, 22 Jan 2013 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q-mH7b65A4d for ; Tue, 22 Jan 2013 11:38:29 -0800 (PST) Received: from nm38-vm3.bullet.mail.bf1.yahoo.com (nm38-vm3.bullet.mail.bf1.yahoo.com [72.30.239.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0D421F8A93 for ; Tue, 22 Jan 2013 11:38:28 -0800 (PST) Received: from [98.139.212.152] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2013 19:38:28 -0000 Received: from [98.139.212.207] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2013 19:38:28 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 22 Jan 2013 19:38:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509361.91646.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 68116 invoked by uid 60001); 22 Jan 2013 19:38:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1358883508; bh=knBG4V/T04ziYBuVhPR8+9wBA0ZVWeYiRXdLi2F6OxU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=krSKcFKZhsmL5o/8wx4tSFWEXkPW2AQTUg7vOz0CMjeEL8P0ErDzaYrHtNZw1VmZncMK7KCwVyvR121cQ7vLEOLRgaJbVZmhBZfgFX8ba/m+9+DvixZ2/ZVaWt9TY/6vCeRY3ih1OAvJ2zLIOt89/LjS855lQIMX9U8creH2Nr0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v7aQ//HYfC3DxmtWsDmHHVGb2tl9ShHdsnMzLURobJAazTNM5/Dh9jynkFxLdmzmstcr5JindPdMFj7TDnjTcZz7st1CmxAeigvPbjqAbzM9pCBaaSKzxpoMTCDQK7jrAgDYQIo5i1OpJFHuJAx3iUTN18okKTqla2+ILnrs2/Y=; X-YMail-OSG: X2L6hwEVM1kC2n..xp3aZb8BoUX03q6XDRmDUvI0gIr9hLZ U8neQyZOhDyux3E_V8Qp3iXwkMnn_gUUs6hE_dqhKaki2RvT8sziEYxe9xPs V3T6byTJIEbvumKbJOetNHShtYiVv1LR1SFvzGwN2advtdBPNYO9SOCF9PPn 4_Yq2XSr12pDF2F44av.VtT71oKvjpPaSfBAOD_GwDtfPjMKXFYmWuueHZqs Rf0sjdW3eE7dSDwDNwrQRG8XSCo2Zg5IPpVVnTLmBH.H6RXWJ3DfWuipvBt0 d_LK6OG41FsoJgI_TPP4yNLcQACLuNJ4iTXb0IXN5.CuNPDB25mfSFk53t8R qxOsqDe3db9FBCo0S9Y7UfBeldsCiiquT1X1Vz5J5Xlg3zG5lQwA9GpPIk9P hlfPKcxX1k..LZOFUfByszB77hdDClCFgIOclzJMde_AOmhi7gIlKdyo1CHA bA.bLBiuP0chPHlFT.Ra7gD6AMrhN4Sq44TfhhFYuo0w6na3rW.Lz1ixz.8E oXbY.SyV7R7FZetm417wfUBmk Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Tue, 22 Jan 2013 11:38:27 PST X-Rocket-MIMEInfo: 001.001, CkhpIENhbWVyb24sCgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogQ2FtZXJvbiBCeXJuZSA8Y2IubGlzdDZAZ21haWwuY29tPgo.VG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.IAo.Q2M6IHY2b3BzIHY2b3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBNb25kYXksIDIxIEphbnVhcnkgMjAxMyAzOjUzIEFNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTY0c2hhcmUKPiAKPgo.TWFyaywKPlNlbnQgZnJvbSBpcHY2LW8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.496 References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> Message-ID: <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Tue, 22 Jan 2013 11:38:27 -0800 (PST) From: Mark Smith To: Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:38:30 -0000 =0AHi Cameron,=0A=0A=0A>________________________________=0A> From: Cameron = Byrne =0A>To: Mark Smith = =0A>Cc: v6ops v6ops WG =0A>Sent: Monday, 21 January 2013 3= :53 AM=0A>Subject: Re: [v6ops] draft-ietf-v6ops-64share=0A> =0A>=0A>Mark,= =0A>Sent from ipv6-only Android=0A>On Jan 20, 2013 3:31 AM, "Mark Smith" wrote:=0A>>=0A>> Hi,=0A>>=0A>>=0A>> >____________= ____________________=0A>> > From: Cameron Byrne =0A>> >= To: v6ops@ietf.org=0A>> >Sent: Sunday, 20 January 2013 12:23 PM=0A>> >Subje= ct: [v6ops] draft-ietf-v6ops-64share=0A>> >=0A>> >=0A>> >Hi,=0A>> >I posted= this update as a WG draft=0A>> >http://tools.ietf.org/html/draft-ietf-v6op= s-64share-00=0A>> >Please take the time to review this update and share you= r feedback.=A0 I hoping that a clearly defined scope, clear need for this w= ork,=A0 as well running code will make it easy to advance. I am now aware o= f 3 implementations that approximately use this method (ios6, an LTE mifi r= outer, and Dan Drown's Android submission)=0A>>=0A>> Regarding this text,= =A0=0A>>=0A>> =A09. =A0Since the address 2001:db8:ac10:f002:1234:4567:0:9/1= 28 is the=0A>> =A0 =A0 =A0 =A0only instance of the assigned /64 on the 3GPP= interface, there is=0A>> =A0 =A0 =A0 =A0no chance of an address conflict o= n that interface. =A0On the LAN=0A>> =A0 =A0 =A0 =A0interface, there is no = chance of address conflict since the=0A>>=0A>>=0A>>=0A>> Byrne =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Expires June 17, 2013 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0[Page 4]=0A>> =A0=0A>> V6OPS Working Group =A0 draft-ietf-v6ops-= 64share-00 =A0 =A0 =A0December 14, 2012=0A>>=0A>>=0A>> =A0 =A0 =A0 =A0addre= ss is defended using Duplicate Address Detection (DAD).=0A>>=0A>> I'd sugge= st adding something like "address is defended using Duplicate Address Detec= tion (DAD), as the LAN interface is also assigned the address in use on the= 3GPP interface."=0A>>=0A>> I struggled a bit with working out what was goi= ng on until it became clear that the 3GPP and LAN interfaces are using the = same global unicast address.=0A>>=0A>The DAD procedure on the LAN is only s= coped for the LAN. For the 3gpp link, it is the fact that only 1 off-link a= ddress is architecturally permitted by 3gpp that ensures no collision. =0A>= Did I parse your concern correctly?=A0=0A=0AInitially what confused me was = I thought the /128 that is assigned to the 3GPP interface had been "stolen"= from within the /64 assigned to the LAN interface i.e. a hole had been pun= ched in the /64, and that is why I wondered how DAD was working in that sce= nario. While covered in other areas, further reinforcing the duplication of= the address when functions would break without it could be useful.=0A=0A>>= I also think it would be better to be clearer about the type of IPv6 addre= ss and also cover that their may be multiple IPv6 addresses, such as privac= y addresses on the 3GPP/LAN interface. For example, in=A03. Method for Shar= ing the 3GPP Interface /64 to the Tethered LAN,=A0=0A>>=0A>> "The UE checks= to make sure the 3GPP interfaces is active and has=0A>> =A0 =A0 =A0 =A0an = IPv6 address. =A0If the interface does not have an IPv6 address,=0A>> =A0 = =A0 =A0 =A0an attempt will be made to acquire one, or else the procedure=0A= >> =A0 =A0 =A0 =A0will terminate."=0A>>=0A>> Strictly, the 3GPP interface a= lways has an IPv6 address because it always has a link local address, so th= e above would be better if it clarified that the type of address to check f= or is a global IPv6 address.=0A>>=0A>Ack. I will change it to "globally sco= ped address"=0A>> I'll have to do some digging, however I'm wondering if th= e sockets API might have an assumption that an individual IPv6 address is o= nly assigned to a single interface.=A0=0A>>=0A>> Actually, reviewing the IP= v6 Addressing Model in RFC4291, it says, "An IPv6 unicast address refers to= a single interface."=A0=0A>>=0A>> Was a translational bridge model conside= red? That is, the 3GPP and LAN interfaces are part of a bridge instance, an= d a single bridge virtual layer 2/3 interface is assigned the UE's global u= nicast address within the /64, with a /64 prefix length. Enabling or disabl= ing tethering would be a simple matter of administratively enabling/disabli= ng the LAN interface.=0A>>=0A>Is there an ietf doc on what a translational = bridge is? We considered ndproxy but that method was deemed unfit due to in= sufficient loop prevention.=A0=0A=0ATranslational bridging goes back to the= token ring and ethernet days. At layer 2 they were similar enough (because= they were both IEEE standards), to be able to translate reasonably effecti= vely between them, such that they combined token ring/ethernet LAN was pres= ented as a single link at layer 3. I was wondering about reusing that model= because it could have been a way to avoid duplicating the 3GPP address on = the LAN interface. Whether it is possible to do between 3GPP and Ethernet w= ould depend on how similar they are at layer 2, although one thing that wou= ld probably help is that the 3GPP link (if I understand correctly), is a po= int to point link, so the translational bridging would really only be to pr= esent the single remote 3GPP device as an ethernet device on the LAN interf= ace.=0A=0AThinking about it some more, perhaps the following model might ac= hieve a single IPv6 address identifying a single interface more conventiona= lly -=0A=0A- 3GPP link is "unnumbered", only having a link local address=0A= =0A- UE has a bridge instance, with a bridge virtual interface (BVI) that i= s always present.=0A=0A- the IPv6 address configuration information (i.e. R= A PIO for SLAAC) is received over the 3GPP link, but is used to configure g= lobal IPv6 address(es) on the BVI, leaving the 3GPP link "unnumbered". I th= ink the "loophole" that would allow this is that I don't think IPv6 require= s that the address configuration information used to configure addresses on= an interface is required to arrive over that interface, although commonly = it does.=0A=0A- tethering is enabled or disabled by adding or removing the = LAN interface(s) to or from the bridge. An optimisation would be to issue R= As immediately after the LAN interface is enabled.=0A=0A- conventional rout= ing will take care of forwarding traffic received over the 3GPP interface t= o the global addresses on the BVI.=0A=0ARegards,=0AMark.=0A=0A=0A=0A=0A=0A>= CB=0A>> Regards,=0A>> Mark.=0A>=0A>=0A> From cb.list6@gmail.com Tue Jan 22 12:34:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E026821F885E for ; Tue, 22 Jan 2013 12:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtBhxhm7Z42k for ; Tue, 22 Jan 2013 12:34:09 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C393721F8853 for ; Tue, 22 Jan 2013 12:34:08 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id r1so2156853wey.15 for ; Tue, 22 Jan 2013 12:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=hs1I1koWxVdTS/RvzvD2l7kLKWlo1LlMUQnDak2Tm6g=; b=zRzeCxqeZBgNP+fSLQ/4bZqJJnd5+TVH/rFaEImBlXRaAs8eVkKcDiW6oXAyHolwQM ax9CauXjZa4RXueWMcReCW3Pk9sg0NnaUeeY2rN8hsmexAmLuS1gVLj/qdo7W/FYquCB oIK7kwPiDZyop5RxwRNSf7RtqaBBv1+MTRfB9eeznpR56Rs5EnL9Ynf9l78pqpym0idS eDHbO6OxWQAOZrU5yX6sXRZSV/3ALqXPiCqHerZiBUVS7kaBUIQfRY98oK13IY2BrpJu EiC0pa/Hix6HRy5HiPX9bzljwZU7OyX8vwoEzbc5p/sloq41Ec/ABjbX/oshXWPx+vwy iaUQ== MIME-Version: 1.0 X-Received: by 10.180.24.70 with SMTP id s6mr23653959wif.22.1358886847910; Tue, 22 Jan 2013 12:34:07 -0800 (PST) Received: by 10.194.46.232 with HTTP; Tue, 22 Jan 2013 12:34:07 -0800 (PST) In-Reply-To: <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Tue, 22 Jan 2013 12:34:07 -0800 Message-ID: From: Cameron Byrne To: Mark Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:34:10 -0000 Mark, On Tue, Jan 22, 2013 at 11:38 AM, Mark Smith wr= ote: > > Hi Cameron, > > >>________________________________ >> From: Cameron Byrne >>To: Mark Smith >>Cc: v6ops v6ops WG >>Sent: Monday, 21 January 2013 3:53 AM >>Subject: Re: [v6ops] draft-ietf-v6ops-64share >> >> >>Mark, >>Sent from ipv6-only Android >>On Jan 20, 2013 3:31 AM, "Mark Smith" wrote: >>> >>> Hi, >>> >>> >>> >________________________________ >>> > From: Cameron Byrne >>> >To: v6ops@ietf.org >>> >Sent: Sunday, 20 January 2013 12:23 PM >>> >Subject: [v6ops] draft-ietf-v6ops-64share >>> > >>> > >>> >Hi, >>> >I posted this update as a WG draft >>> >http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 >>> >Please take the time to review this update and share your feedback. I= hoping that a clearly defined scope, clear need for this work, as well ru= nning code will make it easy to advance. I am now aware of 3 implementation= s that approximately use this method (ios6, an LTE mifi router, and Dan Dro= wn's Android submission) >>> >>> Regarding this text, >>> >>> 9. Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is the >>> only instance of the assigned /64 on the 3GPP interface, there i= s >>> no chance of an address conflict on that interface. On the LAN >>> interface, there is no chance of address conflict since the >>> >>> >>> >>> Byrne Expires June 17, 2013 [Page 4= ] >>> >>> V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 201= 2 >>> >>> >>> address is defended using Duplicate Address Detection (DAD). >>> >>> I'd suggest adding something like "address is defended using Duplicate = Address Detection (DAD), as the LAN interface is also assigned the address = in use on the 3GPP interface." >>> >>> I struggled a bit with working out what was going on until it became cl= ear that the 3GPP and LAN interfaces are using the same global unicast addr= ess. >>> >>The DAD procedure on the LAN is only scoped for the LAN. For the 3gpp lin= k, it is the fact that only 1 off-link address is architecturally permitted= by 3gpp that ensures no collision. >>Did I parse your concern correctly? > > Initially what confused me was I thought the /128 that is assigned to the= 3GPP interface had been "stolen" from within the /64 assigned to the LAN i= nterface i.e. a hole had been punched in the /64, and that is why I wondere= d how DAD was working in that scenario. While covered in other areas, furth= er reinforcing the duplication of the address when functions would break wi= thout it could be useful. > >>> I also think it would be better to be clearer about the type of IPv6 ad= dress and also cover that their may be multiple IPv6 addresses, such as pri= vacy addresses on the 3GPP/LAN interface. For example, in 3. Method for Sha= ring the 3GPP Interface /64 to the Tethered LAN, >>> >>> "The UE checks to make sure the 3GPP interfaces is active and has >>> an IPv6 address. If the interface does not have an IPv6 address= , >>> an attempt will be made to acquire one, or else the procedure >>> will terminate." >>> >>> Strictly, the 3GPP interface always has an IPv6 address because it alwa= ys has a link local address, so the above would be better if it clarified t= hat the type of address to check for is a global IPv6 address. >>> >>Ack. I will change it to "globally scoped address" >>> I'll have to do some digging, however I'm wondering if the sockets API = might have an assumption that an individual IPv6 address is only assigned t= o a single interface. >>> >>> Actually, reviewing the IPv6 Addressing Model in RFC4291, it says, "An = IPv6 unicast address refers to a single interface." >>> >>> Was a translational bridge model considered? That is, the 3GPP and LAN = interfaces are part of a bridge instance, and a single bridge virtual layer= 2/3 interface is assigned the UE's global unicast address within the /64, = with a /64 prefix length. Enabling or disabling tethering would be a simple= matter of administratively enabling/disabling the LAN interface. >>> >>Is there an ietf doc on what a translational bridge is? We considered ndp= roxy but that method was deemed unfit due to insufficient loop prevention. > > Translational bridging goes back to the token ring and ethernet days. At = layer 2 they were similar enough (because they were both IEEE standards), t= o be able to translate reasonably effectively between them, such that they = combined token ring/ethernet LAN was presented as a single link at layer 3.= I was wondering about reusing that model because it could have been a way = to avoid duplicating the 3GPP address on the LAN interface. Whether it is p= ossible to do between 3GPP and Ethernet would depend on how similar they ar= e at layer 2, although one thing that would probably help is that the 3GPP = link (if I understand correctly), is a point to point link, so the translat= ional bridging would really only be to present the single remote 3GPP devic= e as an ethernet device on the LAN interface. > I think would rather avoid any of this translational bridging business. And in fact, i am only trying to document running code to avoid multiple divergent methods of achieving the same goal. That said, it appears a few folks (Rajiv and Alex) have some indigestion over having one IP address in multiple places. It works for me, but i can accept that it may not work well for others. So, i think i can change the wording to allows for 2 methods 1) When tethering is enabled, move /64 from 3GPP interface to LAN interface and run 3GPP interface with only Link Local while tethering. This results in active connection possibly being bounced while tethering is turned on and off. 2) Alternatively, retain the /128 address on the 3GPP interface and copy the /64 to the LAN with the same address as /128. (same as is documented already in 00) CB > Thinking about it some more, perhaps the following model might achieve a = single IPv6 address identifying a single interface more conventionally - > > - 3GPP link is "unnumbered", only having a link local address > > - UE has a bridge instance, with a bridge virtual interface (BVI) that is= always present. > > - the IPv6 address configuration information (i.e. RA PIO for SLAAC) is r= eceived over the 3GPP link, but is used to configure global IPv6 address(es= ) on the BVI, leaving the 3GPP link "unnumbered". I think the "loophole" th= at would allow this is that I don't think IPv6 requires that the address co= nfiguration information used to configure addresses on an interface is requ= ired to arrive over that interface, although commonly it does. > > - tethering is enabled or disabled by adding or removing the LAN interfac= e(s) to or from the bridge. An optimisation would be to issue RAs immediate= ly after the LAN interface is enabled. > > - conventional routing will take care of forwarding traffic received over= the 3GPP interface to the global addresses on the BVI. > > Regards, > Mark. > > > > > >>CB >>> Regards, >>> Mark. >> >> >> From ales.vizdal@t-mobile.cz Tue Jan 22 13:46:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1021F89A3 for ; Tue, 22 Jan 2013 13:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgbgfSZgkoBF for ; Tue, 22 Jan 2013 13:46:38 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 81C9821F899F for ; Tue, 22 Jan 2013 13:46:37 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 0B88D28582F; Tue, 22 Jan 2013 22:46:33 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 22 Jan 2013 22:46:32 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Mark Smith , Cameron Byrne Date: Tue, 22 Jan 2013 22:42:05 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: Ac342B2m2Ezy5zOyS4WZI4JaTvTNQQACenvg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CF9C940A@SRVHKE02.rdm.cz> References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:46:39 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Mark > Smith > Sent: Tuesday, January 22, 2013 8:38 PM > To: Cameron Byrne > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-64share =20 > Translational bridging goes back to the token ring and ethernet days. At = layer 2 they > were similar enough (because they were both IEEE standards), to be able t= o translate > reasonably effectively between them, such that they combined token ring/e= thernet > LAN was presented as a single link at layer 3. I was wondering about reus= ing that > model because it could have been a way to avoid duplicating the 3GPP addr= ess on the > LAN interface. Whether it is possible to do between 3GPP and Ethernet wou= ld depend > on how similar they are at layer 2, although one thing that would probabl= y help is that > the 3GPP link (if I understand correctly), is a point to point link, so t= he translational > bridging would really only be to present the single remote 3GPP device as= an ethernet > device on the LAN interface. To my understanding there is no link-layer addressing at the 3GPP interface= , so it wouldn't be easy to do l2 bridging. > Regards, > Mark. Cheers, Ales From cb.list6@gmail.com Tue Jan 22 15:48:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FCA21F8753 for ; Tue, 22 Jan 2013 15:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTQQNo4nVvv6 for ; Tue, 22 Jan 2013 15:48:08 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 91DE221F84DA for ; Tue, 22 Jan 2013 15:48:07 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id er20so2607774lab.4 for ; Tue, 22 Jan 2013 15:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=8BaY5StRq/ttTOvy2LcoaIrw77qz3DZEB0xwKl884oY=; b=k/HGb+tudeluZ1MlCtLdOiE2cQu/zMnNCTkuTpkZdWvUktX0dIsF2CR2XFjWY7kFMg 6m5uT2f27Jhs4NGo+0mqNRQUoZLLkOUkJQXqLs2lbWwxjKXwPnJqyBtwyFa7S/vc0o5c lBthCSm4bYhCNmpX6fOtAJCiD8kTxkpIVr7tyPcVJJu6kSTRRTlr93EMOIDpGGFlsxT7 lpcTsgd69k6vAiV7se1euJ7gXybGT1FNMEXPpGkfs57rMEV/EE1lgrdTFDTYYtWuq/z4 Bs6XtHgSAy6eA90+1/noiOnqT4euKhJLReUA1InZQOJGkErVFcry0wmks+nIiipZyPC6 TOwg== MIME-Version: 1.0 X-Received: by 10.152.144.130 with SMTP id sm2mr22993905lab.49.1358898486526; Tue, 22 Jan 2013 15:48:06 -0800 (PST) Received: by 10.112.44.36 with HTTP; Tue, 22 Jan 2013 15:48:06 -0800 (PST) Received: by 10.112.44.36 with HTTP; Tue, 22 Jan 2013 15:48:06 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Jan 2013 15:48:06 -0800 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=e89a8f2348a99342c704d3e9353d Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:48:09 -0000 --e89a8f2348a99342c704d3e9353d Content-Type: text/plain; charset=ISO-8859-1 Relevant for this thread http://prolixium.com/blog?id=984 Sent from ipv6-only Android On Jan 19, 2013 5:23 PM, "Cameron Byrne" wrote: > Hi, > > I posted this update as a WG draft > > http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 > > Please take the time to review this update and share your feedback. I > hoping that a clearly defined scope, clear need for this work, as well > running code will make it easy to advance. I am now aware of 3 > implementations that approximately use this method (ios6, an LTE mifi > router, and Dan Drown's Android submission) > > CB > > Sent from ipv6-only Android > --e89a8f2348a99342c704d3e9353d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Relevant for this thread http://prolixium.com/blog?id=3D984

Sent from ipv6-only Android

On Jan 19, 2013 5:23 PM, "Cameron Byrne&quo= t; <cb.list6@gmail.com> wro= te:

Hi,

I posted this update as a WG draft

http://tools.ietf.org/html/draft-ietf-v6ops-64shar= e-00

Please take the time to review this update and share your fe= edback.=A0 I hoping that a clearly defined scope, clear need for this work,= =A0 as well running code will make it easy to advance. I am now aware of 3 = implementations that approximately use this method (ios6, an LTE mifi route= r, and Dan Drown's Android submission)

CB

Sent from ipv6-only Android

--e89a8f2348a99342c704d3e9353d-- From markzzzsmith@yahoo.com.au Wed Jan 23 10:41:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC60A21F85D9 for ; Wed, 23 Jan 2013 10:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMiK-w9WyTCH for ; Wed, 23 Jan 2013 10:41:40 -0800 (PST) Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfa.amsl.com (Postfix) with SMTP id 3D29D21F86BE for ; Wed, 23 Jan 2013 10:41:40 -0800 (PST) Received: from [98.139.212.148] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jan 2013 18:41:39 -0000 Received: from [98.139.215.249] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jan 2013 18:41:39 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 23 Jan 2013 18:41:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 674764.39560.bm@omp1062.mail.bf1.yahoo.com Received: (qmail 38315 invoked by uid 60001); 23 Jan 2013 18:41:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1358966499; bh=hhbAcq7k2RTpmtk83uSCR+pzNZtC+/dBTyAWUN48gtQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HpfRbcOIT7+kzEsP+VH0u0IffCYRDFOJYupxXbpRfYbZztfnRsw8H0eCIv0qy20WNw5/9xYBQQG1Cvu8jatlWCD1VLGmX56ZYLUzzAD9zYHS4wk1ORBoM5od1Bgpk17apBLZoN26RPRZXYlwhkPmSE4wftNP2NTVuyQG0npV6R4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iUcsOBFxZ3mIa+tmWf2cNxM6hVWsGnE0WAuhTeBB1nMP1eXQ5Yb8NSpiVHqpHWGGWnx20fiCY8+lQ/khrtnVLUghB2swWpDOIEVI496nvzj+2gfUmXkzIIwUpdgyq4Td0h6zrBRGl4s25GNGzqDtv8Ab6oWViagPtpbAMCJEvMM=; X-YMail-OSG: O5KkvFAVM1mJTIZYrGoe93i6gEX4FbZCOtTSh2J1qKzHI0_ oCsfSNx_UrkvYM8CttC.upCGxdEMtYT1Oski8sK0GJLXAgwvdS6Dn3CcsF9p vz1sgfUfTAZA8lGo2XeyO_2Vb2XQaQuM1wNpGvwyvWttKHyH_gbgalJv5kds 2CK2KGBSMOC89KlKZRz3nNWOCw_EqeGoIXxEhz23vv1wWQ_jk136XQ2wXUUr 5qukI9EsVUkuq5aGGOufq5pviMK3uFYtoYFhaBO9pU7qZmIrHBMoHextXbmL CStvCdGCwRhHraD.DPXgXmg0uusSYZiSZOZasvBii8BkrAHywdNAacz5H6l2 Y51IAYpb2jNOAgJE4nrHLCQobwYu4zS2rOGHDhov6dhdHoSH87_rbsc03gD5 rUunEpI5WSus8GOZPwxhduFiVzrd5Y.RnGC1ii4jbsioF1IrFG14qozQ52wO ey5A5HeiVuXh6eu6lOA4d0b3onijGwD1eP6_r0Ct52..5hfaHwNW7RcqcOVb 8nfBNO3XdY2uulkdYRsbuHbwa Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Wed, 23 Jan 2013 10:41:39 PST X-Rocket-MIMEInfo: 001.001, CkhpIENhbWVyb24sCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBDYW1lcm9uIEJ5cm5lIDxjYi5saXN0NkBnbWFpbC5jb20.Cj5UbzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4gCj5DYzogdjZvcHMgdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IE1vbmRheSwgMjEgSmFudWFyeSAyMDEzIDQ6MDcgQU0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtNjRzaGFyZQo.IAo.Cj5NYXJrLAo.SnVzdCBvbiB0aGUgdGhpcyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> Message-ID: <1358966499.33291.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Wed, 23 Jan 2013 10:41:39 -0800 (PST) From: Mark Smith To: Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:41:41 -0000 =0AHi Cameron,=0A=0A>________________________________=0A> From: Cameron Byr= ne =0A>To: Mark Smith =0A>C= c: v6ops v6ops WG =0A>Sent: Monday, 21 January 2013 4:07 A= M=0A>Subject: Re: [v6ops] draft-ietf-v6ops-64share=0A> =0A>=0A>Mark,=0A>Jus= t on the this one topic=0A>=0A>> Actually, reviewing the IPv6 Address= ing Model in RFC4291, it says, "An IPv6 unicast address refers to a single = interface."=A0=0A>>=0A>Should we explicitly call it anycast then? Is that w= orth noting in the draft, citing=A0 tools.ietf.org/html/rfc4291#section-2.6= =0A=0AWhile I think what you're doing could qualify as anycast, as the abov= e text says, anycast addresses have to be flagged as anycast addresses -=0A= =0A"the nodes to which the address is=0A=A0 =A0assigned must be explicitly = configured to know that it is an anycast=0A=A0 =A0address."=0A=0AThat influ= ences ND operation for the anycast address - the first ND NA response recei= ved after a ND NS is the one accepted, rather than the last, and Duplicate = Address Detection is switched off for the anycast address. If my understand= ing is correct, the latter defeats one of the main motivations for duplicat= ing the address on the 3GPP and LAN interfaces in your scenario in the firs= t place.=0A=0AND NS/NA handling anycast text=0Ahttps://tools.ietf.org/html/= rfc4861#section-7.2.7=0A=0A=0A=0AND anycast DAD text=0Ahttps://tools.ietf.o= rg/html/rfc4862#section-5.4=0A=0A=0A=0ARegards,=0AMark. From alexandru.petrescu@gmail.com Thu Jan 24 00:27:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9921F8457 for ; Thu, 24 Jan 2013 00:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcklzztK4E0X for ; Thu, 24 Jan 2013 00:27:49 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 489BE21F844C for ; Thu, 24 Jan 2013 00:27:49 -0800 (PST) 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 r0O8RljV007840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Jan 2013 09:27:47 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0O8RlNJ027560 for ; Thu, 24 Jan 2013 09:27:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0O8RT5T014700 for ; Thu, 24 Jan 2013 09:27:46 +0100 Message-ID: <5100F071.2050101@gmail.com> Date: Thu, 24 Jan 2013 09:27:29 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 08:27:50 -0000 Le 22/01/2013 21:34, Cameron Byrne a écrit : > Mark, > > On Tue, Jan 22, 2013 at 11:38 AM, Mark Smith > wrote: >> >> Hi Cameron, >> >> >>> ________________________________ From: Cameron Byrne >>> To: Mark Smith >>> Cc: v6ops v6ops WG Sent: Monday, 21 January >>> 2013 3:53 AM Subject: Re: [v6ops] draft-ietf-v6ops-64share >>> >>> >>> Mark, Sent from ipv6-only Android On Jan 20, 2013 3:31 AM, "Mark >>> Smith" wrote: >>>> >>>> Hi, >>>> >>>> >>>>> ________________________________ From: Cameron Byrne >>>>> To: v6ops@ietf.org Sent: Sunday, 20 >>>>> January 2013 12:23 PM Subject: [v6ops] >>>>> draft-ietf-v6ops-64share >>>>> >>>>> >>>>> Hi, I posted this update as a WG draft >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 >>>>> Please take the time to review this update and share your >>>>> feedback. I hoping that a clearly defined scope, clear need >>>>> for this work, as well running code will make it easy to >>>>> advance. I am now aware of 3 implementations that >>>>> approximately use this method (ios6, an LTE mifi router, and >>>>> Dan Drown's Android submission) >>>> >>>> Regarding this text, >>>> >>>> 9. Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is >>>> the only instance of the assigned /64 on the 3GPP interface, >>>> there is no chance of an address conflict on that interface. On >>>> the LAN interface, there is no chance of address conflict since >>>> the >>>> >>>> >>>> >>>> Byrne Expires June 17, 2013 [Page 4] >>>> >>>> V6OPS Working Group draft-ietf-v6ops-64share-00 >>>> December 14, 2012 >>>> >>>> >>>> address is defended using Duplicate Address Detection (DAD). >>>> >>>> I'd suggest adding something like "address is defended using >>>> Duplicate Address Detection (DAD), as the LAN interface is >>>> also assigned the address in use on the 3GPP interface." >>>> >>>> I struggled a bit with working out what was going on until it >>>> became clear that the 3GPP and LAN interfaces are using the >>>> same global unicast address. >>>> >>> The DAD procedure on the LAN is only scoped for the LAN. For the >>> 3gpp link, it is the fact that only 1 off-link address is >>> architecturally permitted by 3gpp that ensures no collision. Did >>> I parse your concern correctly? >> >> Initially what confused me was I thought the /128 that is assigned >> to the 3GPP interface had been "stolen" from within the /64 >> assigned to the LAN interface i.e. a hole had been punched in the >> /64, and that is why I wondered how DAD was working in that >> scenario. While covered in other areas, further reinforcing the >> duplication of the address when functions would break without it >> could be useful. >> >>>> I also think it would be better to be clearer about the type >>>> of IPv6 address and also cover that their may be multiple IPv6 >>>> addresses, such as privacy addresses on the 3GPP/LAN >>>> interface. For example, in 3. Method for Sharing the 3GPP >>>> Interface /64 to the Tethered LAN, >>>> >>>> "The UE checks to make sure the 3GPP interfaces is active and >>>> has an IPv6 address. If the interface does not have an IPv6 >>>> address, an attempt will be made to acquire one, or else the >>>> procedure will terminate." >>>> >>>> Strictly, the 3GPP interface always has an IPv6 address >>>> because it always has a link local address, so the above would >>>> be better if it clarified that the type of address to check for >>>> is a global IPv6 address. >>>> >>> Ack. I will change it to "globally scoped address" >>>> I'll have to do some digging, however I'm wondering if the >>>> sockets API might have an assumption that an individual IPv6 >>>> address is only assigned to a single interface. >>>> >>>> Actually, reviewing the IPv6 Addressing Model in RFC4291, it >>>> says, "An IPv6 unicast address refers to a single interface." >>>> >>>> Was a translational bridge model considered? That is, the 3GPP >>>> and LAN interfaces are part of a bridge instance, and a single >>>> bridge virtual layer 2/3 interface is assigned the UE's global >>>> unicast address within the /64, with a /64 prefix length. >>>> Enabling or disabling tethering would be a simple matter of >>>> administratively enabling/disabling the LAN interface. >>>> >>> Is there an ietf doc on what a translational bridge is? We >>> considered ndproxy but that method was deemed unfit due to >>> insufficient loop prevention. >> >> Translational bridging goes back to the token ring and ethernet >> days. At layer 2 they were similar enough (because they were both >> IEEE standards), to be able to translate reasonably effectively >> between them, such that they combined token ring/ethernet LAN was >> presented as a single link at layer 3. I was wondering about >> reusing that model because it could have been a way to avoid >> duplicating the 3GPP address on the LAN interface. Whether it is >> possible to do between 3GPP and Ethernet would depend on how >> similar they are at layer 2, although one thing that would >> probably help is that the 3GPP link (if I understand correctly), is >> a point to point link, so the translational bridging would really >> only be to present the single remote 3GPP device as an ethernet >> device on the LAN interface. >> > > I think would rather avoid any of this translational bridging > business. And in fact, i am only trying to document running code to > avoid multiple divergent methods of achieving the same goal. As described, the 'translational' bridging looks new to me. It looks feasible, yes, yet I don't understand whether it would perform better than the method in the draft. I will read the draft better. > That said, it appears a few folks (Rajiv and Alex) have some > indigestion over having one IP address in multiple places. It works > for me, but i can accept that it may not work well for others. > > So, i think i can change the wording to allows for 2 methods > > 1) When tethering is enabled, move /64 from 3GPP interface to LAN > interface and run 3GPP interface with only Link Local while > tethering. This results in active connection possibly being bounced > while tethering is turned on and off. This is right - possibly the application on the UE using the global address may be interrupted if tethering is turned off. The implementation should make sure that when the tethering is turned off the address is assigned back again to the cellular interface. Speaking of which, I think it would be appropriate if the text discusses (if it does not already) that when the UE wants to tether it will become a Router. A Router will not use the PIO in RA to form a global address. I.e. if tethering is turned on, and followed by UE connecting to cellular, the UE will not have a global address on its cellular. (if on the other hand the UE first connects to cellular and then turns tethering on, the address will stay on the cellular interface for a while). > 2) Alternatively, retain the /128 address on the 3GPP interface and > copy the /64 to the LAN with the same address as /128. (same as is > documented already in 00) Yes, it is documented, steps 1-9. Alex > > CB > >> Thinking about it some more, perhaps the following model might >> achieve a single IPv6 address identifying a single interface more >> conventionally - >> >> - 3GPP link is "unnumbered", only having a link local address >> >> - UE has a bridge instance, with a bridge virtual interface (BVI) >> that is always present. >> >> - the IPv6 address configuration information (i.e. RA PIO for >> SLAAC) is received over the 3GPP link, but is used to configure >> global IPv6 address(es) on the BVI, leaving the 3GPP link >> "unnumbered". I think the "loophole" that would allow this is that >> I don't think IPv6 requires that the address configuration >> information used to configure addresses on an interface is >> required to arrive over that interface, although commonly it does. >> >> - tethering is enabled or disabled by adding or removing the LAN >> interface(s) to or from the bridge. An optimisation would be to >> issue RAs immediately after the LAN interface is enabled. >> >> - conventional routing will take care of forwarding traffic >> received over the 3GPP interface to the global addresses on the >> BVI. >> >> Regards, Mark. >> >> >> >> >> >>> CB >>>> Regards, Mark. >>> >>> >>> > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Jan 24 01:56:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E1421F85AD for ; Thu, 24 Jan 2013 01:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5EpaesVTmCS for ; Thu, 24 Jan 2013 01:56:47 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2518421F8584 for ; Thu, 24 Jan 2013 01:56:46 -0800 (PST) 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 r0O9uigb014410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Jan 2013 10:56:44 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0O9uim0013765 for ; Thu, 24 Jan 2013 10:56:44 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0O9uOli014260 for ; Thu, 24 Jan 2013 10:56:44 +0100 Message-ID: <51010548.3010104@gmail.com> Date: Thu, 24 Jan 2013 10:56:24 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1808340F7EC362469DDFFB112B37E2FCC6CF9C940A@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CF9C940A@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:56:48 -0000 Le 22/01/2013 22:42, Vízdal Aleš a écrit : >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith Sent: >> Tuesday, January 22, 2013 8:38 PM To: Cameron Byrne Cc: >> v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-64share > >> Translational bridging goes back to the token ring and ethernet >> days. At layer 2 they were similar enough (because they were both >> IEEE standards), to be able to translate reasonably effectively >> between them, such that they combined token ring/ethernet LAN was >> presented as a single link at layer 3. I was wondering about >> reusing that model because it could have been a way to avoid >> duplicating the 3GPP address on the LAN interface. Whether it is >> possible to do between 3GPP and Ethernet would depend on how >> similar they are at layer 2, although one thing that would probably >> help is that the 3GPP link (if I understand correctly), is a point >> to point link, so the translational bridging would really only be >> to present the single remote 3GPP device as an ethernet device on >> the LAN interface. > > To my understanding there is no link-layer addressing at the 3GPP > interface, so it wouldn't be easy to do l2 bridging. Well it depends. In general I think very many cellular interfaces on the UE do not use link-layer addressing. The devices have 'all-zero' MAC address, use the "NO_ARP" flag and so on. However, more recent devices (e.g. USB keys for LTE: bandrich C502, huawei e392, more) using qualcomm chipsets in some instances, using 'qmi' interfaces and drivers, exhibit a form of link-layer addressing. First, these devices use centrally-allocated IEEE identifiers for Company_ID. Suprisingly to some, the well known file oui.txt exhibits such id's for manufacturers of 3GPP-compatible equipment (traditionally it mentions only manufacturers of IEEE-compatible equipment). Second, some kernel modules, for instance in the 'qmi' family, form the last 3 bytes of a 48bit address. Finally, wireshark dumps of packets emitted by these cellular interfaces show Ethernet headers with MAC src and dst addresses, and interprets them according to oui.txt (wireshark interpretation is a good indicator about the width of the spread of some protocol). These three aspects make me think that maybe the new and future cellular interfaces may be more and more link-layer addressable. One consequence is the arrival of the use of classical ND on these links, and, why not, the bridging forms which are customary on Ethernet links. (caveat emptor: yes much intelligence exists in the small computer in a USB key that may make some things appear what they are not - proxying, on behalf of, etc. - yet they don't run the IP stack, it's the USB Host computer which runs the stack). Alex > >> Regards, Mark. > > Cheers, Ales _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Jan 24 02:39:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6621F8942 for ; Thu, 24 Jan 2013 02:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9QHLTDyfMSD for ; Thu, 24 Jan 2013 02:39:45 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id CF4FA21F86A5 for ; Thu, 24 Jan 2013 02:39:44 -0800 (PST) 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 r0OAdhgM032584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Jan 2013 11:39:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0OAdhb2002295 for ; Thu, 24 Jan 2013 11:39:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0OAdYZs012804 for ; Thu, 24 Jan 2013 11:39:43 +0100 Message-ID: <51010F66.5090605@gmail.com> Date: Thu, 24 Jan 2013 11:39:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:39:45 -0000 Le 23/01/2013 00:48, Cameron Byrne a écrit : > Relevant for this thread http://prolixium.com/blog?id=984 Right; is this ipv6 MASQUERADE implementing the RFC 6296 "IPv6-to-IPv6 Network Prefix Translation"? If yes then I think it is relevant to aspects of the problem that 64share solve. I.e. if one wants to do tethering one could use RFC6296 instead of 64share. This RFC could be cited and commented in the 64share draft. Alex > > Sent from ipv6-only Android > > On Jan 19, 2013 5:23 PM, "Cameron Byrne" > wrote: > > Hi, > > I posted this update as a WG draft > > http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 > > Please take the time to review this update and share your feedback. I > hoping that a clearly defined scope, clear need for this work, as > well running code will make it easy to advance. I am now aware of 3 > implementations that approximately use this method (ios6, an LTE mifi > router, and Dan Drown's Android submission) > > CB > > Sent from ipv6-only Android > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From ales.vizdal@t-mobile.cz Thu Jan 24 04:56:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09DC21F8996 for ; Thu, 24 Jan 2013 04:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGZkoeWLr6pS for ; Thu, 24 Jan 2013 04:56:59 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4004C21F8960 for ; Thu, 24 Jan 2013 04:56:58 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 95AE5285835; Thu, 24 Jan 2013 13:56:56 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 24 Jan 2013 13:56:56 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Thu, 24 Jan 2013 13:58:08 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: Ac36GS962/MbBN7yTEakNQUbQQSRfQAGKsxA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CF9C98B3@SRVHKE02.rdm.cz> References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1808340F7EC362469DDFFB112B37E2FCC6CF9C940A@SRVHKE02.rdm.cz> <51010548.3010104@gmail.com> In-Reply-To: <51010548.3010104@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 12:57:00 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Thursday, January 24, 2013 10:56 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-64share Alex, > > To my understanding there is no link-layer addressing at the 3GPP > > interface, so it wouldn't be easy to do l2 bridging. >=20 > Well it depends. >=20 > In general I think very many cellular interfaces on the UE do not use > link-layer addressing. The devices have 'all-zero' MAC address, use the > "NO_ARP" flag and so on. What are you seeing is not the 3GPP link traffic, but the Ethernet emulatio= n=20 done by the modem firmware. To be able to sniff on the 3GPP interface level you would need a tracer to see what's happening there. > However, more recent devices (e.g. USB keys for LTE: bandrich C502, > huawei e392, more) using qualcomm chipsets in some instances, using > 'qmi' interfaces and drivers, exhibit a form of link-layer addressing. >=20 > First, these devices use centrally-allocated IEEE identifiers for > Company_ID. Suprisingly to some, the well known file oui.txt exhibits > such id's for manufacturers of 3GPP-compatible equipment (traditionally > it mentions only manufacturers of IEEE-compatible equipment). >=20 > Second, some kernel modules, for instance in the 'qmi' family, form the > last 3 bytes of a 48bit address. >=20 > Finally, wireshark dumps of packets emitted by these cellular interfaces > show Ethernet headers with MAC src and dst addresses, and interprets > them according to oui.txt (wireshark interpretation is a good indicator > about the width of the spread of some protocol). >=20 > These three aspects make me think that maybe the new and future cellular > interfaces may be more and more link-layer addressable. >=20 > One consequence is the arrival of the use of classical ND on these > links, and, why not, the bridging forms which are customary on Ethernet > links. >=20 > (caveat emptor: yes much intelligence exists in the small computer in a > USB key that may make some things appear what they are not - proxying, > on behalf of, etc. - yet they don't run the IP stack, it's the USB Host > computer which runs the stack). >=20 > Alex Ales From alexandru.petrescu@gmail.com Thu Jan 24 05:00:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A9921F89EE for ; Thu, 24 Jan 2013 05:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p82t1wAvPoUQ for ; Thu, 24 Jan 2013 05:00:51 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id ED89C21F8960 for ; Thu, 24 Jan 2013 05:00:50 -0800 (PST) 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 r0OD0n2A024550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jan 2013 14:00:49 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0OD0nLT016721; Thu, 24 Jan 2013 14:00:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0OD0jaP018131; Thu, 24 Jan 2013 14:00:49 +0100 Message-ID: <5101307D.8050402@gmail.com> Date: Thu, 24 Jan 2013 14:00:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1808340F7EC362469DDFFB112B37E2FCC6CF9C940A@SRVHKE02.rdm.cz> <51010548.3010104@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6CF9C98B3@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CF9C98B3@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 13:00:51 -0000 Le 24/01/2013 13:58, Vízdal Ale¹ a écrit : >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, January 24, 2013 10:56 AM To: v6ops@ietf.org >> Subject: Re: [v6ops] draft-ietf-v6ops-64share > > Alex, > >>> To my understanding there is no link-layer addressing at the >>> 3GPP interface, so it wouldn't be easy to do l2 bridging. >> >> Well it depends. >> >> In general I think very many cellular interfaces on the UE do not >> use link-layer addressing. The devices have 'all-zero' MAC >> address, use the "NO_ARP" flag and so on. > > What are you seeing is not the 3GPP link traffic, but the Ethernet > emulation done by the modem firmware. YEs to some extent. But what that firmware does may be more than simple emulation. (an emulator would not generate packets at its will but only upon request). An IP stack is happier to work with an emulator than with a 3GPP link. > To be able to sniff on the 3GPP interface level you would need a > tracer to see what's happening there. Ok, but what is a tracer? Where can I obtain one? Do you mean wireshark? Alex > >> However, more recent devices (e.g. USB keys for LTE: bandrich >> C502, huawei e392, more) using qualcomm chipsets in some instances, >> using 'qmi' interfaces and drivers, exhibit a form of link-layer >> addressing. >> >> First, these devices use centrally-allocated IEEE identifiers for >> Company_ID. Suprisingly to some, the well known file oui.txt >> exhibits such id's for manufacturers of 3GPP-compatible equipment >> (traditionally it mentions only manufacturers of IEEE-compatible >> equipment). >> >> Second, some kernel modules, for instance in the 'qmi' family, form >> the last 3 bytes of a 48bit address. >> >> Finally, wireshark dumps of packets emitted by these cellular >> interfaces show Ethernet headers with MAC src and dst addresses, >> and interprets them according to oui.txt (wireshark interpretation >> is a good indicator about the width of the spread of some >> protocol). >> >> These three aspects make me think that maybe the new and future >> cellular interfaces may be more and more link-layer addressable. >> >> One consequence is the arrival of the use of classical ND on these >> links, and, why not, the bridging forms which are customary on >> Ethernet links. >> >> (caveat emptor: yes much intelligence exists in the small computer >> in a USB key that may make some things appear what they are not - >> proxying, on behalf of, etc. - yet they don't run the IP stack, >> it's the USB Host computer which runs the stack). >> >> Alex > > Ales > > From ales.vizdal@t-mobile.cz Thu Jan 24 06:55:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357E621F8A56 for ; Thu, 24 Jan 2013 06:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdUjcWXnIFEI for ; Thu, 24 Jan 2013 06:55:49 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id AB02B21F8A53 for ; Thu, 24 Jan 2013 06:55:49 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id A73E428582B; Thu, 24 Jan 2013 15:55:48 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 24 Jan 2013 15:55:48 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Thu, 24 Jan 2013 15:56:36 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: Ac36OlghSip8uC3ISVeq0ORrHVvU/QABsAIA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CF9C992E@SRVHKE02.rdm.cz> References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1808340F7EC362469DDFFB112B37E2FCC6CF9C940A@SRVHKE02.rdm.cz> <51010548.3010104@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6CF9C98B3@SRVHKE02.rdm.cz> <5101307D.8050402@gmail.com> In-Reply-To: <5101307D.8050402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 14:55:50 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, January 24, 2013 2:01 PM > To: V=EDzdal Ale=B9 > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-64share Alex, > > To be able to sniff on the 3GPP interface level you would need a > > tracer to see what's happening there. >=20 > Ok, but what is a tracer? Where can I obtain one? That's something the chipset vendors can provide the terminal testers with, so they can see the 3gpp link traffic in the provided tracing softwar= e. > Do you mean wireshark? No, I don't as wireshark cannot be attached directly to the 3gpp link as it has no access to it. =20 > Alex Ales From ales.vizdal@t-mobile.cz Thu Jan 24 07:07:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9221F8A79 for ; Thu, 24 Jan 2013 07:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqji6GPguVLn for ; Thu, 24 Jan 2013 07:07:04 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB2B21F8A56 for ; Thu, 24 Jan 2013 07:07:04 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id C19EA285832; Thu, 24 Jan 2013 16:07:03 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 24 Jan 2013 16:07:03 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Thu, 24 Jan 2013 16:08:21 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: Ac36HyypSe+lEzmBR86gAkbzyY95UAAJChDg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CF9C9943@SRVHKE02.rdm.cz> References: <51010F66.5090605@gmail.com> In-Reply-To: <51010F66.5090605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 15:07:05 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Thursday, January 24, 2013 11:40 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-64share >=20 > Le 23/01/2013 00:48, Cameron Byrne a =E9crit : > > Relevant for this thread http://prolixium.com/blog?id=3D984 Alex, =20 > Right; is this ipv6 MASQUERADE implementing the RFC 6296 "IPv6-to-IPv6 > Network Prefix Translation"? there are two ip6tables modules available - ip6t_NAt that is providing RFC6296 support that allows you to set the IPv6 prefix IPv6 packets will be translated to and ip6t_MASQUERADE that is taking the prefix from a defined interface (e.g. wwan0). > If yes then I think it is relevant to aspects of the problem that > 64share solve. I.e. if one wants to do tethering one could use RFC6296 > instead of 64share. >=20 > This RFC could be cited and commented in the 64share draft. Well, there is a difference as the current draft allows for /64 sharing and= =20 a GUA to be assigned to a host, the 6296 approach wouldn't support it. (i am not saying that's bad, just noting it) > Alex Ales From cb.list6@gmail.com Thu Jan 24 09:04:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C9C21F8922 for ; Thu, 24 Jan 2013 09:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-HSl-QAjzmx for ; Thu, 24 Jan 2013 09:04:46 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3585121F8884 for ; Thu, 24 Jan 2013 09:04:46 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id jk13so843886bkc.11 for ; Thu, 24 Jan 2013 09:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Yd96opWxhXViw5yQ2ZblFL6wvxIPhTYEiYWWW5du2x8=; b=B8bUu6hTKJvlrWSIyjQOdcucZy3lF+Xha4kLCe/FbtjT5qlikYMN9MqGcJ7bbfVRJx SQlir+gGQkG6ja8OZ3fvwuklcI8i+eSgXzhcg4Epm0kO8b97FOb24ROWdIKXY2P7BPNI 0obdm3hsM+HvQybi2dVsSN9YCGwmPD1K5HtuYBE/Iznijf+oqQVyvz7ydyP9uNqJRoG/ BbMKVGcydLDK7q//Gesv9bDkhLAYzrVyTm4RH/VIWUELxRedjo7wdlqHkFPMvLDIlSU6 6sj/hxuZmnQZ0um3v1bBD6sDv2qFVp6oPvkIm66WCRHvcJJYru1wJy1Bnd+JyAu1C45G C4bA== MIME-Version: 1.0 X-Received: by 10.152.132.137 with SMTP id ou9mr2588512lab.7.1359047084975; Thu, 24 Jan 2013 09:04:44 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 24 Jan 2013 09:04:44 -0800 (PST) In-Reply-To: References: <2CF4CB03E2AA464BA0982EC92A02CE2501E2E981@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Thu, 24 Jan 2013 09:04:44 -0800 Message-ID: From: Cameron Byrne To: Hui Deng , wangzhenkai@chinamobile.com Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , Hui Deng Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:04:47 -0000 Wang Zhen Kai, Can you please respond to the IETF v6ops group about your IPR concerns for China Mobile regarding draft-ietf-v6ops-464xlat ? Is there a way for China Mobile to change the IPR terms? Can China Mobile clearly communicate which part of draft-ietf-v6ops-464xlat has an infringement? Making an IPR claim without any dialog reflects poorly on China Mobile. It would be very unfortunate for the IETF to terminate this without a dialog. Regards, Cameron On Thu, Jan 10, 2013 at 11:53 PM, Hui Deng wrote: > Cameron > > As an individual participant of IETF, I am not the right people to answer > this, > it says the contact from the below link: > > > https://datatracker.ietf.org/ipr/1730/ > > > so I am cc to him now. > > Best regards, > > -Hui > > > 2013/1/11 Cameron Byrne >> >> Hui, Deng and v6ops, >> >> On Thu, Jan 10, 2013 at 4:41 PM, Randy Bush wrote: >> > thanks for the flag, ron. imiho >> > >> > "Reasonable and Non-Discriminatory License to All Implementers with >> > Possible Royalty/Fee." >> > >> > is a pretty much a show-stopper >> > >> >> >> As you can see, we have a problem. The IESG only has this final IPR >> issue to resolve before publishing 464XLAT. >> >> I see a few ways forward: >> >> 1. China Mobile can grant free use for the benefit of the IETF and >> the benefit of global IPv6 adoption and on-going evolution of the >> Internet >> >> 2. The IETF can move forward on the basis that the IPR claim is invalid*. >> >> 3. Other options??? >> >> Regards, >> >> CB >> >> *I am not a lawyer, but the 464XLAT draft is just a combination of >> existing technologies, none of which has IPR. And, AFAIK [1], it is >> not legitimate to patent a combination of existing technologies .... >> which is what the IPR claim is. NAT-PT goes back to the year 2000 as >> prior art. >> >> So, simple analysis, says this patent is not valid. Yet, we have this >> claim. >> >> CB >> >> [1] -- >> http://www.nolo.com/legal-encyclopedia/combination-invention-patentable-patents-29891.html >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Jan 24 09:39:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBADA21F89B9 for ; Thu, 24 Jan 2013 09:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.679 X-Spam-Level: X-Spam-Status: No, score=-9.679 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zZDnpUoMcHk for ; Thu, 24 Jan 2013 09:39:10 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44A21F87C5 for ; Thu, 24 Jan 2013 09:39:10 -0800 (PST) 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 r0OHd8KV010681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Jan 2013 18:39:08 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0OHd88l029553 for ; Thu, 24 Jan 2013 18:39:08 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0OHcuHg020505 for ; Thu, 24 Jan 2013 18:39:08 +0100 Message-ID: <510171B0.9000904@gmail.com> Date: Thu, 24 Jan 2013 18:38:56 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Comments on draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:39:15 -0000 Cameron, thank you for the new version, and as WG item. I have some comments below, if time allows. This is my personal oppinion. Le 20/01/2013 02:23, Cameron Byrne a écrit : > Hi, > > I posted this update as a WG draft > > http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 > > Please take the time to review this update and share your feedback. I > hoping that a clearly defined scope, clear need for this work, as > well running code will make it easy to advance. I am now aware of 3 > implementations that approximately use this method (ios6, an LTE mifi > router, and Dan Drown's Android submission) Well, in addition to this mostly handheld mobile device implementations, one could add a larger PC variable platform for deploying in vehicles - a Mobile Router using ubuntu linux, on atom 32bit and 64bit, with 3G, LTE-in-3G-mode testing using nokia, icon, bandrich and huawei USB keys and miniPCI 3G+, with ppp and qmi. The method described in the draft was tested, as well as some variations of it (e.g. assign the IP address solely on the LAN interface and remove it from the WWAN interface; configure the IPv6 address from RA or scripted, on ptp link or on Ethernet 'emulated' link, etc.). BAsed on that experience I comment on the draft below. > This document describes a known and implemented method of sharing a > /64 IPv6 prefix from a User Equipment 3GPP radio interface to a > tethered LAN. This is a terminology discussion, but I have some issues digesting this use of the word 'sharing'. It is not blocking comments, and we could pursue with it ok. 'Sharing' one personal 3G subscription with several other users is ok. But 'sharing' a prefix across two links - especially if it's a /64 - is very hard to understand. Or we could find something else instead of 64sharing. Sounds to me more like 'extending the use of a /64 beyond the link initially allocated' or 'making a Host into a Router when only one /64 prefix is valid on only one of its interfaces which is a Ethernet-compatible' or 'Point-to-Point IPv6 extended with a shared Ethernet' or something else. The problems I have are about this '64' which sounds like '6 to 4', as if we used the IPv4 cell connection to form an IPv6 prefix for WLAN. And with the 'sharing', because the prefix is not shared at all - it is _moved_ from one interface to the other. I am using a lot the term 'shared link' (between Hosts on a link) and and they are not as in the way described in this draft. I also have problems with the word 'tethering' because in many cases there's actually no tether - it's without wires (exception USB cable or Ethernet cable). With the vehicle case, the PC Mobile Router has most likely wireless interfaces. > this document describes how the 3GPP UE interface assigned /64 subnet > may be shared from the 3GPP interface to a tethered LAN. That /64 is maybe little 'assigned' - I think it is rather 'announced' on that ptp link. The 3GPP uses indeed the term 'assign a /64 to a UE' but I dont like it. > This is achieved by specifying the UE 3GPP interface as an IPv6 /128 > subnet taken from the 3GPP interface's network assigned /64 subnet. This has formulation and content problems, to my reading. I will follow it whether it evolves. > Then, assign the same address to the tethered LAN interface with the > full /64 subnet. This has formulation problems. How about: "Then, assign that address to the ingress interface, and set its prefix length on that interface as 64". 'tethered LAN' has problems because often it's WLAN and W means no tether. Reading 'tethered LAN' makes think that this does not work on WLAN or WPAN. > The /64 tethered LAN subnet will then be advertised to the tethered > LAN via Router Advertisements (RA) [RFC4861]. "The prefix and the prefix length received in the PIO in the RA on the cellular interface are copied in the PIO in the RA sent on the ingress interface". This is a non-typical operation (not seen elsewhere, other than maybe Router Renumbering) and yes deserves mentioning. > The end result is that all UE interfaces have link-local IPv6 > addresses, the UE's 3GPP interface has a /128 address from the 3GPP > network assigned /64, and the same address that is assigned to the > 3GPP interface is assigned to the tethered LAN interface with a /64 > subnet and advertised to the LAN via RA. This is too long, and a bit illogic, and a bit for discussion. Each UE interface does indeed have a ll address, but this is due to architecture spec, not an end result of this spec. 'UE 3GPP iface has a /128 address' - any other address is a /128, suffices it to say 'an address'. It is not necessary for the UE to keep that global address (derived from the IID of the interface, together with the PIO in the received RA). It can remove it altogether from the egress interface. Besides, when it becomes a Router, the UE will no longer self-configure an address based on the RA (and its IID) - it will just log the reception of that RA. > This approach only impacts the UE configuration and does not require > any changes to the 3GPP network. Yes, I agree, and deserves being mentioned. This is an important aspect which may lead to widespread deployment. I'd even stress that it does not need any changes to the 3GPP network nor to any other entity in the 3GPP network or elsewhere in the Internet. > Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been > suggested as an option for sharing the assigned /64 from the 3GPP > interface to the LAN, but ND Proxy is an experimental protocol and > has some limitations with loop-avoidance. ... and issues with security - proxying for somebody without that somebody agreeing to be represented may be seen as a leap of faith. > As [RFC6459] describes, the 3GPP network assigned /64 is completely > dedicated to the UE and the gateway does not consume any of the /64 > addresses. The gateway routes the entire /64 to the UE Yes. The method described in this document works because the gateway does not issue a NS for an IP address prefixed by the announced prefix on that link. The gateway considers (1) the route to be all towards a device, instead of towards a next-hop IP address (the route is expressed as a triplet "prefix-0-device" instead of "prefix-nexthop-device"), and (2) the link of the device to be point-to-point, with maximum two addresses on that link, and each address with link-local scope and (3) when the gateway needs to deliver a packet whose destination address matches that prefix in its routing table, it will not issue a NS to obtain the MAC address of the destination address. > and does not perform ND or Network Unreachability Detection (NUD) > [RFC4861]. Yes, too. > Communication between the UE and the gateway is only done using link- > local addresses and the link is point-to-point. Well I am not sure about the first part. I haven't seen much communication exclusively between the UE and the gateway (other than maybe the RAs). And, even if one removes the global address from the 3GPP interface (and assigns it on the ingress interface) it is still possible for the gateway to communicate to the UE by using their respective global address. However, some things which are more sure are: (1) the RA is sent to the a link-scoped multicast address, and with a link-local src address (2) the nexthop field of the default route entry in UE's routing table is a link-local address, etc. > This allows for the UE to use the 3GPP network assigned /64 to > assign itself a /128 address to the 3GPP radio interface for > consistent network connection formation and the same address with a > /64 to the tethered LAN interface. Again this is too long. I can understand it, but it could be shortened and I could propose if needed. > The tethered LAN interface may then advertise the /64 to the LAN with > RA. The LAN interface RA configuration must be tightly coupled with > the 3GPP interface state. If the 3GPP interface goes down or changes > address, that state should be reflected in the LAN IPv6 > configuration. YEs. > Just as in a standard IPv6 router, the packet TTL will be > decremented when passing packets between interfaces. Yes, and just as in a standard IPv6 Router, the UE will no longer form an IPv6 address at the reception of the RA on its egress interface (not as when it did when it was a Host). > The procedure may also be described in terms of the following usage > example: Yes, I read it and it works. Alternatively, one could describe a method with deletion of the Address from the egress interface. Alex PS: > 4. The UE copies the address 2001:db8:ac10:f002:1234:4567:0:9 with > a 64 bit mask from the 3GPP interfaces to the wireless LAN interfaces > and begins announcing the prefix 2001:db8:ac10:f002::/64 via RA to > the wireless LAN. (this is an example where it's written 'wireless LAN interfaces' and which means precisely the same that was referred to earlier as 'tethered LAN' - yet tether is not wireless). > 6. The UE directly processes all packets destine to itself at > 2001:db8:ac10:f002:1234:4567:0:9. 'destined'. And last 0 could be omitted or made an 8 instead. > > The UE should be compliant with the relevant requirements in [I- > D.draft-binet-v6ops-cellular-host-requirement]. In particular, it should not run QMI and not present the ptp link to the IP stack as a Ethernet link with MAC addresses. Otherwise the method in this document will fail. > 4. Security Considerations There is security problem if the operator of that 3GPP link does not want to allow several Hosts behind a single one. This problem is bigger when the link is LTE because the larger bandwidth (and lower latencies) compared to 3G will lead to more opportunities to share one LTE connection with more users. Alex > > CB > > Sent from ipv6-only Android > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Thu Jan 24 10:11:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52421F87FB for ; Thu, 24 Jan 2013 10:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWraPaTWQIDs for ; Thu, 24 Jan 2013 10:11:51 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 77FD221F8858 for ; Thu, 24 Jan 2013 10:11:47 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so4304884wgl.18 for ; Thu, 24 Jan 2013 10:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=NfiMf9egR3IDG1sbuX7/hc12krrR3oPmS7UWo9eRTaY=; b=TQy5p/XZeIwhijCgKuPGFhgkUSJeux1Q2n5NxwlfIg/n8snkjr0a8Z8XC7D5EorYdN 5sw2DKlqLbPuKgzxDS7COOe4EFzmTjQccQTx4fLF7a7fx3ZiFglhIrTh72MAsniQWQdI CIXL1RIQWRMlmKtgZ5L2yzmLtwSV7y27Xz07V1OZSitsO/TOBnZx+8cldSHJ6L8FRc2k 1nLzHTuZ/0otPjCvTaE+PF0mG4HX8dB1m7VQqtuvfQ8BndB6O+zKgs6mhqQoRa1uGylw n7EiO3Kee4QBjlbMV5Ouw0tGn7EIPz4u3c2V9nbcizdc6wHLmNPi63GVUy3i6Tkl53Fs NlNQ== MIME-Version: 1.0 X-Received: by 10.194.142.162 with SMTP id rx2mr4859903wjb.17.1359051106503; Thu, 24 Jan 2013 10:11:46 -0800 (PST) Received: by 10.194.46.232 with HTTP; Thu, 24 Jan 2013 10:11:46 -0800 (PST) In-Reply-To: <510171B0.9000904@gmail.com> References: <510171B0.9000904@gmail.com> Date: Thu, 24 Jan 2013 10:11:46 -0800 Message-ID: From: Cameron Byrne To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:11:53 -0000 Alex, Thanks for the detailed review. I am considering adding 2 more scenarios in addition to the one already described 1) The UE only has LLA, and just relays the 3GPP RA announced /64 to the LAN. In this case, the UE is effectively off-line while tethering since it does not have a global address, it is just doing a router function. 2) The same as above, but the UE assigns itself an address on the LAN. This avoids the multiple interface address issue. 3) Maintain the existing method which allows for long lived connections and is the running Android code that we have. If those 3 methods are defined, the solution becomes more general, so i would like feedback from the group on if the document should move to BCP , become more general, and remove all 3GPP related language. The BCP would say 1) Do DHCPv6-PD 2) when DHCPv6-PD is not available for whatever reason, these 3 method can support extending a /64 subnet from a WAN to a LAN. In Atlanta, there was discussion about the need for a more general solution= . CB On Thu, Jan 24, 2013 at 9:38 AM, Alexandru Petrescu wrote: > Cameron, thank you for the new version, and as WG item. > > I have some comments below, if time allows. This is my personal oppinion= . > > Le 20/01/2013 02:23, Cameron Byrne a =E9crit : >> >> Hi, >> >> I posted this update as a WG draft >> >> http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 >> >> Please take the time to review this update and share your feedback. I >> hoping that a clearly defined scope, clear need for this work, as >> well running code will make it easy to advance. I am now aware of 3 >> implementations that approximately use this method (ios6, an LTE mifi >> router, and Dan Drown's Android submission) > > > Well, in addition to this mostly handheld mobile device implementations, > one could add a larger PC variable platform for deploying in vehicles - > a Mobile Router using ubuntu linux, on atom 32bit and 64bit, with 3G, > LTE-in-3G-mode testing using nokia, icon, bandrich and huawei USB keys > and miniPCI 3G+, with ppp and qmi. > > The method described in the draft was tested, as well as some variations > of it (e.g. assign the IP address solely on the LAN interface and remove > it from the WWAN interface; configure the IPv6 address from RA or > scripted, on ptp link or on Ethernet 'emulated' link, etc.). > > BAsed on that experience I comment on the draft below. > >> This document describes a known and implemented method of sharing a >> /64 IPv6 prefix from a User Equipment 3GPP radio interface to a >> tethered LAN. > > > This is a terminology discussion, but I have some issues digesting this > use of the word 'sharing'. It is not blocking comments, and we could > pursue with it ok. > > 'Sharing' one personal 3G subscription with several other users is ok. > But 'sharing' a prefix across two links - especially if it's a /64 - is > very hard to understand. > > Or we could find something else instead of 64sharing. Sounds to me more > like > 'extending the use of a /64 beyond the link initially allocated' or > 'making a Host into a Router when only one /64 prefix is valid on only > one of its interfaces which is a Ethernet-compatible' or > 'Point-to-Point IPv6 extended with a shared Ethernet' > or something else. > > The problems I have are about this '64' which sounds like '6 to 4', as > if we used the IPv4 cell connection to form an IPv6 prefix for WLAN. > And with the 'sharing', because the prefix is not shared at all - it is > _moved_ from one interface to the other. > > I am using a lot the term 'shared link' (between Hosts on a link) and > and they are not as in the way described in this draft. > > I also have problems with the word 'tethering' because in many cases > there's actually no tether - it's without wires (exception USB cable or > Ethernet cable). With the vehicle case, the PC Mobile Router has most > likely wireless interfaces. > >> this document describes how the 3GPP UE interface assigned /64 subnet >> may be shared from the 3GPP interface to a tethered LAN. > > > That /64 is maybe little 'assigned' - I think it is rather 'announced' > on that ptp link. > > The 3GPP uses indeed the term 'assign a /64 to a UE' but I dont like it. > >> This is achieved by specifying the UE 3GPP interface as an IPv6 /128 >> subnet taken from the 3GPP interface's network assigned /64 subnet. > > > This has formulation and content problems, to my reading. I will follow > it whether it evolves. > >> Then, assign the same address to the tethered LAN interface with the >> full /64 subnet. > > > This has formulation problems. How about: > "Then, assign that address to the ingress interface, and set its prefix > length on that interface as 64". > > 'tethered LAN' has problems because often it's WLAN and W means no > tether. Reading 'tethered LAN' makes think that this does not work on > WLAN or WPAN. > >> The /64 tethered LAN subnet will then be advertised to the tethered >> LAN via Router Advertisements (RA) [RFC4861]. > > > "The prefix and the prefix length received in the PIO in the RA on the > cellular interface are copied in the PIO in the RA sent on the ingress > interface". This is a non-typical operation (not seen elsewhere, > other than maybe Router Renumbering) and yes deserves mentioning. > >> The end result is that all UE interfaces have link-local IPv6 >> addresses, the UE's 3GPP interface has a /128 address from the 3GPP >> network assigned /64, and the same address that is assigned to the >> 3GPP interface is assigned to the tethered LAN interface with a /64 >> subnet and advertised to the LAN via RA. > > > This is too long, and a bit illogic, and a bit for discussion. > > Each UE interface does indeed have a ll address, but this is due to > architecture spec, not an end result of this spec. > > 'UE 3GPP iface has a /128 address' - any other address is a /128, > suffices it to say 'an address'. > > It is not necessary for the UE to keep that global address (derived from > the IID of the interface, together with the PIO in the received RA). It > can remove it altogether from the egress interface. > > Besides, when it becomes a Router, the UE will no longer self-configure > an address based on the RA (and its IID) - it will just log the > reception of that RA. > >> This approach only impacts the UE configuration and does not require >> any changes to the 3GPP network. > > > Yes, I agree, and deserves being mentioned. This is an important aspect > which may lead to widespread deployment. I'd even stress that it does > not need any changes to the 3GPP network nor to any other entity in the > 3GPP network or elsewhere in the Internet. > >> Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been >> suggested as an option for sharing the assigned /64 from the 3GPP >> interface to the LAN, but ND Proxy is an experimental protocol and >> has some limitations with loop-avoidance. > > > ... and issues with security - proxying for somebody without that > somebody agreeing to be represented may be seen as a leap of faith. > >> As [RFC6459] describes, the 3GPP network assigned /64 is completely >> dedicated to the UE and the gateway does not consume any of the /64 >> addresses. The gateway routes the entire /64 to the UE > > > Yes. The method described in this document works because the gateway > does not issue a NS for an IP address prefixed by the announced prefix > on that link. The gateway considers (1) the route to be all towards a > device, instead of towards a next-hop IP address (the route is expressed > as a triplet "prefix-0-device" instead of "prefix-nexthop-device"), and > (2) the link of the device to be point-to-point, with maximum two > addresses on that link, and each address with link-local scope and (3) > when the gateway needs to deliver a packet whose destination address > matches that prefix in its routing table, it will not issue a NS to > obtain the MAC address of the destination address. > >> and does not perform ND or Network Unreachability Detection (NUD) >> [RFC4861]. > > > Yes, too. > >> Communication between the UE and the gateway is only done using link- >> local addresses and the link is point-to-point. > > > Well I am not sure about the first part. > > I haven't seen much communication exclusively between the UE and the > gateway (other than maybe the RAs). > > And, even if one removes the global address from the 3GPP interface (and > assigns it on the ingress interface) it is still possible for the > gateway to communicate to the UE by using their respective global address= . > > However, some things which are more sure are: (1) the RA is sent to the > a link-scoped multicast address, and with a link-local src address (2) > the nexthop field of the default route entry in UE's routing table is a > link-local address, etc. > >> This allows for the UE to use the 3GPP network assigned /64 to >> assign itself a /128 address to the 3GPP radio interface for >> consistent network connection formation and the same address with a >> /64 to the tethered LAN interface. > > > Again this is too long. > > I can understand it, but it could be shortened and I could propose if > needed. > >> The tethered LAN interface may then advertise the /64 to the LAN with >> RA. The LAN interface RA configuration must be tightly coupled with >> the 3GPP interface state. If the 3GPP interface goes down or changes >> address, that state should be reflected in the LAN IPv6 >> configuration. > > > YEs. > >> Just as in a standard IPv6 router, the packet TTL will be >> decremented when passing packets between interfaces. > > > Yes, and just as in a standard IPv6 Router, the UE will no longer form > an IPv6 address at the reception of the RA on its egress interface (not > as when it did when it was a Host). > >> The procedure may also be described in terms of the following usage >> example: > > > Yes, I read it and it works. > > Alternatively, one could describe a method with deletion of the Address > from the egress interface. > > Alex > PS: >> >> 4. The UE copies the address 2001:db8:ac10:f002:1234:4567:0:9 with >> a 64 bit mask from the 3GPP interfaces to the wireless LAN interfaces >> and begins announcing the prefix 2001:db8:ac10:f002::/64 via RA to >> the wireless LAN. > > > (this is an example where it's written 'wireless LAN interfaces' and > which means precisely the same that was referred to earlier as 'tethered > LAN' - yet tether is not wireless). > >> 6. The UE directly processes all packets destine to itself at >> 2001:db8:ac10:f002:1234:4567:0:9. > > > 'destined'. And last 0 could be omitted or made an 8 instead. > >> >> The UE should be compliant with the relevant requirements in [I- >> D.draft-binet-v6ops-cellular-host-requirement]. > > > In particular, it should not run QMI and not present the ptp link to the > IP stack as a Ethernet link with MAC addresses. Otherwise the method in > this document will fail. > >> 4. Security Considerations > > > There is security problem if the operator of that 3GPP link does not > want to allow several Hosts behind a single one. This problem is bigger > when the link is LTE because the larger bandwidth (and lower latencies) > compared to 3G will lead to more opportunities to share one LTE > connection with more users. > > Alex > >> >> CB >> >> Sent from ipv6-only Android >> >> >> >> _______________________________________________ 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 markzzzsmith@yahoo.com.au Thu Jan 24 11:25:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3719221F85E2 for ; Thu, 24 Jan 2013 11:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig8nKijGOJ8O for ; Thu, 24 Jan 2013 11:25:18 -0800 (PST) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by ietfa.amsl.com (Postfix) with SMTP id 45A4521F857D for ; Thu, 24 Jan 2013 11:25:18 -0800 (PST) Received: from [98.139.212.146] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2013 19:25:17 -0000 Received: from [98.139.212.203] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2013 19:25:17 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 24 Jan 2013 19:25:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 653063.85425.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 37742 invoked by uid 60001); 24 Jan 2013 19:25:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359055517; bh=AKTWPv1Z5t2MjDsAZqTHMUu7hghw2o5jglZWtjnNxZk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=emzSgJ4N8ZHHYsczNm6rV19s3vdcoi1Vr4WtEuJBWLnYa54lNrgEZr3XjTVgtA4W0itImpmCjZxRfuQFPolEiiw6DXKr01t8pv2n03Mz9sv0/IVMxb5B8FU9knD8L6tXnGyHIXvGseCZiRuYVyXN11frDmZogzjzT1pOnQB5saQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DeC0VoiFbd08Ydi03iE7+GaEjCQ5WjyXcrOOaqKkEERoE8s5Lyz3NNpxuAYeHnuPCf0j7iW5ixuGt36ni+bA8/PMbWy7z46Zki8aE3szThocag00yIOheotDBwBV0pcbxoTl/jInL5/NV85cAOB7ld9cwqYrxWPSsOQLSpqK2L4=; X-YMail-OSG: 1uJqgR0VM1mFIY7t8CvXisaWggh8_UdlN0ZFtlLQj0_HLoU 0sYxs9ZFvoUak5CJxhARD5iRBofZFtobUvilUQZUCSiH2q0Uqzolqp.PSz6n 6hJux1l9QoQ4NTQWC2sgUhZuXu.pElEytWhLeZzTjmpe16V.wiCEKKh.YZhk 5hEO5zExYdG3afLjTrkO0ve5s5NXJCG1.yVUivLH6N6_j0cctV30x5fNjGW2 .cMDNMHwi82CWnYik52bppDS7WXsZpmixIcZGfeJC4b7x.zrIei4bm883AC7 CwU2vyFLQUPt92UMajVDauu9Ey3AcCsa_q.SakyMnMPMoFBNmpNdoNGj9rjB sH5BN4Gwmo1DppWxVmdqx2bDYQL9t9MIOjVb8PAD3DCwhaPlo2BsFo_xrcLL VSLOISCl3KW44C607Uc_5YqTs64zh4jT7e4rFrq1tD71cY7NILt73fl9fwkZ g6Iw92hGIGK5YRITF9.y4UwoR84Vwrtp1OFe4DNsw5i.RN63LliGnH32YaOa 5LqyYkYh1C9BpkV.4CSmYo4Gdd5l5qe0clsp7FBQF7VKvTltM8Z3RcXzJ02t WHZdE5kmKpCLUlkhxBOmelasUkZeYmmpyJIlm3i7fLQ-- Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Thu, 24 Jan 2013 11:25:17 PST X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEFsZXhhbmRydSBQZXRyZXNjdSA8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4KPiBUbzogdjZvcHNAaWV0Zi5vcmcKPiBDYzogCj4gU2VudDogVGh1cnNkYXksIDI0IEphbnVhcnkgMjAxMyA5OjM5IFBNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02NHNoYXJlCj4gCj4gTGUgMjMvMDEvMjAxMyAwMDo0OCwgQ2FtZXJvbiBCeXJuZSBhIMOpY3JpdCA6Cj4.ICBSZWxldmFudCBmb3IgdGhpcyB0aHJlYWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <51010F66.5090605@gmail.com> Message-ID: <1359055517.36858.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Thu, 24 Jan 2013 11:25:17 -0800 (PST) From: Mark Smith To: Alexandru Petrescu , "v6ops@ietf.org" In-Reply-To: <51010F66.5090605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 19:25:19 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Alexandru Petrescu =0A> To: v6ops@ietf.org=0A> Cc: =0A> Sent: Thursda= y, 24 January 2013 9:39 PM=0A> Subject: Re: [v6ops] draft-ietf-v6ops-64shar= e=0A> =0A> Le 23/01/2013 00:48, Cameron Byrne a =E9crit :=0A>> Relevant fo= r this thread http://prolixium.com/blog?id=3D984=0A> =0A> Right; is this ip= v6 MASQUERADE implementing the RFC 6296 "IPv6-to-IPv6=0A> Network Prefix Tr= anslation"?=0A>=A0=0A=0ARFC6296 is=A0experimental, I think it would be bett= er to avoid it.=0A=0AGenerally I think there is nothing wrong the the model= being pursued, I think the only issue is making sure it complies with the = existing IPv6 addressing model and related expectations, such as API ones.= =0A=0A=0A=0A> If yes then I think it is relevant to aspects of the problem = that=0A> 64share solve.=A0 I.e. if one wants to do tethering one could use = RFC6296=0A> instead of 64share.=0A> =0A> This RFC could be cited and commen= ted in the 64share draft.=0A> =0A> Alex=0A> =0A>> =0A>> Sent from ipv6-onl= y Android=0A>> =0A>> On Jan 19, 2013 5:23 PM, "Cameron Byrne" > > wrote:=0A>> =0A>> Hi,=0A>> =0A>= > I posted this update as a WG draft=0A>> =0A>> http://tools.ietf.org/htm= l/draft-ietf-v6ops-64share-00=0A>> =0A>> Please take the time to review th= is update and share your feedback. I=0A>> hoping that a clearly defined sc= ope, clear need for this work,=A0 as=0A>> well running code will make it e= asy to advance. I am now aware of 3=0A>> implementations that approximatel= y use this method (ios6, an LTE mifi=0A>> router, and Dan Drown's Android = submission)=0A>> =0A>> CB=0A>> =0A>> Sent from ipv6-only Android=0A>> =0A= >> =0A>> =0A>> _______________________________________________ v6ops maili= ng list=0A>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops=0A= >> =0A> =0A> =0A> _______________________________________________=0A> v6ops= mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/= v6ops=0A> From joelja@bogus.com Thu Jan 24 18:47:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91A41F0CF7 for ; Thu, 24 Jan 2013 18:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxuxEMRvRtm2 for ; Thu, 24 Jan 2013 18:47:00 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07DA21F0CE4 for ; Thu, 24 Jan 2013 18:46:56 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0P2kuew096718 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 25 Jan 2013 02:46:56 GMT (envelope-from joelja@bogus.com) Message-ID: <5101F21B.2050204@bogus.com> Date: Thu, 24 Jan 2013 18:46:51 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> In-Reply-To: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 25 Jan 2013 02:46:56 +0000 (UTC) Subject: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 02:47:00 -0000 Fyi, I would call the attention of the wg to this new draft. Thanks joel -------- Original Message -------- Subject: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt Date: Thu, 24 Jan 2013 18:42:20 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A mechanism to allocate IPv6 blocks for BGP networks based on the networks AS Number Author(s) : Martin J. Levy Matthew Pounsett Filename : draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt Pages : 7 Date : 2013-01-24 Abstract: This document provides a methodology for automatically allocating IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] and are either single-homed or multi-homed [BARBER2011]. The automatic allocation is taken from a specific /16 block assigned by IANA for this purpose. Networks that require more than this single /48 can still request additional allocations via the existing RIR process. Networks are not forced to use this allocation and can ignore this completely. Availability of the /48 assignment via this mechanism does not change existing mechanisms for obtaining IPv6 assignments through the existing RIR (Regional Internet Registry) or LIR (Local Internet Registry) mechanisms. There is an implicit assumption that it's a good thing to promote networks to enable IPv6 with a near-zero effort. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mlevy-v6ops-auto-v6-allocation-per-asn There's also a htmlized version available at: http://tools.ietf.org/html/draft-mlevy-v6ops-auto-v6-allocation-per-asn-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From randy@psg.com Thu Jan 24 19:52:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2517F11E80DF for ; Thu, 24 Jan 2013 19:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXEJtKBDotiN for ; Thu, 24 Jan 2013 19:52:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C3AFE11E80DE for ; Thu, 24 Jan 2013 19:52:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TyaLZ-0006tf-H3; Fri, 25 Jan 2013 03:52:57 +0000 Date: Fri, 25 Jan 2013 12:52:56 +0900 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <5101F21B.2050204@bogus.com> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 03:52:59 -0000 > A mechanism to allocate IPv6 blocks for BGP networks based on the networks AS Number i advocate the wg adopting this this does not imply that i support it or not. only that i think that this wg is the proper place to discuss it. randy From cb.list6@gmail.com Thu Jan 24 20:55:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E85021F8769 for ; Thu, 24 Jan 2013 20:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfBTzc3zDPw5 for ; Thu, 24 Jan 2013 20:55:07 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 171D521F874B for ; Thu, 24 Jan 2013 20:55:06 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id gm6so48626lbb.40 for ; Thu, 24 Jan 2013 20:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A1/OH8crLtCrmOPSc6nS0etvF+6RXmjPKx8+RevmrDo=; b=W1ORdeqUhQpkL0G3Nowtqa28AYWiYw5NTp9lLTjh9Eb8DRgUvCzM+YzoV5+nDZs24q GylQfYOOgqM+cxbCHaCyb/f6AJpBstkorjP8X/fRXMvJF66K03EnijXFosN9OhxUY/RR npPcUZVcRuMPW4eeHtb19ZFAMtn4p8wyR9ER8BcHreNtaGzcywNxnUIWR1LglIhF1mPk Xat8sWpddTFsNmwVyEQiVobXyeZbg1GPnLU2Sy6MIAtQYd5QVxKiHrVzQxdQAHLJbL/L rzNWL+l+aXJyt6/JqNoFe4jvSCsuMTBGUWJCIiujZChMMuSlGi8i3OV/Dp7FOhKTEhO3 cE5A== MIME-Version: 1.0 X-Received: by 10.112.51.44 with SMTP id h12mr1639328lbo.111.1359089706072; Thu, 24 Jan 2013 20:55:06 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 24 Jan 2013 20:55:05 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 24 Jan 2013 20:55:05 -0800 (PST) In-Reply-To: <5101F21B.2050204@bogus.com> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> Date: Thu, 24 Jan 2013 20:55:05 -0800 Message-ID: From: Cameron Byrne To: joel jaeggli Content-Type: multipart/alternative; boundary=f46d0401714725fbd204d415bb0e Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 04:55:08 -0000 --f46d0401714725fbd204d415bb0e Content-Type: text/plain; charset=ISO-8859-1 I believe this I-D would benefit from a clearly articulated problem statement. Afaik, acquiring an ipv6 prefix is not a problem. Sent from ipv6-only Android --f46d0401714725fbd204d415bb0e Content-Type: text/html; charset=ISO-8859-1

I believe this I-D would benefit from a clearly articulated problem statement.
Afaik, acquiring an ipv6 prefix is not a problem.

Sent from ipv6-only Android

--f46d0401714725fbd204d415bb0e-- From sander@steffann.nl Thu Jan 24 23:22:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD77921F8A7B for ; Thu, 24 Jan 2013 23:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+pEgxoye4tf for ; Thu, 24 Jan 2013 23:22:40 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65821F8A79 for ; Thu, 24 Jan 2013 23:22:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 2C956200F; Fri, 25 Jan 2013 08:22:38 +0100 (CET) X-Virus-Scanned: 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 10024) with ESMTP id KEwUX9s9gmid; Fri, 25 Jan 2013 08:22:37 +0100 (CET) Received: from [IPv6:2a00:8640:1::a04c:fa4b:301e:52c6] (unknown [IPv6:2a00:8640:1:0:a04c:fa4b:301e:52c6]) by mail.sintact.nl (Postfix) with ESMTP id 529622008; Fri, 25 Jan 2013 08:22:33 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Fri, 25 Jan 2013 08:22:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1499) Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 07:22:41 -0000 Hi WG, >> A mechanism to allocate IPv6 blocks for BGP networks based on the = networks AS Number >=20 > i advocate the wg adopting this >=20 > this does not imply that i support it or not. only that i think that > this wg is the proper place to discuss it. +1 Sander From simon.perreault@viagenie.ca Fri Jan 25 01:20:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14A21F8804 for ; Fri, 25 Jan 2013 01:20:23 -0800 (PST) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZvCE8Ee7MqJ for ; Fri, 25 Jan 2013 01:20:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D67221F8830 for ; Fri, 25 Jan 2013 01:20:20 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c90c:4a03:ec7d:ee87]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B92CC403B7 for ; Fri, 25 Jan 2013 04:20:19 -0500 (EST) Message-ID: <51024E85.5090803@viagenie.ca> Date: Fri, 25 Jan 2013 10:21:09 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 09:20:29 -0000 Le 2013-01-25 05:55, Cameron Byrne a écrit : > I believe this I-D would benefit from a clearly articulated problem > statement. Afaik, acquiring an ipv6 prefix is not a problem. If I understand correctly, the problem statement would look something like this: "ASes that do not care or know about IPv6 will not request IPv6 space. This is sub-optimal for the promotion and adoption of IPv6." Discuss. Simon From brian.e.carpenter@gmail.com Fri Jan 25 02:17:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC7221F86F0 for ; Fri, 25 Jan 2013 02:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.587 X-Spam-Level: X-Spam-Status: No, score=-101.587 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtZhO5srr1DD for ; Fri, 25 Jan 2013 02:17:16 -0800 (PST) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id F2AC621F86DA for ; Fri, 25 Jan 2013 02:17:15 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id d13so87978eaa.14 for ; Fri, 25 Jan 2013 02:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lEe5BtXCjmy7YcE0IMYPQXWS7WyEd8xbTJG+2sD4qkw=; b=BhFC6CE7wB8ARdCXN+WoFllDK8n9CoXtU49bK6YWcZir+N1v20OxwtxLqbO1tiEgvl lsoZF7eJexUGYPxStyc4QDyp8imMJdIL8vk4ImiCP8FbhIH8iwOQ/sUh/MwlBwyd9LnF us+8BhgEkaiS0YQAKTsWDlRbW+wOIvqy85FVCCJKMh0VOzMMSpWJdmPrARdT34faoRdN ZAJ/WmXiG3gF3dcLQmivpkwbHCiarVf/Kmh0RRKwEBsbpLw/IFYZWkH2jj2xHGL64meL Jy+1j7GUMsStyXZkyki8L9pYc7aYns2sApH6MCNS/x6fMQ6IyE/Du0gVdGeOEDzjIHWt FohQ== X-Received: by 10.14.176.66 with SMTP id a42mr16645092eem.34.1359109034823; Fri, 25 Jan 2013 02:17:14 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-213.as13285.net. [2.102.216.213]) by mx.google.com with ESMTPS id q5sm915356eep.11.2013.01.25.02.17.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 02:17:14 -0800 (PST) Message-ID: <51025BB7.2060600@gmail.com> Date: Fri, 25 Jan 2013 10:17:27 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> In-Reply-To: <51024E85.5090803@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:17:16 -0000 On 25/01/2013 09:21, Simon Perreault wrote: > Le 2013-01-25 05:55, Cameron Byrne a =C3=A9crit : >> I believe this I-D would benefit from a clearly articulated problem >> statement. Afaik, acquiring an ipv6 prefix is not a problem. >=20 > If I understand correctly, the problem statement would look something > like this: >=20 > "ASes that do not care or know about IPv6 will not request IPv6 space. > This is sub-optimal for the promotion and adoption of IPv6." >=20 > Discuss. That argument seems irrelevant - people who don't deploy IPv6 still won't deploy it. The new prefix will simply sleep. I think another way of looking at it is: "Everybody who bothers to get an AS # automatically gets an IPv6 PI prefix." afaik, every IPv6-active AS will already contribute at least one IPv6 BGP4 announcement. I suspect that this proposal would likely add zero BGP4 entries in practice; it would just save the RIRs and LIRs some work in handing out PI prefixes. This doesn't change my underlying distaste for PI prefixes, but my first guess is that it would not additionally damage BGP4 scaling. The damage comes from the number of PI prefixes, not from the bit pattern in the prefixes. Brian From alexandru.petrescu@gmail.com Fri Jan 25 02:37:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3521C21F8700 for ; Fri, 25 Jan 2013 02:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.674 X-Spam-Level: X-Spam-Status: No, score=-9.674 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA1Wnx6mImdZ for ; Fri, 25 Jan 2013 02:37:08 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id E153021F871E for ; Fri, 25 Jan 2013 02:37:07 -0800 (PST) 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 r0PAb6JJ013301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Jan 2013 11:37:06 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0PAb6K3030744; Fri, 25 Jan 2013 11:37:06 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0PAaxRR002889; Fri, 25 Jan 2013 11:37:06 +0100 Message-ID: <5102604B.9060707@gmail.com> Date: Fri, 25 Jan 2013 11:36:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mark Smith References: <51010F66.5090605@gmail.com> <1359055517.36858.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1359055517.36858.YahooMailNeo@web142506.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:37:09 -0000 Le 24/01/2013 20:25, Mark Smith a écrit : > Hi, > > > ----- Original Message ----- >> From: Alexandru Petrescu To: >> v6ops@ietf.org Cc: Sent: Thursday, 24 January 2013 9:39 PM >> Subject: Re: [v6ops] draft-ietf-v6ops-64share >> >> Le 23/01/2013 00:48, Cameron Byrne a écrit : >>> Relevant for this thread http://prolixium.com/blog?id=984 >> >> Right; is this ipv6 MASQUERADE implementing the RFC 6296 >> "IPv6-to-IPv6 Network Prefix Translation"? >> > > RFC6296 is experimental, I think it would be better to avoid it. > > Generally I think there is nothing wrong the the model being > pursued, I think the only issue is making sure it complies with the > existing IPv6 addressing model and related expectations, such as API > ones. I am not sure which API expectations are considered. If API is BSD Socket, then I think there are some relationships with the ways the application on the UE uses the Address in question. The following sequence works: - assign IP address on egress interface - application stops - assign Address on ingress interface - delete Address from egress interface - application start Other sequences may work and yet others may not work. A sequence which may break the application is: - assign Address on egress interface - application start - delete Address from egress interface (application may break, packets may get lost) - add Address on the ingress interface (application may restart by itself or may need manual restart) Not sure whether this is the kind of API expectation which are considered. Yours, Alex > > > >> If yes then I think it is relevant to aspects of the problem that >> 64share solve. I.e. if one wants to do tethering one could use >> RFC6296 instead of 64share. >> >> This RFC could be cited and commented in the 64share draft. >> >> Alex >> >>> >>> Sent from ipv6-only Android >>> >>> On Jan 19, 2013 5:23 PM, "Cameron Byrne" >> > wrote: >>> >>> Hi, >>> >>> I posted this update as a WG draft >>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 >>> >>> Please take the time to review this update and share your >>> feedback. I hoping that a clearly defined scope, clear need for >>> this work, as well running code will make it easy to advance. I >>> am now aware of 3 implementations that approximately use this >>> method (ios6, an LTE mifi router, and Dan Drown's Android >>> submission) >>> >>> CB >>> >>> Sent from ipv6-only Android >>> >>> >>> >>> _______________________________________________ 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 gert@space.net Fri Jan 25 04:08:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83D21F85DB for ; Fri, 25 Jan 2013 04:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skK5sCG8gWAS for ; Fri, 25 Jan 2013 04:08:39 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id CFBEF21F85BB for ; Fri, 25 Jan 2013 04:08:37 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 11AB860337 for ; Fri, 25 Jan 2013 13:07:35 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E7312602B4 for ; Fri, 25 Jan 2013 13:07:34 +0100 (CET) Received: (qmail 32773 invoked by uid 1007); 25 Jan 2013 13:07:34 +0100 Date: Fri, 25 Jan 2013 13:07:34 +0100 From: Gert Doering To: Simon Perreault Message-ID: <20130125120734.GX51699@Space.Net> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51024E85.5090803@viagenie.ca> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:08:39 -0000 Hi, On Fri, Jan 25, 2013 at 10:21:09AM +0100, Simon Perreault wrote: > "ASes that do not care or know about IPv6 will not request IPv6 space. > This is sub-optimal for the promotion and adoption of IPv6." And having a mechanism for "if you care and know about, you can auto-assign an IPv6 /48 for yourself" will alleviate that? I'm fine having this in the WG to discuss, but the idea itself I find fairly useless - it's not solving the original problem, and it's causing a bunch of new interesting issues, like "update all tools that build routing filters / RPKI to take into account a new class of networks that is following different rules for route authorization". 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 (89) 32356-444 USt-IdNr.: DE813185279 From gert@space.net Fri Jan 25 04:16:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0A721F8873 for ; Fri, 25 Jan 2013 04:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2V8l40dgtJN for ; Fri, 25 Jan 2013 04:16:25 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 256B421F8859 for ; Fri, 25 Jan 2013 04:16:24 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 8C7796033C for ; Fri, 25 Jan 2013 13:16:23 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 61C78602E5 for ; Fri, 25 Jan 2013 13:16:23 +0100 (CET) Received: (qmail 35435 invoked by uid 1007); 25 Jan 2013 13:16:23 +0100 Date: Fri, 25 Jan 2013 13:16:23 +0100 From: Gert Doering To: Brian E Carpenter Message-ID: <20130125121623.GY51699@Space.Net> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51025BB7.2060600@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:16:25 -0000 Hi, On Fri, Jan 25, 2013 at 10:17:27AM +0000, Brian E Carpenter wrote: > "Everybody who bothers to get an AS # automatically gets > an IPv6 PI prefix." > > afaik, every IPv6-active AS will already contribute at least one > IPv6 BGP4 announcement. I suspect that this proposal would likely > add zero BGP4 entries in practice; it would just save the RIRs and LIRs > some work in handing out PI prefixes. > > This doesn't change my underlying distaste for PI prefixes, but > my first guess is that it would not additionally damage BGP4 scaling. > The damage comes from the number of PI prefixes, not from the bit > pattern in the prefixes. There is a small risk to it. If the RIR's PI policies are more strict than it's AS number policies (which is what we have in RIPE land right now), people might go for PA space under RIR policies, and not contribute a global routing entry. Having this proposal in place would then shift the question of "who can have an IPv6 PI entry in the global routing?" to the AS number policy, where it does not belong. Gert Doering -- RIPE APWG chair -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From sander@steffann.nl Fri Jan 25 04:36:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B4B21F8788 for ; Fri, 25 Jan 2013 04:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ+X65hAX6JX for ; Fri, 25 Jan 2013 04:36:11 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9FECA21F8795 for ; Fri, 25 Jan 2013 04:36:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id AE64D2040; Fri, 25 Jan 2013 13:36:10 +0100 (CET) X-Virus-Scanned: 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 10024) with ESMTP id E7jbxQ8y-D4u; Fri, 25 Jan 2013 13:36:08 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 25C742008; Fri, 25 Jan 2013 13:36:08 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <20130125121623.GY51699@Space.Net> Date: Fri, 25 Jan 2013 13:36:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:36:12 -0000 Hi, > There is a small risk to it. If the RIR's PI policies are more strict > than it's AS number policies (which is what we have in RIPE land right > now), people might go for PA space under RIR policies, and not = contribute > a global routing entry. Having this proposal in place would then = shift > the question of "who can have an IPv6 PI entry in the global routing?" = to > the AS number policy, where it does not belong. Doesn't it? Having an AS number means you can participate in the global = routing table. So by giving someone an AS number you (implicitly) allow = them to advertise prefixes there, right? ;-) Cheers, Sander From gert@space.net Fri Jan 25 04:43:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA4B21F86FB for ; Fri, 25 Jan 2013 04:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHPGTJDshoqV for ; Fri, 25 Jan 2013 04:43:32 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 6589121F8606 for ; Fri, 25 Jan 2013 04:43:32 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 6322B60372 for ; Fri, 25 Jan 2013 13:43:31 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 491B06033A for ; Fri, 25 Jan 2013 13:43:31 +0100 (CET) Received: (qmail 43134 invoked by uid 1007); 25 Jan 2013 13:43:31 +0100 Date: Fri, 25 Jan 2013 13:43:31 +0100 From: Gert Doering To: Sander Steffann Message-ID: <20130125124331.GZ51699@Space.Net> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WQlakiwWJnBZuvs8" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:43:33 -0000 --WQlakiwWJnBZuvs8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 25, 2013 at 01:36:07PM +0100, Sander Steffann wrote: > > There is a small risk to it. If the RIR's PI policies are more strict > > than it's AS number policies (which is what we have in RIPE land right > > now), people might go for PA space under RIR policies, and not contribu= te > > a global routing entry. Having this proposal in place would then shift > > the question of "who can have an IPv6 PI entry in the global routing?" = to > > the AS number policy, where it does not belong. >=20 > Doesn't it? Having an AS number means you can participate in the > global routing table. So by giving someone an AS number you > (implicitly) allow them to advertise prefixes there, right? ;-) Do I? I give them a unique identifier that they might need for something, like private peerings that still should have an unique identifier, building an internal confederation (where multiple ASes are externally only visible behind an aggregate), etc. 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 (89) 32356-444 USt-IdNr.: DE813185279 --WQlakiwWJnBZuvs8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUQJ986kuBuNlUUl1AQIOAAP/WUZ69r5njcnQttAvvzsnc1SfqnmFmYRO zs8jlibs/MrqgjH+Gauw+dCfnw9dyxP3KMGeZrJiiD7O8KlKuF2VVhDtbN/Ygcvh uTpUaxkfB3i0VePj0ok3NwVeuQRTzNjTP9x1+Y2jK9ziXlzBKxvKSZIS9L9Dp/qP 75/V60gh+Fg= =sPAZ -----END PGP SIGNATURE----- --WQlakiwWJnBZuvs8-- From sander@steffann.nl Fri Jan 25 04:49:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A379221F8B5B for ; Fri, 25 Jan 2013 04:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqWi01OZCzkJ for ; Fri, 25 Jan 2013 04:49:52 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4C621F8AB7 for ; Fri, 25 Jan 2013 04:49:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 64FEA2040; Fri, 25 Jan 2013 13:49:51 +0100 (CET) X-Virus-Scanned: 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 10024) with ESMTP id Now8ATTAj3y0; Fri, 25 Jan 2013 13:49:50 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id C292A2008; Fri, 25 Jan 2013 13:49:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <20130125124331.GZ51699@Space.Net> Date: Fri, 25 Jan 2013 13:49:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:49:52 -0000 Hi, >> Doesn't it? Having an AS number means you can participate in the >> global routing table. So by giving someone an AS number you >> (implicitly) allow them to advertise prefixes there, right? ;-) >=20 > Do I? I give them a unique identifier that they might need for = something, > like private peerings that still should have an unique identifier, = building > an internal confederation (where multiple ASes are externally only = visible > behind an aggregate), etc. It would be interesting to see how many AS numbers that are given out by = the RIRs are visible in the global routing table... If almost all them = them are visible then for practical purposes your use-cases don't make a = noticeable difference. The other areas like RPKI and reverse DNS are a bigger problem I = think... Cheers, Sander From fred@cisco.com Fri Jan 25 05:45:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C451A21F8837 for ; Fri, 25 Jan 2013 05:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxCoiytIUvoT for ; Fri, 25 Jan 2013 05:45:01 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84021F8830 for ; Fri, 25 Jan 2013 05:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=143; q=dns/txt; s=iport; t=1359121501; x=1360331101; h=date:from:message-id:to:subject:cc; bh=YICDjKskuUQgK0spx+DqhjWVUPIZ40tA0XD8Gg/JwyQ=; b=UgoEfDNSqGA02joG/PvB01i25Q1VMJjrkhicRLJTJqb7ElXGwj7fPPwN MLbERvTDnioURYCQxpaq1WLuaKyibadbv4hwA5QQvNXJppzXCQJgqMxpK 3e4w0faFg7UUjqVgDLaD8+jGRhwASXlyLAVL46tGpXChj1LiXf5zIdgdb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8MAOiJAlGrRDoG/2dsb2JhbABEhX+mKAGRHgQDgQQWc4MKFDwtB4h6Db4vjhWDKQOIYY5HjyyDGQ X-IronPort-AV: E=Sophos;i="4.84,538,1355097600"; d="scan'208";a="69618618" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 25 Jan 2013 13:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0PDj0dW028498; Fri, 25 Jan 2013 13:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r0PDj0f07997; Fri, 25 Jan 2013 05:45:00 -0800 (PST) Date: Fri, 25 Jan 2013 05:45:00 -0800 (PST) From: Message-Id: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:45:01 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-vyncke-balanced-ipv6-security. Please take a look at it and comment. From fred@cisco.com Fri Jan 25 05:45:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3121F8838 for ; Fri, 25 Jan 2013 05:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf-JZqUPf8zu for ; Fri, 25 Jan 2013 05:45:04 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB2E21F8837 for ; Fri, 25 Jan 2013 05:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=146; q=dns/txt; s=iport; t=1359121504; x=1360331104; h=date:from:message-id:to:subject:cc; bh=+fxiwK+xCi8EPqTXHyo+Dq+mooXYwsKJ3pKw9oJG9pQ=; b=PaVkfLnpnBHJLZ3/ZCF5PvJpsKhzMVhF/NXRtnY2jVFGWS6DQr6I4Es3 j8V/G4EBRTqv4PMWzLdY6zNlcGTAeWkLgGPnXNCEz5ApNxCHKdYAz6IgT GAKdcpT6dBjprDRqM0gNMhcFYy8lMQbPUpPlxAVn+HYQetW0Zi/uBlt8o Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8MACuMAlGrRDoJ/2dsb2JhbABEhX+mKAGRHgQDgQQWc4MePC0HiHoNvi6OFYMpA4hhjkePLIMZ X-IronPort-AV: E=Sophos;i="4.84,538,1355097600"; d="scan'208";a="67116757" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 25 Jan 2013 13:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PDj0v7022788; Fri, 25 Jan 2013 13:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r0PDj0o07991; Fri, 25 Jan 2013 05:45:00 -0800 (PST) Date: Fri, 25 Jan 2013 05:45:00 -0800 (PST) From: Message-Id: <201301251345.r0PDj0o07991@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-mlevy-v6ops-auto-v6-allocation-per-asn@tools.ietf.org Subject: [v6ops] new draft: draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:45:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-mlevy-v6ops-auto-v6-allocation-per-asn. Please take a look at it and comment. From nick@inex.ie Fri Jan 25 05:51:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9C421F8859 for ; Fri, 25 Jan 2013 05:51:29 -0800 (PST) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udrtFQOpxupc for ; Fri, 25 Jan 2013 05:51:28 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADD421F881D for ; Fri, 25 Jan 2013 05:51:27 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local ([IPv6:2001:1bb8:2004:200::180]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r0PDn8TI099662 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 13:49:09 GMT (envelope-from nick@inex.ie) Message-ID: <51028DDD.6070904@inex.ie> Date: Fri, 25 Jan 2013 13:51:25 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gert Doering References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> In-Reply-To: <20130125120734.GX51699@Space.Net> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:51:29 -0000 On 25/01/2013 12:07, Gert Doering wrote: > fairly useless - it's not solving the original problem what problem? It doesn't actually articulate what problem it's trying to solve. Nick From brian.e.carpenter@gmail.com Fri Jan 25 06:54:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C729E21F86CC for ; Fri, 25 Jan 2013 06:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.613 X-Spam-Level: X-Spam-Status: No, score=-101.613 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpVos8Bh-EHT for ; Fri, 25 Jan 2013 06:54:31 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2118621F86A5 for ; Fri, 25 Jan 2013 06:54:30 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm6so1479904wib.15 for ; Fri, 25 Jan 2013 06:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eP6CebPpP69azUMPUuSzCv94cOUBp1sTgeK+uPhxO1E=; b=Nd/KN8s1kP4IbFG/bJhgV1t7G1BVtb7SHYK8I3DzFgyBThDLA++g1gaG8JmzllXImL AdJNs3+Uyg60Z58QYEc4j3S/gxkuvilhr3X8+HjYPqJiiA44PWISKZ2TtjKdc3ho+aOb YLS/SXEuCW0AEALlcebRYlPxO++QVF8Rk9yHvtcZJwSxdvE8tZmg+0tzWmmRFquylUnk yZWtzAwZd9hR0tZb6RLKlF/Q0IpNoEW8u4fvLmtG1qOzyZxpN8lWoyNSKkZjpDwHxhyV 8qWxkAoCrOl9nLeNgbxSZpIAgnsQO3Tg7vMXkT15dAUHoA+e2ZjDBbY2i5n9juoW2MQ5 HpUQ== X-Received: by 10.180.93.133 with SMTP id cu5mr9265699wib.32.1359125670077; Fri, 25 Jan 2013 06:54:30 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-213.as13285.net. [2.102.216.213]) by mx.google.com with ESMTPS id bz12sm2160265wib.5.2013.01.25.06.54.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 06:54:29 -0800 (PST) Message-ID: <51029CB4.9060306@gmail.com> Date: Fri, 25 Jan 2013 14:54:44 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sander Steffann References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> In-Reply-To: <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:54:31 -0000 On 25/01/2013 12:49, Sander Steffann wrote: > Hi, > >>> Doesn't it? Having an AS number means you can participate in the >>> global routing table. So by giving someone an AS number you >>> (implicitly) allow them to advertise prefixes there, right? ;-) >> Do I? I give them a unique identifier that they might need for something, >> like private peerings that still should have an unique identifier, building >> an internal confederation (where multiple ASes are externally only visible >> behind an aggregate), etc. > > It would be interesting to see how many AS numbers that are given out by the RIRs are visible in the global routing table... If almost all them them are visible then for practical purposes your use-cases don't make a noticeable difference. The answer to that is updated daily on Geoff's site. That's why I referred to "active" ASs - the ones that are visible in BGP4. Today for example, he shows 43205 ASs advertising IPv4 routes and 6660 advertising IPv6 routes, out of 69630 allocated. These are not big numbers in terms of BGP4 scale. > The other areas like RPKI and reverse DNS are a bigger problem I think... Why are they a bigger problem than for PI prefixes? Brian From gert@space.net Fri Jan 25 06:58:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1800C21F8863 for ; Fri, 25 Jan 2013 06:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+ZuJtSIfcj7 for ; Fri, 25 Jan 2013 06:58:18 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 762FD21F8842 for ; Fri, 25 Jan 2013 06:58:18 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 20D0560374 for ; Fri, 25 Jan 2013 15:58:17 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 0386E6034E for ; Fri, 25 Jan 2013 15:58:17 +0100 (CET) Received: (qmail 94257 invoked by uid 1007); 25 Jan 2013 15:58:16 +0100 Date: Fri, 25 Jan 2013 15:58:16 +0100 From: Gert Doering To: Brian E Carpenter Message-ID: <20130125145816.GC51699@Space.Net> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <51029CB4.9060306@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrnY8GquOzEdxs9Q" Content-Disposition: inline In-Reply-To: <51029CB4.9060306@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:58:19 -0000 --lrnY8GquOzEdxs9Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 25, 2013 at 02:54:44PM +0000, Brian E Carpenter wrote: > > The other areas like RPKI and reverse DNS are a bigger problem I think.= =2E. > Why are they a bigger problem than for PI prefixes? Both assume a hierarchical structure with "someone" at the level above you to handle delegation. If it's self-service "I have an AS, here's the formula, that's my network", who is going to handle RPKI certificates, run the DNS zone and handle delegations? Just sayin' - the RIRs have the machinery for this, and this proposal is=20 building a parallel address distribution system without any of the=20 associated services. 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 (89) 32356-444 USt-IdNr.: DE813185279 --lrnY8GquOzEdxs9Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUQKdiKkuBuNlUUl1AQL58gP/bEl1hpcabmhH5yRmeAFXp+Omj41xugGE +WKboVP70QAKRmZEZnPSVR9/VPsxtPawm+SQypReUHQxzncXE9k5kENyMJoEts5X o37U1Np9nt5k+QKh58AwJRMzjK6Kv+IDwuYWZUFCmXNAmf4PlDghS5crqO1+5RZp oHR7LdDgpLs= =NiTS -----END PGP SIGNATURE----- --lrnY8GquOzEdxs9Q-- From sander@steffann.nl Fri Jan 25 06:59:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B173321F8858 for ; Fri, 25 Jan 2013 06:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-n0geRZvo5w for ; Fri, 25 Jan 2013 06:59:32 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 396FB21F8842 for ; Fri, 25 Jan 2013 06:59:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id CB0852040; Fri, 25 Jan 2013 15:59:28 +0100 (CET) X-Virus-Scanned: 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 10024) with ESMTP id bt53Lp52DyoD; Fri, 25 Jan 2013 15:59:24 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id C9FC22008; Fri, 25 Jan 2013 15:59:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <51029CB4.9060306@gmail.com> Date: Fri, 25 Jan 2013 15:59:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8732006D-A735-4F80-B193-31B9F7830C4C@steffann.nl> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <51029CB4.9060306@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:59:32 -0000 Hi, >> The other areas like RPKI and reverse DNS are a bigger problem I = think... >=20 > Why are they a bigger problem than for PI prefixes? They are not a problem for PI prefixes since the RIRs have started to = establish a contractual relationship between themselves (as operators of = (part of) the RPKI and reverse DNS infrastructure) and the holders of = the PI prefixes. How would that relationship work when every ASN holder can use a IPv6 = allocation by default? Who maintains the trust relationship needed for = RPKI for example? - Sander From jcurran@istaff.org Fri Jan 25 07:34:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F4B21F8950 for ; Fri, 25 Jan 2013 07:34:42 -0800 (PST) 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=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvQKX1rPvpAG for ; Fri, 25 Jan 2013 07:34:41 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id A943A21F8887 for ; Fri, 25 Jan 2013 07:34:41 -0800 (PST) Received: from [64.197.173.10] (helo=[10.3.12.138]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TylIe-000BdH-Dk; Fri, 25 Jan 2013 15:34:40 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 64.197.173.10 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ArRbSzPYW/2R3zv/wOQG2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Curran In-Reply-To: <20130125145816.GC51699@Space.Net> Date: Fri, 25 Jan 2013 10:34:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <51029CB4.9060306@gmail.com> <20130125145816.GC51699@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:34:42 -0000 On Jan 25, 2013, at 9:58 AM, Gert Doering wrote: > On Fri, Jan 25, 2013 at 02:54:44PM +0000, Brian E Carpenter wrote: >>> The other areas like RPKI and reverse DNS are a bigger problem I = think... >> Why are they a bigger problem than for PI prefixes? >=20 > Both assume a hierarchical structure with "someone" at the level above > you to handle delegation. >=20 > If it's self-service "I have an AS, here's the formula, that's my = network", > who is going to handle RPKI certificates, run the DNS zone and handle > delegations? =46rom my reading of the draft, it could very easily be the RIRs = providing=20 those services: " 8. RIR support It is suggested that RIRs, via their Internet Registry services, support these automatic assignments (including but not limited to whois and reverse DNS). The RIRs should provide these services in addition to the services already provided for the associated AS number. " > Just sayin' - the RIRs have the machinery for this, and this proposal = is=20 > building a parallel address distribution system without any of the=20 > associated services. Perhaps it would be better characterized as "this proposal is building = an alternative ASN-based address distribution system which would require services similar to those services provided for the existing provider- independent IPv6 assignment mechanisms" I also advocate the v6ops working group adopting this ID for discussion. This does not imply that I support it or not, only that I believe that=20= this WG is the proper place to discuss it. /John From simon.perreault@viagenie.ca Fri Jan 25 07:45:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DF421F8712 for ; Fri, 25 Jan 2013 07:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb4-NdgzecgJ for ; Fri, 25 Jan 2013 07:45:18 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D306621F86D6 for ; Fri, 25 Jan 2013 07:45:18 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c90c:4a03:ec7d:ee87]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2BEB840367 for ; Fri, 25 Jan 2013 10:45:18 -0500 (EST) Message-ID: <5102A8BE.8020001@viagenie.ca> Date: Fri, 25 Jan 2013 16:46:06 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <51029CB4.9060306@gmail.com> <20130125145816.GC51699@Space.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:45:19 -0000 Le 2013-01-25 16:34, John Curran a écrit : > I also advocate the v6ops working group adopting this ID for discussion. > This does not imply that I support it or not, only that I believe that > this WG is the proper place to discuss it. In my understanding, when a WG adopts a document it means that it agrees with the general idea and that it wants to work on the draft with the goal of publishing it as an RFC. Deciding whether it's a good idea happens *before* adoption. Like, now. Simon From dougb@dougbarton.us Fri Jan 25 07:56:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DAF21F8946 for ; Fri, 25 Jan 2013 07:56:40 -0800 (PST) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvAfzwfrmSQq for ; Fri, 25 Jan 2013 07:56:39 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id C530A21F889A for ; Fri, 25 Jan 2013 07:56:39 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:10c8:21f0:f0a0:7fa0] (unknown [IPv6:2001:470:d:5e7:10c8:21f0:f0a0:7fa0]) by dougbarton.us (Postfix) with ESMTPSA id 4EBA922BA9 for ; Fri, 25 Jan 2013 15:56:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1359129399; bh=5KQ9stce6ieG8hgRr93z7DjQ6cRBoxeNVzjTKAWr6Mo=; h=Date:From:To:Subject:References:In-Reply-To; b=r2TfYVWzKnS1Dk1r2K/f+efY1vL+bDtKWhHOKuBFJ0gqTE4Fk90+Q3j0AVUvHE0XB veqgT8utMWjpCwct1gJrFfUr/1qizcyHd4vQAw3mxoftCf5Vcuq+Rwa1EotkeaQFAg CYw7xAePgFP9hecZcECxr7GscmLFAZrPxm3wAprg= Message-ID: <5102AB36.1010102@dougbarton.us> Date: Fri, 25 Jan 2013 07:56:38 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> In-Reply-To: <51024E85.5090803@viagenie.ca> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:56:41 -0000 On 1/25/2013 1:21 AM, Simon Perreault wrote: > Le 2013-01-25 05:55, Cameron Byrne a écrit : >> I believe this I-D would benefit from a clearly articulated problem >> statement. Afaik, acquiring an ipv6 prefix is not a problem. > > If I understand correctly, the problem statement would look something > like this: > > "ASes that do not care or know about IPv6 will not request IPv6 space. > This is sub-optimal for the promotion and adoption of IPv6." That's not a problem we can solve with an RFC. Automatically allocating an IPv6 prefix is a bad idea on its face. This draft should not be adopted by the group, and should not progress. hth, Doug From evyncke@cisco.com Fri Jan 25 08:08:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDE221F8862 for ; Fri, 25 Jan 2013 08:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vzQycyialXn for ; Fri, 25 Jan 2013 08:08:14 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 220F321F87F5 for ; Fri, 25 Jan 2013 08:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1450; q=dns/txt; s=iport; t=1359130094; x=1360339694; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MmnEH2FDzVyIU45awwpZHS/ioSiDAj29eiynOjT6j4Q=; b=BUGYKPPxX2tvG9vVhTdXch7V597pERCohJE1K9fVyLklthqFmboPnoNw pdMIZG5R07WLg6IB8g57/ts9ZJ09khwi+aRc/bCSbYL9MavM4yQ0BlBHl DYVERk/zECswxmpTyIa+I+TFhXhRy2zkR3u4QijY9p1XPCHFRmhJxHkld I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKSsAlGtJV2a/2dsb2JhbABEvlMWc4IeAQEBBGUUDAQCAQgRBAEBCyQyHQgCBAENBQiIBwy+OpBeYQOILI59jyyCd4Ik X-IronPort-AV: E=Sophos;i="4.84,539,1355097600"; d="scan'208";a="168135759" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jan 2013 16:08:13 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0PG8DEt010150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 16:08:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 10:08:12 -0600 From: "Eric Vyncke (evyncke)" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: new draft: draft-v6ops-vyncke-balanced-ipv6-security Thread-Index: AQHN+wIz3PiIlFLtCU60otWELnKqjZhaNBkQ Date: Fri, 25 Jan 2013 16:08:10 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> In-Reply-To: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.67] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:08:16 -0000 Some explanations about this new draft... (which should also be of interest= to OPSEC WG) IPv6 CPE have always the issue of the default security policy especially ar= ound allowing inbound connections: - Some say allow (fully open) to restore end-to-end - Some say block (fully closed/valve like) to mimick the IPv4 NAPT stateful= behavior. RFC6092 describe a simple security policy for IPv6 CPE. Together with Mark = Townsley and Andrew Yourtchenko, we wrote the advanced-security draft somet= hing in the line of fully open but use IPS in line (what is called Universa= l Threat Mitigation) but this is expensive and the I-D did not gather momen= tum. This I-D is based on Swisscom deployment which is 'balanced' between open a= nd close. It is simply allowing all traffic inbound EXCEPT for well-known T= CP/UDP ports linked to malware or vulnerable services. The authors are the Swisscom engineers who initiated this balanced security= and Ragnar from Altibox (a Norvegian ISP). Hope this helps -=E9ric > -----Original Message----- > From: Fred Baker (fred) > Sent: vendredi 25 janvier 2013 14:45 > To: v6ops@ietf.org > Cc: draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org > Subject: new draft: draft-v6ops-vyncke-balanced-ipv6-security >=20 >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops- > vyncke-balanced-ipv6-security. Please take a look at it and comment. From ietf@rozanak.com Fri Jan 25 08:16:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0321F86B2 for ; Fri, 25 Jan 2013 08:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWcWmjh0RDWN for ; Fri, 25 Jan 2013 08:16:22 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4C821F869A for ; Fri, 25 Jan 2013 08:16:22 -0800 (PST) Received: from FB10H117WS01 ([141.89.226.146]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LiRym-1Ub7RQ0QwO-00cp0p; Fri, 25 Jan 2013 11:16:21 -0500 From: "Hosnieh Rafiee" To: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <51029CB4.9060306@gmail.com> <20130125145816.GC51699@Space.Net> <5102A8BE.8020001@viagenie.ca> In-Reply-To: <5102A8BE.8020001@viagenie.ca> Date: Fri, 25 Jan 2013 17:16:06 +0100 Message-ID: <003201cdfb17$505e2860$f11a7920$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac37EwFlzYt8KrOQSWCn75G5ea4LTAAASabg Content-Language: de X-Provags-ID: V02:K0:em8Gx5/yUa7VHqmlEHIiu9SFw7M8BODW+7zW0j/gWy8 IHlkkxn4Az9WsDOltDeOzvuetOSqJZwQ9NtwTJ/DJDiDGhFmYk Mq+bMemK/4IEI7rI7ygr8wrmTPcQo04uEGgRQldhI0XAnWfjnE oRphFhEWslHLYwnXNhQJQ4AZyz5zH8Z9kj5ZcDGui+NMBujQia a528CgDpndvB0DNvWzrRIWwa0EcnZGcM6GmaF0nwHGnG0VmxGb Gxls/fWUOrZ6J3mKT5CeQGVz8RTXvw24FcluZ7tL7le0TtTm5M nD4N4cblyGSwkcMJ7s+CJJOAPVGWuE4jEEQFoxyUmwhOT4N+I2 QeSDodX0jC/ne0gzSvBk= Subject: [v6ops] I-D Action: draft-rafiee-6man-ssas-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:16:23 -0000 Hello, We are looking for comments on our latest draft RFC version of SSAS. Any and all comments would be greatly appreciated as we are trying to improve it as much as possible. Thanks in advance. http://tools.ietf.org/html/draft-rafiee-6man-ssas-01 Hosnieh From wesley.george@twcable.com Fri Jan 25 12:02:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD721F888B for ; Fri, 25 Jan 2013 12:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L+LQXdcQ7AL for ; Fri, 25 Jan 2013 12:02:18 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E861321F886E for ; Fri, 25 Jan 2013 12:02:17 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,540,1355115600"; d="scan'208";a="17366383" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jan 2013 15:01:14 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 25 Jan 2013 15:02:17 -0500 From: "George, Wes" To: Doug Barton , "v6ops@ietf.org" Date: Fri, 25 Jan 2013 15:02:15 -0500 Thread-Topic: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt Thread-Index: Ac37FJYxC3taikxhTMG7QNZvAR8JhQAHzPpA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <5102AB36.1010102@dougbarton.us> In-Reply-To: <5102AB36.1010102@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-mlevy-v6ops-auto-v6-allocation-per-asn@tool.ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:02:18 -0000 > > If I understand correctly, the problem statement would look something > > like this: > > > > "ASes that do not care or know about IPv6 will not request IPv6 space. > > This is sub-optimal for the promotion and adoption of IPv6." > > That's not a problem we can solve with an RFC. > > Automatically allocating an IPv6 prefix is a bad idea on its face. > > This draft should not be adopted by the group, and should not progress. [WEG] +1 I thought I remembered this idea being batted around in one or more RIR pol= icy discussions, but I don't know if anything ever came of it (in terms of = a formal policy proposal that was subsequently shot down or approved) and a= quick search didn't really turn up anything. I'm opposed to this proposal because it has the potential to further perpet= uate routing table bloat by encouraging PI space use in places where it's n= ot strictly necessary, and I do not believe that the adoption of IPv6 is in= any way hampered by the current RIR allocation rules. If the authors belie= ve that there is a barrier to IPv6 entry in one or more RIRs' allocation po= licies, the right place to solve that problem is within the RIR policy deve= lopment process. I'm willing to be convinced otherwise, but the draft needs to do a much bet= ter job of explaining how this fixes anything and why it needs to be addres= sed by IETF and not in the RIRs. As others have stated, I agree that v6ops is probably the right WG for disc= ussion of this draft. *However* I do not believe that's the right test for = adoption. I don't support adopting it as a WG item without consensus that t= he WG agrees with the basic problem statement and solution and just needs t= o refine it. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From sander@steffann.nl Fri Jan 25 14:35:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3952E21F84E4 for ; Fri, 25 Jan 2013 14:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzj7Tc22+tCn for ; Fri, 25 Jan 2013 14:35:52 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 262BA21F84A1 for ; Fri, 25 Jan 2013 14:35:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 69A362016; Fri, 25 Jan 2013 23:35:49 +0100 (CET) X-Virus-Scanned: 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 10024) with ESMTP id Mr7PwJN1RMPR; Fri, 25 Jan 2013 23:35:48 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 668442008; Fri, 25 Jan 2013 23:35:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> Date: Fri, 25 Jan 2013 23:35:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2287519D-7B29-4326-970A-9B015198D53E@steffann.nl> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <5102AB36.1010102@dougbarton.us> <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 22:35:53 -0000 Hi Wes, >>> "ASes that do not care or know about IPv6 will not request IPv6 = space. >>> This is sub-optimal for the promotion and adoption of IPv6." >>=20 >> That's not a problem we can solve with an RFC. >>=20 >> Automatically allocating an IPv6 prefix is a bad idea on its face. >>=20 >> This draft should not be adopted by the group, and should not = progress. >=20 > [WEG] +1 Well, to be honest I think it's a bad idea for several reasons. At least = in the RIPE region the policy for IPv6 PI space is such a low barrier = that I can't imagine any organisation who is serious about IPv6 not = qualifying... So I really don't see the need (to put it bluntly) to = bypass the RIRs here. > I thought I remembered this idea being batted around in one or more = RIR policy discussions, but I don't know if anything ever came of it (in = terms of a formal policy proposal that was subsequently shot down or = approved) and a quick search didn't really turn up anything. Probably this one: http://www.ripe.net/ripe/policies/proposals/2008-01. = The conclusion was that those who want IPv6 can get it easily from the = RIR, and those that don't want IPv6 won't use any address space you = 'force' on them. > I'm opposed to this proposal because it has the potential to further = perpetuate routing table bloat by encouraging PI space use in places = where it's not strictly necessary, and I do not believe that the = adoption of IPv6 is in any way hampered by the current RIR allocation = rules. +1 > If the authors believe that there is a barrier to IPv6 entry in one or = more RIRs' allocation policies, the right place to solve that problem is = within the RIR policy development process. Yes, and I would welcome any discussion if someone thinks we're doing it = wrong in RIPE land! Usually people tell me that in the RIPE region it is = incredibly easy to get IPv6 PI space. I can't speak for other regions = obviously. > I'm willing to be convinced otherwise, but the draft needs to do a = much better job of explaining how this fixes anything and why it needs = to be addressed by IETF and not in the RIRs. +1 > As others have stated, I agree that v6ops is probably the right WG for = discussion of this draft. *However* I do not believe that's the right = test for adoption. I don't support adopting it as a WG item without = consensus that the WG agrees with the basic problem statement and = solution and just needs to refine it. I think at least having some discussion in this WG is good, even if it = only is to confirm that it doesn't belong here. The only reason for a = draft like this would be if the RIR policies are bad. As one of the = address policy WG chairs of the RIPE region I wouldn't mind this = discussion, hopefully with the conclusion that this draft isn't = necessary :-) Thanks, Sander From joelja@bogus.com Fri Jan 25 16:32:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF83521F87F7 for ; Fri, 25 Jan 2013 16:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0KtJnSTtJSE for ; Fri, 25 Jan 2013 16:32:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1221F87B1 for ; Fri, 25 Jan 2013 16:32:09 -0800 (PST) Received: from joels-MacBook-Air.local (173.sub-70-199-79.myvzw.com [70.199.79.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0Q0W7RN010961 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 26 Jan 2013 00:32:08 GMT (envelope-from joelja@bogus.com) Message-ID: <51032401.7080805@bogus.com> Date: Fri, 25 Jan 2013 16:32:01 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 26 Jan 2013 00:32:08 +0000 (UTC) Subject: [v6ops] Upcoming Milestones prior to IETF 86 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 00:32:09 -0000 *I note these because they're about 2 and 3 weeks out respectively. 2013-02-18 (Monday):*Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload usingIETF ID Submission Tool .*** 2013-02-25 (Monday):*Internet Draft final submission cut-off by UTC 24:00, upload usingIETF ID Submission Tool . From randy@psg.com Fri Jan 25 20:22:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EC721F84DC for ; Fri, 25 Jan 2013 20:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9pTJ3TtiivU for ; Fri, 25 Jan 2013 20:22:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7618921F84D9 for ; Fri, 25 Jan 2013 20:22:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TyxHI-000KKZ-AZ; Sat, 26 Jan 2013 04:22:04 +0000 Date: Sat, 26 Jan 2013 13:22:03 +0900 Message-ID: From: Randy Bush To: Sander Steffann In-Reply-To: <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 04:22:08 -0000 my first take, tactless as usual the goal is avoiding rir bureaucracy and cost. this is not necessarily a bad thing. the result will be yacaa, yet another class of address allocations. every time we have done this, it has been convenient until it becomes painful. look at the effort in the ripe region reconciling pi space, legacy space, .... some of the immediate consequences have been pointed out. who delegates the dns and how do they know who the heck you are and if you have the right to that asn/space? abuse contact, rpki, ... but i do see sense in the argument that the cost and bureaucracy of dealing with rirs is painful and unnecessarily so. i just think that, at least in this case, it would be better though not easier to fix the root cause of the problem than kludge around it. randy From ipepelnjak@gmail.com Fri Jan 25 22:49:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940621F86B2 for ; Fri, 25 Jan 2013 22:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7MrsPuc93au for ; Fri, 25 Jan 2013 22:49:16 -0800 (PST) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 11AAF21F84ED for ; Fri, 25 Jan 2013 22:49:11 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id d1so441021eab.34 for ; Fri, 25 Jan 2013 22:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=O+GHDIJD284T6zE6ypzd4y3J/n0gBZ87lhUpjyd7nkE=; b=Dx8yKCIFzY46Br7KsnVIBrTkRd6OdRWuH32asg+RoFah3YJ+anPnRiIsejojA+/mrl TuHmoXFLRxX1R40AYl94aywcIsDOB4LiBG5n61nHsOXm5H7RQDpzHwvcVeaopPh586qx iTzJXH+FKNX9ozpNOVgm3vYkwmpnQ/rfUqMLiyYweDkkxNZbKQL5fyi1a/Ie8bsOR3X8 kYlAlsv8fRhMA2SMTc7asj5qyYAtVMeO/iu5F2tOVVn1jCQ6W0Eoxyf4bjFPjKTkGcrg jWDBKBYjM+oREwwuSIHvuabte60EqweGXz31NlqxGfvYRr2ARdqEnFxcCxGSXa0JjWeF 42/w== X-Received: by 10.14.177.1 with SMTP id c1mr26610859eem.8.1359182950931; Fri, 25 Jan 2013 22:49:10 -0800 (PST) Received: from PIPINB2009 (BSN-61-105-190.dial-up.dsl.siol.net. [86.61.105.190]) by mx.google.com with ESMTPS id d3sm4893374eeo.13.2013.01.25.22.49.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Jan 2013 22:49:10 -0800 (PST) From: "Ivan Pepelnjak" To: "'Randy Bush'" , "'Sander Steffann'" References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> In-Reply-To: Date: Sat, 26 Jan 2013 07:49:09 +0100 Message-ID: <000001cdfb91$3eabf960$bc03ec20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac37fL2nppxP1BAZRka84G0iuzd7BgAE7vJA Content-Language: sl Cc: 'IETF v6ops list' Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 06:49:17 -0000 Could the root cause be that ARIN charges at least $1250 per PI = allocation, whereas it costs =E2=82=AC50 in RIPEland if you're smart = enough to attach yourself to a LIR? https://www.arin.net/fees/fee_schedule.html http://www.ripe.net/ripe/docs/ripe-566 In any case, there's a long history of horrible technology kludges = created to "solve" layer 8-10 problems ... and they all looked like a = great idea once. Ivan > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of > Randy Bush > Sent: Saturday, January 26, 2013 5:22 AM > To: Sander Steffann > Cc: IETF v6ops list > Subject: Re: [v6ops] I-D Action: = draft-mlevy-v6ops-auto-v6-allocation-per- > asn-00.txt >=20 > my first take, tactless as usual >=20 > the goal is avoiding rir bureaucracy and cost. this is not = necessarily a > bad thing. >=20 > the result will be yacaa, yet another class of address = allocations. > every time we have done this, it has been convenient until it becomes > painful. look at the effort in the ripe region reconciling pi space, > legacy space, .... >=20 > some of the immediate consequences have been pointed out. who = delegates > the dns and how do they know who the heck you are and if you have the > right to that asn/space? abuse contact, rpki, ... >=20 > but i do see sense in the argument that the cost and bureaucracy of > dealing with rirs is painful and unnecessarily so. i just think that, = at > least in this case, it would be better though not easier to fix the = root > cause of the problem than kludge around it. >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Fri Jan 25 23:54:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18721F86D9 for ; Fri, 25 Jan 2013 23:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDv9QbvN4WX6 for ; Fri, 25 Jan 2013 23:54:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A57FB21F86B8 for ; Fri, 25 Jan 2013 23:54:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tz0aU-000KgI-5b; Sat, 26 Jan 2013 07:54:06 +0000 Date: Sat, 26 Jan 2013 16:54:05 +0900 Message-ID: From: Randy Bush To: Ivan Pepelnjak In-Reply-To: <000001cdfb91$3eabf960$bc03ec20$@com> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 07:54:08 -0000 > Could the root cause be that ARIN charges at least $1250 per PI > allocation, whereas it costs =E2=82=AC50 in RIPEland if you're smart enou= gh > to attach yourself to a LIR? and you get the pain of dealing with the bureaucracy and arrogance. > In any case, there's a long history of horrible technology kludges > created to "solve" layer 8-10 problems ... and they all looked like > a great idea once. exactly. the long term solution is to clean up the rirs. randy From brian.e.carpenter@gmail.com Sat Jan 26 00:46:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A45521F886B for ; Sat, 26 Jan 2013 00:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.234 X-Spam-Level: X-Spam-Status: No, score=-100.234 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6JLsKaSKxJV for ; Sat, 26 Jan 2013 00:46:30 -0800 (PST) Received: from mail-we0-x22d.google.com (we-in-x022d.1e100.net [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7E21F8583 for ; Sat, 26 Jan 2013 00:46:30 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id r5so557087wey.18 for ; Sat, 26 Jan 2013 00:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=y3mR1sdH6Qbcti5pyrmoOYgqHGJf10/CkWeoGVjNofI=; b=ZvZjvd5GQAZWE6TEakSAj/IEKppn0+ATuefJ5Lj7c1j7mLa9FPO2x6QanraV/ta226 1oSTO5UaIT7K/RxmAzPYzDX4nkDQqsBMbDTTnM96FaOeH5yJbBD0djnQsQEzPXMbXyqk QFF2lO2GQBjrvPF/e441xlaHDJFApuTHNvjmsro1JQhzPhSNoInOBgz9iJDW6ch0YEXL vnnRrJod7+7A91T0FiI47z1ZS0mRiw1P/TqUyYyq6lrN2XYArv48TrX+bdESHg/ih2Zk B1shm6Ajyd/YYgRfaIJX9Cs9RK+cPpCS6FpEFJGQLyy2E0HJlq0z7bhEgUE5h7+FyaLj WJBg== X-Received: by 10.195.13.67 with SMTP id ew3mr12655280wjd.59.1359189989629; Sat, 26 Jan 2013 00:46:29 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-163.as13285.net. [2.102.216.163]) by mx.google.com with ESMTPS id ex6sm1780662wid.3.2013.01.26.00.46.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 00:46:28 -0800 (PST) Message-ID: <510397F5.8090102@gmail.com> Date: Sat, 26 Jan 2013 08:46:45 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "George, Wes" References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <5102AB36.1010102@dougbarton.us> <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-mlevy-v6ops-auto-v6-allocation-per-asn@tool.ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 08:46:31 -0000 On 25/01/2013 20:02, George, Wes wrote: > I thought I remembered this idea being batted around in one or more RIR policy discussions, but I don't know if anything ever came of it (in terms of a formal policy proposal that was subsequently shot down or approved) and a quick search didn't really turn up anything. I remember suggesting this idea to Steve Deering in about 1995, before IPv6 basics had even stabilised, and he explained to me why it was a bad idea because of the resulting BGP4 bloat. This was at a time when we did not expect PI prefixes to exist in IPv6, and we seriously hoped to have a very nicely aggregated IPv6 DFZ. That hope is receding today, so the argument is less strong than in 1995. All the same, unless there is factual evidence of operators finding it harder to get an IPv6 prefix than an AS #, it does seem like unnecessary entropy. Brian From sander@steffann.nl Sat Jan 26 04:43:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B853B21F8718 for ; Sat, 26 Jan 2013 04:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8SQFmZlp-at for ; Sat, 26 Jan 2013 04:43:45 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 305B121F8712 for ; Sat, 26 Jan 2013 04:43:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0219A2016; Sat, 26 Jan 2013 13:43:43 +0100 (CET) X-Virus-Scanned: 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 10024) with ESMTP id v7ljusFoJJ6w; Sat, 26 Jan 2013 13:43:40 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 290E72008; Sat, 26 Jan 2013 13:43:39 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Sat, 26 Jan 2013 13:43:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> To: Randy Bush X-Mailer: Apple Mail (2.1499) Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 12:43:45 -0000 Hi Randy, > my first take, tactless as usual Nah, just a clear an honest answer I think :-) Thanks, Sander From jcurran@istaff.org Sat Jan 26 06:54:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A894121F8820 for ; Sat, 26 Jan 2013 06:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsMAUsNFGTzY for ; Sat, 26 Jan 2013 06:54:51 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 067A621F8812 for ; Sat, 26 Jan 2013 06:54:50 -0800 (PST) Received: from pool-72-66-100-126.washdc.fios.verizon.net ([72.66.100.126] helo=[192.168.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Tz79c-0005nK-9N; Sat, 26 Jan 2013 14:54:48 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 72.66.100.126 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/y7nfQUaknBDgCFarFS1tk Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Curran In-Reply-To: <000001cdfb91$3eabf960$bc03ec20$@com> Date: Sat, 26 Jan 2013 09:54:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <276EF40D-4157-4255-AB0C-03961C267A90@istaff.org> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> To: Ivan Pepelnjak X-Mailer: Apple Mail (2.1499) Cc: 'IETF v6ops list' Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 14:54:51 -0000 On Jan 26, 2013, at 1:49 AM, Ivan Pepelnjak = wrote: > Could the root cause be that ARIN charges at least $1250 per PI = allocation, whereas it costs =8050 in RIPEland if you're smart enough to = attach yourself to a LIR? >=20 > https://www.arin.net/fees/fee_schedule.html Note that in the ARIN region there has been well-received fee schedule = consultation=20 to add a smaller ISP category (XX-Small, $500/yr, IPv4 /22 or smaller, = IPv6 /48 or=20 smaller), and there will more information on this in the next month. = It's still not=20 $50/year, but it a step in the that direction for provider-independent = v6 assignments. There is a more fundamental underlying question here, which is whether = or not an=20 organization which has obtained an AS for multihoming should be able to = have use=20 of an IPv6 block for the same purpose. There's definitely potential = IPv6 routing=20 table bloat of order (number of ASNs), but that same order of magnitude = potential=20 exists if they multihome using their current provider-assigned IPv6 /48 = assignments. =20 Perhaps the interesting question is whether ISPs would route such = ASN-based /48's=20 for non-multihomed customers, or push back and requiring multihoming = (and/or charge=20 to do so...?) Do ISPs today provide any incentive to use = provider-assigned IPv6=20 prefixes, or is it simply lack of PI availability which prevents IPv6 = routing table growth? /John Disclaimer: My views alone. This post is composed of 100% post-consumer = electrons. From farmer@umn.edu Sat Jan 26 09:42:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9921F8449 for ; Sat, 26 Jan 2013 09:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSp5KdHh389m for ; Sat, 26 Jan 2013 09:42:26 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1498D21F842D for ; Sat, 26 Jan 2013 09:42:26 -0800 (PST) Received: from mail-qc0-f200.google.com (mail-qc0-f200.google.com [209.85.216.200]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Sat, 26 Jan 2013 11:42:15 -0600 (CST) X-Umn-Remote-Mta: [N] mail-qc0-f200.google.com [209.85.216.200] #+LO+TR X-Umn-Classification: local Received: by mail-qc0-f200.google.com with SMTP id l42so1947691qco.3 for ; Sat, 26 Jan 2013 09:42:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=t/jFZADRBhsSUjg976SHydxhWWEozizPhatztb70cg8=; b=ABBi4cCe04v2gAQlr9ytXGnjMDHUHb0gYtfrJyjENoJAP5RC5vriL+y4L2cHzypM6G IWFEmApN+w2TjvKYyV+T/zpEYNQ5RM7fuy2vF90Kbqg9b7havX3KafuMl7i+7yD3d77d aKqQIATcHfJVqIBdQi6YIrg6HhRv57G2u7ugWCONkorjV1GlkSIoNxCtKTxLWCq/QRXZ uWG9xrPhGj53BVe9LJcGBmMdgGuxPVsYR6Lyk11EMZcm4YJ+tSN8555NEksAO9j8kQRD 9BLEdldwIRsLhB+H0OEt9PHbqBLDQnxFcfaXTRsgUjaF5d0FDGzSCy1jVnaM/zFpSsl/ vhjg== X-Received: by 10.220.218.197 with SMTP id hr5mr9900701vcb.8.1359222134520; Sat, 26 Jan 2013 09:42:14 -0800 (PST) X-Received: by 10.220.218.197 with SMTP id hr5mr9900693vcb.8.1359222134426; Sat, 26 Jan 2013 09:42:14 -0800 (PST) Received: from oit201651646.local ([64.197.173.10]) by mx.google.com with ESMTPS id l8sm2753768vdh.8.2013.01.26.09.42.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 09:42:13 -0800 (PST) Message-ID: <51041573.8090602@umn.edu> Date: Sat, 26 Jan 2013 11:42:11 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: IPv6 Ops WG References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> In-Reply-To: <5101F21B.2050204@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlEXA1Pa58KhRABbEvZk4b/pyUGoAeCcFnttG0a9+3PJTFja8AZfC/8m7ch4GQswm4Xd94sSEmjy8dyXEx+e0wOp1Vc2cA9u5AJn2ItFR39ZkgduhQkiR+vyk8q1OcFpA6LOLqN Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 17:42:26 -0000 This Draft basically substitutes ASN assignment policy for IPv6 address assignment policy or at least makes them equivalent for one /48. This isn't necessarily a bad thing, but it means we need to evaluate the ASN assignment policies of the RIR's and the technical basis for those policies to properly evaluate the consequences of this Draft. RFC 1930 provides the most recent technical recommendations for the use and assignment of a unique ASN and are more or less the basis of the RIRs' ASN assignment policies. However, RFC 1930 itself assumes an ASN is only necessary if there are one or more IP prefixes to be routed with a unique routing policy. It is generally understood that a unique routing policy effectively requires multihoming or peering with more than one other ASN. The fact that RFC 1930 seems dependent on a prefix to justify an ASN, seems to imply that you already need an IPv4 or IPv6 prefix in order to use the IPv6 prefix assigned by this Draft. If you already have an IPv6 prefix then the IPv6 prefix assigned by this Draft is unnecessary and superfluous. This leaves IPv4, and if you have already have an IPv4 prefix the RIR's policies make it trivial to justify getting an IPv6 prefix, and one RIR has essentially a one click request process at least for ISPs. There is one corner case where this Draft may be useful, depending on your point of view; It would allow Legacy ASN holders to get a /48 of IPv6 without having to talk to any RIR. While this may be beneficial to a small few, allocating a /16 of IPv6 space solely for the benefit of such a small few seems wasteful of even a plentiful resource like IPv6. However, if we were to reexamining and update RFC 1930, better defining when unique ASNs should be used and allocated, especially making that independent of any existing IP prefix; then maybe this Draft would have the general applicability and usefulness that would justify the allocation of a /16 of IPv6 space for this purpose. Without such an update of RFC 1930, I could not support this draft. Side Note, the Draft should require; That an IPv6 prefix from this range MUST only be originated from the ASN that the IPv6 prefix is assigned to. Furthermore, an ASN MUST NOT originate a IPv6 prefix from this range that assigned to another ASN. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nick@inex.ie Sat Jan 26 09:49:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22621F84E0 for ; Sat, 26 Jan 2013 09:49:30 -0800 (PST) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unpRC9dXR33g for ; Sat, 26 Jan 2013 09:49:30 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7E21F84D5 for ; Sat, 26 Jan 2013 09:49:29 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r0QHl4Wl008307 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 26 Jan 2013 17:47:10 GMT (envelope-from nick@inex.ie) Message-ID: <51041722.5080607@inex.ie> Date: Sat, 26 Jan 2013 17:49:22 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gert Doering References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> In-Reply-To: <20130125120734.GX51699@Space.Net> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 17:49:30 -0000 On 25/01/2013 12:07, Gert Doering wrote: > I'm fine having this in the WG to discuss, but the idea itself I find > fairly useless I'm not sure why the WG should adopt this without a clear problem statement. Nick From joelja@bogus.com Sat Jan 26 13:05:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CE621F8BBC for ; Sat, 26 Jan 2013 13:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5SByQYattSJ for ; Sat, 26 Jan 2013 13:05:57 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E463921F8B3F for ; Sat, 26 Jan 2013 13:05:57 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0QL5rkJ023356 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 26 Jan 2013 21:05:53 GMT (envelope-from joelja@bogus.com) Message-ID: <51041EE2.9070906@bogus.com> Date: Sat, 26 Jan 2013 10:22:26 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter , "George, Wes" References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <5102AB36.1010102@dougbarton.us> <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> <510397F5.8090102@gmail.com> In-Reply-To: <510397F5.8090102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 26 Jan 2013 21:05:54 +0000 (UTC) Cc: "v6ops@ietf.org" , "draft-mlevy-v6ops-auto-v6-allocation-per-asn@tool.ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 21:05:58 -0000 On 1/26/13 12:46 AM, Brian E Carpenter wrote: > On 25/01/2013 20:02, George, Wes wrote: > >> I thought I remembered this idea being batted around in one or more RIR policy discussions, but I don't know if anything ever came of it (in terms of a formal policy proposal that was subsequently shot down or approved) and a quick search didn't really turn up anything. > I remember suggesting this idea to Steve Deering in about 1995, before > IPv6 basics had even stabilised, and he explained to me why it was a bad > idea because of the resulting BGP4 bloat. This was at a time when we did > not expect PI prefixes to exist in IPv6, and we seriously hoped to have a > very nicely aggregated IPv6 DFZ. There a somewhat naive notion of what constitutes a provider that seems to have pervaded that discussion. It should have been obvious (was to me at least) when among the first assignments were universities, equipment vendors, and large enterprises, that the entities that find it necessary to multihome from their own address space in ipv4 did (and would) find it necessary to do so in ipv6. There are some other things we were totally wrong about like flow cached forwarding. The ipv4 routing table doesn't have 440,000 ipv4 routes in it because 30,000ish ASes find it necessary to advertise a prefix, a big chunk of those only advertise 1 prefix in ipv4. It has 440k entries because ISPs are fairly obnoxious polluters and enterprises like the one I work for find it necessary to go back for additional direct assignments, de-aggreate regionally for TE purposes, don't have enough bits in ipv4 to hierarchically allocate prefixes so they can more easily be aggregated. I have to de-aggregate in ipv6 for more or less the same reasons except for the don't have enough bits problem, the upshot being that I can better aggregate in ipv4 relative to ipv6 . > That hope is receding today, so the > argument is less strong than in 1995. All the same, unless there is > factual evidence of operators finding it harder to get an IPv6 prefix > than an AS #, it does seem like unnecessary entropy. Having done this in three different entities over the years (in the arin region), getting an AS number, ipv4 prefix assignment, and ipv6 prefix assignment was not particularly onerous, prior to the notion of ipv6 direct assignments, the justification for and entity that was not obviously a transit isp was a bit different 12 years ago then it is now... > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sat Jan 26 13:30:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6721F8AA0 for ; Sat, 26 Jan 2013 13:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBzoIV7lKrIL for ; Sat, 26 Jan 2013 13:30:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5643621F8A0F for ; Sat, 26 Jan 2013 13:30:37 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0QLUXh9023594 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 26 Jan 2013 21:30:34 GMT (envelope-from joelja@bogus.com) Message-ID: <51044AF5.20100@bogus.com> Date: Sat, 26 Jan 2013 13:30:29 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter , "George, Wes" References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <5102AB36.1010102@dougbarton.us> <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> <510397F5.8090102@gmail.com> <51041EE2.9070906@bogus.com> In-Reply-To: <51041EE2.9070906@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 26 Jan 2013 21:30:34 +0000 (UTC) Cc: "v6ops@ietf.org" , "draft-mlevy-v6ops-auto-v6-allocation-per-asn@tool.ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 21:30:37 -0000 On 1/26/13 10:22 AM, joel jaeggli wrote: > > The ipv4 routing table doesn't have 440,000 ipv4 routes in it because > 30,000ish ASes find it necessary to advertise a prefix, a big chunk of > those only advertise 1 prefix in ipv4. It has 440k entries because > ISPs are fairly obnoxious polluters and enterprises like the one I > work for find it necessary to go back for additional direct > assignments, de-aggreate regionally for TE purposes, don't have enough > bits in ipv4 to hierarchically allocate prefixes so they can more > easily be aggregated. I have to de-aggregate in ipv6 for more or less > the same reasons except for the don't have enough bits problem, the > upshot being that I can better aggregate in ipv4 relative to ipv6 . ipv6 relative to ipv4 I mean. From randy@psg.com Sat Jan 26 18:28:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2D21F890D for ; Sat, 26 Jan 2013 18:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZGi+LhiFH0v for ; Sat, 26 Jan 2013 18:28:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 960ED21F892E for ; Sat, 26 Jan 2013 18:28:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TzHyp-000NMs-BN; Sun, 27 Jan 2013 02:28:23 +0000 Date: Sun, 27 Jan 2013 11:28:22 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <51041722.5080607@inex.ie> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> <51041722.5080607@inex.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 02:28:26 -0000 >> I'm fine having this in the WG to discuss, but the idea itself I find >> fairly useless > I'm not sure why the WG should adopt this without a clear problem > statement. this wg is clearly the place to discuss this draft. in fact, we are discussing it. can we please not in the pointless sport of draft torture to get it properly on the table and in our gunsights? or stop discussing it. randy From swmike@swm.pp.se Sat Jan 26 21:56:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840A721F84E0 for ; Sat, 26 Jan 2013 21:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiimibIRC3zs for ; Sat, 26 Jan 2013 21:56:22 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 96C8E21F88A2 for ; Sat, 26 Jan 2013 21:56:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3D2209C; Sun, 27 Jan 2013 06:56:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 361579A; Sun, 27 Jan 2013 06:56:16 +0100 (CET) Date: Sun, 27 Jan 2013 06:56:16 +0100 (CET) From: Mikael Abrahamsson To: "v6ops@ietf.org" In-Reply-To: <510397F5.8090102@gmail.com> Message-ID: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <5102AB36.1010102@dougbarton.us> <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> <510397F5.8090102@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "draft-mlevy-v6ops-auto-v6-allocation-per-asn@tool.ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 05:56:22 -0000 On Sat, 26 Jan 2013, Brian E Carpenter wrote: > I remember suggesting this idea to Steve Deering in about 1995, before > IPv6 basics had even stabilised, and he explained to me why it was a bad > idea because of the resulting BGP4 bloat. This was at a time when we did > not expect PI prefixes to exist in IPv6, and we seriously hoped to have > a very nicely aggregated IPv6 DFZ. That hope is receding today, so the > argument is less strong than in 1995. All the same, unless there is > factual evidence of operators finding it harder to get an IPv6 prefix > than an AS #, it does seem like unnecessary entropy. I agree with the above statement. Generally, a lot of ASNs will only need a single prefix. If this prefix is that single prefix, then I'm fine (this replaces PI/PA handed out by a RIR). *BUT*, I don't want a lot of ASNs both advertising a /48 out of this draft, *and* addresses from RIR space. I dislike DFZ slot usage for no good reason. If this draft stated that this draft-handled space was ok to use if it was the only space announced by this ASN, then I would be fine. But I agree with Randy Bush, that if this is created to somehow fix a RIR problem, then we're fixing it through semi-technical means which is the wrong way to fix a perceived RIR problem. I also dislike the reverse DNS pointer in 9. Who administrates this, the RIR in charge of the ASN? So even though this seems to try to circumvent RIRs, parts of what the draft handles is still going to need RIR administration assistance? -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Sun Jan 27 00:15:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC43221F8903 for ; Sun, 27 Jan 2013 00:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.237 X-Spam-Level: X-Spam-Status: No, score=-101.237 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY-+megbpwLD for ; Sun, 27 Jan 2013 00:15:29 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id AB01121F88F0 for ; Sun, 27 Jan 2013 00:15:22 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so1054366wgi.3 for ; Sun, 27 Jan 2013 00:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=16g2c9t5wiM9e+/32tBgIx4j/132QbqmRhbHnjK82bs=; b=udv7TZihVUFMF0L5LtphDPUDQG7CVGpI0aQHLm9Kw3weGd8Jz2UhizcrfsGZtFVsl6 Vb9vSpVHNGB3mBGhjXgB1rkCxBUZVSVqEG6w7bBqekKEnRMK9i4ERBjuYzrSWcDxxzSu J2kWqPORUhjkMdPfaqCsL8M538trZlASPmu8gvH4IXpPLQKhKfY7IjliryIRtCdOcLI9 3wwIWGze9BJqSiG0s5ph9scvELxQt46jaHHSVwgIDMWqBjf1pC5zo83n1DvuT/gFt8l1 aJh0UKw/QTGmXreld7UIc0PoGLx/1/7QWECI9UnVURrKDDJfcK03OoFXiHVnPATeQRAD +WDA== X-Received: by 10.194.21.70 with SMTP id t6mr15788711wje.42.1359274521915; Sun, 27 Jan 2013 00:15:21 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-80.as13285.net. [2.102.217.80]) by mx.google.com with ESMTPS id cu7sm6118945wib.8.2013.01.27.00.15.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 00:15:20 -0800 (PST) Message-ID: <5104E212.8080709@gmail.com> Date: Sun, 27 Jan 2013 08:15:14 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <5102AB36.1010102@dougbarton.us> <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE114@PRVPEXVS15.corp.twcable.com> <510397F5.8090102@gmail.com> <51041EE2.9070906@bogus.com> In-Reply-To: <51041EE2.9070906@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-mlevy-v6ops-auto-v6-allocation-per-asn@tool.ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 08:15:29 -0000 Joel, On 26/01/2013 18:22, joel jaeggli wrote: > On 1/26/13 12:46 AM, Brian E Carpenter wrote: >> On 25/01/2013 20:02, George, Wes wrote: >> >>> I thought I remembered this idea being batted around in one or more >>> RIR policy discussions, but I don't know if anything ever came of it >>> (in terms of a formal policy proposal that was subsequently shot down >>> or approved) and a quick search didn't really turn up anything. >> I remember suggesting this idea to Steve Deering in about 1995, before >> IPv6 basics had even stabilised, and he explained to me why it was a bad >> idea because of the resulting BGP4 bloat. This was at a time when we did >> not expect PI prefixes to exist in IPv6, and we seriously hoped to have a >> very nicely aggregated IPv6 DFZ. > There a somewhat naive notion of what constitutes a provider that seems > to have pervaded that discussion. All I can say was that in 1995, CIDR was quite new, commercial and consumer use of the Internet was just getting seriously started, and there was serious hope that IPv6 would remain 100% provider-aggregated. My point was not to complain that this didn't work out, but to observe that this is not a new idea by any means. > It should have been obvious (was to me > at least) when among the first assignments were universities, equipment > vendors, and large enterprises, that the entities that find it > necessary to multihome from their own address space in ipv4 did (and > would) find it necessary to do so in ipv6. Yes, but that's why some of us have tried very hard to promote multi-prefix multihoming. However, that's a side issue for the present draft, which is just another form of PI allocation. > There are some other things > we were totally wrong about like flow cached forwarding. > > The ipv4 routing table doesn't have 440,000 ipv4 routes in it because > 30,000ish ASes find it necessary to advertise a prefix, a big chunk of > those only advertise 1 prefix in ipv4. It has 440k entries because ISPs > are fairly obnoxious polluters and enterprises like the one I work for > find it necessary to go back for additional direct assignments, > de-aggreate regionally for TE purposes, don't have enough bits in ipv4 > to hierarchically allocate prefixes so they can more easily be > aggregated. I have to de-aggregate in ipv6 for more or less the same > reasons except for the don't have enough bits problem, the upshot being > that I can better aggregate in ipv4 relative to ipv6 . >> That hope is receding today, so the >> argument is less strong than in 1995. All the same, unless there is >> factual evidence of operators finding it harder to get an IPv6 prefix >> than an AS #, it does seem like unnecessary entropy. > Having done this in three different entities over the years (in the arin > region), getting an AS number, ipv4 prefix assignment, and ipv6 prefix > assignment was not particularly onerous, prior to the notion of ipv6 > direct assignments, the justification for and entity that was not > obviously a transit isp was a bit different 12 years ago then it is now... That's the data point we need for this discussion. If there is no particular difficulty about getting a PI prefix *when it's justified* we don't need a new method. Brian >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From nick@inex.ie Sun Jan 27 08:20:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8246721F86D3 for ; Sun, 27 Jan 2013 08:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvK0lpjpKG0u for ; Sun, 27 Jan 2013 08:20:58 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7E21F86CE for ; Sun, 27 Jan 2013 08:20:56 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r0RGIPuj014758 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 27 Jan 2013 16:18:31 GMT (envelope-from nick@inex.ie) Message-ID: <510553DC.9080503@inex.ie> Date: Sun, 27 Jan 2013 16:20:44 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Randy Bush References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> <51041722.5080607@inex.ie> In-Reply-To: X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 16:20:58 -0000 On 27/01/2013 02:28, Randy Bush wrote: > can we please not in the pointless sport of draft torture to get it > properly on the table and in our gunsights? or stop discussing it. ok, whatevs. Without a clear statement of purpose, I'm left guessing that the purpose of this draft is probably a combination of an attempt to bypass the RIRs, to make ipv6 more easily available to end-users and to generally drop costs. There may also be an element of protest about RIR resource management, policy management and all that. These are all guesses, btw. The rationale needs to be stated clearly in the document. The problem as I see it is that this draft attempts to replace one system which is arguably broken at layers 9 and above with another system which is broken at layer 3 and above. in no particular order, specific technical problems with the draft include: - this looks like a rehash of rfc1897 with extra knobs. I used a 5f00::/8 prefix at the time and remember a disappointing lack of general management associated with it. - renumbering ASNs creates a requirement to renumber the network assignment. This is a major pain. - the draft creates a requirement for Internet-with-a-big-I DFZ routers to filter off an entire extra class of prefixes corresponding to the private ASN allocation ranges. - the whois mechanism is poorly specified. - the draft requests that the RIRs agree to this. I'm not going to make any statement about whether they would intend to or not, just that the IETF doesn't have any particular authority to demand this, although they can request it as a favour. But what happens if a RIR refuses to comply due to top-down or bottom up policy mandate, or simply because the bottom up process couldn't come to a conclusion? - as a separate issue, there is no existing mechanism to tie these prefixes into the IRRDBs (which are technically separate to the RIR assignment databases). This will have operational implications. - as an aside to this, there are two mechanisms for handling IRRDB registration: good faith (e.g. RADB, ALTDB) and grandfathered (RIPE DB, ARIN RR DB, etc). While there wouldn't be any particular reason that you couldn't register these prefixes in a good faith database, you couldn't register them in a grandfathered IRRDB without buy-in from the RIRs. This has serious implications for the IRRDB data trust model. - reverse DNS hard-codes IP addresses. I really don't like this on a matter of principal. It also explicitly prevents ipv4 dns servers from being used. - RPKI will not work without full support from the RIRs. - the proposal may drag the IETF into resource assignment arguments. - there is no indication of whether a prefix of this form must or should be announced from its corresponding ASN - no statement on what happens if someone relinquishes their ASN but decides hey they don't want to bother renumbering. - it ties ipv6 assignment to ASN assignment. These two things are separate and should probably be kept separate. - it will create ipv6 dfz bloat some nits relevant to the draft: - it should probably reference rfc1897 as a precedent - this line is incorrect: | AS29001 | 7149 | NNNN:0000:0001::/48 | it should be: | AS29001 | 7149 | NNNN:0002:9001::/48 | If this is an attempt to provide easy access to IPv6 addresses to anyone with an ASN, I can understand the intention but think the approach is broken. If it's an attempt to bypass the RIRs, it's also broken on multiple accounts - namely that it requires substantial RIR buy-in in order to work, but doesn't provide the RIRs with the resources to support those services. If there is a problem with RIRs, then perhaps that ought to be taken up by the RIR memberships so that they can fix their own problems from the bottom-up. Either way, I don't think that this draft solves any problems that I can see in such a way that even worse problems aren't created as a by-product. This is why I suggested that the authors need to specify their problem statement. Because of this I don't think that it ought to be adopted as a WG document. Nick From randy@psg.com Sun Jan 27 10:00:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84321F84E0 for ; Sun, 27 Jan 2013 10:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnKbEyjtyyk8 for ; Sun, 27 Jan 2013 10:00:51 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9221F84DE for ; Sun, 27 Jan 2013 10:00:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TzWX8-000PJc-Ec; Sun, 27 Jan 2013 18:00:46 +0000 Date: Mon, 28 Jan 2013 03:00:45 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <510553DC.9080503@inex.ie> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> <51041722.5080607@inex.ie> <510553DC.9080503@inex.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 18:00:52 -0000 > The problem as I see it is that this draft attempts to replace one > system which is arguably broken at layers 9 and above with another > system which is broken at layer 3 and above. pretty much agree, except i would s/9/8/ (apnic and arin being worse than ripe) > specific technical problems with the draft include: yep, fair arguments to either get these points addressed by the author or to not advance the draft. > - the draft requests that the RIRs agree to this. probably takes only one to do the whois, rdns, irr, certs, ... but i suspect none will touch it with a 3.048m pole. randy From nick@inex.ie Sun Jan 27 10:42:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E6521F843C for ; Sun, 27 Jan 2013 10:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFDLR1FNRwk2 for ; Sun, 27 Jan 2013 10:42:22 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9924921F843B for ; Sun, 27 Jan 2013 10:42:21 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r0RIdut6015346 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 27 Jan 2013 18:40:01 GMT (envelope-from nick@inex.ie) Message-ID: <51057507.3050302@inex.ie> Date: Sun, 27 Jan 2013 18:42:15 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Randy Bush References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> <51041722.5080607@inex.ie> <510553DC.9080503@inex.ie> In-Reply-To: X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 18:42:23 -0000 On 27/01/2013 18:00, Randy Bush wrote: > probably takes only one to do the whois, rdns, irr, certs, ... but i > suspect none will touch it with a 3.048m pole. it will take buy-in from all of them due to the way that ASNs are allocated piecemeal from iana. mess level: severe. Nick From jcurran@istaff.org Sun Jan 27 12:16:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A712821F87C3 for ; Sun, 27 Jan 2013 12:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta-wi5a67XrP for ; Sun, 27 Jan 2013 12:16:04 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2723621F871D for ; Sun, 27 Jan 2013 12:16:04 -0800 (PST) Received: from pool-72-66-100-126.washdc.fios.verizon.net ([72.66.100.126] helo=[192.168.1.5]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TzYe2-0007Oy-UE; Sun, 27 Jan 2013 20:16:02 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 72.66.100.126 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX197gKhieBZCyZ8M92cEBIUs Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Curran In-Reply-To: <510553DC.9080503@inex.ie> Date: Sun, 27 Jan 2013 15:16:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <60BDFA2F-5266-4CCF-B1DE-FB7AAAA2521D@istaff.org> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> <51041722.5080607@inex.ie> <510553DC.9080503@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1499) Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 20:16:04 -0000 On Jan 27, 2013, at 11:20 AM, Nick Hilliard wrote: > ... > - the draft requests that the RIRs agree to this. I'm not going to = make > any statement about whether they would intend to or not, just that the = IETF > doesn't have any particular authority to demand this, although they = can > request it as a favour. But what happens if a RIR refuses to comply = due to > top-down or bottom up policy mandate, or simply because the bottom up > process couldn't come to a conclusion? If the Internet technical community feels that the world has changed (or=20= is now sufficiently well understood?) such that autonomous systems = should=20 be able to automatically have provider-independent IPv6 prefixes, then=20= that is worth clearly stating. The Internet technical community = consists of lots of folks (including protocol and system folks, academics, = operators, etc.); some participate in IETF and some in the Regional registry = meetings. =20 There are actually agreements that are applicable to how Internet = addresses are managed (e.g. parts of RFC 2860), but in general, the status quo = prevails=20 unless/until the Internet community has reached some overall consensus = on=20 some need for change. I don't see any reason for the IETF not to consider the question posed = by the=20 draft, as it is architectural in nature (effectively being "would = Internet route=20 aggregation be significantly harmed if IPv6 included = provider-independent prefixes=20 for all autonomous systems?"), but am also realistic that any such = finding would=20 also need to be considered in those participating in the Regional = registry=20 communities if we're to achieve overall consensus. I have yet to see a case where the IETF and RIR processes have not = converged=20 on an outcome, and while there always is a potential for such = disagreement,=20 that is usually indicative that _more_ discussion of merits and concerns = of=20 a topic is needed, not less. FYI, /John Disclaimer: My views alone, based on personal experience with RIR and = IETF=20 processes; YMMV. From jan@go6.si Mon Jan 28 01:03:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC5521F87B3 for ; Mon, 28 Jan 2013 01:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvu1rtuvxTlW for ; Mon, 28 Jan 2013 01:03:00 -0800 (PST) Received: from ipv6.go6.si (unknown [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610F321F844A for ; Mon, 28 Jan 2013 01:03:00 -0800 (PST) Received: from isoc-macbook15.local (unknown [62.205.99.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id CC9CC23780C1 for ; Mon, 28 Jan 2013 10:02:55 +0100 (CET) Message-ID: <51063EC1.8030601@go6.si> Date: Mon, 28 Jan 2013 10:02:57 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <20130125120734.GX51699@Space.Net> <51041722.5080607@inex.ie> <510553DC.9080503@inex.ie> <51057507.3050302@inex.ie> In-Reply-To: <51057507.3050302@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 09:03:01 -0000 On 1/27/13 7:42 PM, Nick Hilliard wrote: > On 27/01/2013 18:00, Randy Bush wrote: >> probably takes only one to do the whois, rdns, irr, certs, ... but i >> suspect none will touch it with a 3.048m pole. > it will take buy-in from all of them due to the way that ASNs are allocated > piecemeal from iana. mess level: severe. > +1 Jan From cb.list6@gmail.com Mon Jan 28 20:03:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DA021E8083 for ; Mon, 28 Jan 2013 20:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU7skCCG4140 for ; Mon, 28 Jan 2013 20:03:46 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id E98F021E8042 for ; Mon, 28 Jan 2013 20:03:45 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fo13so2433lab.38 for ; Mon, 28 Jan 2013 20:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=zVBZcny7LDpsGASzrXKaAKVGY1c7+hv983+yuoLf6Y8=; b=BOTzTacwgHwpUnhrvwCjqcNZHCU+odFFcq2cFfD2S7Amhm7R2MLefMGVA3rwm9R97/ r5vYJtMCGdo7X7hhOubZkW6TnWatAmWoYJbuqCN88apk77Ev/UuKjLTim7omLtD8kKrd +8coAF4R69FtnIrrUt4xQHXietT2gZiV4J76RJkC5k2UK+ubOxU/p1vbvLi6mo1vdc7U 8cN5BFM86bGm7yy76pOgXl9Dw4x04EdfjdhSdnR9+E98v7xOodH6kBlStcSWu90EGhZl j/Jkyhd7qh1lbny0NZcwKyzngr3X/2/6l7vSWr/j2CY0wCAC5lk3j3S3hR6xfdTqt1gT deNw== MIME-Version: 1.0 X-Received: by 10.112.46.199 with SMTP id x7mr172270lbm.109.1359432224628; Mon, 28 Jan 2013 20:03:44 -0800 (PST) Received: by 10.112.7.165 with HTTP; Mon, 28 Jan 2013 20:03:44 -0800 (PST) In-Reply-To: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> Date: Mon, 28 Jan 2013 20:03:44 -0800 Message-ID: From: Cameron Byrne To: Randy Bush Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 04:03:47 -0000 On Fri, Jan 25, 2013 at 11:54 PM, Randy Bush wrote: >> Could the root cause be that ARIN charges at least $1250 per PI >> allocation, whereas it costs =8050 in RIPEland if you're smart enough >> to attach yourself to a LIR? > > and you get the pain of dealing with the bureaucracy and arrogance. > >> In any case, there's a long history of horrible technology kludges >> created to "solve" layer 8-10 problems ... and they all looked like >> a great idea once. > > exactly. the long term solution is to clean up the rirs. > What exactly would a clean up of the RIR entail? In any event, let us have mercy on the folks who would benefit from this /48 per ASN. I see no major downside and a substantial upside to making this I-D a WG dr= aft. CB > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dougb@dougbarton.us Mon Jan 28 20:28:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E11321E8087 for ; Mon, 28 Jan 2013 20:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlrGwIQGKjK2 for ; Mon, 28 Jan 2013 20:28:26 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 95EF021E8083 for ; Mon, 28 Jan 2013 20:28:26 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:9dbe:e3d1:5bc5:4ff5] (unknown [IPv6:2001:470:d:5e7:9dbe:e3d1:5bc5:4ff5]) by dougbarton.us (Postfix) with ESMTPSA id 2B87522BA7 for ; Tue, 29 Jan 2013 04:28:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1359433706; bh=0nQ0E/HGJQq+SKwmY28hu+G/MdTp5UcKzoSUYA0ZgZ4=; h=Date:From:To:Subject:References:In-Reply-To; b=fvsV5VNX19FVEm+JfgJYelTi8IenttBegBFyqPox3BqrIiO+cHfu35oE25ZAaGCnu LurFdGY342ix1hgbxXPk1mXunz4vtwy28R4fnD/othdPDtrlIfqsRXOMrwAIW6NweC 9o+aOLumgzfDvlyBGNMR8000i66+7Hinf2GTbDkk= Message-ID: <51074FE9.1080509@dougbarton.us> Date: Mon, 28 Jan 2013 22:28:25 -0600 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 04:28:27 -0000 On 01/28/2013 10:03 PM, Cameron Byrne wrote: > What exactly would a clean up of the RIR entail? Outside the scope of of this WG, IMO. There are various and sundry improvements that could be made in all 5, but ... > In any event, let us have mercy on the folks who would benefit from > this /48 per ASN. Before this would even be a viable candidate, it is necessary to define what the current barriers are that prevent organizations who already have, or will be assigned, an ASN from also getting PI space now. To the best of my knowledge not only are there no meaningful barriers now, all of the RIR policies that I'm aware of (and while my knowledge isn't perfect, I do try to stay on top of these things) already _encourage_ organizations to get IPv6 allocations. > I see no major downside and a substantial upside to making this I-D a WG draft. Have you actually followed the discussion on the list to date? There have been numerous downsides discussed, and no upsides defined yet. Doug From randy@psg.com Mon Jan 28 20:44:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4231F0CFA for ; Mon, 28 Jan 2013 20:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCwViLQUorQd for ; Mon, 28 Jan 2013 20:44:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA61F0D05 for ; Mon, 28 Jan 2013 20:44:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U033o-0005CD-DZ; Tue, 29 Jan 2013 04:44:40 +0000 Date: Tue, 29 Jan 2013 13:44:39 +0900 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 04:44:46 -0000 > What exactly would a clean up of the RIR entail? well, to start, teaching them words such as 'bookkeeper' 'customer' ... > In any event, let us have mercy on the folks who would benefit from > this /48 per ASN. who are they? > I see no major downside and a substantial upside to making this I-D a > WG draft. hey, i get credit for being the first to advocate adoption. just don't take this to mean i think the draft should progress further. but i am listening. randy From cb.list6@gmail.com Mon Jan 28 21:17:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743C721F85D4 for ; Mon, 28 Jan 2013 21:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjY4W4AZg4bI for ; Mon, 28 Jan 2013 21:17:35 -0800 (PST) Received: from mail-la0-x229.google.com (la-in-x0229.1e100.net [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0E49D21F84DA for ; Mon, 28 Jan 2013 21:17:34 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so24659lab.28 for ; Mon, 28 Jan 2013 21:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VijDOg7VX9TgAKjiS01J+5CkmZpKSuh3yeHG+hP2dI8=; b=Sa6Lxh1UkF7QxN/fEB0+n/rIw7umnX7ShWbkul4OiKUdO39ToQDVBk5hHOUVqWpW/n xHE5YbAzHP0+87/FyYHMEXUlAU4592wswFdLioAGpliDOuDJFmQzA2GjJAmDRuUWvX8K UHR/IwlxnCBfGG5zAzIIR86tvcOUzzDDejwwhr4CEhQgT5s4TrcY2WNogBiAG+lzbEk1 hzJ8KxKdCEHv3AtpLqBfXJqNZQobQX10ahy6gHir8AXBivjtnBxekrryx/ciQY/+EL08 I30ba2Jvm7svPCqPvhoyXZ9mMrOvjvpGwxZpgO1NR/VHljUYd/87KAccP4hyuZVsRNuF AdDA== MIME-Version: 1.0 X-Received: by 10.152.132.137 with SMTP id ou9mr276321lab.7.1359436653693; Mon, 28 Jan 2013 21:17:33 -0800 (PST) Received: by 10.112.7.165 with HTTP; Mon, 28 Jan 2013 21:17:33 -0800 (PST) Received: by 10.112.7.165 with HTTP; Mon, 28 Jan 2013 21:17:33 -0800 (PST) In-Reply-To: <51074FE9.1080509@dougbarton.us> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> <51074FE9.1080509@dougbarton.us> Date: Mon, 28 Jan 2013 21:17:33 -0800 Message-ID: From: Cameron Byrne To: Doug Barton Content-Type: multipart/alternative; boundary=f46d042c6aedd68b5104d4668219 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 05:17:36 -0000 --f46d042c6aedd68b5104d4668219 Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Jan 28, 2013 8:28 PM, "Doug Barton" wrote: > > On 01/28/2013 10:03 PM, Cameron Byrne wrote: > > > What exactly would a clean up of the RIR entail? > > Outside the scope of of this WG, IMO. There are various and sundry > improvements that could be made in all 5, but ... > > > In any event, let us have mercy on the folks who would benefit from > > this /48 per ASN. > > Before this would even be a viable candidate, it is necessary to define > what the current barriers are that prevent organizations who already > have, or will be assigned, an ASN from also getting PI space now. To the > best of my knowledge not only are there no meaningful barriers now, all > of the RIR policies that I'm aware of (and while my knowledge isn't > perfect, I do try to stay on top of these things) already _encourage_ > organizations to get IPv6 allocations. > I do not believe ARIN has done much to push v6. They showed up for carrier transition space and have done drip-feed ipv4 allocation policy to make the transition last as long as possible and ensuring the future of CGN. Let's just say I do not feel well served by my RIR. That has been my feeling for 13 years. I have tried to be involved in RIR policy, but it has been a real stretch of my patience. > > I see no major downside and a substantial upside to making this I-D a WG draft. > > Have you actually followed the discussion on the list to date? There > have been numerous downsides discussed, and no upsides defined yet. > TL; DR I stopped dreaming that ipv6 was going to be strongly aggregated at least 5 years ago. Many networks dont use rir whois / rdns / ... Upside is that I dont have to disclose anything to an rir who has no business / understanding in how my network runs. If LISP can get a /16, so can this. CB --f46d042c6aedd68b5104d4668219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Jan 28, 2013 8:28 PM, "Doug Barton" <dougb@dougbarton.us> wrote:
>
> On 01/28/2013 10:03 PM, Cameron Byrne wrote:
>
> > What exactly would a clean up of the RIR entail?
>
> Outside the scope of of this WG, IMO. There are various and sundry
> improvements that could be made in all 5, but ...
>
> > In any event, let us have mercy on the folks who would benefit fr= om
> > this /48 per ASN.
>
> Before this would even be a viable candidate, it is necessary to defin= e
> what the current barriers are that prevent organizations who already > have, or will be assigned, an ASN from also getting PI space now. To t= he
> best of my knowledge not only are there no meaningful barriers now, al= l
> of the RIR policies that I'm aware of (and while my knowledge isn&= #39;t
> perfect, I do try to stay on top of these things) already _encourage_<= br> > organizations to get IPv6 allocations.
>

I do not believe ARIN has done much to push v6. They showed = up for carrier transition space and have done drip-feed ipv4 allocation pol= icy to make the transition last as long as possible and ensuring the future= of CGN.

Let's just say I do not feel well served by my RIR. Tha= t has been my feeling for 13 years. I have tried to be involved in RIR poli= cy,=A0 but it has been a real stretch of my patience.

> > I see no major downside and a substantial upside t= o making this I-D a WG draft.
>
> Have you actually followed the discussion on the list to date? There > have been numerous downsides discussed, and no upsides defined yet. >

TL; DR

I stopped dreaming that ipv6 was going to be strongly aggreg= ated at least 5 years ago.=A0 Many networks dont use rir whois / rdns / ...=

Upside is that I dont have to disclose anything to an rir wh= o has no business / understanding in how my network runs.

If LISP can get a /16, so can this.

CB

--f46d042c6aedd68b5104d4668219-- From dougb@dougbarton.us Mon Jan 28 22:08:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AA421F89B9 for ; Mon, 28 Jan 2013 22:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mam3s0X6-PB6 for ; Mon, 28 Jan 2013 22:08:45 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9321F8928 for ; Mon, 28 Jan 2013 22:08:45 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:9dbe:e3d1:5bc5:4ff5] (unknown [IPv6:2001:470:d:5e7:9dbe:e3d1:5bc5:4ff5]) by dougbarton.us (Postfix) with ESMTPSA id 58BE822BA7; Tue, 29 Jan 2013 06:08:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1359439723; bh=VEFFNVa58zhmP2AEwNTGCgviHjRUu/M6Mo4v7Qj0WhQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=TuGF7o8yVim8OstZKOQa33UD9OJOCLTqz/ysboengZOwPhEjvdBeryghaDBvr7Hv0 gYH8dMJiZdpQSjHtVMhkAxDAwKPI2Z5fjvEuNwE5crBy68xTuYPHuXNo72n7DNajyq O5FXfXbEtc9jxqtt7Z+S8Gj/2UNwMRSgZS7oVtMM= Message-ID: <5107676B.4060705@dougbarton.us> Date: Tue, 29 Jan 2013 00:08:43 -0600 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Cameron Byrne References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> <51074FE9.1080509@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 06:08:46 -0000 On 01/28/2013 11:17 PM, Cameron Byrne wrote: > Sent from ipv6-only Android > On Jan 28, 2013 8:28 PM, "Doug Barton" > wrote: >> >> On 01/28/2013 10:03 PM, Cameron Byrne wrote: >> >> > What exactly would a clean up of the RIR entail? >> >> Outside the scope of of this WG, IMO. There are various and sundry >> improvements that could be made in all 5, but ... >> >> > In any event, let us have mercy on the folks who would benefit from >> > this /48 per ASN. >> >> Before this would even be a viable candidate, it is necessary to define >> what the current barriers are that prevent organizations who already >> have, or will be assigned, an ASN from also getting PI space now. To the >> best of my knowledge not only are there no meaningful barriers now, all >> of the RIR policies that I'm aware of (and while my knowledge isn't >> perfect, I do try to stay on top of these things) already _encourage_ >> organizations to get IPv6 allocations. >> > > I do not believe ARIN has done much to push v6. Then to put it bluntly, you haven't been paying attention. I have "issues" with some of what ARIN does, and/or how they do it, but they have been going out of their way to promote v6 adoption for years now, especially during the "promotional period" when they were practically giving it away. I don't have all the details easily to hand atm, and frankly don't feel compelled to dig them up for you. On the contrary, the burden is on you (and other proponents) to demonstrate actual, concrete barriers that the RIRs have placed in front of v6 allocation, and why this draft would solve them. > They showed up for > carrier transition space and have done drip-feed ipv4 allocation policy > to make the transition last as long as possible and ensuring the future > of CGN. Their support of "the CGN prefix" is one of the things they have done that I don't like, for sure. I do think that carefully scrutinizing all applications at this point is reasonable, but in my experience this isn't really a new policy. > Let's just say I do not feel well served by my RIR. That has been my > feeling for 13 years. I have tried to be involved in RIR policy, but it > has been a real stretch of my patience. C'est la vie. No one said it would be easy. Personally I have chosen not to tilt at these particular windmills because I have other things to fill my days with. You have to decide how important it is to you. >> > I see no major downside and a substantial upside to making this I-D > a WG draft. >> >> Have you actually followed the discussion on the list to date? There >> have been numerous downsides discussed, and no upsides defined yet. >> > > TL; DR > > I stopped dreaming that ipv6 was going to be strongly aggregated at > least 5 years ago. Many networks dont use rir whois / rdns / ... > > Upside is that I dont have to disclose anything to an rir who has no > business / understanding in how my network runs. So what you want is an end-run around the RIRs? The IETF is not going to approve that (nor should they). They are equally unlikely (nee unable) to dictate to the RIRs that they allocate space to people outside of their usual policies/procedures/fees/etc. In short, completely aside from all the reasons this is a bad idea, it cannot, and should not happen. Can we move on now? Doug From randy@psg.com Mon Jan 28 22:17:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA3B21F8A74 for ; Mon, 28 Jan 2013 22:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYzSocGRvW4B for ; Mon, 28 Jan 2013 22:17:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DC9F121F8A6F for ; Mon, 28 Jan 2013 22:17:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U04Vw-0005Om-5H; Tue, 29 Jan 2013 06:17:48 +0000 Date: Tue, 29 Jan 2013 15:17:47 +0900 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> <51074FE9.1080509@dougbarton.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 06:17:49 -0000 > If LISP can get a /16, so can this. it's not the space. if that was all of it, i would be a very strong supporter. it's the whois, reverse dns, irr, rpki, ... and, while the receiver may or not want those services, as an op who gets their packets, i want them to have them. and, while the rir cartel is pretty aggressive at layers nine and ten, they're damaged and stingy at eight and below. so who provides those services? randy From gert@space.net Tue Jan 29 00:30:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B56221F866D for ; Tue, 29 Jan 2013 00:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPM7416PW6aH for ; Tue, 29 Jan 2013 00:30:43 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id DDA0521F8658 for ; Tue, 29 Jan 2013 00:30:42 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 6A7F960337 for ; Tue, 29 Jan 2013 09:30:38 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4BFA2602B4 for ; Tue, 29 Jan 2013 09:30:38 +0100 (CET) Received: (qmail 56794 invoked by uid 1007); 29 Jan 2013 09:30:38 +0100 Date: Tue, 29 Jan 2013 09:30:38 +0100 From: Gert Doering To: Cameron Byrne Message-ID: <20130129083038.GR51699@Space.Net> References: <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@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.21 (2010-09-15) Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 08:30:43 -0000 Hi, On Mon, Jan 28, 2013 at 08:03:44PM -0800, Cameron Byrne wrote: > In any event, let us have mercy on the folks who would benefit from > this /48 per ASN. Who exactly would that be? (I see this through RIPE land glasses, so there might well be some good reasons in the ARIN region) 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 (89) 32356-444 USt-IdNr.: DE813185279 From cb.list6@gmail.com Tue Jan 29 06:36:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098FB21F8890 for ; Tue, 29 Jan 2013 06:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACm12yztLCrQ for ; Tue, 29 Jan 2013 06:36:06 -0800 (PST) Received: from mail-la0-x233.google.com (la-in-x0233.1e100.net [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9E59921F8487 for ; Tue, 29 Jan 2013 06:36:05 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fo13so348303lab.38 for ; Tue, 29 Jan 2013 06:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OLdy6Tn/QzJ0T6vdtBOKgh12WaLfLLwyzPwK2g4Hu7s=; b=Sxl6SUFjEus3pKsVjoxWvSAW6cFCClZiVLyKKrynZSV1w3PdBeSL+mwLr2je2xYtMX ku+X2cyjloi4tLkYADpUiVXJ9D/FQWWEowzMjLXTn8KocH0vCvKHEdxU9t21tCQgSx5K 3BWwufjPX/AwuKw6eAXm4JYPCGs3dnx0gFnWcKKD0y0i15X3NpKdkzRue+Ne5nDEAv4l j4NZbIKSSSXz3Xs2NqQCkaDsfiYXUtMjI/SzNHBYQNFLYV79KKfWR7h6GQYT+k/sAfVe S9Ny4rmqZcM4uQkSvsD61hqe8PzjnxYxkOHHFSdOiAVZUABZoCssSQ7IqkYsJLbuqgZ+ yqcw== MIME-Version: 1.0 X-Received: by 10.112.17.108 with SMTP id n12mr568550lbd.21.1359470164434; Tue, 29 Jan 2013 06:36:04 -0800 (PST) Received: by 10.112.7.165 with HTTP; Tue, 29 Jan 2013 06:36:04 -0800 (PST) Received: by 10.112.7.165 with HTTP; Tue, 29 Jan 2013 06:36:04 -0800 (PST) In-Reply-To: <5107676B.4060705@dougbarton.us> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> <51074FE9.1080509@dougbarton.us> <5107676B.4060705@dougbarton.us> Date: Tue, 29 Jan 2013 06:36:04 -0800 Message-ID: From: Cameron Byrne To: Doug Barton Content-Type: multipart/alternative; boundary=f46d0401fc913be15604d46e505a Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 14:36:07 -0000 --f46d0401fc913be15604d46e505a Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Jan 28, 2013 10:08 PM, "Doug Barton" wrote: > > On 01/28/2013 11:17 PM, Cameron Byrne wrote: > > Sent from ipv6-only Android > > On Jan 28, 2013 8:28 PM, "Doug Barton" > > wrote: > >> > >> On 01/28/2013 10:03 PM, Cameron Byrne wrote: > >> > >> > What exactly would a clean up of the RIR entail? > >> > >> Outside the scope of of this WG, IMO. There are various and sundry > >> improvements that could be made in all 5, but ... > >> > >> > In any event, let us have mercy on the folks who would benefit from > >> > this /48 per ASN. > >> > >> Before this would even be a viable candidate, it is necessary to define > >> what the current barriers are that prevent organizations who already > >> have, or will be assigned, an ASN from also getting PI space now. To the > >> best of my knowledge not only are there no meaningful barriers now, all > >> of the RIR policies that I'm aware of (and while my knowledge isn't > >> perfect, I do try to stay on top of these things) already _encourage_ > >> organizations to get IPv6 allocations. > >> > > > > I do not believe ARIN has done much to push v6. > > Then to put it bluntly, you haven't been paying attention. I have Far out. > "issues" with some of what ARIN does, and/or how they do it, but they > have been going out of their way to promote v6 adoption for years now, > especially during the "promotional period" when they were practically > giving it away. I don't have all the details easily to hand atm, and > frankly don't feel compelled to dig them up for you. > > On the contrary, the burden is on you (and other proponents) to Why is the burden on me? Because of inertia? > demonstrate actual, concrete barriers that the RIRs have placed in front > of v6 allocation, and why this draft would solve them. > > > They showed up for > > carrier transition space and have done drip-feed ipv4 allocation policy > > to make the transition last as long as possible and ensuring the future > > of CGN. > > Their support of "the CGN prefix" is one of the things they have done > that I don't like, for sure. I do think that carefully scrutinizing all > applications at this point is reasonable, but in my experience this > isn't really a new policy. > > > Let's just say I do not feel well served by my RIR. That has been my > > feeling for 13 years. I have tried to be involved in RIR policy, but it > > has been a real stretch of my patience. > > C'est la vie. No one said it would be easy. Personally I have chosen not > to tilt at these particular windmills because I have other things to > fill my days with. You have to decide how important it is to you. > > >> > I see no major downside and a substantial upside to making this I-D > > a WG draft. > >> > >> Have you actually followed the discussion on the list to date? There > >> have been numerous downsides discussed, and no upsides defined yet. > >> > > > > TL; DR > > > > I stopped dreaming that ipv6 was going to be strongly aggregated at > > least 5 years ago. Many networks dont use rir whois / rdns / ... > > > > Upside is that I dont have to disclose anything to an rir who has no > > business / understanding in how my network runs. > > So what you want is an end-run around the RIRs? The IETF is not going to > approve that (nor should they). They are equally unlikely (nee unable) > to dictate to the RIRs that they allocate space to people outside of > their usual policies/procedures/fees/etc. > > In short, completely aside from all the reasons this is a bad idea, it > cannot, and should not happen. > > Can we move on now? > > Doug > --f46d0401fc913be15604d46e505a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Jan 28, 2013 10:08 PM, "Doug Barton" <dougb@dougbarton.us> wrote:
>
> On 01/28/2013 11:17 PM, Cameron Byrne wrote:
> > Sent from ipv6-only Android
> > On Jan 28, 2013 8:28 PM, "Doug Barton" <dougb@dougbarton.us
> > <mailto:dougb@dougbarto= n.us>> wrote:
> >>
> >> On 01/28/2013 10:03 PM, Cameron Byrne wrote:
> >>
> >> > What exactly would a clean up of the RIR entail?
> >>
> >> Outside the scope of of this WG, IMO. There are various and s= undry
> >> improvements that could be made in all 5, but ...
> >>
> >> > In any event, let us have mercy on the folks who would b= enefit from
> >> > this /48 per ASN.
> >>
> >> Before this would even be a viable candidate, it is necessary= to define
> >> what the current barriers are that prevent organizations who = already
> >> have, or will be assigned, an ASN from also getting PI space = now. To the
> >> best of my knowledge not only are there no meaningful barrier= s now, all
> >> of the RIR policies that I'm aware of (and while my knowl= edge isn't
> >> perfect, I do try to stay on top of these things) already _en= courage_
> >> organizations to get IPv6 allocations.
> >>
> >
> > I do not believe ARIN has done much to push v6.
>
> Then to put it bluntly, you haven't been paying attention. I have<= /p>

Far out.

> "issues" with some of what ARIN does, and/or = how they do it, but they
> have been going out of their way to promote v6 adoption for years now,=
> especially during the "promotional period" when they were pr= actically
> giving it away. I don't have all the details easily to hand atm, a= nd
> frankly don't feel compelled to dig them up for you.
>
> On the contrary, the burden is on you (and other proponents) to

Why is the burden on me? Because of inertia?

> demonstrate actual, concrete barriers that the RIRs hav= e placed in front
> of v6 allocation, and why this draft would solve them.
>
> > They showed up for
> > carrier transition space and have done drip-feed ipv4 allocation = policy
> > to make the transition last as long as possible and ensuring the = future
> > of CGN.
>
> Their support of "the CGN prefix" is one of the things they = have done
> that I don't like, for sure. I do think that carefully scrutinizin= g all
> applications at this point is reasonable, but in my experience this > isn't really a new policy.
>
> > Let's just say I do not feel well served by my RIR. That has = been my
> > feeling for 13 years. I have tried to be involved in RIR policy, = =A0but it
> > has been a real stretch of my patience.
>
> C'est la vie. No one said it would be easy. Personally I have chos= en not
> to tilt at these particular windmills because I have other things to > fill my days with. You have to decide how important it is to you.
>
> >> > I see no major downside and a substantial upside to maki= ng this I-D
> > a WG draft.
> >>
> >> Have you actually followed the discussion on the list to date= ? There
> >> have been numerous downsides discussed, and no upsides define= d yet.
> >>
> >
> > TL; DR
> >
> > I stopped dreaming that ipv6 was going to be strongly aggregated = at
> > least 5 years ago. =A0Many networks dont use rir whois / rdns / .= ..
> >
> > Upside is that I dont have to disclose anything to an rir who has= no
> > business / understanding in how my network runs.
>
> So what you want is an end-run around the RIRs? The IETF is not going = to
> approve that (nor should they). They are equally unlikely (nee unable)=
> to dictate to the RIRs that they allocate space to people outside of > their usual policies/procedures/fees/etc.
>
> In short, completely aside from all the reasons this is a bad idea, it=
> cannot, and should not happen.
>
> Can we move on now?
>
> Doug
>

--f46d0401fc913be15604d46e505a-- From sander@steffann.nl Tue Jan 29 06:47:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E435B21F8542 for ; Tue, 29 Jan 2013 06:47:29 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1OSwr8vGkX3 for ; Tue, 29 Jan 2013 06:47:29 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1916B21F84FC for ; Tue, 29 Jan 2013 06:47:28 -0800 (PST) Received: from [IPv6:2a02:88fe:de30:1104:f413:1210:f9c1:b76f] (unknown [IPv6:2a02:88fe:de30:1104:f413:1210:f9c1:b76f]) by mail.sintact.nl (Postfix) with ESMTP id CAB632059; Tue, 29 Jan 2013 15:47:27 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Tue, 29 Jan 2013 14:47:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <582B2171-BB1A-4C4F-959F-8404FAE8B474@steffann.nl> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> <51074FE9.1080509@dougbarton.us> <5107676B.4060705@dougbarton.us> To: Cameron Byrne X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 14:47:30 -0000 Hi, > > "issues" with some of what ARIN does, and/or how they do it, but = they > > have been going out of their way to promote v6 adoption for years = now, > > especially during the "promotional period" when they were = practically > > giving it away. I don't have all the details easily to hand atm, and > > frankly don't feel compelled to dig them up for you. > > > > On the contrary, the burden is on you (and other proponents) to >=20 > Why is the burden on me? Because of inertia? I think the burden is on the people who want to push this policy = forward. I don't think it's unreasonable to let those who want to change = something explain/justify why they want the change. If it's not possible = to give good reasons for a proposal then why propose it in the first = place? Thanks, Sander From randy@psg.com Tue Jan 29 07:25:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1D821F8940 for ; Tue, 29 Jan 2013 07:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOiM4KJJJYZM for ; Tue, 29 Jan 2013 07:25:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1282021F8936 for ; Tue, 29 Jan 2013 07:25:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U0D3q-0006dO-OM for v6ops@ietf.org; Tue, 29 Jan 2013 15:25:22 +0000 Date: Wed, 30 Jan 2013 00:25:22 +0900 Message-ID: From: Randy Bush To: IETF v6ops list In-Reply-To: <582B2171-BB1A-4C4F-959F-8404FAE8B474@steffann.nl> References: <20130125024220.17785.82562.idtracker@ietfa.amsl.com> <5101F21B.2050204@bogus.com> <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> <51074FE9.1080509@dougbarton.us> <5107676B.4060705@dougbarton.us> <582B2171-BB1A-4C4F-959F-8404FAE8B474@steffann.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:25:24 -0000 [ attribution intentionally removed ] < pontification > >>> On the contrary, the burden is on you (and other proponents) to >> Why is the burden on me? Because of inertia? > I think the burden is on the people who want to push this policy > forward. we all share the burden, that of making the best engineering decision we can. can we please stick to the engineering part of the discussion? despite 60+ messages in the thread, i have not learned anything new on this one for nigh a day. and yes, this message is as guilty as most. randy From holger.metschulat@telekom.de Tue Jan 29 07:25:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC1F21F896B for ; Tue, 29 Jan 2013 07:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlEhMUL8S-5C for ; Tue, 29 Jan 2013 07:25:47 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8766821F892F for ; Tue, 29 Jan 2013 07:25:47 -0800 (PST) From: Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 29 Jan 2013 16:25:08 +0100 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 29 Jan 2013 16:25:08 +0100 To: Date: Tue, 29 Jan 2013 16:25:07 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: Ac343+oS6nOnfObnRTuCtVeptfxsVQFUgDHg Message-ID: References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:25:48 -0000 -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Cameron Byrne Gesendet: Dienstag, 22. Januar 2013 21:34 An: Mark Smith Cc: v6ops@ietf.org Betreff: Re: [v6ops] draft-ietf-v6ops-64share Cameron, > I think would rather avoid any of this translational bridging business. = And in fact, i am=20 > only trying to document running code to avoid multiple divergent methods= of achieving the > same goal. > That said, it appears a few folks (Rajiv and Alex) have some indigestion = over having one IP=20 > address in multiple places. It works for me, but i can accept that it ma= y not work well for others. I personally also don't like the idea of having the same IP address in two = places. I always look at this as the UE's own IPv6 address attached to an i= nternal interface int0 inside the UE, and the UE building a "virtual brigde= " connecting the wlan0, int0 and wwan0 interface together. In front of the = wwan0 interface, there is a matching logic adapting Ethernet L2 towards the= WWAN L2 the same way as it was done when connecting Frame Relay PPP connec= tions into Ethernet interfaces (Juniper calls this "translational crossconn= ects"; I am sure other vendors have similar implementations as well). Howev= er, I don't have a good word for describing such a scenario. Holger From alexandru.petrescu@gmail.com Tue Jan 29 08:20:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1EF21F8834 for ; Tue, 29 Jan 2013 08:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.779 X-Spam-Level: X-Spam-Status: No, score=-9.779 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U-YNbfF8aYf for ; Tue, 29 Jan 2013 08:20:14 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id F034621F882C for ; Tue, 29 Jan 2013 08:20:13 -0800 (PST) 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 r0TGKCiW029289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 Jan 2013 17:20:12 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0TGKCLE013380 for ; Tue, 29 Jan 2013 17:20:12 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0TGK3fb026978 for ; Tue, 29 Jan 2013 17:20:12 +0100 Message-ID: <5107F6B2.8070708@gmail.com> Date: Tue, 29 Jan 2013 17:20:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 16:20:14 -0000 Le 29/01/2013 16:25, holger.metschulat@telekom.de a écrit : > -----Ursprüngliche Nachricht----- Von: v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] Im Auftrag von Cameron Byrne > Gesendet: Dienstag, 22. Januar 2013 21:34 An: Mark Smith Cc: > v6ops@ietf.org Betreff: Re: [v6ops] draft-ietf-v6ops-64share > > Cameron, > >> I think would rather avoid any of this translational bridging >> business. And in fact, i am only trying to document running code >> to avoid multiple divergent methods of achieving the same goal. > >> That said, it appears a few folks (Rajiv and Alex) have some >> indigestion over having one IP address in multiple places. It >> works for me, but i can accept that it may not work well for >> others. > > I personally also don't like the idea of having the same IP address > in two places. I always look at this as the UE's own IPv6 address > attached to an internal interface int0 inside the UE, and the UE > building a "virtual brigde" connecting the wlan0, int0 and wwan0 > interface together. In front of the wwan0 interface, there is a > matching logic adapting Ethernet L2 towards the WWAN L2 The bridging of the virtual interface and the other two real interface- I could visualize it, with a single address attributed to the virtual interface. However, I wonder what this bridging may mean to routing. If all the interfaces on this machine are 'bridged' (maybe brconfig, brctl) then is there any IP routing possible on this machine. I guess the two subnets - the one on wwan0 and the one on wlan0 - shoudl stay separate scope. One wouldn't want a NS sent by a Host in the WLAN subnetwork be transmitted to the WWAN subnetwork. > the same way as it was done when connecting Frame Relay PPP > connections into Ethernet interfaces (Juniper calls this > "translational crossconnects"; I am sure other vendors have similar > implementations as well). I guess the figure there would be similar, but I have never seen a Frame Relay. Alex > However, I don't have a good word for describing such a scenario. > > Holger _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From rajiva@cisco.com Tue Jan 29 09:18:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D9B21F86B7 for ; Tue, 29 Jan 2013 09:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPGuycQsScVT for ; Tue, 29 Jan 2013 09:18:40 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C3BF221F8688 for ; Tue, 29 Jan 2013 09:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=142953; q=dns/txt; s=iport; t=1359479918; x=1360689518; h=from:to:subject:date:message-id:mime-version; bh=TcoF6AyMK4t0EKaoefh/K8RRANblwyUO8amNhMpNtmQ=; b=IsrqrXdixFwo+84ygbGyICdeBRrKs1Sms4mf3Ac6qV21uyHdzQghiVak vd5zpaQlSa3bDcdxdjggctjrSFyevp6pJd/UJmCpBSdn5l9aiMo8+32S7 yKNsmP4aJzZDAFjTTCZP17KFgdQGt6k76XYzRHvdtHLVMKM6tTNEuCfmb A=; X-Files: Screen Shot 2013-01-29 at 11.38.35 AM.png, Screen Shot 2013-01-29 at 11.40.04 AM.png : 51533, 51262 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFALQCCFGtJXG8/2dsb2JhbABEhX+4XxZzgiABBAVEHiQBJQEBAyYVGycEGwaIA6AHkRSQKpAoYQOPCYEjliyCd4Ik X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="png'150?scan'150,208,150";a="169976702" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jan 2013 17:18:25 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0THIPC0007465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jan 2013 17:18:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 11:18:25 -0600 From: "Rajiv Asati (rajiva)" To: "v6ops@ietf.org" Thread-Topic: OSX 10.8 poor performance for IPv6-only! Thread-Index: AQHN/kSlHZLWiwT60EaYA9l3n7/StA== Date: Tue, 29 Jan 2013 17:18:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.249.228] Content-Type: multipart/mixed; boundary="_003_B14A62A57AB87D45BB6DD7D9D2B78F0B114E66F5xmbrcdx06ciscoc_" MIME-Version: 1.0 Subject: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:18:41 -0000 --_003_B14A62A57AB87D45BB6DD7D9D2B78F0B114E66F5xmbrcdx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 GUA, but no IPv4 public/private address) is intermittently causing very poor browser internet experience on the MacBook. MBP nicely issues both DNS A and AAAA queries over IPv6 transport for a given website (say, www.cnn.com) almost at the same time (e.g. opens 2 UDP sockets), and receives both A and AAAA responses from the DNS server. However, it may close both UDP sockets upon receiving the first DNS response (whether A or AAAA), thereby ignoring the 2nd DNS response (whether A or AAAA). Suffice to say that MBP issues an ICMPv6 Destination/port unreachable for the 2nd DNS response (see the attached 2 screen wireshark screenshots). This is quite bad, since if an AAAA record was carried in the ignored DNS message, then no TCP connection would follow =3D> forget happy eyeballs and recall poor internet experience. :( Has anybody else run into this or noticed it? Cheers, Rajiv --_003_B14A62A57AB87D45BB6DD7D9D2B78F0B114E66F5xmbrcdx06ciscoc_ Content-Type: image/png; name="Screen Shot 2013-01-29 at 11.38.35 AM.png" Content-Description: Screen Shot 2013-01-29 at 11.38.35 AM.png Content-Disposition: attachment; filename="Screen Shot 2013-01-29 at 11.38.35 AM.png"; size=51533; creation-date="Tue, 29 Jan 2013 17:18:24 GMT"; modification-date="Tue, 29 Jan 2013 17:18:24 GMT" Content-ID: <602C9D8767CEB94FA26217EEFEA63C2F@cisco.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABpAAAACPCAIAAAByEQ/iAAAYIWlDQ1BJQ0MgUHJvZmlsZQAAWAmt WXk8Vd3X3+eOpmu65nkek3nOPA+Zh0i4rukaLq55LlMZUiSEKCSSKJUhJDQhGUKjDCmiogkR79FT z/P8Pr/3/e89n88993vX/u61115rn7XPXhcAruuE0NAgBCMAweQIip2JvsABF1cB7CsAAQTAAlUg QSCGh+rZ2FiC//P6PgGz4WtMZlfX/0n73xuYvH3CiQBANnCzl3c4MRjG1wFAthJDKREAoHf1iURH hO7ikzBmocAGwrh6F/v9hVt3sddfePAXx8HOAOZMA0BFRyBQ/ADALcNygSiiH6yHng4ADDPZm0SG uwnAWJvoT/AGgMsT5uwJDg7ZxTkwlvD6lx6/f2ECwetvnQSC39/4r7nAPeGBDUnhoUGE2F8//j9v wUGRsL9+XXzwnS480N4C/maD/RZDJBjZw5gDxrn+PmaWv+U1oRH6dr/lHaQIMwcYs8CcJ/6Rpo6/ 8UJkoKMejHlg+VZgiMUuH/YTgoPsZWUNY2YYixDDDWDf746FUInzd3D+zbH09jE0gjG8ihAHKCF2 f/j+4VH2f+Rxcf4GVn/4AQTz3XjTw/wsAgVGv+xBFPsEmeyOKwTLL4dG2OzauTvWEDnI6vdcEG98 Kca7nF35D5/wX/Pdtc0/wt/BFJbDNiMZIygOuxx4jkgeX5KxGYxh25By/hTTP3Ld0KBfaxrui3Sg RNrt+kEExr4+ZMddH+7Ks7wJhru+hX2CLAPGgAAowAd4ATJYBALAEhgAw993AVhOhmVEEAKC4A9F gOFPC/otegQ9ix5HT6Of/ZHBPX/zAAl4w/gvXf/qD8vtQRz4AGv1AeF/RkNxobRRmihL+K4LfxRQ aij1P21Dyy3Lf/BvW/3gvjK/dev/tj4K1vjzD8+DlEL5g3/38fq7x3/bZAzewB7w+8OQq5dblNv6 0/+fGWOMMIYYU4wxRhJ5DNmMvI+8g3yI7EC2AAHkbWQrchDZuYt/2/VnFAIs2fXKrofDgQXsRR8Q +esX+c94/+GlyL8ZvzXQS9ErAzu4FxkEwm2kv0dw+mU16b+0RMIML3jEAJhr8Xc8ftuFEoO9q4zS R2nBfoZ9jGJDcQEZlBLscT2UDhwDZVj6TxT/czYywPeXt6N+zSUQvIXnERzhExMBryVgEBIaSyH5 +UcI6MHZ0mePgBmZuHePgIKcvCLYzb27HAC+2P3KqRDb439kwY0AqJHg59P9H5kXnBPbZeAcVv+P TKwQzncBAAyIECMpUX/pQ+1+oQENYICfCk7AB4SBBOwRBaACNIEuMALmwBo4ABfgDq9hfxAMWxwN EsARkAGywUlwGpSAClAFakEDuAZaQAe4A+6BATAMxsELMA3mwRJYAd/BJgRBWAgH4SFOiB8ShaQh BUgN0oaMIEvIDnKBPCE/iAxFQglQKpQN5UMl0HmoDroKtUF3oIfQCPQMmoEWoc/QDwQSQYdgQfAi xBCyCDWEHsIC4YA4hPBDhCHiEGmIXEQxohJxGXETcQcxgBhHTCOWEN+QAEmLZEMKImWQakgDpDXS FemLpCCTkFnIQmQl8gqyHV6LY8hp5DJyA4VB4VECKBk4kqYoRxQRFYZKQuWgSlC1qJuoPtQYaga1 gtpG49A8aGm0BtoMfQDth45GZ6AL0TXoG+i78PM8j/6OwWDYMOIYVXi1u2ACMPGYHMxZTCOmGzOC mcN8w2KxnFhprBbWGkvARmAzsGewl7G3saPYeew6FS0VP5UClTGVKxWZKoWqkOoSVRfVKNU7qk1q RmpRag1qa2pv6ljqE9TV1O3Uj6nnqTdpmGjEabRoHGgCaI7QFNNcoblL85LmCy0trRCtOq0tLYn2 MG0xbRPtA9oZ2g06ZjopOgM6N7pIuly6i3TddM/ovuBwODGcLs4VF4HLxdXhenFTuHV6PP1eejN6 b/pk+lL6m/Sj9B8ZqBlEGfQY3BniGAoZmhkeMywzUjOKMRowEhiTGEsZ2xgnGb8x4ZnkmayZgply mC4xPWRaYMYyizEbMXszpzFXMfcyz+GReGG8AZ6IT8VX4+/i51kwLOIsZiwBLNksDSxDLCuszKxK rE6sMaylrJ2s02xINjE2M7YgthNs19gm2H6w87LrsfuwZ7JfYR9lX+Pg5tDl8OHI4mjkGOf4wSnA acQZyJnH2cL5igvFJcVlyxXNVc51l2uZm4Vbk5vIncV9jfs5D4JHiseOJ56nimeQ5xsvH68Jbyjv Gd5e3mU+Nj5dvgC+Ar4uvkV+PL82P4m/gP82/3sBVgE9gSCBYoE+gRVBHkFTwUjB84JDgptC4kKO QilCjUKvhGmE1YR9hQuEe4RXRPhF9oskiNSLPBelFlUT9RctEr0vuiYmLuYsdlSsRWxBnEPcTDxO vF78pQROQkciTKJS4okkRlJNMlDyrOSwFEJKWcpfqlTqsTRCWkWaJH1WemQPeo/6HvKeyj2TMnQy ejJRMvUyM3vZ9lruTdnbsvejrIisq2ye7H3ZbTlluSC5arkX8szy5vIp8u3ynxWkFIgKpQpPFHGK xorJiq2Kq0rSSj5K5UpPlfHK+5WPKvco/1RRVaGoXFFZVBVR9VQtU51UY1GzUctRe6COVtdXT1bv UN/QUNGI0Lim8UlTRjNQ85Lmwj7xfT77qvfNaQlpEbTOa01rC2h7ap/TntYR1CHoVOrM6grreuvW 6L7Tk9QL0Lus91FfTp+if0N/zUDDINGg2xBpaGKYZThkxGzkaFRiNGUsZOxnXG+8YqJsEm/SbYo2 tTDNM5004zUjmtWZrZirmiea91nQWdhblFjMWkpZUizb9yP2m+8/tf+llagV2arFGlibWZ+yfmUj bhNmc8sWY2tjW2r71k7eLsHuvj3e3sP+kv13B32HEw4vHCUcIx17nBic3JzqnNacDZ3znacPyB5I PDDgwuVCcml1xbo6uda4fjtodPD0wXk3ZbcMt4lD4odiDj1053IPcu/0YPAgeDR7oj2dPS95bhGs CZWEb15mXmVeK0QDYhFxyVvXu8B70UfLJ9/nna+Wb77vgp+W3ym/RX8d/0L/ZZIBqYS0GmAaUBGw FmgdeDFwJ8g5qDGYKtgzuI3MTA4k94XwhcSEjIRKh2aETodphJ0OW6FYUGrCofBD4a0RLPBL7mCk RGR65EyUdlRp1Hq0U3RzDFMMOWYwVio2M/ZdnHHchXhUPDG+J0Ew4UjCTKJe4vkkKMkrqSdZODkt ef6wyeHaIzRHAo88SpFLyU/5muqc2p7Gm3Y4bS7dJL0+gz6DkjF5VPNoxTHUMdKxoUzFzDOZ21ne Wf3ZctmF2Vs5xJz+4/LHi4/v5PrmDp1QOVF+EnOSfHIiTyevNp8pPy5/7tT+UzcLBAqyCr6e9jj9 sFCpsKKIpiiyaLrYsrj1jMiZk2e2SvxLxkv1SxvLeMoyy9bOep8dLdctv1LBW5Fd8eMc6dzT8ybn b1aKVRZWYaqiqt5WO1Xfv6B2oa6Gqya75udF8sXpWrvavjrVurpLPJdO1CPqI+sXL7tdHm4wbGi9 InPlfCNbY3YTaIpsen/V8+rENYtrPc1qzVeui14vu4G/kXUTuhl7c6XFv2W61aV1pM28radds/3G rb23LnYIdpR2snae6KLpSuvauR13+1t3aPfyHb87cz0ePS96D/Q+6bPtG7prcffBPeN7vff17t9+ oPWg46HGw7Z+tf6WAZWBm4PKgzceKT+6MaQydPOx6uPWYfXh9pF9I12jOqN3xgzH7j0xezIwbjU+ MuE48XTSbXL6qffThWdBz1afRz3ffHH4Jfpl1ivGV4VTPFOVryVfN06rTHfOGM4MztrPvpgjzi29 CX+zNZ/2Fve28B3/u7oFhYWORePF4fcH388vhS5tLmd8YPpQ9lHi4/VPup8GVw6szK9SVnc+53zh /HLxq9LXnm8236a+B3/fXMta51yv3VDbuP/D+ce7zegt7FbxT8mf7dsW2y93gnd2QgkUwq93ASR8 R/j6AvD5Ivye4AIAfhgAGvq/zka/GPDrLgRzYOwE7YWWEGeR7ihR1Ht0N6YYG0plR21Eo0IrS7cX J02vxmDB6MkUyXwa38Yyw0bHrsdB4WzgWuKR5A3ga+JfFzQUOik8KyovdlT8laSy1EnpZRmjvVWy 2/JuCu1KXMoxKuNqiuq5Gsv7TLTOaf/QtdO7oL9haGFUYrxgqmQWb95lCe3XtYqzbrKZs2Oy13Lw dkx3OufcfOC2S69r98E2t8ZDNe5lHic9UwhhXu5ES29VHyFfnO+a34x/P+laQElgShAp2IasHMIe shY6FlZPSQ63juCP+BTZFZUb7RYjHfMjtj+uJJ6UoJaISRxLqkgOOqx/RCSFJZUhjTGdKYPxKO4Y dSYqcydrI/tzztLx2dznJ0ZPDuT15LedulJQdfpMYW5RanH8mdiSlNLishtnh8tnK5bPrZxfqVyp +lT98cKHmqWLC7Vv6mYuzdWvNjBdMWhMamq5+vra+nXsDfxN/hapVuU2nXazW/YdXp0xXcW373Qv 9KB68X1cdwXuSd1XfaD/UL9fov/TQNYg5+D5RzqPlocaHlOG1UegkUej5WNhT4zGOcc/TvROFj31 f6bybOd594u4l4ovl181TIW/3jeNmR6dKZv1nZOf23xzb77grc87jQXmhfeLXe9zlpyXBZcXP1z9 GPdJf4V2ZXy14XP5l+tf1777rj3f0P1RsDn9U3G7YGfnV/yFoSaEC5IZ+QCVgbbAsGJeYZupcqiD aBxpDekUcZL0ogwSjLJMyszGeCcWMmsaWxV7H8cSFxO3Ng+Jt4RvkH9HUE0oQviKyHsxaXF/iVrJ JWmZPRSZG3s35HTkjyjcV6JVtlTJVR1Rx2vYaObu69fG6OjoRunV6r8wpDXSMPYyyTStNxswX7RE 7Ge3ErdWtNGw1bBTtBdxoHf45vjcqdu5+kCWC9nV/qCqG7fbzqFZ9z6PGs8MgreXLpGHuOY94lPv m+7n7q9KYiQtBNwOLAoiBxuRucgfQm6H5oa5UoQoi+FNEdGRGpE/o7qik2N0Y1GxD+KOx9sk4BPG E4uSDsKZdeVw75GKlNRUcpprukmG0lHBY3TH1jJnswazb+acO34sl3Li0EnLPJ185VN7CyROCxXy FLEXM52hKUGVbJV+LVs6O10+WTFybvj8eOXrqqXq9RrkRfpazjqRS3L1+y4bN1hfcWn0aYq6mnOt trnv+tSN1RaolbFNsF3xlnHHwc7Qrozbpd11dxp6qntP9kXcdbincJ/p/uqDJ3BuqhhIHwx8ZDuk 9lhwmHZ4fWRu9NHYtSdF44kTxEmLp0rPeJ+jny+/ePLy1quqqeOvE6ZDZwJng+ci3iTOZ7zNe1e6 cGGx6X37Uu/yow8vPq6vqK9Wf9H/Rvv96/rCj9Gtym2X3/HngY4jJBADyGAUN2oAnYLRxqxjO6mO UrvQKNLS0y7QPcQ105czHGdMZYpjjsLHssSyJrJlsJ/gOMvZyNXH/ZTnIx+OX0RAX9BTKFW4SuSu 6KI4vYS8pKNUvHTFnj6ZRVkmOVV5V4V4xXKl28pTKttq3OrqGnaapH1JWnnaVTpXdTv07ur3Gwwa DhjdN75t0mxaaZZlTrawsBSw/Lr/nlWRNclG3RZrO2F3wT7cQdeRznHSqdo59ICmC8Zl2LXkoI/b Xrfvh7rcMzysPPGek4QSOE/wE6e9z/l4+vL7vvY75+9J4idNBZwNdAnCBw0FZ5KNQqCQW6ERYeJh TynHwlXD30UURhpGfo46F20VvRlTF+sUh4hrjD+YgE5oSjyYhE5qSnY/zHJ45Ehhik+qWhp92nx6 Z0bB0cBjepnsmR+y7mQX5PgeV82lyZ0+0XoyP4+Sb39KuYCzYPv0m8L+osbiU2eiSlxKNcq44N1y vPxGRem54+czKtOq0quPXjhak34xsTa47sAlo3rNy1oNFlcIjQlNxVevX3vUPH998yZTi1jrvjbb dr9bSR2nOy91ddy+391/52HP3d47fZ13W+813294cPFhRf+ZgfzBnEcZQ6mP04fzRmpHH46tjvNO mE1GPa18NvR846XIK/upE6+nZ0hzHG++vUMvJi33rp5aF9mN/181st09AaMCQA1cy3E6DIAt3FJr C4BoAVxuaQPABgeAgzpABKYDBNMSgMok/t4/IIAC1HDthRM+b8oCLficfRA+myeBfFADboERsAif F7kgJcgaCoSOQhegXmgWgUAII4zgk142ohHxBPEDPs+ZIsOQJcg+5Cd4DZqgIlFVqDE0Eq0En8hK 0EMYJEYdE4qpxcxiebAHsAXYUSomKluqU1Tj1JzUHtQ11B9p1GhSaYZp+WjJtN10LHQBdHdw3Lho 3Di9Cv0Z+h0GP4ZRRj3GZiYpphpmceZGvCZ+kMWD5SvrcTYptgH2UA52jl7OMC4hrgnu4zymvBje e3xZ/LYCPAIfBPuEqoSzReJEg8W8xT0k3CU9pXykg/fEymTuLZdtl5uUf6/wUfGN0hPlXpWbqlfU LqnXaVzSbNrXqtWnPaYzr7uhz2AgaWhs5GecbXLV9IU51kLB0nk/xSrV+oRNuW2L3QsHakdtp2h4 v/vsqnQwxu2OO87DzbOOsEzk9dbxcfYN9jvmf430IVA1KDP4dYhK6Mmwj/D+di2KNToipj+OPd49 oTZxJ9n/8EwKIfV1ukvG+DGXzK3shdzcvLMFXIXmxaElxWWt5UPnZiq/X6C/KFlnUR/T0N7Ed63y hnRLedtOh1vXrTsCvVl3Nx749489UnqcPTL3ZP/E0DPPFxtTRTNqc6/fpi1sLgktb3+sXhFZrfjC +bXyu/bau43iTf2tqW3Kr/wBwTUHWoAHvEASriUbA2e41pIA8sBF0AUmwCeIBq4R6EMeUBJUDnVB 03DsxRDmiFBEIaIL8RbJiNRA+iDz4KrRBxQPaj98Qr+KeoPmRFuh09Gd8OlbDhMEx/0tVhTri63F LlHJUkVSdVJjqG2oz1K/p9GgyaZ5TatEm037hk6H7izdT5wn7i69DH0RA5ohimGJkcg4zeTF9J45 Fs+Av8RiwrLAms0mz/acPYNDieMtZymXAzcj9yhPMa8Xnyw/4B8XaBDMFPITNheRF+UWoxLbFP8q 8VVySxq3R1hGe6+nbKZcm/x7RR4lG+VslUE1JnVnjTOaY1qQtpiOsa6v3jH9BoNxI4Sxgomv6Vmz SQs2S6f9hVZjNvS2JnbJ9u0Oa04qzjEHOl3RB23cKg599jD3rCb8JNrCeeq9n6J/ImkgkDcoLPhe CG9oVNhYuFJEUeRWtEdMVxxHPDnhXpJwctbh9ZSA1FfpNhm9x1QzG7KFckpy2U9U5GnkfyhoLSwq TikJK/MoNz+nVMlfTX9h5+Lnurf1TxseNHZcbWu+c+Nxy6u2pVsbXTTdAj0afQfuxT4o7W8fHB56 Mfx0dPBJx8Tlp2ef5708OpU8HTsb/SbmbfxCzPtDy2wfaj6xr5BWqz6Pf1n7xv5dcc1mPXzjzI9H W9ifttvVv+OPATjADj/98kAfri/5g0RQANeQ7oNZsAPxQvugQ3Dsz0P34LdMZoQGgog4jmhFzCPx SD24clOFnEBRw/W3SNRl1DyaH30QXYyegCsuzpgSzBRWGBuAbcZuU5lTFVMtwBWT49RzcMwLaFZo rWmb6PB0sXSzOCtcJ70c/QUGfoYyRj7Garhu0cfsgUfA8XZmxbLeYotgl2Nf4bjOmchlxs3BvczT x3uOL5mfKGApqC4kJSwowi8qKCYpriJhJukhFStdtKddZlaWWc5cPkOhVwmtbKvSoIZXT9ZY3UfS WtAJ0v2un2HIY9Ru4mFGa95hSbJCW2fbArsQ+1eOVk498J7UelDdrdvdymOGEENk8K7yVfLrJlkE TAYRg1dDjoSxUhoj9keuRJ+JNY+HElqTiMnbR3JTOdIqM2SOdmY6ZK3nXMkln5TKGzsVUPClMLLo 25nokq2yjHKWiprzmpVj1cE1NBdr60wvLV7OuaLU+Obq+eagG4YtQm2o9sWOka7O7oaeyr6SewUP 8vpPDJ4Yyh5OHHV/Ijf+bfLas+AXki/fTl2Y9p2Vmlud73iXvmj4fnX52IfPn8xWclZbPr/6svx1 49vc94dr+ev71t9upG1s/CD/mNs8sHl7i2WLtNX1k+Un6WfXNtW2zXbx9usd8Z2QnZbd+If7Kirs 7h4AotOHy49TOztfxADA5gPwM29nZ7NyZ+dnFXzYeAlAd9Bf/7vskjFwrf4cehc95J07vPv97+t/ AO7o2U2DSwTDAAABnmlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4 PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS4xLjIiPgogICA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgog ICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpleGlm PSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyI+CiAgICAgICAgIDxleGlmOlBpeGVsWERp bWVuc2lvbj4xNjgwPC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZ RGltZW5zaW9uPjE0MzwvZXhpZjpQaXhlbFlEaW1lbnNpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0 aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgrPj3koAABAAElEQVR4AexdBZxVRRdftthg l1i6GwSkRKSRFkEaAQFRCUG6RFBCUgmRkPoQUCQUDLpzaQQJkY4Flm52ge3v/xgcL/feM++93fc2 z/7wee6ZM+ec+U/euROpYmJiQkJCXOLxb926de+++278243HJNpqiqGwFSmWYwQSBwJcZxNHPrAX jIAJAsm+eia/BHKKTMpxgrKSX44kKJxsnBFgBBgBRoARMEFg+/bt1apVw4QYwsLCwp48eRIaGurq 6urh4eHt7e3p6Zk6dWo8RkVFnTpz2t1EAbMYAUaAEWAEGAFGgBFgBBgBRoARYAQYAUaAEWAEGAFG wHEIuLm5YW4uVapUmLPz8vLy9/d/8OAB5uwwVSem7SAAERfXMNh0dZxd1sQIMAKMACPACDACjAAj wAgwAowAI8AIMAKMACPACDACJghgqk7M1uEXM3SYnMOcHSbvQLi7u4OJX3ewU1lW1/EKOxMEmcUI MAKMACPACDACjAAjwAgwAowAI8AIMAKMACPACDgQAUzHQZtl0i5VqujoaLGqTssU6++iXdwgxivs HIg8q2IEGAFGgBFgBBgBRoARYAQYAUaAEWAEGAFGgBFgBKwggDk7IfHnn39i5g6PWGeH0+tkNJ6w k1AwwQgwAowAI8AIMAKMACPACDACjAAjwAgwAowAI8AIOAsBy+K651N14uqJs2fPzpo168yZM7AH PmbupOH/KMlighFgBBgBRoARYAQYAUaAEWAEGAFGgBFgBBgBRoARYAQciwDm6cQfpuewK3bu3LnQ /9NPP0VERICDFXYIFTN65hN22bJl+/HHH3U++fn56TgOfIRy6k9agYCknUrgbt3u3bs70MTgwYNx Wa/tCpFPX3/9dYkSJbJnz96gQYOtW7faHpclGQFGIEEQkC1Y2rRpixQp0rVr13PnzjnDE+e1hM7T 7AwcWCcjYDsCsnrmy5evbdu2mzdvtj1uQkk6pD4mxYSbAq5DIymmS5cE02Q6lRlHB+yKjoHra6+9 li5dOrtiOTX5rJwRYAQYAUaAEUiECGBibtu2bWJt3cWLF3ft2oXZOjFVhyA4bD5hFxISsmjRItws G29Jeqz5g1HN0+N480EYwmRZ48aN8b7tQLt4gX/nnXfCw8Nt1Dl69Gi4gdw6evToBx98MGrUKBsj shgjwAgkIAJouB49enTt2rW1a9eWL1++adOmkydPjos/mFyIS3RFXOdpVhjlIEYgAREQ1fPIkSOY TEevumrVqtg5k+TqTnJNeHJNV+yKpTFWwhbUXr16zZgx4/79+8gmo2/MYQQYAUaAEWAEGAGBwNOn T5csWSJX24HGXJwWHPMJO0hgidm3336rFU1wOn56/WHDhmFRG4YaDkzvp59+Cm0jRoywUefixYv7 9OmDL5OZMmVq2bIl5lxtjMhijAAjkLAI4HuIr69vgQIFPvroI0zbTZkyZcOGDbF26c6dO8a4DmkJ nafZ6DBzGIFEggCqJ76fVa1add68eePHj4+dV6Z1J3aq4i1Wck14ck2XQwpGwhbUy5cvv/HGG8gg h6SFlTACjAAjwAgwAskVgRUrVty9e1f2mJit++WXX8T8nUgyOWHXqFGjQ4cO3bx5k4Jm9erVr7/+ ekBAAH7xXkqJOZCvXVcvaLwJ16hRAxt433//fbHndMeOHTVr1syaNSsm3S5cuCCtI9nFixfPkiUL Pq0/e/ZM8nXE33//jVT36NFD8C9dutSiRQvsS4U5YVHKKxTu2bPnrbfeypw5c+nSpZcvX44oODVw 4MCB06dPP3nypNSgIDw9Pfft20cJKJDXOQkNWg5oDKE6d+6cP39+f39/qd/osAhSpFHGZYIRYAQo BHLlyoWKj6kBKUDVKdOmRlRe/ApCKtE+CvqPP/4oV64c2j2s6bt69aqUBLFp06Y6deqg6cO704ED B0SQiIVfQUh53aPVpkZhV+pkghFIhAhg2CC2HqDMm3aLVOEXdQS/gpBJo+SFANXJqmNJ5VYJ0wbE NJZMOEIV1pE6HSwivZZkx9fhJNhkUKVKFQylKlSo8Ouvv5omRzKTULqkz1qC6hoE2oqWFmPF6tWr S5Rk7ggCv4LQ2kKngHEyEDP2F1oxNS3UUo4hFG8aFtua0qIob2pbHMoIMAKMACPACCRjBNq0afP7 779jJDB//vyFCxdihR2WfYj5O9WWWIHIkCFDxo4da4rOX3/9hVVj33zzTVBQEH7xUnrs2DFTSecx cTLfhAkT8JH8/PnzlStXHjp06Lp168aNG4fT3zBVhwnHTz75RFjHHBz2vyxduvT06dMFCxYcPnw4 5RVerTt06CAnODt16tSsWTMMhbGkRbuqRaEQQZjjA+54GViwYMHPP/8sbFWrVg0X9H7//feUaS0f eLZu3RoJMZ58F0fkAQte7A8ePIiNe8Ii5bAijVpXmWYEGAEFApi7P3z4sBBQ1CnTpka0Oc/bHtWW ot9++2379u04oxSnHtStW7dnz55af2bOnIkt9mgS0bINGDBABNmi2WpTo7ar9YFpRiCxIYD9sFhn J7wydouKwm9adxTyMEF1supYdiFm2oCYapAJt2pdB4tpwk1NOISJcRc+r44ZMwbEd999h8GrWm1S SZdpKhRdA+QVLS0mVXEgY//+/YEShq8Y7kv9VH5BbNq0aRg8Y+Rs7C9kdFsIhWNG61bLmy0WWYYR YAQYAUaAEUgeCERGRiIhmHQS806YmHN3d8fVE/gT101ok5kKwbpdsgjGNzHR3Xbs2BETc+JAN8mE QLt27XAoW6tWrYQuzAji05nxngqtJUljWu3dd981tStktIZkLBBaPuiGDRv+8MMPWIyGIBwPlzt3 7iZNmkydOlVysDJO7AiAt/Xq1Wvfvj0kgcKrr7564sQJrWZJly1bFh9y5cEfOXPmxEAKi1OkgCAU CoEJZsQw46aLgkcsuMOcHRTKIAUUGH1iMx0GYVCFsTgiStMK5LUQCXktBzS+rOJjtXQABOWwIo3a 6EwzAikKAUWd1dY1iQmaJix8u3fvHjiKOkU1NaY6tUzQWMaL9k1YxBR/3rx5b926JR2QBM5HQCN5 +/ZtwdEqkTJaJrxVNzU22pXKmWAEnI2ALdUTY4D169fje+SyZcsKFSqEMm/sFq0WfjFAkslRyys6 WUUVg3JtfRS2qARSDYhWiS7hap9NYTH6IxGINUGlqHfv3riyAJsnpGaddfmY2NJFpUibFzJRgkBe UGNUJFPR0uLwFhy/AKykQgmLqTmE4iM0vhzjrQACpv2Fjf6rHTNaV5c36T8TjAAjwAgwAoxASkAg MDAQq93FAjrM84DAzF1wcLCXlxe2Zvr4+GBGC3zM6x05dpTcEiuQwrI1rM4wooZvZVgyJvn4Uq2d h5J8pxIYc4i5OVgBgSsysNZPy8Flr8IBrHDBdjBBAwLM4uHd1dQ3fK7UTs/huy6G2liah5lOrbxC IbYn4NQ5rbCkcSYd9MtHNYFxPK6x+/L5X61ateQbeByR183WwQfKYUUa1Z5zKCPACEgE0M7KRklR p6imRupREHK2DjJo300bNzBTp06tOA3AqN9qU2OLXaNa5jACCYUAphgKFy6M/nT37t0bN27EbJ3w xNgtWi38uiSo5alOVh1LZ0L9qG5ATBNu1boRFrUPjg0VA1m1zqSYLtMUKboGyCtaWqCEhZCmOikm LoIQs3UQoPoLKq6Or3BMJ4lHq+XNGIU5jAAjwAgwAoxAckVALKN7vsDuv8NexfydWHMnfkXyLR/Z FH9YrIFjmDC6xZ5TrRjOtsPpdZIDWs4oSaazCQw1dCaMHCFw48YNfKrVCmPyUvtI0bgu9s033xw0 aBCmAnERBLbTWlWIraZYUEMptJePzQ74HIqLJnEHBRxAdIcjTzkca9DsTSPLMwLJGAEsks2TJ49I oKJOUU1NHJHBDB1OAMAnByzx07b7tqh1eFNji1GWYQSch4BuWZzCkL2FXy1PdbLqWAr3jEHqBsQ0 4Q60bvQn7hycxYlz2dR6kmK6TFOk6BpM5SUTn+JxFJ18tIXAnUi2iDlcJpGXN4enlxUyAowAI8AI MAIKBDAZJXbFYpIOi8mw4RUrPLy9vfGIhXVYYSbW3IGAEisr7CCBLbGTJk3S2cMyNLHJS/BhRrsw TSec4I8ZMmQ4deoUxnbyj3p3xZYxjCq0DuNGuVmzZmG9G/alSr5CYcaMGXUaZKwHDx5Av3y0kUDO YdfD1q1bhbxdyEdERFi1QjmsSKNVnSzACDACAgFsL8KJ4IJW1ynTpiaOMPbt2xc79HHgPe4eksdW 2qjTrqbGRp0sxggkCQTsLfxqeaqTVceyFyh7GxDHWrfXW6vyGKFi24RVMaNAIk+X0WFw1F2DaRTB xL4N0yXViigJFZQU8yWhsGK7jAAjwAgwAskeAYxzMFGDOTtcCIFbAffv34/NHzixF+fD4uURy9Jx qhJAEGvurE/YYUCAm1h1V3ThrDcsxZdQ4m7WMmXKyMfERuCFec2aNbZ4hfV0eLk1Svbr1097watC oREroQ1nhSA/oN+o3CoHc6MYzwkxNfKY3ZP3VCCD5RnzChOUw4o0KrRxECPACEgEsPxh9uzZH3/8 seDYUqd0TQ32scblfQwtfvPmzXPkyCG35Yp2H/5Y1axuamQamWAEkh8C6sJvrDtqeaqTVceKHaq6 BkShJBbWjQlX6I9jENzTHrRi+x6ORJ4uU1hs6RpMIxYvXhzbaWUQvp1rv0bHZ35JHygiFvlCqWI+ I8AIMAKMACOQ1BHAllh02f/88w8OTsFUD97UsLEAu7KwbxVBuM11w4YNwcFXRDKtT9hBDi+cuN5B iwsGhSNGjMBWWXwCxWzdyJEjcU2VFMDBIviTjwlOYE8rFgni/iyssDt+/DguYKVcwh26uDpDvtMK MUx/4r7XKlWqyFgKhViQOH36dNzI+/DhQ+SBuOkCEXfu3An0cYmHVKIgsAEZ54xgihDv6vgF/gBc yKuRx6EzyCnEQjYjmeXLl1dYEUGUw4o0WtXJAoxASkYANf369euLFi2qX78+zgDFoeACDat1ytjU FC1aFB9bcKp67PDE9nzcEotJfDQjqOnYDIXbq4Uqq5rVTU3s/OFYjECSQEBd+I11Ry1PdbLqWLEA ytiAKJTEwrox4Qr9cQzCAcrjxo3D3gg0XytWrGjRooWNChN5ukxTYbVrMI0FZo8ePb744ovTp08D JXyWBkoeHh5SOD7zSxqliFjkC6WK+YwAI8AIMAKMQFJHALN1+OR27tw5HOmG0y1wVyom7HCHGP6w 0gI3oGIJHtbZ4VMcUmrThB3m/Dp06KDFBevpMJbq2bMn9nhiGdfEiRNxBapWIFHROGcaL8+YR8uf P3/37t11adG6WqJECXwGhKRgiplHAIdJSclEkEIhzrnD3XOY4MOB1p988gkOoYM83rcBEYZWxYoV 05qjaEwv7t279+2338b9vDi9DleAyQ25auSnTZuGNTVI5uDBgxFRWKesCL6pwwhSpFGtkEMZgRSL gGgxsB4W9/5gjh5zbbgRW6KhqFNUU4NmdsKECdjsJpXYRcyZMwfNET7XoPHBJdpo/eR7r1XN6qbG LjdYmBFIWgioC7+x7qjlqU5WHcsuxKgGRKEkFtaNCVfoj2NQxYoV8dkS125hzApCOwBTa07k6RI5 pf1FchRdgzqxuEEFn4FxgiGG4hg3Ypyp7SziM7/UfiI0FvliVScLMAKMACPACDACSRQBzMdh9wBm 69KnT483RxBpnv/5+/tnypQJ50hgCs/HN+2Fi0FIYCqsJsMpd/GZVMwo4SU2/u3amEZ8o8aJdQ0a NMB0pI1RrIp99dVXmzZtQsLlxjQRJZFDYTVdLMAIpDQEuM6mtBzn9CYhBJJ99Ux+CeQUObB+nT9/ Ht9mAGlcdCa/HIkLGhyXEWAEGAFGgBFwBgLYqIo9kbh6AudX4EwzXOCOaSL8ihsnsNgLc2VREdEP Htxz9/K0aYWdM7xMtDqxoeCPP/7ARgwHeojtsatWrdLN1jlQP6tiBBgBRoARYAQYAUaAEUhRCLRs 2RJbQHA6DbbV4JYhW/ZVpCh8OLGMACPACDACjEAiRAAHKInZOjFJh2kizEHhD/N34GMKDwcZ+aRJ nTFLejjvnggTkOAuAabvvvvOgW5gY4IDtbEqRoARYAQYAUaAEWAEGIEUjgDOeMExdjilFNtncN5x u3btUjggnHxGgBFgBBgBRiDxI4CJOWzrxHo6MU+HaTtB4Be0uEIqKgq054OHoTxhl/gzlD1kBBgB RoARYAQYAUaAEWAEXkKg4fO/l1j8wAgwAowAI8AIMAKJHgFMzOEkO7EHFr94xJ+YsAMfc3aRkZFi 5o4n7BJ9ZrKDjAAjwAgwAowAI8AIMAKMACPACDACjAAjwAgwAkkcARxRh0V22AkrfgUhFtxhtg6h kZHhYWFhkZHRSChP2CXx3Gb3GQFGgBFgBBgBRoARYAQYAUaAEWAEGAFGgBFgBBI9AmI9nTi6Dqex YWEdZu7AFAvusLAuKsodG2LDnz5DUiwTdnG8UirWgCSU3Vg77LyIDIXzsGXNjIAzEOA66wxUWScj 4BAEkn31TH4J5BQ5pOQ7UEnyyxEHgsOqGAFGgBFgBBiBWCBQv359EQtr6EBgYk78YapOEGLCDrfE uru6hWF1nXsUxF6caRcLe3GMAp/iqCHZRGcokk1WckJSCAJcZ1NIRnMykyICyb56Jr8EcooSW0VL fjmS2BBmfxgBRoARYARSIAKPHz8WqUY/i62v+BOn1wlarLCDAAhcI+vq5gK+5fGfG5bpPfFXLKvJ JBoE2jWuOmnW0izZcgixO7duNKlZatffN/+NF9f/U3bjqjcJxj98YHe7RlW0jv+0clfZ8pUB0bo9 Z/LkL4SgoAtnu7R5a8P+86ApvtBQNq/P3tP3cDuwVNiwarHFq3f7p7XcEGzLH5U1dcvn/+Z/v5Qo Vc4WJVIG2rTlDXxKv4xiJK5cOt+/a5v0GTJ+Nf1H/AqBWOgxamYOIxALBHSl+vGjh2+WznHoQghU 6YKE8trl8n7/yyZRly+dP9O5db1NBy8iqF6Fgl16Da7boLlf2nSPHt6vUCSDqCz13igwZ8l6Kf92 5SKCT9VBSo9MWlRk5PpVy8Z+3mv3P7cls3g217+vRfFLmgSECUZAIKDolLXd2YE920cM/Hh14MkS 2d20fIaREYgjAorhjelwKI7mjNFfL+hftHjpVh26usTELPvpf/8cP3zw3COI6To4+Uj1cUbNgiMj 6h5j15dRVsDXGRKSY4b0xEHfn42cTEV8+OBejdI5D196Qgno+FI+1q9ORj9jkdGm6YqFHl3qrD4a nVe/dxjfU4QJiq9wQGfaRvznzZhw6u8j42csUmi2BbfrwZeb1iy97/Q9uGFUpegUFPK22NXZMua7 Qr8uLj8yAoxAvCBgeUPEH965sMhOvnndv38fl8beunXLz88vffr0uXLlssjEYImdZcLO8p/8Q4Oi /Qe+aGJatO00pPcH506fCA8Pu3zx3JeDutVp0EzGijuhNSosit+4a05yGrauX/FJ/2ESENDbNqwU qZg46lNMld69fRPE203byKRRfAgUKV7qj6ULMEErhd9t3+WLvh3RByArj/y5t/v7jWSQKSE9EQRk RNa836XP0L4doeHZ0yeYdECR0EZH92DaQ2hlBE3pF6FGPauW/9SiXrk36zSctWiNnK2DsFqP0S5z GAGHI4CKdvvm9fkzJxYpVlKhvG7D5qLOojpPGDkQj0IYVSlDxsxePj7BVy6N+qy71IDKDnlUfCiH vORTdZDS06lV3cCt656EhqDuP30SmjZ9BqkKROasOXZsXqNtK7ShTDMCKRYBRaesxaR8pTfRJW1Z 94eWyTQjEHcEqOENNRyKu0WdhnwFix4+sKti1VoVq9X+c9/O/IVe0QnoHqk+Tidm9TF2fZlVtVqB C2dPbli9vHv/4VrmRy1ro9bjs1lERDjGtxNHfvpqmfJSwDgupeTVr05GPdKEjlBntKke03RZ1aOz 66hH9XuH8T1F2KX4tntF4d/zw6biffZK0IU5U8b+MHty9wEjpFojnhRuXd6rv2vbhpDHj1BQj/91 YOAnbWEReqgKK0wY9VPylF1KD/im+U7pF3r4lxFgBBIcgejomAGjVjb7dF+FTy82nBr67qQTbYcu HjZ6UmjoE9wS6+L6fOcsajLlKJoVGbrwf1MWzZt+7WpQxkxZ673TotegUd4+vlTEOPK1duOoKslF x/KZCTMXFy/5mvD8xLFDn3Zru2b3KWAyYNj4/039Cssm32r07sARE8W6OYovov999M/Perx/8dwp zOCKrMSO6J/mTv3lx9mYFChQuNjHfT63a+5VmzWrf1v8w6xvLp4/jfV63QcMb/5eR4k2xEDLwqPl G5kyFIRWv3jErzaK0KyNAnr/6ftYlKRl6vRog5hmBByLgCyTuIg7Q0Cm8pVr9B0yNluO3LBiWg4x ZfbVsL54H4BAzbca48O+j28a0Lu3b/x6eD+sn82aPWefIWP7f9xalPywsGcTvxy4buUv0VFRXXoP GT+iv6wRpnWQ0oPZurnTvj56aB+a7lKvVeg/9OtCRUtIKNb8vmTSqEG3bgSjiZD6ZSgTjECKRUDR KetqyqY1v2G+Ht+xdPwUCx0n3BkIyG5Fdj1aK8bhkDY0dvTgXh1OHv/rj23HEL1JjZLFXi07duoC 0NIToVY+Un2cEDP+yog6PbHry4z6wdFhJWso5lxq1m3U+oOXPjkf2h8477sJmJqMCA/Pkj0numks fk+b7sUnLqFKaoByhbzi1cmoh/JT57xIoMxoUz2m6bKqR5soYSUWv7Ci06N+7zC+pwijFN/UJV3S pAOm+G9c/euUcZ9fDjofkDFzhaq1MF2bK28BqdaIp065kAT+ewM3z5856fSJox6enrnzFmzZvgsm 7MTmNakNhA4Qo36tsFaesived0z1mOY7pV/H50dGgBGIHwRy+b5YYXfo0CHcMpEqlUfvMceO3MwY 7ufp4ueVxt/d18fdJ7VrloizNXI9/KB57bTp0128eFHfsMaPr2zFXgR0Lb6MTvGlABOMACPACDAC jAAjwAgwAowAI8AIMAKMACPACDACCYWAbsJu0OiTgWf9YgK8XdJ5eaVL7Z/G088vta+XW2p3F+/7 x0p6/NO/V+ebt26+tCU2oVxnu4wAI8AIMAKMACPACDACjAAjwAgwAowAI8AIMAKMQPJG4MSp+3vP +Lqk9XJN5506nVfatD4Z0qfJmCFNxoD0mTIF+BeucuaRz8IffwQI7skbCE6dLQiYrruWS8pt0cAy jAAjwAgwAowAI8AIMAKMACPACDACjAAjwAgwAmoEJs6+5uqfqUbtHB7pPO88inn0zCWDv7c//vni +CJfN9fouznLPHiwGUp4wk6NZGIJpabPKL5dfjtEiV0WWZgRYAQYAUaAEWAEGAFGgBFgBBgBRoAR YAQYgZSGwJUHXhXqZav+WkCUq9v9pzF7zj7zSeOV1t8vXVpfHG/u7uHiGVU+bNcawOL+SpaUBg6n lxFgBBgBRoARYAQYAUaAEWAEGAFGgBFgBBgBRoARiA8EQl7cOeGCG0FDoz1fKejv7e0eGePiH5PK O7V7Gq/nl054u/j5unh6uKTLF3BhSxjccu8bFB/OsQ1GgBFgBBgBRoARYAQYAUaAEWAEGAFGgBFg BBgBRiClITAqQJNiT3e/NJ6pPVxTRbp4ebp6eUZ7e7r7uHt4u7v4Ys7Oz8U12uVUeDgi8KUTGtSY ZAQYAUaAEWAEGAFGgBFgBBgBRoARYAQYAUaAEWAEnIQAjqZzd0mVyvLPJTrSwzXK3S0GR9el9nTx xC2xXi5uri7R0dEwzhN2TsqBJKk2aOeGOa9l+TYvSg3/2YQAY2UTTCzkNAS4zgpoHY4DV22nlVlW zAjYgYCTaqKT1NqRMBYlEHBU1jhKD+FmYmE7vO9LLAljPxgBRoARSPYIeHq4e7pGRMVExcRExGA5 Xaqo6JjIGNeoaJeISBf8Rka+gIAn7JJ9WbAjgXsmDa0/dXGfSzF2xGFRRoARSDgEuM4K7BmHhCuD bJkRSHoI8Dgn6eUZe2yGAPd9ZqgwjxFgBBiBpICAm4s7puViXNzdXN1dU8XEpIpywXI7zN+5REa7 PA5zefDsRSrMb4l9FBy0tFH5J3dviTGN8TtV6rTpux295ygknK3fUX7Gg57LuzYfWTA1+EBgVES4 f448Rd5p/VqXAe7ePjD9MOj8vqkjr+ze8uTOrXT5ClUeOKZA3SbgH188+9CciY+uBvnnzFOu66AS rTuBGTtI7587lb18VW0yKT1GvigqT+/d3jPxi4vb1j69e9s7IFO+Gm9XGjDaO0MmrU4trUivaboU +k3ltbZ0tCme1w7uOrpwxuVdmyKfPfUD/g1ble3c38PHVxfX6iPlJ4UbxbdqSCdg1COqqpEvX1dk kOTodGofI0JDMDo8t/63J7dv+OXMU+bD3qXe7y4E7MVfq9Z2Wtc0KfLLrnTZ7oBRUlGGTcsYNJhi JR2WJmxpZlNUnZUQGcuqEQcJIxOMQFwQEKXO3cs7TbacuSvVKtdtkH/OvFAIfok2nWuPmyOVg4OS GRn27K953576Y9Gjq5dcXd1yVKhe5oNeuSrXkmIOJ6h2xrS+SKZ0Q7QzVJ8FMRnFWO+kEiach4Ci 242frFEXafjABcNRuW86NlArt6vvo9oKtQm7Qk/8/P2mQZ3qfD23eKuOdkVkYUaAEWAEUhQCqSz7 YF2iIqNdny+fw+7XVC7Rbi4xqWJSgXZ3dXGLcfH4d2WdyYRddGTkuh6ty33y2c5R/QRwus749/ff wkSMAzF1tn4HuupsVXsnD8eMW42R030zZwu5Ebx/6qi1PVs3mrvywaVzy1pVL92hR4Vew/DacP/C acyLYcLu7NrlB6aNqfftwswlyt46fmh93/Ze6QMK1msaO0jDQx+7eXhq06jQowsSsdb2bJOh4Cut ftvjkzHLkzs3/5w1HpzmizZrdWppKr1Uuij9lLzWlpam8Nw1fnDJtl2rDpngkzFzyM1rhyz+t278 /SptXFtoyk/ENcVNwbfFnJTRKddWVV2QLooc90u+KbFjVF/M4yND02TP9fDSOTx6pvF/pVl7e/E3 VW6VaWyaFPkl0mtjuqyaVghQZZgqYxRWugzS5p3CesqpswBBkadGHBSgcRAjYBcCKHhR4WGPr125 sHnlspbVmi3alD5/EWgI2r7++uG92cpW1Grb0Le9h7dvgxnL0ubOHxHyOPjPXQdnfuW8CTuqnYFL pvWFames9lnx0JZqYWRaIkB1u1QWy4iOIuK5SDvK7SSnhxobqBNie9+naCvUJuwKPb9pBd4Qz29e yRN2duHGwowAI5DSEMAtsUhylIurq6tlJ6wl+W5uqSz/UuEB/9w9XKIsF05Y/v6duBNPz393Txji lSFj2Y59Nbz/yItb1zy+drlk+0/+YzmUcrZ+hzrreGWtft1dvOWHftlzu7p74DN+9WGTsX4HZvZ+ M6xsp36vfzI4bZ4Cbp6pMxYtiVk88I8tnFFlyPicb1T39PXLWeHNKoO+OvrDdJ1bRkgx8tYNviVH EjoleDTqMcrc+GsfltT5ZcuFiT/8Vuo/6saR/VLMqJxKL5UuSj8lL0wb7VJ4vrsssGiTtmmy5rDg nyMP0nLlOf6UHvCPL54zu2ym2WUzbxvWAx+ihSTlpwi199foPzScWf3zksblZxT3n1c574lf5hl1 2pJfxlhajtHu+Y0rao2djQWe7qm9AoqUqDtxwfEllgUmCvwVfhr1Q9WpFYsX1Cg8rbDXr21qYomK 1h9j06TOL21c59FUGabKmAIr6aQx74xYSY4kZHRJGPXIIEmoy6pROZVeKl2UfkpeOGa0Kx3WEVJS EloBUyYEjHxU3m3De+IQT1Tnw3O/0SphmhFAt5sub0H0wm/0Hrb3m+ECEHTQW4Z0xYcELT6odOBn KFAUnSC+nxWo07jZT5u0Ao6lqXbGFiva9oGqp7bocawMVRMjnoQCbdRQ/Nv6ebfIp0+EXdTltT1a zSyVYd+3I/CdY2bJ9McWzRJBpr2JqPv41bkNzrl1v/5Qo8j0It6L3yl3+58jOoGEeqS63XjzhyrS Akm4YYSUQt4UYSrHodlUj7CInSXfV8w9/RVf2Vwr9JhipZHPjFWxskhIQsSSjzFRUQemj5lXNT/K 2Ib+HbDyUaqFjNGfxQ1fCwrcKGRga1aZjPjeKaMYCapPXN+nHUq+kN8y5GN8mBc0jArfJCH4lJ+K tkIxTjP6qeCgVl7dtwNrDq7u3S5rqKk8hnlYeaANwiOY9vK1Goy0aboAl2k5pPhGtZJjqj8WLZVU yAQjwAikOASwBRazc5b/XN0wZecS4+oS4+7m4unh4pbK8k/86SfsLu1Yf2bl0noTF5jihYFp4JgB 1YZ+4+pusjTPNIpdTGfrt8uZxCB8YctqTMPBkyt7tmJj5sK6JTCRgeHC7vFDsGcT/Fsn/sJsnXQ1 V8UaulGmjZDiq7v48C4JqVMQRj3/K599akHPuRVyYoh8YZNl9hB/Beo13Td5eMj1q9GREfjFALrg W81EkC2/Mr1Uuij9lDxllMJTyiO9Dy9fCPxqUK5KNSXTlLi4bU279cfabTj2+PqVA9NGCxnKT4Sa 4qbgmxo9smDa/mmjqw+d3Png9SY/rr92aI9OzMb80sWy+ojlu2IFr5S8e+o4aAp/q35KPZLAftvG 81Zjx33uqnXkIBWhVpsmG/NLGnISIcswVcYorKQ/xryTQVpCVlVJaENBG/WYlj1FWdUpNH2U6aXS Remn5E2tKJgy+ZJQCCuCDkwdhW9Rbdcfbbfu6JW92xSSHJSSEchf+52r+7YLBArWb+6XPRde9bWA 5ChfbePAj67u3yH6aG2QM2iqnbFqS9c+UPXUqh6HC1A1EUOL0NvXUUPbrjuC3nbflC+l6Vff+7jx 3JX7vv0SR4g0WbD2z5lfiyDT3kTRUJxetbTpTxs//utOgdqNtg59cdqDtJJQBNXtxps/VJGWSAoC v9IlU+QRaoowleOQp/Qg6HLgpuaLt3TcfQljA2FXoUcI6H4xYHvR5q8/enn3Fl2o8fHwvG/RNbRY svWjwAuubu44HkQrY/QHW+b/XvI/IXNxy+pspd/wCcisjaKjqT6x5mjLOS3nNvwONPAJH48iog5/ qY3yk2orYjFOk7Z0RNCuTVlKve6fK1+WkuVA60K1j/lrNgzev1PLwUwfmPbytRp0tCJdpuUQ0Sm+ TrN4pPTHoqUy1c9MRoARSN4IiBV2MZbFdTi9zgX/i4qKxol20alc8SHYcukEOJYbYi1/L827hd68 tmnAh29/9zM+C4tg3e/RH7/DLo+81d/S8R316Gz9jvIzfvScXbNs58i+LZcHwtzT+3fQ3789bWna vAUxERY4diD+4StWeMgjkVlY3oVHLI0Me/xQ654ppNpxlVZYQev0SA3PHty7cfTArnGD7pz5u3z3 IfDht3Z1/pqXS6hCz63dDytjmRrSppdKF6WfkheGjHYpPIW8+GgJGqskWi6z4C/+jHrArzZkIvYv C+L3Dm9hUR5oyk+pQYcbxafs4hURhQHwQgBO4rgQISl/bcwvKW9KSK9kKF5Q8RpT9bOvsS8b2yt2 jfs04mkoQin81X4a9UNVw5nLhbnSH/TCpKSg1U0TlV8ibnz+asswVcYorKSfurwTfFOsZBRTQqdH atCVPaqs2mJXm14qXZR+St4Wu6bpNWXKVOtCjfxTK5c0+3GDb6askKz2+US0t7oo/MgIAAGvdAHP HtyVUKB4L238RuF3WmFFuWA2mPELlvzsGNH73vlTWBFvOYi2c39xEK2M5UCCamesmtC1D1Q9tarH 4QJUTTy77tdmCze+qKFfTPq9Q/0qn72YmMternKq52fA5ChfFQSOExFemfYmCofxDQxdGwQw8Xdw 1gvlCvn4CaK63fixDiuxKNIU8qYIUzkO05QeBNUaOwsTQyBQKvCLP4UeIaD7Pb1ySdMf1tve5mP2 rcn8NeIIy8qDxi1553WspZU6jf5guwY+rmNVHebpcKhl0abtpLApQfWJOHjkrSmLVnVqjFiNvl+J /TSm0SWT8pNqK9TjNKnWFuLCxhVYUwxJ/OJDvqBNI+ar1fDEsvmY01zbozWWgLz17U/BB3YWf/cj CNvLN9UPpiJdpuUQUSi+qQlKfyxaKlP9zGQEGIHkjYCYsHPBnRPRMRERLtHRURGR0eERUZHhkVEx 7pizi4xwCQt/gcFLK+zW9W5bsl03fEwzBQiveQe/G4vldaahcWc6W3/cPYw3DViehpWMO0f3bzx/ Tfp8hWHX0ycNtiJiEyK2ImJjTs0xM3HahYWfxh+4gcBoG7/P7t1J7ZcWhPhzFKQKPV7pMmAC953Z v4ldCRv7dcha+o2Oe4J6ng3Db9aSr2/o+/6/7pD/N0kvkS5KvxoHo2EKTyGJl/le58I/2HYma5kK 2IBgjK7l+OXILR5BhN66LmjKTxlRh5tVvhQQBD4LBxQurmPKR9vzS0axkcBERro8BX5tV2dGibTY hZS3ZgO8viIuhb/aT6PRW38fxoQvNjdhDu67Ymnklgp102RXfhmNOoRjUoa5zj5vi6i6QJUZh2RH LJQ8uXVdU5fzxEIDR0kJCGC2zittBplSvL1jn+z2YT0lBwW7Qp8RWAXW42Qobl1/EHQOO9pkqMMJ dV9GmTP2EVQ9pTQ4j0/VRHSv2hoKMekDNizjFAs8CgKtMWiqN5GxjISYrQMfE6yy9zGKxTOH6nbj zQ17i7QCeVOEqRxX6EHaxcSZFgRKj1ZGS+NDoLZEaYNMaYxn5lcviMEJ/mFfdsiNq1oxoz+YWcMW k5PLfwh7eD/4YKBi9kroUfSJ2cpUwGoJfADAAFtr1JSm/KTaCnvHaaZGwYyJjsbu6fx1GoHGLz56 gUMJY279zslj2L2LdX9YNgjJO6eOgWkvn9IPviJdpuUQUSi+qRVKv70tlalyZjICjECyRwBn14k0 hkVaTrMLj4zBFbHRLm4RMa7hUZYVduHRlkV24u+lCTts9MAB6qI3wi8kxK8QRVCRxu+Js5ZfxHbo /5yt36HOOlEZbnH6uXnlu2f/eW/NYawqF5YCir6qN/n8qMJMxUoH798hg67s2w6OfHQUpFb1uHp4 iI4Za+Bxbh3O4LOcYZc9d6WBYy7v3iz9MSVM00uli9JPyZtaBJPCU8pj9I+T2qp9MenS9nWSaUo8 Dr4s+CBw+J2gKT91GiRuNvKlWJpsuVBC5KOOsD2/dBGtPuI1BosasB+k55ln7Tf+HfkkNPfz2w8p /NV+Gs2t6f4uFqRAP+bgtPdQq5sm6LE9v4xG484xLcNUGaOwEm5YzTsbvbWqR5Y9G8uq1q5peql0 Ufopea2h+KR9s2T/ry5fe1Gp49MBtpUkELiweVXOijW0rpbt3O/B5fPga5mgcXJwpldKvTl8ijiI VhfqqEeqnVHrN7YPVD1V63FGKFUTsRJKW0N9ni+GVThA9SaKKIkziOp2499b8yKNe+6eD0elP/Yi T+W4FT3P79eTRkFQerQyWtonczZtiZJBuBJaTtdi87XkY0oOwxIMTsS/3heiZJCFMPgD3qvvdfl7 6dwza5blq9nA6jJbRZ+IBXq4XAJL8HCo30tGzR4oP6m2wt5xmplNCw838GA5IU5VxpvjvCr5QIND CWPMlr5AkTNrfslUrBTWIoBIX6AomPbyKf3gOypdlAlKv70tFaWf+YwAI5ASELAcXodTjGJisKwu FbbFYlNsJEhcRuESGYVZvBcYvDRhJ/shQUAEhBC8d+7kubXLK/QZ/iKeo//nbP2O9tdZ+k79/hNO O8YhDlh4750hozSDq2M3Dvjg7pkTuKsOWxFx4rI4G67U+92xHTX4QCCOv8V68t1ffVaqQw8RSwGp mJOVytWEqZ4/OtQP2rkBowcMa7AlFgug4CH0YEndngmf47sTPnHjF3TWUuWlfqNdKr1Uuij9lLww bbRL4flr29q44gqfQ6Miwu9fPBM47lO1/9APmdDbN3AlLgjsgBAWKT8p3Cg+5X/Zj/ps+rQjBkPA H36iPAhJ/NqVXzKWKWHEbVWXpqIQ4sC4A9+NPfz9ZKwlQVwKf4WfiGXUj+R4B2TGuBbXTWiPEKKa JnV+mSbK4UyqDFNljMIKjpnmnXDYiJUiIaZ6qDJGlVXKLpVeKl2UfkqesqtIryKIws3IL9KoDaow KjI+j+PAAYVODkqBCKBHwDw19kDtnzKyYr8vtQjgDbPW6JnbR/QSzOWta2D9O1owRHl05eKurz7D hk2tvGNpqp1RWDFtH6h6qtDjpCCqJmJnqOht0eGihhaq31ztANWbqGMlwlCq2403V9VFGt8psa4K S6WkP/YiT+W4o/RIx3RE0edtPoqTKFEyFBNn2DKCqwMwiN05qp/kY/YN4y60AxiHY/S1spNlKZn6 DwNITP/htodC9VuoJRFK9YnoleBG3Qnz60yYB0J9cwX0UH5SbYV6nGbVbSmAwTPu5JGjNdC4VluG Ggm86QAZLAQp2vi9vZOG4lHI2MsXsYx9uqPSZa9+e1sqIzLMYQQYgZSAgGVL7JNIV3fLXBwuinXD ijv3VLh5Qq5MxmegjP9um3S3ERF0Emh8U/uns1HeXjFn67fXn4SSF9c/4es3/kkfuh27X6x5h7CH D1Z1afLoahC+3hR6u0XF/qMgAALHUmwc+CG+E2JtP/KoYL2mIqKjIDXVg/va900ecfvkUaykw7F6 r7bpgqEA7NafvnT314N/blbp6d3b3gGZ8lSrV3/aEpkQI0Gll0oXpZ+SN1oUHArPCr2HH5ozAZuD 8K6FtfHYwlB19m+UEsHP/nqVhXWK4wRiHGOEa3wFk/KTwo3iU6ZLf9gL5xXiUkvcq+Xln147k25X fkE/RjnCiiDkHL2p6VeatlvdtfnDy+cxrYa1dbikFXs0IEnhr/DTVH/dSQvg/5puLQB+5U/H4ogZ UzHJVOSXXemSCmNBUGWYKmMUVjBtmnexcMlUD1XGqLJK2aXSS6WL0k/JU3bBd2qelu/5BWYBfqpX EqdI4DhOeZGOwh8OSiEIoOBhryXul8hVqVbLZTuNe9/QC+SuUhtLaQAICs9f86dsHtQJb/VYwoOV NTh/ynlAUe0MLFL1xbR9oOqpQo+TEkXVxIp9v9wxqi9qKOwWqNtYfCtS+ED1JhQsClUJG0R1u/Aq ftKiLtJVB4/f+sUnITeDsc1CjB8o5CkYqRx3lB7Sbq+hOHzmeYmKKd/jc9nm41aHTYM64Qhd/xx5 cFadOH8GSnCuLn5XfNQQ0/EZChVDFEqzlo9j2tCzoH3QMk1pqk/Ex8ti734oziwu1qLDtqHdG8xY ZqpBMCk/qbbC3nEaZRoH2OEQABmKm1vwLV8eNCn5kshb4+0tn3e1LD6IicEx3HgUQfbypUId4ah0 6dTKR0q/vS2VVMgEI8AIpCgELLc4RkZiUZ0b7oXFVlhcF2s5zy5KLqbzdnOJ+vcMu1Tq9/MUBRwn lhFgBBgBRoARYAQYAUaAEWAEUhQCmP10xgsRvjvi7tFG/1uRosDkxDICjAAjwAiYIjAqIETwDx48 WLPr3QGflsmWyyciyuVZhMu202EB6XwzpPdPmza1f1oXPz+XmHCXvya279Grp60r7ExNMpMRYAQY AUaAEWAEGAFGgBFgBBgBRkCLAJbZHl80G+vjtEymGQFGgBFgBBgBywq7sIhnobgaNiY8OhoXwoaG PPVJnfqJx1NPz9TubhaEsMLOzc1CyWV3jBsjwAgwAowAI8AIMAKMACPACDACjEBcEZhW2AuXUeCQ vrgq4viMACPACDACyQ6BNG6Rp849jIqIDg23/HsSFv34SdijJ+EPHj15EOJy75HLlQt3fXx8kG5e YZfsMp8TxAgwAowAI8AIMAKMACPACDACtiHgjP2wztBpW2pYihFgBBgBRiBRI4AVdnkyhu0NvOad 1jNVWs9rj6IehUa4u+G615joGCy4i/D0cA+9eKhkQACS4T45T6JODDvHCDACjAAjwAgwAowAI8AI MAKMACPACDACjAAjwAgkUQRCXhxhh+t2YiqW8zqxNmztpmCXjN7u/p7p/D3Dwl3Dwp4+SRUVExke 5ubice9E6eqlkVL3vkFJNL3sNiPACDACjAAjwAgwAowAI8AIMAKMACPACDACjAAjkKgRGGVZMPfi r8nbWY9fuv7n1fCoUPdoD9cwj1TPPFw8UsWkioqKDHuWJuTkB7UKv17u1evBN/gMu38x4/8zAowA I8AIMAKMACPACDACjAAjwAgwAowAI8AIMALOQQBbYtOl8x7UJVe1VyPcwqNinkU+eRb15GlUyLOI kKcRqR+dejNvWMVyZXx8vGGfJ+yckwlJU2vQzg1zXsuCu+2TpvsJ4DVjlQCgs0kNAlxnBRgOx4Gr tqaUMckIJBgCTqqJTlKbYDAlI8OOyhpH6Ukq0OrS6/A+MangwH4yAowAI5BUEMANsIUKZJzYv+jk zj5lA+6nd33qGR2S1SX4Dd9Tfepm7NGhqb+/n0gLXzqRVPI0PvzcM2lo/amLc1WuFR/G2AYjwAjE GQGuswJCxiHORYkVMAIpCAG+DSAFZXaKTCr3iSky2znRjAAjkPQQ8PfzaVo7Q4t6RdzdLfNykZGR uBnW29uysC48PEykx3zC7lFw0NJG5Z/cvSXGNE/v3d4z8YuL29Y+vXvbOyBTvhpvVxow2jtDJkdB ovsuBLWp06bvdvSeo/QnIT2Xd20+smBq8IHAqIhw/xx5irzT+rUuA9y9LRf6Pgw6v2/qyCu7tzy5 cytdvkKVB44pULcJ+McXzz40Z+Kjq0H+OfOU6zqoROtOYMYO0vvnTmUvX1ULF6XHyI9dUVGk1zRd iqJoKq9Ni442xfPawV1HF864vGtT5LOnfsC/Yauynft7+Pjq4lp9pPykcKP4Vg3pBIx6RFUy8uXr igySHJ1O7WNEaAhGgefW//bk9g2/nHnKfNi71PvdhYC9+GvV2k7rmiZFftmVLtsdMEoqyrBpGYMG U6ykw9KELc1giqqzEiJjWTXiIGFkghGICwKi1Ll7eafJljN3pVrlug3yz5kXCsEv0aZz7XFzpHJw UDJx7Mhf87499ceiR1cvubq65ahQvcwHvZz6GcyudkZ6q2tLwXdguyStMBF3BBTdrqJJjLtdqUFd pEWxl8JMxAUB0zoYO4XGPlGWFqlQjjGoNkRK2k6c+Pn7TYM61fl6bvFWHbWxHMXX6mSaEWAEGIHk gQC2x3o8//P09BTTduBER0fL1JlM2EVHRq7r0brcJ5/tHNVPyK3t2SZDwVda/bbHJ2OWJ3du/jlr PDjNF22WWuJI6N6+fn//LcwJxlFnEo2+d/JwzLjVGDndN3O2kBvB+6eOWtuzdaO5Kx9cOresVfXS HXpU6DUMrw33L5zGFCom7M6uXX5g2ph63y7MXKLsreOH1vdt75U+oGC9prGDNDz0sZuHpxY6hR5d kIhlb1Gh0kuli9JPyWvToqUpPHeNH1yybdeqQyb4ZMwccvPaIUtRb934+1XauLbQlJ+Ia4qbgm+L OSmjU66tSrogXRTjSE4KaIkdo/piHh91P032XA8vncOjZxr/V5q1txd/rU7baWPTpMgvkV4b02W7 D0ZJqgxTZYzCSpdB2rwzGpWclFNnkWRFnhpxkBAxwQjEEQEUvKjwsMfXrlzYvHJZy2rNFm1Kn78I dAZtX3/98N5sZStq9W/o297D27fBjGVpc+ePCHkc/OeugzO/ct6Enb3tjHDV2JY6tl3SAsJ0HBGg ul2oVTSJcTSqjR7PRVprOkXRVB2MHQjGPpEaY1BtSOzsnt+0Am9w5zev1E3YOYofO684FiPACDAC iRABzMqpvbKEPxcxOcNu94QhXhkylu3YV6q48dc+LKnzy5YLszn4rdR/1I0j+2WoY4mLW9c8vna5 ZPtPHKs2qWhr9evu4i0/9Mue29XdA5/xqw+bjPU7cH7vN8PKdur3+ieD0+Yp4OaZOmPRkpjFA//Y whlVhozP+UZ1T1+/nBXerDLoq6M/TNcl1ggpZjF0ExmSIwmdEjwa9Rhl1EXFqJxKL5UuSj8lLzw0 2qXwfHdZYNEmbdNkzWHBP0ceFPsrz/Gn9IB/fPGc2WUzzS6beduwHvgQLSQpP0Wovb9G/6HhzOqf lzQuP6O4/7zKeU/8Ms+o05b8MsbScox2z29cUWvsbCzwdE/tFVCkRN2JC44vsSwwUeCv8NOoH6pO rVi8oEbhaYW9fm1TE0tUtP4YmyZ1fmnjOo+myjBVxhRYSSeNeWfESnIkIaNLwqhHBklCXVaNyqn0 Uumi9FPywjGjXemwjpCSktAKmDIhYOSj8m4b3hOHeKI6H577jVYJ04wAut10eQuiF36j97C93wwX gKCD3jKkKya/tPig0oGfoUBRjJfw/axAncbNftqkFXAsHbt2xtiWquuj8NmW9iTuqaNqYsSTUKCN Gop/Wz/vFvn0ibCFury2R6uZpTLs+3YEvnPMLJn+2KJZIsi0NxF1H786V8E5t+7XH2oUmV7Ee/E7 5W7/c0QnkFCPVLcbb/5QRVogCTeMkFLImyJM5Tg0m+oRFrGz5PuKuae/4iuba4UeU6w08pmxKlYW CUmIWPIxJirqwPQx86rmRxnb0L8DVj5KtZAx+rO44WtBgRuFDGzNKpMR3ztlFCNB1cH1fdqh5Av5 LUM+xod5qdO0z4IzwmdJGG1p6zLVhhhjWeWgVl7dtwNrDq7u3S5rKGI5im90AMNFrGDQ8vEIpr18 rQYjbTqOBbym5ZniG9VKjqn+WLR4UiETjAAjkAwQiLH8ubjgn/HSiUs71p9ZubTexAXadBao13Tf 5OEh169GR0bgF6Oigm810wo4isbAN3DMgGpDv3F9vonXUWqTrp4LW1ZjGg7+X9mzFRszF9YtgYkM DBd2jx+CPZvg3zrxF2brZAJzVayhG2XaCCm+vImPb5KQOgVh1PO/8tmnFvScWyEnhsgXNllmD/EX x6Ii00uli9JPyQuvjL8UnlIS6X14+ULgV4NyVaopmabExW1r2q0/1m7DscfXrxyYNlrIUH4i1BQ3 Bd/U6JEF0/ZPG1196OTOB683+XH9tUN7dGI25pcultVHfArQfQ24e+o4YlH4W/XTaBH7bRvPW40d 8bmr1pGDVIiZNk0yuu35JaM4iZBlmCpjFFbSH2PeySAtIauqJLShoI16TMueoqzqFJo+yvRS6aL0 U/KmVhRMmXxJKIQVQQemjsK3orbrj7Zbd/TK3m0KSQ5KyQjkr/3O1X3bBQIF6zf3y54Lr/paQHKU r7Zx4EdX9+8QfbQ2yBl0LNoZ07bUan00tifOSA50UjURo9DQ29dRQ9uuO4Ledt+UL6UDr773ceO5 K/d9+yWOEGmyYO2fM78WQaa9iaKhOL1qadOfNn78150CtRttHfritAdpJaEIqtuNN3+oIi2RFAR+ pUumyCPUFGEqxyFP6UHQ5cBNzRdv6bj7EsqzsKvQIwR0vxiwvWjz1x+9vHuLLtT4eHjet+gaWizZ +lHgBVc3dxwPopUx+oMt838v+Z+QubhldbbSb/gEZNZG0dFUHaw52nJOy7kNvwMNfMLHo4hIpVeX LzoreNTVZaoNMUa0ygnatSlLqdf9c+XLUrIcaCnvKL5UKIn8NRsG798pH0FgxhBMe/laDTpaMY41 Lc+ITvF1msUjpT8WLZ6pfmYyAoxAMkDgpRV2oTevbRrw4VtTfsJnYW3a8LUEMwJzK+ayTNBUzAW6 xpfTtAKOoo/++B12keSt/pajFCZpPWfXLNs5sm/14ZaXgaf376C/f3va0m7HHzRbuPHeuZOBYweC Hx7ySGQWlnfhEUsjseOOjgAAQABJREFUwx4/1KbaFFLZnWsl1bRODzR0PnCt17lwzFWV6dgHA5cD 342FBnVRUdvVppdKF6WfkheJMtql8BTy+D42taDH/GoFrh0IrDvpB4mMUQ+Cqg2ZiP3Lvpmygji9 cokQpvykcKP4QpvRLl4R646fl71cZUzjYikHjguRTgrCxvzSxdI9Gu3iBRWvMTjuBBvE7p45sWVw l4inoYhF4a/206gfqhrOXJ4+X2Gc21j6g17BBwOFS1TTJEKp/BKh8fmrLcNUGaOwkn7q8k7wTbGS UUwJnR5oSNJ11jSNVpkUbkb+qZVLLHU5U1bfLNmrfT7RqmYWSJkIeKULePbgrkw7mvpDsydg/khy Gsz4JVOxUjtG9MYynB/rFMe5FtqVJlLMUYS97QzVlsauXXJUKrR6qJp4dt2vL2po5mzVvph0Zs0y GQtdYdYyb+AxR/mqmCnAcSIiyLQ3kbGMBL6BYWU9elVM/Om+fRqF441Ddbvx5kAsijSFvCnCVI4j gZQeBNUaOwuL/XGaNobEAgqFHlOsMGD7r0TZ0OZj9q322NnY+4Kj3yoPGofpM61aoz/YroF5QLGq DodaFm3aTitvpKk6iINH3pqyaOuQrlhYinvhsJ9GxLU3vdKibmxAtSFS3nbiwsYVWFMMefzKD/l4 dBTf6Em+Wg2vHrBM2K3t0RpLEUEEH9gJpr18o2bJUYxjTcszIlJ8qVNLUPpj0eJp1TLNCDACyQmB lybs1vVuW7JdN3xM06VwY78OWUu/0XFPUM+zYfjNWvL1DX3f18nE/fHZg3sHvxuL5XVxV5XUNWAl I1Ya7hzdv/H8NZi8QHI8fdJgKyI2IWIrIjbm1BwzE6ddWPhp/IEbCLw24PfZvTup/dKCEH+OglSh xytdBkywvjP7N7ErIXZFxSS9RLoo/Woc/sXjv/9TeAoJvMxjLvKDbWeylqmADQj/RTOj/HLkFmwQ obeuC5ryUyrQ4WaVLwUEgc/CAYWL65jy0fb8klFsJDCRkS5PgV/b1ZlRIi12IeWt2QCvr4hL4a/2 02j01t+Hf2tXB5ubMAf3XbE08kWXapqEBrvyy2jUIRyTMsx19nlbRNUFqsw4JDtioeTJreuaupwn Fho4SkpAALN1XmkzyJTi7R37ZLcP6yk5KNgV+ozAKrAeJ0Pxdv0g6Jx4jZQCjiWovoyqX1RbSskL bxV9imOTA21UTUT3qq2hEJOmsWEZp1jgURBojUFTvYmMZSRwQLBg4ouR7H2MYvHMobrdeHPD3iKt QN4UYSrHFXqQdlQ9HQKUHp2YfMTktbZEST5FYDwzv3pBDE7wD/uyQ25c1Uoa/cHMGnYjnVz+Q9jD +/j6KGaytFF0tKIOZitTAasZcCQO3sVkLHvTKyIa6zLVhkhDNhIx0dHYaZu/TiPI4xeLDMAB7Si+ qRuYo79z8hh2K2OdIJYfwtadU8fAtJdvqlwwFeNY0/KMWBTf1Aql394Wz1Q5MxkBRiDpI2A5weOl CTts9MAB6qI3wi+CxS8WM+PcOhysZjnDLnvuSgPHXN692eHph+kijd8TZzk7XHkSUojlSz83r3z3 7D/vrTmMb8XC84Cir+qTYNnW7JKpWOng/Ttk0JV928GRj46C1KoeVw8P0THHoqiYppdKF6WfkpdQ 6AgKTymG0T8+3uIz/qXt6yTTlHgcfFnwQeDwO0FTfuo0SNxs5EuxNNlyoYTIRx1he37pIlp9xGtM lc++xn6Qnmeetd/4d+ST0NyVayEWhb/aT6O5Nd3fxc3I0I85OO090VTTJDXYnl8yigMJ0zJMlTEK K+GP1byz0W2remTZs7Gsau2appdKF6Wfktcaik8aC+v+q8vXXlTq+HSAbSUJBC5sXpWzYg2tq2U7 93tw+Tz4WiboVG5umV4p9ebwKeIgWl2oox7tbWeotlRdH622J45KDvRQNRGrX7U11CdTVrVRqjdR x0qEoVS3G/+umhdpnIn9fDgq/bEXeSrHregxnNVN6ZGO6QifzNm0JUqG4kpoOV2rXTyLKTkMS8Tq bPz2vhAlo1gIgz/gvfpel7+XzsVq0Hw1GyAfX5I3PCjqIBbo4RIJLMHDoX4ynr3pFRGNdZlqQ6Qh GwncwIPlhDhVGW+O86rkAw0O4jqKb+oGxn7pCxQ5s8ayrhlrGkCkL1AUTHv5psoF095xrEKVaRCl 394Wz1Q5MxkBRiB5IPDShJ3shwSBFILAL5bU7ZnwOT4C4LslfkFnLVXesenHHs9za5dX6DPcsWqT nLZTv/+E045x+EKT+Wu8M2SU/uPq2I0DPsAmRGxFxI1OWBgvjhEs9X73XeMGBR8IxPG3WAe++6vP SnWw7I3FnwJSMScrxKz+mur5o0P9oJ0bMHrAsObG0QP4aA8PoUpdVIx2qfRS6aL0U/IidUa7FJ6/ tq2Nq6zwOTQqIvz+xTOB4z7VFnWjHuiHTOjtG7g9GQR2QAiLlJ8UbhSf8r/sR302fdoRwyDgDz9R HoQkfu3KLxnLlDCmd1WXpqIQ4oA/bII+/P1krCVBXAp/hZ+IZdSP5HgHZMa4FtdNaI8QopomdX6Z JsrhTKoMU2WMwgqOmeadcNiIlSIhpnqoMkaVVcoulV4qXZR+Sp6yq0ivIojCzcgv0qgNqjAqMj5r iwMHFGo5KKUhgB4B89TYu7R/ysiK/b7UJh9vhrVGz9w+opdgLm9dA+vf0YIhyqMrF3d99Rk2bGrl HUvb285QbamiPpq2J45NhVYbVROxM1T0tuhwUUML1W+ujWWkqd7EKJnIOVS3G29uq4s0vlNiXRWW OEl/7EWeynFH6ZGO6Yiiz9t8FCdRomQoJs6wZQRH/uN9Z+eofpKP2TeMu9AOYByO0dfKTpalZOo/ DCAx/YdbHQrVb6GWRChVB9ErwY26E+bXmTAPhLy5gsJNYci0LlNtiEKPaRAGz7iTR7YwoHGtNiQd xTc1CibemIAwFnwUbfze3klD8Sgk7eWLWMaxgXocS3lF8W3Xb2+LR1lkPiPACCQDBNxtSUP96Ut3 fz3452aVnt697R2QKU+1evWnLbElou0y6ITQuKf2T2d7lGQpKa5/whcw/JMJ7HbsfrHmHcIePljV pcmjq0H46lLo7RYV+4+CAAgcP7Fx4If4Toi1/cCwYL2mIqKjIDXVg/va900ecfvkUSy6TJu34Ktt uqDLh117iwqVXipdlH5KXmKoIyg8K/QefmjOBGziw7sW1rRjC0PV2b/p4uoes79eZWGd4jiBuPA7 rXCNrwil/KRwo/g6W/Kx9Ie9cF4hLgjDfVhe/um1M9125RcUYvQg1ApCzNFLQzrilabtVndt/vDy eUyrYW0dLmnFHg3IUPgr/NRpFo91Jy2A/2u6tQD4lT8dK88ENBUGU5FfdqWL0m8LnyrDVBmjsIIt 07yzxQedjKkeqoxRZVWnUz5S6aXSRemn5KUhI+HUPC3f8wvMAvxUr2R0dFT57kO05+8YPWFOikIA BQ97LXG/RK5KtVou22nc+4ZeIHeV2lhKA1hQeP6aP2XzoE54q8cSHqyswflTzoMrFu2MqTOK+mja npgqcQiTqokV+365Y1Rf1FBYKVC3sfhWpLBI9SZObUYU/sQ6iOp2oTB+0qIu0lUHj9/6xSchN4Ox zUKMHyjkKQSoHHeUHtJur6E4fOZ5iYop3+Nz2ebjVodNgzrhXi8caIiz6sT5M1CCc3Xxu+KjhpiO z1CoGKJQmrV8XD2BngXtg5ZpSlN1EB8vi737IS5zQKxiLTpsG9q9wQzLAY4UbqbKBdO0LlNtiEKP aRAOqsMhADIIN7fgWz72ZDiKLzXriLw13t7yeVfLIoaYGBznjUchYC9fp1Y+2juOlRFtJCj99rZ4 NppjMUaAEUhaCIi39FTq9/OklST2lhFgBBgBRoARYAQYAUaAEWAEGAHbEcDspzNeiPDdEXeGNvrf Cts9YUlGgBFgBBiB5IrAqIAQkbRDhw55eXn5+vri19vbO3Xq1B4eHp6enu7uluV0uCA+KioqIiI8 LDLs3NkLL22JTa7QcLoYAUaAEWAEGAFGgBFgBBgBRoARiB8EsMz2+KLZ4gSb+LHIVhgBRoARYASS FwKWNXY8YZe88pRTwwgwAowAI8AIMAKMACPACDACCYrAtMJeWCaBw+YS1As2zggwAowAI5BkEbBc J+Fi0xl2STaJ7DgjwAgwAowAI8AIMAKMACPACDACJALO2A/rDJ1kAjiAEWAEGAFGIJki4D45TzJN GSeLEWAEGAFGgBFgBBgBRoARYAQYAUaAEWAEGAFGgBFIUARCXhxhZ58T7n2D7IvA0owAI8AIMAKM ACPACDACjAAjwAgwAowAI8AIMAKMACNgCwKjAmyR+k9G3BLLZ9j9hwhTjAAjwAgwAowAI8AIMAKM ACPACDACjAAjwAgwAoxAgiLAl04kKPyJ0HjQzg1zXsuCu+0ToW/x6ZLDcWBI4zP7UpQth5fVZI8e V8Zkn8UpOYFOKt5OUpuSc4rTTiHgqMLmKD2Un8x3KgI8tnEqvKzcRgS4HNoIVLIXQ4ci/ulSGm8d Da+w0yGfoh/3TBpaf+piPiWXcUjR1SBJJZ7LapLKLnaWEUiSCPCoIElmGzvNCCRZBHhsk2SzLlk5 zuUwWWVnHBKDUVDCDoTMb4l9FBy0tFH5J3dvCeciQkNQZM+t/+3J7Rt+OfOU+bB3qfe7xyHV+qjG 6cnUadN3O3pPL5cCni/v2nxkwdTgA4FREeH+OfIUeaf1a10GuHv7IOkPg87vmzryyu4tT+7cSpev UOWBYwrUbQL+8cWzD82Z+OhqkH/OPOW6DirRuhOYsYP0/rlT2ctX1cJM6THyRVF5eu/2nolfXNy2 9und294BmfLVeLvSgNHeGTJpdWppRXpN06XQbyqvtaWjZRKMNdCIgy4uPzICEgFFGeY6C5QcWGdN 8bx2cNfRhTMu79oU+eypH9rMhq3Kdu7v4eMrM8hGgvJTNhRSj2gxKL4Us5Ew6hHdn5EvWyoZJDkK W4ru2942U2FFEaQbTijyy650KSw6Nkh45e7lnSZbztyVapXrNsg/Z16YAL9Em861x82R5sBBjkSG Pftr3ren/lj06OolV1e3HBWql/mgV67KtaQYE1YRMK3piGVaQiRTqhU1iKrRlB4ZPVERuupDJRY+ U6DFPTnqIi2KfdytsIZkjEAs+hq7xuHOK/wiU9CY75s8Iihw49N7d9LlLVi+5xdFG7+Hkm/aBYgo J37+ftOgTnW+nlu8VUfBgXzm4mXeW3NYPC5uUPbWib/QZRgrNQRs6dyFHv51CAJUO2ZXOYyFJ5Rd U1Upqhwa64WsFM6u76bgJzjTZMIuOjJyXY/W5T75bOeofsK/HaP6YvKu+aLNabLnenjpHB490/i/ 0qy9o7yXeSAU/v7+W5jocZTypKVn7+ThmHGrMXK6b+ZsITeC908dtbZn60ZzVz64dG5Zq+qlO/So 0GsYXhvuXziNeTFM2J1du/zAtDH1vl2YuUTZW8cPre/b3it9QMF6TWMHaXjoYzcPTy1iCj26IBFr bc82GQq+0uq3PT4Zszy5c/PPWePBQcnR6tTSVHqpdFH6KXmtLR0t/De2CBAz4qCLy4+MgESAKsNc Z0Vb5Kg6S+G5a/zgkm27Vh0ywSdj5pCb1w5Z2pzWjb9fJTPIRoLyE9FN2zoF30aLQkynXNv96YKk WkXbJWUkQXXfsWgzpU7bCeNwQpFfdqXLdh/iLgnHosLDHl+7cmHzymUtqzVbtCl9/iJQG7R9/fXD e7OVrag1saFvew9v3wYzlqXNnT8i5HHwn7sOzvyKJ+y0EKlpqqYjlmkJEUypU9YgqzXatPeXehID Yaw+VGIVoMU9IVyk445hStYQu77G9nG4Uws/Mg6zJMverV62U9+K/Ud6B2TGq9b+KSMxYYcg0y5A 5PX5TSvwJnt+80o5YQd+2OOHN4/9maVkuZtHD4aFPBKS+NXVa8lnIsERsL0cOtvVFFgOTeuFs+u7 s/Mx1vpNtsTunjDEK0PGsh37SqXnN66oNXY2VnW5p/YKKFKi7sQFx5f891VZijmEuLh1zeNrl0u2 /8Qh2pKckla/7i7e8kO/7Lld3T3wGb/6sMlYv4NU7P1mWNlO/V7/ZHDaPAXcPFNnLFoSs3jgH1s4 o8qQ8TnfqO7p65ezwptVBn119IfpulQbIcU4VTdUlRxJ6JTg0ajHKHPjr31YUueXLRcm/vBbqf+o G0f2SzGjciq9VLoo/ZS8MG20K13SEVJSEloBUyYEjHx8kd42vCcOBJxdNtPhud9olTCdzBCgyjDX WdEWOarOUni+uyywaJO2abLmsLSZOfKg/bnyvM0UxcxYN8E/vngOKubsspm3DeuBqiokKT9jV1xN 7Z5Z/fOSxuVnFPefVznviV/mGTXb0sYaY2k5RrtU961oMxV+GvXD+qkVixfUKDytsNevbWpiTKn1 xzicUOeXNm6iotHtYmEFeuE3eg/b+81w4Rs66C1DumJWResqMhH8DAWKohPEnHWBOo2b/bRJK+BY muprIp6Ewjf0Qfi39fNukU+fCLvIwbU9Ws0slWHftyMwtzWzZPpji2aJINN8FDmOX53b4Jxb9+sP NYpML+K9+J1yt/85ohOI9SNV021RqK1Bjq3Rtlh3uIyx+mhNaBMbF9C0Ok1pqkiLsoEoxkJClSXT MkOVYWg21SMsYmfJ9xVzT3/FVw6xFHpM06WRz4xVsbKQS0LEko8xUVEHpo+ZVzU/as2G/h2weFmq hYzRn8UNX8OaLCEDW7PKZMTSBxnFlDDVQ9nF+qw/OtSH2mmFUqMOAluhE0oOfz8ZfRzq/vYRvfCx QfAVbYJpvlD6KX9MUwQm1des79MObZSItWXIx1hwIGj4j3+gJSH4lF1F4Vf0ZUKnLb/Qj11lZT7q g1czvAVnL1e56cINIqJpF4AgtLdX9+3A2oure7fLthd8LMgQr8/4FduhbHFAK4OuFis2tBw8gmkv X6vBSJvihuwwLScU36hWckz1K8on1WdJhVrix9rFrh/aIzggfqxTXNDYuLZjZJ/n72Wo71NEGUOQ LGaCoPhaE6Y0IpriQ5Vbyq6pcjATVTkUTprmI4UDxafSS/Gp+g79dpUTqjxQ7R7lD/im7xSUPMon FQR+qlQvxlog/qXBsjD1E3aXdqw/s3JpvYkLtOo00V6w7546rhVwFI2Bb+CYAdWGfuPqbrL0z1FW kpCeC1tWYxoODl/ZsxWbvBbWLYGXIgwXdo8fgv1f4KNgYbZOpihXxRq6cbONkGIaW8xkS0LqFIRR z//KZ59a0HNuhZwY9F/YZJk9xF+Bek33TR4ecv1qdGQEfvFKUPCtZiLIll+ZXipdlH5K3hajWhmZ fEloQ22nD0wdhXnntuuPtlt39MrebbZHZMmkjoAsw1xnRVvkqDpL4SkLDNqoh5cvBH41KFelmpJp Slzctqbd+mPtNhx7fP3KgWmjhQzlJ0JN2zoF39TokQXT9k8bXX3o5M4Hrzf5cf21fweUUtjGNlbK 20hQ3TfVZlr102gXx2U0nrcap1jkrlpHvoBBzHQ4IaPbnl8ySmIg8td+5+q+7cKTgvWb+2XPhVd9 rWM5ylfbOPCjq/t3iD5aG+QMmupr0BGH3r6OPqjtuiMo5/umfCmtv/rex43nrtz37Zc4cKPJgrV/ zvxaBJnmo6IrPL1qadOfNn78150CtRttHeqwY1Ks1nSZEB2hq0GKGq2LmDgfrVYf7Wg51qDZknaq SMuyIQj8Sm2mZQmhpmWGKsOQp/Qg6HLgpuaLt3TcfQlACbsKPUJA94vG/8U4bf3Ry7u36EKNj4fn fYvhXIslWz8KvODq5o6TgrQyRn+wX/LvJf8TMhe3rM5W+g2fgMzaKKa0UQ9ld/XHzYo2a99x16Vu fz98c9i3//z2o1SINgp9HKo/tlQfnDFO8BVtgmm+UPopf6R1HUH1NTVHW86yOLfhd+QylibgUUTU lSupjbJLFf5Y9GXSlpZAjhRu0FLLkbRpF4DQoF2bspR63T9XPiymAy3li7X8EOsNQ29dP7vuVyzO kHzbifw1Gwbv36mVx8wgmPbytRp0tAI303KC6BRfp1k8UvoV5ZPqs0z1F2rQEiCLoDNrlsm8O/jd uAcXz2JLcvuNx2UnDjFdeZPtmI5vakvHNMWBKrc6/dKuTqd8TFTlEF5R+YggUxwUfJlGHWE69qbq O+LaVU6o8kC1ezrftI+m7xRaAS2N8ql9tJ1+acIu9Oa1TQM+fGvKT/gsrFWBJgmjMewZxoeau2dO bBncJeJpqFbAUfTRH7/DLpK81d9ylMIkrefsmmU7R/atPtzyMvD0/h30929PW9rt+INmCzfeO3cy cOxA8MNDHonMwlIRPGJpJFZca1NtCqlsJrSSalqnBxo6H7jW61w4xgRlOvbBwOXAd2OhAR+U8CI6 t2Iuy1xexVyga3w5TWpW29Wml0oXpZ+SF6bVdqV7VglKj5F/auWSakMm+mbK6psle7XPJ1rVzALJ AwFtGeY6K9oiR9VZCk9RcvBtbWpBj/nVClw7EFh30g+yOBnrJoIsdTNzNlRPEKdXLhHClJ/QYNrW UXyhzWgX0zp1x8/Dx3l8esHyKxxtI50UhI1trC6W7tFol+q+qTZT7adRPxxoOHN5+nyFcdZq6Q96 BR8MFC5RwwkRSuWXLjmJ8NErXcCzB3elYyg2h2ZPwIyY5DSY8UumYqV2jOiNZTj4to9zLbQrLKSY owiqr8EL4Ys+KHO2al9MwnuLtIhCmLXMG3jMUb4q3idx+IYIMs1HGctIYPYZa1pRnjHxp/tSaBS2 naOu6Qo9uhpE1WiFhsQTpK4+8FOX2FiDZkuSY1GkqbJkWmaoMgzfKD0IqjV2Fvb94IhkDIlFKhR6 TJOJxv+/OmLDOA2zb7XHzsbeFxySWHnQOEwzadUa/cHSb8wDilV1ONSyaNN2WnmKNuoh7aZKde/s P7dOHA57eD/ba5Ua/W+F1Knt42Ba8BVtgmm+YLGHqX7SH2n+ZYLqa3C20ltTFm0d0hVLgHHfHfYJ vRxP/0TZpQq/ui/Ta6efod8nczYq3NgFQPLCxhVYWw0Cv3JBAx4x6sC6itVdm+OzIg4OkjrRIer+ ySAdka9Ww6sHLBN2a3u0xhJFEMEHdoJpL1+nVvuowM28nLi4UHytWklT+hXlk+qzpE4tUah+C6iy cGJisOQNjyL05O8Lqw2bjN0YQL7q4PHaKI6iTXGgyq29RhNVOYTzVD4iyBQHBd8UCmqMTdV3KLGr nJDlgWj3TJ0UTG17K98pKHlZICkBiv/ShN263m1LtuuGj2k6acw4pMtT4Nd2dWaUSIsFh3lrNsCY VScT98dnD+4d/G4sltfFXVVS14Dlafh2unN0/8bz1+BFCMnx9EmDXcnYj4z12NiYU3PMTPEBAR0e cIMA+gz8Prt3J7VfWpl8R0Gq0OOVLgMmWN+Z/ZvYlbCxX4espd/ouCeo59kw/GYt+fqGvu9LfyjC JL1Euij9ahwou87jP7l13S9HbqEfB+E7zxBrTiQImJRhrrPP2yJH1VmqDRQFAF07vh98sO1M1jIV sLlGXSo0dTM3vnULYcpPqUrX1lnlSwFBYClHQOEXWzN0QXi0vY01xlVzqO6bajPVfhpt3fr78G/t 6mCLJd43viuWRk5OUcMJocGu/DIaTUAOZuu80maQDuDtHftktw/rKTkAtkKfEVjX1uNkKN5CHwSd E69VUsCxBNXXoGBrynkeiEm72N6L/eN4FATaLtBUPspYRgLH6Qom5mplvhvF7OWoazqlzViDrNZo SlVi4KurjzGxsQPNxpTaW6QVZcm0zFBlWKEHnqPq6fyn9OjE5CNmRbV1RPIpAm3j/OoFxcQKNtaF 3LiqlTT6gxkobDE5ufwHTKjhS4aYwdFGMaWNeii7WB4bevvG9hG98aVqTrmsZ1b/IhVq0pVbzsgr 2gTTfKH0U/5I6zqC6msglq1MBazSwFE/eHHQxTI+Unapwg95RZ9r1E9xvNNn1LafOjFjFxATHY1d 5PnrNIIkfrHYAhwZ69X3uuDkU/xKDgjxJUz7qw3V0vjKcufkMeyyxDojLEuE5junjoFpL1+rU0cr cDMtJ4hO8XWaxSOlX1E+TfssU+VgZiz6Ki6JwnFM14/sx/ckvDgLydAbwfjCJGhZQSglseOb4kCV W3tNJKpyCOepfESQKQ4KvpytNsVEN/am6jvi2lVOqPJAtXumvgmmLE4g5DsFJY/ySQWp+S/tPMUa UfzDGeoyDkBEC4LRWJXPvsY/wcf35NxOuPIMdos0fk+c5SwdSIEEVjKu7dUGNRMLd70zZBQIBBgz OMay+yBTsdLB+3cUbthKiF3Ztx0cCZqjILWqx9XDQ3RIWPvdeX9wav908AHHPVQaOAZ7ZqU/poRp eql0UfopeVOL8cDEwrrHwZfx+Re20KjFg0U2kYAImJZhrrOiLXJUnaXwlPmOOQjUOCwmstrm/Fc3 gy/jc6vQQPkp9QtCtnU28qVYmmy57p79BwuaJEdL2N7GamPZQlPdN9Vmqv00WlzT/d3ynwzGHQto 9vFeipk7IUMNJ6QG2/NLRkkMxIXNq3JWrKH1pGznfosalAVfywSdys0t0yul3hw+BSdt6YIc+Ej1 NVjK8V85v3bZJ1NWtVEqH9WxnBFqtaabGjXWIBtrtKm2BGeqq48xsbEDzd5kmhdpHLCD4ei/J+9A p71liSrDVvRoLIqEUHqoZGLZlLaOSDG87WMCGi0nONrFs5iawZG1WF4nJV8iDP4gFPMyG/q09/RL m69mA6HwpSimDwY9lF25Uhubwc+uXbZtWPfCDd8VKv9LV/BlLCcXTHvbBEo/5Y9pasCk+hoEYfUf DvW3ECsWi2scKCXgU3apwm9vX0aZzlWlNlYol+v6KSWg6wIwH4dllTipVsqDg7U/4jFPtXp4rZZB 9hLoN9MXKHJmjWUdd0xMDIj0BYqKDzD28inTjsLNXv32lk9KP/iF3m5hWdQSE1Pw7RfL68D0zZrj 4ZWLKNWgsVVcHx317uV2TC8Q22eq3L7QZ7PdRFUO4bwDy4ktNUKOvan6bm/+UOWBaveEfkvvEPYM a6e05rTtrXyn0Ao4hH5phZ12dl/AJ35XdWmKnbDYD4sTgrDzEaeZ4gOyQ8xLJdjjeW7t8gp9/psr lEEpijj1+084OxaHETSZv0bO1gEBnE66ccAHIhdwQwoWkIuz4XAS6q5xg4IPBOL4W6yL3v3VZ6U6 WPbG4k8BqZjMFmJWf0314KTboJ0bsNAdw5obRw/ga7A4PxVL6vZM+BxTVPhoj1/QWUuVlyaMdqn0 Uumi9FPywrTRrnTJLoLSY+QXadQmcNynuCcXc+1i87Jdhlg4CSFAlWGus6ItclSdpfD8tW1tXMeG qSKcIHv/4hnUO3Wbg6IFGSxMQPUEgV1LorBRflJtHcUX2oxtQtmP+mz6tCMG7mgz4SfacFnI7Wpj ZSxTwmiX6r6pNlPhJywa9SM5uDgP76K4bkJ7kBk1nFDnl2miEgMTpQvz8tgDgvsBK/b7UusSXpZq jZ6Jw90Fc3nrGnhVABqI8ujKxV1ffSZf1bSxHEVTfQ22QotyjqKOPqhQ/eZqi1Q+qmM5I5Sq6Qpb pjWIqtEKPYkniKo+8NA0sbEAzfbEqos03k+wnghLfqRCe8sSVYYdpUc6piOKPh+noYKIOiJDMcGE LSM4Ah+D2J2j+kk+Zt/QhqMdwNsQWvKVnSxLqNR/6IzwgodT0mO9DQr6Kbu/ta97afs6DP7hD7zV rvzV9nGAVzhpb5tA6af8oaCg+hp0wYC37oT5dSbMA2H1Rg7KLlX41X0Z5a2RX7Hvl0d+mIbGH7O3 gBqvPH988LZWTNcFYECCu4lkFQaN68W18nGk8YaIEoUFLpji3DtpKB6FQnv5IpaxT3cUbvbqt7d8 UvrBF8fYoSOWB9iB+UrT9jhmCqero6Tt/nqwiC5/je2YDDIljLiZioFJlVshb7vdxFYOHVtOjOhR Y2yqvhs1aDnG/KLKA9XuCW34CvvP8gXa/g58bXsr3ymEvNGu1iu76JdW2FExX2naDlvuH14+j3E5 1tbhljcsYKaEY8dHY41GTazMip2G5BFLXJOEz6f4J1PU7dj9Ys07hD18sKpLk0dXg/AVAl8PKvYf BQEQ2M69ceCHmN/FUkxgWLBeUxHRUZCa6sE95fsmj7h98iguwkubt+CrbbqgCsFu/elL0Q7+3KzS 07u3vQMy4VNS/WkvjoiSydESVHqpdFH6KXmtLR2NWiQ4ghBz0zqZWD+W7/kF3pF+qlcyOjqqfPch 2jMsYq2TIyZOBKgyzHVWtEWOqrMUnhV6Dz80ZwK2v2F+BOvwse2o6uzf1EUl++tVFtYpjlPDC7/T CldvC2HKT6qto/iU6dIf9sIZo7g8Gne6efmn136dsquNhX672i6q+6baTIWfpkmrO2kB/F/TrQXA r/zpWKvndyjyy650mTrjJCYcw1YL3C+Rq1Ktlst24oO5zhBKVO4qtf9eOhd8NPh/zZ+yeVAnvNph CQ9W1uCcJp28Ax+pvgaD+x2j+qIPgq0CdRtb/chK5WP8ZwpV05EQyhnTGkTVaIUeB+aL81SZJlYB Wtw9URdpnAa19YtPQm4GY5uFGEdRZYnyhCrDjtJD2u01FIfPPK8jMeV7fC7Habj9YNOgTrgjCBvo cFadOH8GSnBGJ35XfNQQ0/EZChVDFEqzlo+rJzAaRPugZdpFU3bLduyLG2PwSQb7/rC3tOGs5+d2 PVed/bVK6ONSubphzR3gFebsbRMo/ZQ/VKKovgYfeIq9+yEuZ0DEYi06bBvaHSu1KSXgU3apwm9v X0aZxqbdlj/vwEvZwRlf4UiEdHkLSUhlFG0XgAPscBiCDMKdPFjTIPeoSb6WkC2bZCpeSfLWeHvL 510tizZiYnB8OR5FLHv50paOcBRuOrXykdJvb/mUCo0EZlWwIAv8jEUtPaD4e7374F3jPsVyeDxi AKabRTW2Y//Gi+v/qXIr9NpuN7GVQyof44rXv/GpMTZV3/+NZ+v/qfJAtXtC75tfTtvQ7310eah9 spKavlPY6ofNcpYdrzYLsyAjwAgwAowAI8AIMAKMACPACDACyQcBTJo444UI3zBwZ6L2RghnQ+ak hDjbbdbPCMQbAjjY8ZcWVT7adTHeLLKhxIxAPJeHUQEhAo1Dhw55eXn5+vri19vbO3Xq1J6enh4e Hu7u7qme/0VGRkY8/ztz7uxLW2ITM5rsGyPACDACjAAjwAgwAowAI8AIMAKJHwEssz2+aLY4wSbx e8seMgLJGwFcAIUtDmGPHuz7dkSBuk2Sd2I5dVYRSFrlgSfsrGYoCzACjAAjwAgwAowAI8AIMAKM ACNgKwLTCnvhOg55ipyt0ViOEWAEnIAAjmla3qbmgjcL4Z6Wiv1HOsECq0xKCCSt8uCUFeBJKbvY V0aAEWAEGAFGgBFgBBgBRoARYAQYAUaAEWAEGAFGwDkIxG5LrPvkPM5xh7UyAowAI8AIMAKMACPA CDACjAAjwAgwAowAI8AIMAIpG4GQF0fY2YeCe98g+yKwNCPACDACjAAjwAgwAowAI8AIMAKMACPA CDACjAAjwAjYgsCoAFuk9DJ8hp0eEX5mBBgBRoARYAQYAUaAEWAEGAFGgBFgBBgBRoARYAQSEAGe sEtA8BOd6aCdG+a8lgVXwic6z+LXIYfjwJDGbwamIGsOL6vJHjuujMk+i1NyAp1UvJ2kNiXnFKed QsBRhc1Reig/mR8/COjykcc88QM7WxEIcHlLqJKAii/+JZQDic0uT9glthxJSH/2TBpaf+riPpdi EtKJRGCbcUgEmcAu2IQAl1WbYGIhRoARiAMCPCqIA3gclRFgBByGAI95HAYlK7IBAS5vNoDkFBGM OnjgoUXWXfug+46BIAnW8cWzD82Z+OhqkH/OPOW6DirRupM2Yhxpo93UadN3O3ovjmqTYvTLuzYf WTA1+EBgVES4f448Rd5p/VqXAe7ePkjLw6Dz+6aOvLJ7y5M7t9LlK1R54JgCdZuAb5o1sYP0/rlT 2ctX1eJG6THyRVF5eu/2nolfXNy29und294BmfLVeLvSgNHeGTJpdWppRXpN06XQbyqvtaWjZRJk IZcCRhxkEBOMgA4BRRnmOgusHFhnTfG8dnDX0YUzLu/aFPnsqR/azIatynbu7+Hjq8smq4+Un7Kh kBpEi0HxpZiNxP/buw74Koqtv+kJoRMCofcmoiAiHUEQFRXBioLdZy9YPhSfiGLXJyiK5SliRcXy QEGKdJAmXRCpCRBCrwklje+/mTBsdufM3XuzN9yQs+R3OXtm5syZ/5wpe3Zm1ilHDH9OvuypZJDk aPLKykjHjHPj5J+O7tlZpkbtlnc8et6tD4r4/vaZmlw0QYdTU769us3RfbuFtpr68qtcmhy9DRJa RcbGlU6qUav9Ja3vH1S2Rh1kAX7zfvd0f/VjmR04KGP2iePLR49Y97+vD29PDg+PqN62S8vbH6nZ 4RIZjQmfCChbOlLpLdZmaVR8aWZSjRCccDqVlI2dAkcmkTFlAQtJ6E1amH0hs+DkZzcC+pbrV9md 83Np+VKObNFUY5ExXRLozBcOH5oyd+qx/XvL12nQ5uF/N+l9M/JVDgFC5prvPp026O4er39yzo13 CQ7iJ57T8uaJy8TtN71a7V6zHK3VqT8ieN6KRab8SyGAWlBi7rQ3SkJgfCpfpTS2QyUshWH6hX9h Mip82gIOO4hT2uuGST8sHvlyzxFfJjZvtXv10skDB8RWqNSgZ5/CZy8k2DL9+dbL4OjxSnjxkrNg +PNwhnZ98b34xKT0namL3h026eGbrv5kwsHkjeNu7HL+bQ+1fWQIHhsObP4HfjE47KiqCQzSzIwj EVHRVsQ0cmxBItWkh/tVbND0xp/+KJVQ5ejeXX9++AY41379u1WmlabKS5WLkk/Ft+Zlo4X+ypHS iYMtLd8yAhIByoa5zYphwqs2S+E5741nWtxyX6fBb5ZKSEzftWOp2efc1PvTX2QFuSQoPZFc2ddp +C5zFNFswq3Dny1IitX0XTKOJGYPGwhnGTrh0tVqHkreiNvo0mWb9h0QQJ8pZboncrOzf3voptYP PD1n2OMilaa+/CqXex0KHxOK5WSeOLJj2+bfJ4y7vnPfr6dVqNcYYlNmTU5btiCpVTtrFlMGDoiK i+81aly5WvWy0o+k/jlvyQevscPOCpGeplq63mKdlkbFtzUra4vTK1bEoTY9Re4UOAgNXvNhky7i qj/LsqNaYmDFdM7PbS1FtmhNY/Era3hJxt3QpdXdA9s98WJcpUQ8BS9650U47CBEOQQI4ZumjceT 7KbfJ0iHHfgnjhzaterPKi1a71q55ET6YamGrQiSz8QZR8Bpb2dKJbbDM4V8iOTrakvsqi9HdRz8 Ro2LukTHl6nR9uKOg15b+fl7QSrAlhkTj+zY2mLAA0GSH+Jib/xx/jnX31GmWq3wyCi8xu8yZDjW 70DnBW8PaXX34xc+8Ey52vUjomMSmrSAFw98N1XjhBReKpujSnIk4QTKKccZZ+fyhVhSVyapJhx/ +G3/xLCdKxbJaE7hVHmpclHyqfgia2e+UiUbIWNKwhpByUQEJx9vpGc+/zAOBPyoVeVln7xtFcL0 WYYAZcPcZsUw4VWbpfC8YdzcJtfcUrpqdbPPrF4b/c+2vD5TmJmzbYK/+puP0TA/apU4c8hDaKoi JqVnYOaqzHf9r9+N7d1m1DllR3eos+b70U7JbvpYZyorx5nvpqnjL3nlIyzKjoyJrdS4+aVvjVk9 1lwUpukzNXo65UPUuvHfjOnaaGSj2B/7dcOc0qrP/DcHx1ZMaHXXQMnU15eMFmoEhl0srMAofNGj Qxa8/bxQDwP09MH3wVVk1RaVCH7F+k0wCMJnXb9H775fTbNG8JamxpqsoxnQDWMQ/mY8e3/2saMi X9TgpIdu/OC8igtHDMWT7QctKqz6+kMRpKxHUeP4takNzsbffvy8a+P3Gsd9c1XrPWtX2CIEfEu1 dI3FIi+npenjC/UK3+ICLmZgCSlwApPmMhVl0sI2IMRpJJQtKW2GsmFIVsoROWLTz6ftar3XNF5O sTRylCW1xE/Eqlhp5JIQqeTtyZycxe+9PLpTPbSaKU/chsXLUiziOPX55soLsCZLxEFeH7ZMwLsT mURJKOVQ+WJ91v9uuxxiRzaMQRsEtkImhCz7dDjGOLT9WUMfwcsGwdf0Ccp6oeRT+ihLBCbVEic/ 1h99lEg1ffC9WAsiaEu9FJg/o1z4QxxJiPjWX2uL9qqxQA6Wpbe88zE8mmEYrda6Q58vp4hMlUMA gtDfbl84G2svti+YJfte8LEgQ4y/+A1spxqGWqzYsBYZt2D6y7dKcNLKOQBgV9oJxXeKlRylfI19 UmOWFGglvujeLG3pH4ID4ose5wgaG9dmv/hY3nMZ2vs7wpYQJM1JEBTfmoWSRkIlPlR7ofJVCgcz pOxQKKmsRwoHik+VV8NXjgtUf0LJofAHX2lv4Cv7VUo+ZW/oV6kker7dYfffNtXebRD9SdsamMlt nma6hHBBOrx1gsZvzXZdPZycSbEgMPGd+/KTnZ97OzzSvvTPGq3k0Jun/woPKcq77Y8Z2OT15aXN 8VCE6cL8NwZj/xf4PqvGJaR4vSPe8EjCBrJTjtJU6vfss3D48+lp23Ozs/CLR4IGl/W1idLcyvJS 5aLkU/E1eSmDZPEloYzmk7n43WHwO98yeWX/31ZuWzDTZ3yOcNYgIG2Y26wYJrxqsxSe0nLQRx3a unnua4Nqtu8mmUpiy8yJ/Sev6j9l1ZG0bYtHviTiUHoiVNnXafjKTFeMGblo5Etdnht+z5K0a76Y vOPUhFJGdtnHyvguibC8yxp537rVuKX6TJ96WkUJGvtte4/+FadY1OrUQz6AISh59uT1E77t+dYY ZxJw3NeXMvmZYtbrftX2hbNE7g0uv7ZMtZp41LcqU71N56lP3bl90WwxRluDgkFTYw0G4ow9aRiD bvltBex84TsvyNzPvfne3p9MWDjiBRy4cc2YSX9+8LoIUtajZij855dv+3w19d7le+t3v3rGc/n7 rGUuARNUS6csFhkpLU0TX+jmbHEB6xyMhMpuhwInGApImZRJS9sQBH5lEqUtIVRpM5QNIz4lB0Fb 50679pvpd81PRu2LfDVyRATbLzr//Hna5JVb50+3hTpvl40egencdWNn3Dl3c3hEJI4asMZx6oP9 kn+N/a+Is2X6r0nnX1SqUqI1iZJ2yqHy/fXevk36DrhrXvL9fx26eMiItT99IQWij8IYh+aPfeJL Rr0q+Jo+QVkvlHxKH5m7jaBaYreXzLMsNk75GbWMpQm4FQmperTZmy0X3NpatFeNBTXSqNf1zuzA UQ4B4KfMm1blvAvL1qyLxXSgZdpm19+B9YYZu9M2/PYjFmdIvnuiXrcrUxfNscaHZxBMf/lWCTZa MwdQ2gmSU3ybZHFLydfYJzVmKeU37HU9QBZB6yeOk3W35P1XD27ZgC3JA6auloM4otnsSvZjNr4y LxtTiQPVXmzyZb42mfI2pOwQWlH1iCAlDhq+LKNLQjkuUP0JJVODP2Vvyn6Vkk/ZG/pVKomTLybw +EVQAYcdtL9n8Y5HNmaio29512MYjRa//woiZaYfxotiEFiPgF+8MMeyXhCeXyu/eB+7SOp0ucxz ycVR4IaJ4+a8OLDL8+bDwLEDezHeXzHy2/tXH+z75dT9G/+e+8pT4PusGiWk0kzdw2KTQ5kKXijh QfSTdjVNt2+7mqC7vjBS5qLP11peqlyUfCq+yFqfr1TPJ0HJcfLXTRjbefBb8ZWrxlep1vnZt3xK 5ghnBwJWG+Y2K4YJr9oshaewHLz7erdB1Ged6+9YPPfS/3wuzcnZNhFkts3EJDRPEP9MGCsiU3pC gnJYpPhCmjNfuHUufWM0Xs7j1QuWX+FoG6mkIFz2sbZUtltnvniigDMFR/lgncW+9WumP/OvrGMZ SEX1mXo9nfIh6soPfqhQtxHOWj3/9kdSl8wVKmXs2jHtyTsue+crMXmw6UnVly1aCN7Glq90/OA+ qRjMZulHb8IjJjm9Rn1fudl5s4c+imU4eLePcy2sKyxkNK8IaqzBA2H+GJSY1Pnf/8Fzi8wRRli1 5UW4rd6mE54ncfiGCFLWo0zlJOB9xppW2DMcfx6+xKVaOmWxlKVR8WVBbC1O8kOBoLoXCpyg6hyA SVO2pLQZyoZRKEoOgi555UMsHMYRyZgSi+Jr5CjxQed/uo24mKfB+9b9lY+w9wVHpHUY9CoeGq1i nfpg6Tf8gGJVHQ61bNKnvzU+RTvlkPmGhe3fsHb3mmUnDh1IuqD91f8dL2VaxzhkLfiaPkFZLwYh n9RHZl+QoFoiDme47J2vZwy+D0uA8b07bOES6fytR5mbrUV71Vggp1RikszFRjiHAETYPHU81laD wK9c+4JbzDqw5OXX+67Fa0UcHCRFYUC0/ckgG1H3kiu3LzYddpMeuglLikCkLp4Dpr98m1jrrWYO oLYTw6D4VrGSpuRr7JMas6RMK9Hw8usgyuScPIklb7gVoX///GXnIcOxGwPId3rmDWsSr2glDv62 F0qZkLJDKEnVI4KUOGj4VJEpvnJcoPoTSoiGT9mbsl+l5JD2lud9o1Jp+AUcdjJebPmK8Jpd9dFP Yqk5UDh+cD9C0THh9/j+vTFlysnIXhHIYsn7r2B5nVcCi68cLE/DSsM5Lz3R+7OJeBBCQaJLlca2 JmxownpsbMzp9vIH4gWCvmq8glQjx2YqUx+/rer5F931R8rDG07gt2qLC6cMvNVnRSjKS5gcJV+P g08FPI9wdHdameq1hFgchO+5fBYYaggobJjbbN4w4VWbpfpAYQl4vsWrpttnrq/asi021+jNw9I2 a+Fdt4hM6SlF2fo6n3wZQRBYylGpUf7WDFsQbt33sc60eg5eGJSvXf/H/j1GNS+Hdf51uvWCywlJ qD5Tr6czr91/Lfupfw9sscTzxvvNSkvn1G+P3tKi//1Ym+NMAo5f9aWUcKaY8NbFlqsoc8fTO/bJ zhrysOQA2LaPDcW6tof+zsBT6MGUjeKxSkbwlqDGGhi2xc5rI5rMF9t7sX8ct4JA3wWaqkeZykng OF3BhK9W1rszmr8cqqVTFktZGhVf6KNpcf4qHNT4tm6HAieoOvhr0hpbUtoMZcMaOSgvmp6t1JQc WzR5C1evtY1IPkWgb/ysSwPhWMHGuvSd260xnfrAA4UtJn//8DkcaniTITw41iRK2imHyhfLYzP2 7Jw19FG8qfq4ddX1v34vBVrKVUt65DV9grJeKPmUPjJ3G6FpiUkt22KVBo76wYODTOVvPYqEzhbt VWOJq5Bg7T+lnoJwDgEnc3OxM7dej6sRAb9YbAGOTHXuzf/Cyaf4lRwQ4k2Y9dcaaqXxlmXv36uw yxLrB7EsEZL3rlsFpr98q0wbrZkDKO0EySm+TbK4peRr7FM5ZimFg5nQ5Fx8JArHMaWtWIT3SXhw FjEzdqbiDZOgZQOhhATGV+Lgb3uhsg4pO4SSVD0iSImDhi+91VTZrXzNuKDsT5DWL/mIT9mbNBsQ sl+16malKXtDv2qN5p5WO+xE+vCoKNHLVG52fuqi2VLotoWzwJG3XhE4u71x75vFWc5eySyOcrAU 4rtrO+zbsBYLd/H2WxShUpNz7WU5ae4+0FeNV5D6lCNNBWu/cW4dDnowz7CrVqv9Uy9vnf+7XfOC 98ryUuWi5FPxC2ZVdHdYWHckdavID51a0WXMOZ0JBJQ2zG1WDBNetVkKT1nh8EFgwQUWEyXP+k0y lcTptpm6Fa9bRRxKT5sE2de55MtopZNqoleXtzbCfR9rS+jzFs6Ujk+/jj1cD68/PmDqX9lHM2rl fbGU6jP1ejqzm/jgDfiaOeTjYcP6bXfsHUChrPMk0Nbk7uvLmuqM05t//6VGu65WNVrd8/jBrZvA tzJBh0VEVG563sXPvyMOorWFenVLjTVYynHazndsLVW5qj5Hqh71qYIRSrV0ymIpS6PiC519trhg FC1gmbLbocAJWLJfCdUmjfUCedNRKcpfW6Js2IccxzoFSo5UzEZg2ZS1jchQPO1LB7R18SxcM+ji pFfl0c05MolJOPQBD36Zv779BOtb63brha64QHzqxiGHyles1L5l0vIH/jp88dB3Zg45vS39dLlS t2I5ucjK3z6Bkk/pQxVI0xKx+g+H+mMJHg6lksn9rUeR0NmivWosNTt2t65QlnpKwjYEwB+HZZU4 qRZD3uiOdUGDIyPX7twTJlS706WS4xeBcbNC/cbrJ5rruOGKAlGhfhMw/eVrMvV3DqARpQyi5Ptr n0rhgtnwiuuwqGXjpB8aXJG/vA78+KrVD23bIiJgq7g9uaMfs0cI9N5He3Gdb0jZIcCg6jEAnGSn 6kxr9sanTpoWoZpxQdmfIJVGvtlvFxy/nDpIjrJflaE2grI39Ku2mC5vCzjscHxpypwp6DoxVu1c uRjvLcWhmDhuc96rg1IXz8UZq1h8O/+1p8+7zdwb6+GFPZ5oWm0fe95DmcVR1Lqfv8LZsTiM4JrP JsZVTJBFQEVMffJ2bGjCtiZ8+QgLyMXZcJqq0UAqHqKkcD2hlEOZCpbU/fHms3BR4aU9fkFXPa+N lO/MlyovVS5KPhVfZO3MV6rkF0HJcfIbX91v7qv/h+/k4pWR2LzsV0YcuRghQNkwt1kxTHjVZik8 f7ylOz7HhiUMOOH1wJb1aHf6PgemhThYmIDmCQK7loSxUXpSfR3FF9KcfUKrOx+b9n93YeKO4RV6 og+XRu5XHytTKQlnvr/8q48YOHDAH864wKG5WP+FtFSfqdETqZzyURx8OA/PovjchPUgMzlDEgTS gsCvvr4QITQvWBf88tgDgu8Dtnv8BauSeFK65KUPcLi7YP5wU1c8KgANJDm8bcu8157G9gprfG9p aqzBVmhh5zB1jEENL79Wny9Vj/pUwQilWjplsZSlUfGhs7LFBaMsAcukuhcKnIAzcpNQb9J454H1 RFjyI0X5a0uUDXslRypmI5rkzdPQQEQbkaFwMGF3EY7AxyRWft4aofC+oQ9HP4B5OHryCXebS6j0 FwYjPHDitHi5L08fXxlK5fvTgEvxdgrPZdAH2lpX/lrHOMArxPrbJ1DyKX2UyoNJtUQMwYD30jc/ 6/HmaBDyixyUPVDywVe2aK8aS7uBL6z4fCQ6f3hvATWejv93+xVWZWxDACYk+DaR7JdA4/Pi1viF pPGECIvCAhd8qXbBf57DrRDoL1+kco7p+jmAv8q7l++vfVL6gy+OscNALA+wA7NpnwE4Zgqnq8PS 5r/+jK0gzn7MFsF26yyXLYK81bcX9/mGmh16aycSLhuBt55rfxjjZnyh+hObQNute/yRUNmvCoFO e6DsDf2qTQeXtwW+7YCPTy8cPnTP3yuxPKpcnQbn9vsX+jsIgq8ae6enPnUHnItYB4jep0HPPi4z cBkNnTXExpQt7zL+2RpNfCYJb4rwJ8t4/6oDza697cShg7/865rD21PwFgI10u6JYYigqRqvIFXK oUzl8ve+RT/4Xd/2x/btiatUGa+SLh85VhbESVDlpcpFyafiO3OUHLQuQQtCPEzK0EISbR7+N56R vurZIjc3p82Dg61nWBRSMicPNQQoG+Y2K4YJr9oshWfbR59f+vGb2NAK/wjW4WPbUaePftIbSbUL O37Z4xycGt7oqhvx6W0RmdKT6usoPpX1+Xc8guNf8fFofNMttmwF69spv/pYyPer72rapz9OzDm0 dRPcalhbh4+0Yv8RhFB9pkZPZdEu/c8Y6D/x/usAfof/e0WeCaiMDKamvvwqFyU/GPvcVxkAAC8l SURBVHwohi0S+L5EzfaXXD9uDl6Y23KBRdXq2B1LacBHh7/8s3d+H3Q3Hu2whAcra3BOky2+h7fU WIPJ/exhAzEGIa/6l/YWXlpNvlQ9Fn2lUC2dsliqUJr4yhZHyTkjfKp7ocCBksGrKb1J4zSoGf9+ IH1XKnbkiHkUZUsUkpQNeyWHzPeR53D4TF4bOdnmoWflPA2Hl08bdDe+EYQNdDirTpw/AyE4oxO/ 4++8Eu74ig2bIQkl2crHpycwG0T/YGX6RVP54uvb+GIMXslg3x/2gl35Yd65XXmiq13QHmNcWHhE oytvALwiO3/7BEo+pQ9VKKol4gVPsxvuwMcZkLDZdbfNfO7BXqPMozYpe6Dkg69s0ZrGohHlDMKm 3eu/m42HsiWjXsORCOXrNJSQysjWIQAH2OEwBBmEb/Jg+QvWuUuOk5CNVwZpHknqdL1i+rP3mYs2 Tp7EyfK4Fan85cu8bIS/cwBbcp+3lHx/7VOTEbw8WJWMCAlNzBFQXBc++My8V//v616tcIsJmM2L 6uzHTqUr7P/69uI+31CzQ6oeC4tXwfQXvzByyuO3YoiBtevHF6o/KSjPfucef6RU9qt2iafuKXtD v3oqin//h2k6Bf8kcWxGgBFgBBgBRoARYAQYAUaAEWAEihUCcJoE44EI7zDwzUTrFyGCjUqQChJs tVk+I1BkCOAAsu+v63jnvPwdskWWL2dUfBEoTL9qs7dhldIFDkuXLo2NjY2Pj8dvXFxcTExMdHR0 VFRUZGSk+D5sTk5OVt71z4b1BbbEFl8cWXNGgBFgBBgBRoARYAQYAUaAEWAEQgEBLLNd/fVH4gSb UNCHdWAESjIC+AAUtjicOHxw4Yih9S+9piRDwWUvAgS8tTd22BVBlXEWjAAjwAgwAowAI8AIMAKM ACNQUhAY2SgWh5rLU+RKSrG5nIxASCKAY5p+6NdtzMUNc7Oz2z3xYkjqyEqdPQh4a29BWQF+9oDN JWEEGAFGgBFgBBgBRoARYAQYAUaAEWAEGAFGgBFgBAJFwN8tsZmZmes3bogcXjvQDDkdI8AIMAKM ACPACDACjAAjwAgwAowAI8AIMAKMACPACNAIpOcfYYcPaZxELPzaCMHMD8r/QKYROWktLZJDGAFG gBFgBBgBRoARYAQYAUaAEWAEGAFGgBFgBBgBRiBQBDrXyk8pXHX4zc3NxfclxC1oEPjoBH4Nk4RT LxcJ+Ay7QPHmdIwAI8AIMAKMACPACDACjAAjwAgwAowAI8AIMAKMgGsETIdcwQsOO+GzgwsPYk7m huWa/jp22LnGtCRErFza6N7IuKJZSSirN2VkrLzBkaUEigC3WYGc5zhw0w7UJDndmUQgSHYbJLFn EinOO8QQCLaNBVt+6MDpb0mp+OCLP6+KVj/BuPDU0hKvZJ4Fcij8qaJR8QOoL1QHKoUvRoAROCMI YBkd8pX+uuzsbEHDVSe8ddm5OWEns4zsLESLPCMqcqahiUCjysbyVGNfRmhqx1oxAoyAHQFuswIR xsFuGXzPCHiHAJ+d4h2WLEmNQLBtLNjy1aUqzlyBGOUe8rdkEeFG3UrGgi3+puP4bhEIoL7W7jTa 1TWS9xs5eUt43ObE8RgBRsALBOChi46Ohm8Ofjr8hoeHg4PfiIgILLKDOy/PhReelWs66wo47Jz9 shzhZJDkeKFqvgwpXMrMyjGm/SPvShCREG/UqWhUKGWEhxnHsoy0w8bmffk9aaloo2Flo1K8ERNh ZGQa/+w2dh0xkalVwahXyYiLMuNv2mtsO2gyA4M0PsY4cNRMLi9KjpMvDCM6wmiUaCSWNqIjjcxs Y3e6sX63kWku6lRfmvIqy6WRr4yvzjWPq8QTyNeuYCSUNiIc+GtEOYMoPSncKL5Tsp7jlCOakpMv G7IMkhxNFphyoX6rljFiIk17wzCfsj8/ur/4a3LRBMHOO9Q1rUtoq6kvv8qlydFnkMaGlTYGgUqs pMIyRzfdYIlqsxIip606cZAwMsEIUAhIixIRrHaFrgYDLlZuojPHgLtxr7HjkDmwHj5uzNucL69j PaNsrNkXSTk5J43jWUbqIWPzXpw9QmVr8qnOQZemxIRR4Ch7TomKbXQAXxlfVpZM6KanlZGLjPAL BM3QXHiFBWLCtvFCF/NMjP4BX5BmbWgBy6ESBlu+M19njk6OM1VJ42DeeOiY2ZfKCyiJy323KdM6 CcbciYlPDqoDlYKqwZjFFyPACBQ9AuZSupwc4aeDqw40vgkLNUDnefGyTpw4kZ1tOtQLOOxwT42j gi+7V2+LZMsUa3T3nPqChrcZhb40PCHA47Zmp3E824iNNB8YWlY3/txmTu7b1jGdIxv2mM8DeDpt XNl02FUtazRIMFakmk8R5eKM86oZmHruPGKvR5eQRobbnzE0VWMLEti2rGGknzD+SDa9dfCq1K9k gLMohQSeKi9VLko+FZ/KmMKzSaKRcsBYt8s4kWPiXy8hH39KDsWn9ER8JW4aPpWFkm8Tbq13W5BM Lvgum3azqubj6+IUc74eH200rWpk55gjvb/4y9z9IrB2GMBu2mc0rZKfTlNffpXLLzVskSkbpmyM wspWQda6s+VovS05bRal1tSpEwcrSkwzAkoEpEXZWh9cPxhwk/eZA+6JbHNsbZhgOuxwwdJwi4cc /IKWl5CANz1lYs0OCv0kFi9QF9U5UPFLFJ8Ch+o5BTjO0YGKb6trlz1tEVeBvyBQQ7NXagM0vEWO jTKqlDHa1TEndVbPi1e5sJyzGIHEMuYSBNvlV7dpS8u3niCASkHVsMPOEzBZCCPgFwJYQ5eRkQHH XN6xdeYPHHZRUVHw30VGRooNs2FhEeKjE3aHnV85BSMyFmdhrgynScm8FiSfLjd8IpjxX9LY5GDD 15Z95p+4jhw3vXi4sBwM3qX9ecvi8OZz3W6jdkXTYWe9nJAK74x12ir9Nc4gKcopRwZJonycsXSb kecLNh2L6/cY3RrKwPxlCNZ8FySfDrWWlyoXJZ+KL6Q7C0XhadMHywMvaXRaQ6cchOEdPhad4Uo7 ZPy9K9/jSel5WpY/lDLfpLLmykq4buGixVPl9ryVlVapburLGt9JO/PFZH3uJvMJFteRE8aqVNOD hpFeg79GT6d8iK1WzvRToxPAYs9VOwq8yW+caDqC0Qqkw25BMlLkX7AfW32dCgnu/wuST8u32jBl YxqspCBn3TmxEhwkcQZp5MggSeht1Sl8QbJMataO7KOoclHyqfhCujPf07kWpPQ4UHKcfDyOwq5g rkaYuYSEr5KMALp0vB7bcmr5MPqixVvz8cAbtVrljdXHzJ4fNDol64WlIgePmSdLYCEwmkbn+sbq tPx161gOfG6SMWeTGZ3qHKyiXNKU3WLJFewZSydwYUqAsUlseoLl4wkN64KxPhptE39Yrb81b8al 7Htl+7IO3JAJ/rLtZvHRV2MsWL3DfGvoyUWBo+8xnKODPr5Q1dnTelKEwgvxFwRqaC68JlICVowe zTTHX7ylQwNZvh09pXkAVo0KRlS4uZ3ir7R8G8OyU1SH8GjDNtCd7szz1EhbkoQwKtutzFFjY3pb tQm03Ur5mjbiiW1r9EcQpu51KhpREeY8WcztKTyhsLK84FPzK3irlW2TkqOcx0qgbIRGT1tM6y3s AV2N8rJ1m1S9IK0SN1m/krB1VrZMEc0aQd6CoOodQWdrfWF0w7IPvhgBRqDoEcDqObGqLisrC9tg QcNJJ4+xA5G3KzYzM8ucXdkddnBP4M0wlhfBJYQ5nNh0WWRlwDvSJlXMmaX5EVu+DPO9x/68E+Ww ExZeOcz+8d4Vi+/gG9q4x8Agh4nRPssmVkQ+p2oB4FxCKqdN1mHMKsgpR2kqeDDATA7beOHTwa5J eJRs3kOrTCcty0uVi5JPxXdmITgUnjI+yovnEKwQ9HmiH/ZMwYeFq3mS0aCy6TPCRemJICVuGr4p znFhnlezgjk/xjMS9MTJIDaHncv6cgj2xXA0TCwnwUXh71NPZ354wvxzq2nkSAtIl5x6TgbO1cqe 3oxmS+i+vmwJPb+VNkzZGIWV1MRZdzLISpS0Nmstu5X2iYM1soaGmxjrR+ZuNp9CYXh8lWQE4M/a QDxboqfFQIxnbPRU8L7hqdh5wYTElXbYjIYnIlx4hMatuKjOIT/Yn/8ou4XHB0Mw7BnXudXMtyB4 4BQXpnbw1mGdFNZKw4t3fo18h52y75XtKz+x5T90yJCAIy8w0GPisSDZElYIkgJH03MqRwdNfKGd y562EEUJPKnfIBBDc+Aa0CnhmxMvKetUMg9pWZRsvqOFdxjMv/NWlV5Q03TNwPeBmTzcNOY8MM/y pS0JQuYg+ZIjCcrG9LbqUr6mjVD5SsVcEho56GSwUBEvXNEAt+S9jKfwRF7K8mrmV1S+SjmQr5zH UmXU6EklAR/dkXjXS8WR3aamXpDWiZu0H1u9Uxlp+BRuynw1OChxDs36wmQ7JkoDCQcxAoxAsBCA k+7YsWNCutwMKxbcwXmHBXegc7JyDx48EBmLXYuWS3Z2eOeD965NEo3SMUW61gBvRLFko8Tuh7VU hUni1VmzKvmTYFQUHAF4pYltCHiqxNwInk3snI2MMMd7XJgu4xZTZ3CslxJSWdHWmHraJkdKsJnK mjTjotqnV9Vh35B1P6xMpczLWl6qXJR8Kr7IyJkvhaeIj5dp4sL23oXJ+TT+c8oBE09BYhYCAptr hMOO0lNKsOFG8UXeMlSqgoEfizgALy4oidUNtstlfdlS2W6d+cIRCUvDQk4sn4TvGHaILWC4KPz1 ejrlQxRm+eLCI6V874ftyS2qmfavPA+Rqq98QUX4n9WGKRujsJJq2upO8JVYySRKwiZHSrDZHmWr bvK1lpcqFyWfiu8mX2V5lUxZaluok59UzliSkt+W8dII/S1fJRYBvLbEY4zyQm+Ptzitapq/zudP uSVWeCjw27qW+Q4SV1KZ068fqM5BmaOeSdkt/IPwpgkN4Ua5sPZphx0ciMK9g7eAINC7ikvZ92py X7vLHAhw4RUdnDJeXRQ4VI9BjQ5UfKmnrYeU/FAg/AWBGpqDURaMwmgguLAsC2/UMGnHhVkBVpUK hx2MCs8OsA3MVw8eNZZaXiqbUf25KBvz11aVeWraCJWvUo6GqZGDF65H86BDOxUXhSdCleXVzK+o fJVyIF85j81Xy/GfRk9HXFcMW7epqReIc+LmKg93kSjclPlqcFDifNbUlzssORYjwAj4QAC7Xw8c OJD3ZYmT4kMT0luHlMKFdyT9aGysuTTm1EytoEz4gOA1w1jbvm7ROezwGInn8wXJBVUpkXfmi99E 02G3ZFv+QSF4Df7XjvxHCOxKwIiF467hocPeBOCGSTloXJhFgSMvryDVyLGZynnVzQ1BGKugkrnC LsEAB5tk9ZezvFS5KPlUfCpfCk8RHw/zUKkUVtglmGtt5NCrlCZmqwgCId9TUXpKCTbcfPJlBEFg VR38dNTlvr4oCRQfT55YqdGmtvmMBzvErjGsYsBF4a/X05lLOWylqWLgF0WwXsATq0LE1m8rX9B+ 1ZczuSccpw1TNkZhJdTQ1J1femrk2GzPp60q83WWlyoXJZ+Kr8yuCJgwaWtbLoIcOYuQRQAuCbOL I07Wx05YvJtZvKeA+uK1gTg9HafdiV3V2A+IjYR4/YkLq5BwKy6qc8gP9uc/ym4x/lrtGdHkJb+G IQi0ZVxU3ytTOQnhrQMfxcEuNq8uChyqx6BGByq+0FPTQ3pVkMLI8RcEamgujA5UWswzMYjgwsvj ixucjiUX+WGNPFb941g9HNmBguCdTdqptaWnY7ujlDYWgK0qc9O0EWW+SiFgyoLLCJKjkePsXig8 qfJq5lfKfCk5UNvaV8h5rCyOjaD0tEWz3eKhAL2Q7ehDZbepqRfIdOJmy6gwt0rchEBnvhQOFM6h WV+oFPFepzC4cVpGgBEIAAGsoUtMTNy+fTs+NIHtsaVLl4bbDl48iMIt9sli/V1ERFizpo23pW63 TOIcWWE1u1yi7Aj0noFV0KmH7b2599mEvEQsXGpZ3VxJhE/RyfVE2KFsu0TVYEdkxVKnJ0MV4wuc I+MVpD7lSFPBYvUZG/Inc5gBYLmZ9Qw7WxHErbK8VLko+VR8ZY5gUnjK+CgRJhaYBHdrJHlqAmOw mIKAOHHqAY/S0yZC4uaSL6MdyzbfYIsVdpIpCff1JZO4JDD5xptY/IkLqyrElmEKf72ezkzNb0rs NVfS4XkAD1Q98g5wRDTsu8EffIXywjzPukjKfX1JCR4SShumbIzCSujjs+5cqu1TjrQ9l7ZqzVdZ XqpclHwqvjWjoqQxU7e25aLMmvMKNQT2Zpg7WLFwTHnhdaa18xFxnBzBh6sCojBeYw2UvKjOQUZw T1B2i2cwqz37fCSj+l73mngVkwKH6jGo0YGKL/T02UN6VZzA5PgLAjU0B5a7PhUO/hMnsRzLNF+x C+edNYlc9Q9fMF48n5N0eo5qjRYw7ZWt+ttGKIXhGkZJMaSKC8dKghPAReFJlder+RVULdBXnJrH iiLgJQRKJL38YFJ66ouM+SrO8bQ57JTdplf1QumDEuEFA5oMLjjdAr4oHIpXfaFSqEeJgJHhhIwA I+AGAayna9WqFRbQrV279tChQ/Hx8TExMWAiLVx4+B4F3HmtW7dOSEiAw67AW1G8NMZBBvjwGfoy vBM+v7p5pnLRXPA+YFKLc9lK+FW9nLmtAEeEYKOB9NYBE1REi+qmjwYDJ56WsexLzP7xdQ7sjYXP DlWGX6zLw6IncWkghbNDvNdyg7ZSDmUqh46b55hg7Mf0Bb+gseBOXs58qfJS5aLkU/FF1s58KTyx nxeHN8NVBJzxFVRgax3JnHIgH3HwPhB/IOSHlig9KdwoPqU/Pl/YIsmoEGfWO/S0HrnlV33JqlES zvLibBpphFh+iLfo+N4FLgp/jZ5I5ZSP4uAATUykYDzW0xgxq7P+Ia2Y5+nry9Qs+Bdlw5SNUVhB U2XdiRI4sdKUTCmHsjHKVql8qfJS5aLkU/GpfDXl1QRRuDn5Ow4XaMsamRx01iOAbg3bl+pWNB/n MBZgOoTmE9iFXbHwWWB6Y11kRHUOAWRB2S3ytY5NYouuRj7V92qSBCmIAofqMaxDgxgXxC8VH2or e8ggFScwsf6CQA3NgeWuTCUmn2gUeHMmjv7YdsA8HhEzUgRhNtK6Zn46rMHHowQsCnzsdrR59OBi xoEDhVkNoLdV9/L9bSNKWMDEa0vMvcW8F1NBnGspXmRS8Sk+hSdVXv38ypkLJQcxrX2FnMcKCfAd 1yhfoL4oPZ05Wjm7j5g9oZsrsHpxX+9w5cOMgQaqDOcOBXxROFA4h2Z9oVJQNXwxAoxA0SOA9XRw zzVr1qxt27YVK1aEk2737t0pKSn79u1DUIsWLXr27Fm9ev7IWmCFHaYIGIlxirxYroLOCH/iwuON lRDzoXyWF//hMCxMkW3juheCi5kMbO7AhVqwLiaa9o/5SQE4UjEfwgCDt0+Y+uPQa1wY2LA9Acd7 gY8VbcBQvsb3ClKlHMpUsDYKk5V2dU2t4HDcm26sSDX1pC6qvFS5KPlUfCpfCk8AiFVj0AoORwz/ +OiKz/284mMgaDJ4cJIfl6T0pHCj+JT+ON8N8DZLMkpHm60GasvLr/pCKr+aNmZyeDDAZmG41TAl XZBsbozFReGv0dNM5rhW7jDnT6VqmODj1Gp80Ux/aerLr3Lpc9GHUjZM2RiFFXJR1p0+d2WoUg5l Y5StKiWDSZWXKhcln4pP5Qt+UOsUr4uAW6d6+V+JheOer7MeAcqi0K0tTDFHYZzqgLEMq0I2Bvrh YDwcisUp1jVTVOcQAOCU3WKGgD2JneqbIjGQiQmDRj7V91IQaUQVMogCx98eQxNf2UMWUm1vk/sL AjU0e6UVzABmjHEZi08XJOfvoMT4jgvzUvjsxNdgRXb4hALe510QZ757M89IKXgoCk67a17ViKlp +oDEo4S/NkbZqsjdvXx/24iQ7/zF5+zRV7Stk/9dBRgeOAFcFJ5UeT2cXynnsaIIOG/nvGr5b4VF fVF66ouMZ5OmVU1fueY4FyEhsHpx1julD/Zow9GMb8ThoQnzTLxNCeyicChG9YXqwGdh9Mf+BAYO p2IEGAGfCGBLrNgAW7t2bSyvS09Pj46OjouLAxNL7bDyLjLSdNPhW7Hm78Q1p5Zx+xTMERgBRoAR YAQYAUaAEWAEGAFGgBFgBBgB1wjAjYudQNg/xFeIIICV4/DVyqUGIaIVq8EInN0IdK6VLgo4a9as 7t27C38cPguL1XagcaQdfHZYYYdfuO3Ax1cpVqxaWWCF3dkNEJeOEWAEGAFGgBFgBBgBRoARYAQY AUagKBGAY2hTUebHeflCgJ2nvhDicEYgiAjAKwcPnTi0TmYj/HeCaQ1ih52EiAlGgBFgBBgBRoAR YAQYAUaAEWAEGAFGgBFgBBgBRiAoCAhvndNDJ5baiV+ZcYGPTkguE4wAI8AIMAKMACPACDACjAAj wAgwAowAI8AIMAKMACPgFQLiiDo45nBBJjx32P2KPbC4xOI7a0a8ws6KBtOMACPACDACjAAjwAgw AowAI8AIMAKMACPACDACjEBwERg7duy4ceOQx7Fjx4S3rlevXvfddx84Ygle5LT44GrA0hkBRoAR YAQYAUaAEWAEGAFGgBFgBBgBRoARYAQYgZKJQGdVsXv37j1jxoy9e/eKwNKlS99www1w1QlvHZi8 JVYFG/MYAUaAEWAEGAFGgBFgBBgBRoARYAQYAUaAEWAEGIHgIIBvwvbr10946LBDFjR8dtas2GFn RaOk0ylzpnx8QZURdcJKOhCuy89YuYaKIwYFAW6zAlbPceCmHRR7ZaGMgJ8IBKklBkmsn4Xj6AoE vKoar+QoVCyeLAakeNabXWvUo/izBZzZ+vV8DmYrHd8yAmc3AnDVde3atVGjRihm3bp1O3bsiI2x 8mw7MNlhd3YbgH+l++M/z13+7jePJZtnH/LFCDACoY8At1lRR4xD6Nsqa8gIhA4CPM8JnbpgTRgB RsA9Aui7QrD74jmY+xrkmIyAREAsqcMvfHP41sTdd9+NoP79+0dFRYEjDrMTbrsCH51wuudFp7B1 3u8rxrybunhuTlZm2eq1G1910wX/ejIyrpTMr5DEsf17/njr31tmTjq2b09cpcp1u17R/smX4ipW LqTY4phcA/WhlE0L331x2/zpR/fuLl+3YYenXq5/6TUo4+pvPlr68VuHt6eUrVG79X2Dmt9kVraz KmPKVbh/5X49Jgc2rqvWppM1DiXHyRem4m9VasqrLJdGvjK+tSw2WonnjiXzVn45auu8adnHj5WB qV95Y6t7nogq5fdBj5SeFG4U36azz1unHFHvTr4c72WQ5GhyycpIx6i8cfJPR/fsLFOjdss7Hj3v 1gdFfH/x1+SiCTqcmvLt1W2O7tsttNXUl1/l0uToM0hjw0obg0AlVlJhmSO3WQmFICRETlt19l22 tHzLCASGgLC6yNi40kk1arW/pPX9g8rWqANR4Dfvd0/3Vz+WYsGBZWafOL589Ih1//v68PZkfOmr etsuLW9/pGaHS2Q0bwnZKKRY2TpkkOQgDjU2IUgZX9PHyhyZCAYCyupARsrhA3wqfuF105s08rUa WOGzK8kSqMqlMFFWumTKVPoK8raNr/nu02mD7u7x+ifn3HiXVACEV3yrzKKhNXhSc7yiUeyM5EK1 92DPwah8zwgInCkj4BUCcg0dfHaQ2bBhQ3xoQqyzQ1Bubi68eCKvAg47sJTd+oLhz8MN1PXF9+IT k9J3pi56d9ikh2+6+pMJXqk76eF+FRs0vfGnP0olVDm6d9efH74BzrVf/+6V/GIkh4L6YPLGcTd2 Of+2h9o+MgSPDQc2/wMXJxx2Gyb9sHjkyz1HfJnYvNXu1UsnDxwQW6FSg559bPX4862XwQ3qE4fM jCMRUdHWaBo5tiCRyt+qpMpLlYuST8W3lsVKU3jOe+OZFrfc12nwm6USEtN37VhqmuJNvT/9xZrW DU3pibRK3DR8N9nJODbh1nq3BdmSOGckMoKVmD1sIJxlaJulq9U8lLwRt9GlyzbtO8Bf/K0y3dO5 2dm/PXRT6weenjPscZFKU1+ivC7L5V4HZ0zKhikbo7CyVZC17pyZSk7JabMosqZOnThIiJhgBAqJ AAwvJ/PEkR3bNv8+Ydz1nft+Pa1CvcaQmTJrctqyBUmt2lnlTxk4ICouvteoceVq1ctKP5L657wl H7wWPIcdsrZ1HVIZZXvxOTbZ+kxNHyszYiIYCCirjxo+oIAyvieKFb1Je6J2sROiqVyqLFSlCz6V ysb3to1vmjYejxubfp9gc9h5xbcpXzS3SjypOV7RqBRqufAcLNRqhPUpXgjAPSd8dq1bt4afDrc5 OTlYYSdL4WpL7I0/zj/n+jvKVKsVHhmFd8tdhgzHohIpovDEzuULsaSuTFJNeIvw2/6JYTtXLCq8 2OIogYJ6wdtDWt39+IUPPFOudv2I6JiEJi2Ew3TVl6M6Dn6jxkVdouPL1Gh7ccdBr638/D1bwbfM mHhkx9YWAx6QfMzIbZNyyZGEjCwJpxwZJAl9VTqFU+WlykXJp+ILxZz5UnjeMG5uk2tuKV21umnq 1WvDLLdZTN0pB/JXf/PxR60qf9QqceaQh/AiWuRI6SmB8otQ5rv+1+/G9m4z6pyyozvUWfP9aKdA N/XlTGXlOPPdNHX8Ja98hAWekTGxlRo3v/StMavHmgtMNPhr9HTKh6h1478Z07XRyEaxP/brhiUq Vn3mvzk4tmJCq7sGSqa+vmS0oBKUDVM2psFK6umsOydWkiMJmVwSTjkySBJ6W3UKp8pLlYuST8UX ijnzlQrbCBlTEtYISiYiOPlovDOffxiHeKI5L/vkbasQphkBDLvl6zTAKHzRo0MWvP28AARzoemD 78OLBCs+aHTgV6zfBPMZvD+r36N336+mWSOcWZpqj5RWRd/HUi0x62gG0EYLxd+MZ+/PPnZU6Iy2 POmhGz84r+LCEUPxnuODFhVWff2hCFKOJqLt49dWZHA2/vbj510bv9c47purWu9Zu8IWIRRu9d1m kDSkTFogiUydkFLIKxGmahySlXJEjthZ8mm7Wu81jZfdtUaOEhlL/ESsipUmIQmRSt7i+Wnxey+P 7lQPNjbliduw4UCKRRynPt9ceUHK3KkiDvL6sGUC3nfKJE6CqtzJj/WH5Yv40wffixfzzrQuOcr5 qodtHK1y+8LZWN6xfcEs2UKhm1d8qpjKeSYqRWlvFJ8STvGpOR7kUz2SUhT2rs1+8bG8uQfs8B0k F9F2r1n+v9suh9mMbBiDHgllUSa3MpX1a41gpb/o3ixt6R+CA+KLHucImtIHigndBCH1tPGtWShp xFfWC9W+bPJlvkrhzGQEihEC2XmzR/jmcImVdFlZWVYmbnOycuG5Q6HsDrv/tqn2boPoT9rWwLxn 8zT1GrrN03+Fb8hDROr37LNw+PPpadtzs7Pwi1lXg8v6eii/+IqSUG/7YwY2Zn55aXM4MjBdmP/G YOzZRLnQocNbJwtYs11X2ywTzxJzX36y83Nvh0faV1PKVCDw+ki8QZKENRS0U47SVApZlbK8VLko +VR8WynkLYWnjIDyHtq6ee5rg2q27yaZSmLLzIn9J6/qP2XVkbRti0e+JOJQeiJUiZuGr8x0xZiR i0a+1OW54fcsSbvmi8k7Tg26MrLL+pLxXRJis7018r51q3FL4e9TT6soQWO/be/Rv2L7dq1OPeQk FUHJsyevn/Btz7fGOJOA476+lMk9ZEobpmyMwkrq4Kw7GWQlZFOVhDUUtFOO0vY0tmoTqLyV5aXK Rcmn4itz0TBl8SWhiawJWvzuMLzYuGXyyv6/rdy2YKYmJgeVZATqdb9q+8JZAoEGl19bplpNPOpb AanepvPUp+7cvmi2GKOtQUGile2ayotqj1R8yS+yPpZqiZglZuxJQwu95bcVGG0XvvOC1O3cm+/t /cmEhSNewGkt14yZ9OcHr4sg5Wii6Sj++eXbPl9NvXf53vrdr57xXP5pDzKXUCC86jb9Kgtl0hJJ QeBXilUij1AlwlSNIz4lB0Fb50679pvpd81PxtxA5KuRIyLYfjFhy+/zJ6/cOn+6LdR5u2z0CAwN 142dcefczeERkTgexBrHqQ+2zP819r8izpbpvyadf1GpSonWJDaaqtxuL5nntGyc8jPQwGoJ3NoS Om+pPkE5X5XJC9/GU+ZNq3LehWVr1q3SojVoKdkrvhRoJTTzTKW9IS3Ft4q10ko8qTkeElI9klWm pJe8/+rBLRtunrhswNTVcnBB6K/39m3Sd8Bd85Lv/+vQxUNGrP3pC5mEIvT1a0vVsNf1WNQpmOsn jmvU63pBU/pQ7d3Gt+WivFXiT7Uvm3xrP6MUzkxGoLggIFx14gA7rKqDY+7w4cO4BQG3HULxmw32 SfOtcAEnjmwGxw/u37ly8bxXB+1d/1ebBwdbS75h4rg5Lw68/oe5VmYhabyN+al/j+Wjawo56O5L 5n5YG4xWqI8d2Ivx/oqR35ar0wA+zbmvPIU/4JaZfhjv8JEQy7twi/VHJ44csspZ+cX72JhTp8tl VqasaCtTT9vkSAk2U9FXpUylzMtaXqpclHwqvsjImS+Fp4gvX+BglcT1406bulMO4nce/Ba2igvi 59suw6I80JSeUoINN4ov9JGh4ha/eESEMaClgIaSOC5EBgnCZX3ZUtlunfniARWPMZ2efh37srEd YN6r/5d1LAOpKPz1ejrlQ9SVH+RPIM6//RE4JYVKGbt2THvyjive/05Yu01Pqr5s0Yrg1mrDlI1R WEn1bHUn+EqsZBIlYZMjJdhsj7JVN/lay0uVi5JPxXeTr7K8SqYstS3UyV83YWzfL6bEV66KmJ2f fQv9rS0J3zICQCC2fKXjB/dJKGDe3/a+qNFVN2JzgGD2GvU9lvzMHvro/k3rsCLePPP3nic8PPNX Zi0Iacm2dm2LJm+p9igjKImi7GOplrjhtx/7fjk1v4X++z8/33Z5x6fzHXPVWncIyzvnpXqbTiBw cosohXI0URZQMPEODEMbaDj+lnyYL1wTv+iD9N1mkPQJwKQp5JUIUzWO4lByEHTJKx/CMQQCViEK rpEjIth+/5kwts/nk933+fC+XfPZRHGEZYdBr4696kKspZUynfpguwZermNVHfx0ONSySZ/+MrKS oCoXB49c9s7Xv9zdG6mu/nQC9tMok0umpk9QzldFQk/a+Oap47GmGALxizUfgsatV3xZRiuhmWcq 7Q1pKb5VrKQpPKk5HhJSPZKUaSX+/vlLvGbAzh4wOz3zxqap/8sPDQvbv2FtmaQa5es0TLqg/dX/ HW9NpaQ19euM3/Dy68bfeSXWcxgnT2LJG3QQcUh9nCIC5Sjx17evQLPidIxA6CIAxxzW0MExBxVP nDhx9OjRjIwMLLUTC+4QJOicnFxEsK+wE8WKLV8RLp6rPvpJLjUHH8vfsFZrzktP9P5sYoW65ndn vbqmPn5b1fMvuuuPlIc3nMBv1RYXThl4q1fCi6McJ9TRpUpjKyI2IWIrIjbmdHv5A/FiBAM5puko I2bh+D2+f29MmXKyyAha8v4rZndcuEsjx2YqgVWlorxEuSj5ehycpafwFDExPD+yMfP2meurtmyL DQjO5FZOmeq1xC2IjN1pgqb0lAltuPnkywiCwGvhSo3yl6/bgnDrvr6cafUcODLK167/Y/8eo5qX w5r/Ot164fEVSSj89Xo689r91zL47rG5CXPH95uVllsqfnv0lhb978d7fmcScPyqL6WEwjMVNsxt Nq8votoCZTOFr4vAJBzdnWZpy7UDE8KpznoE4K2LLVdRFhNP79gnO2vIw5IDw2772FCsAnvo7wx8 df1gykbsaJOhwSOoMcWWI9UebdFst0XZx1ItEcOrtYUimlQSG5ZxigVuBYHeGDQ1mshUTkJ468CH g1WOPs5oZ5BzRrpNf01ag7wSYarGNXJQBcJxZq0LSo41jpXGi0CrRVmDlDTmM591aYDJCf6wgTF9 53ZrNKc+8Kxht9DfP3x+4tCB1CVzpffKmspKayo3qWVbvHrHCwA8K1mT6Glnn2Ap7+n5qhBS+DaO A9Kxe7pej6shEL946QUOaK/4VGE180ylvUEOxReVi19lXjY8Nc8Ryh5JKRPMjJ2pOIFHhMoKwi08 aBl7ds4a+uhnnet/3Lrq+l+/pyRIvkwOQj6PyFAbkdDkXHxMCSdQpa1YhC1ceMAUESh9bMkLc6vE X9++CpMdp2UEQhMBuOSmTZv2559/zpkzZ/78+StWrNi2bduuXbvS0tK2511bt24FZ1uKOdaEHTly JDSLwVoxAowAI8AIMAKMACPACDACjAAjwAgwAowAI8AIMAIlEAH1CrsSCAQXmRFgBBgBRoARYAQY AUaAEWAEGAFGgBFgBBgBRoARCAUE2GEXCrXAOjACjAAjwAgwAowAI8AIMAKMACPACDACjAAjwAgw AvkIRGL3bFRUVEREBD5LEUl8SFR8qwJn48XGxuIAPBCIDAKbbxEEpvjOBYRAqvjaBX4Z44ARYPQC g84r3MQBkIHp4FcqrxT2K9MzG7nIsD2zxTwjubsxJ8b/jFTNWZxpCbQ6N43IDSw+rcJNRj6FIIJP ZbzKyI0yhY9TZNq6ycgntiivGzk+YfGZkSe5+FTDq+JAjs8SFaUybvLSx/GkOPosvA31xGBCp9Re aVK8YPGq1D5Nq8gy8qkJR1AigAqymS5XmRIov5iAVKAKMOHvQloQ+DoE/F1wneG7rggFDeL48eMu PWlwnfXo0cMvNUTkSGTTuXNnZCyrFoTQzypOMKEucsJnLBYvXvnLlD2Ll2el7I1Jz4k0YqIMHPgL f1+pSGsqphkBRoARYAQYAUaAEWAEGAFGgBFgBBgBRoARYASCgkCOYWRmGfAsZWbHh2fWLH/8yXur NW96+jNZQcn0rBZqeuzyvuIaHR2N9WriK67Hjh07cOBAYmJiq1atEAofGla8abxnAiHEFF+ZCAyw yPLly0OEyAa/SinWUNBz5q1++7Pdf/4TF1++XLte1Zo0KBcbHxkRFRYehi/J5p408oSEGyd5u60S zbOQqTabUC1ocdKWapJnBFuiezgDuoSOJih86CgTOpp4ZhPFqbHCFDwrdxEJ8mUxebOUotDF/KZ9 4S8XUlxEKbwepgRXGbmK5EMfL2T4yIKDGQF/EXDVFxZZ/+Kv9mc2PsOixJ97OiUsJY8ZVvxmWkGu JPQYJ40IIzciMjw7Ijw7MxcOuyPpmX9vPLxwXtr9rxxp12jnG8+1iI+PCbIeZ6F4+MfkBW8dLtzi F0XFCjZ8xxV7TJs1a4Zb6ShDBCUQ4Is4cLspI/hkRmK5HCIJQT69A4i27p+N7/2wZ9mOshFVYrr1 qN6hVUJEVHh4dNjJ3JM55ve7zSsGfsbwsAhXI7ZIwb8lHQHugpUW4LNJ5qVS9w5KgSWJybAoaruk gsKjkcIYiqGLUVkKr5lsLCpEfXl3VWlKAI+NRVnJbqyFeK5RymNmSUeAegwOUVyKaqZlumoKf3kh o/BasITAEDB9SEYYdmfmwgkTZkRFYJekcSIrJikpLqJU5MzfU+duCH/05VWfv9khIoIXUvmHMaAV +15B4IKTDrdYJQcpuM3MzFy7dm3ZsmVr166tkSsf5JEE0YTbTROfCopE9tiOKw6ngx7C/4fz6SAX S/7Gjx/fr18/JAYHv3v27Pll5saFqRVzK0VGxEeFlYs+kJMbH2FE50QYJ8OgCCwmPCzseJYRFWXk mAy+zn4EPPK1FZG1eKRtEVWrm1mvJ+N1EZWHs2EE/EFAjnP+JDpjcYuXtoDJhcJF1C2fsTpTZlwi C61EogCTYSkAR/7NSfbYqWBxM9EqXg471lZVz0XHw/KUosus+OTEvXLxqatgaZpzMgePgWFGOP5l 5+BUNfiSjOyTRk54RFT56LCEUrmRYSt2xQwdPv2t564OlhJnr1yxqg4+MRBwhcFRhrPqQOMX3rND hw6tWbMmPj6+Ro0awADRMK8eO3Zs79694+LiQAsOfsVRd0gCt1tgaP0/rvAYl7EHeccAAAAASUVO RK5CYII= --_003_B14A62A57AB87D45BB6DD7D9D2B78F0B114E66F5xmbrcdx06ciscoc_ Content-Type: image/png; name="Screen Shot 2013-01-29 at 11.40.04 AM.png" Content-Description: Screen Shot 2013-01-29 at 11.40.04 AM.png Content-Disposition: attachment; filename="Screen Shot 2013-01-29 at 11.40.04 AM.png"; size=51262; creation-date="Tue, 29 Jan 2013 17:18:24 GMT"; modification-date="Tue, 29 Jan 2013 17:18:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABpAAAACQCAIAAACAkb+sAAAYIWlDQ1BJQ0MgUHJvZmlsZQAAWAmt WXk8Vd3X3+eOpmu65nkek3nOPA+Zh0i4rukaLq55LlMZUiSEKCSSKJUhJDQhGUKjDCmiogkR79FT z/P8Pr/3/e89n88993vX/u61115rn7XPXhcAruuE0NAgBCMAweQIip2JvsABF1cB7CsAAQTAAlUg QSCGh+rZ2FiC//P6PgGz4WtMZlfX/0n73xuYvH3CiQBANnCzl3c4MRjG1wFAthJDKREAoHf1iURH hO7ikzBmocAGwrh6F/v9hVt3sddfePAXx8HOAOZMA0BFRyBQ/ADALcNygSiiH6yHng4ADDPZm0SG uwnAWJvoT/AGgMsT5uwJDg7ZxTkwlvD6lx6/f2ECwetvnQSC39/4r7nAPeGBDUnhoUGE2F8//j9v wUGRsL9+XXzwnS480N4C/maD/RZDJBjZw5gDxrn+PmaWv+U1oRH6dr/lHaQIMwcYs8CcJ/6Rpo6/ 8UJkoKMejHlg+VZgiMUuH/YTgoPsZWUNY2YYixDDDWDf746FUInzd3D+zbH09jE0gjG8ihAHKCF2 f/j+4VH2f+Rxcf4GVn/4AQTz3XjTw/wsAgVGv+xBFPsEmeyOKwTLL4dG2OzauTvWEDnI6vdcEG98 Kca7nF35D5/wX/Pdtc0/wt/BFJbDNiMZIygOuxx4jkgeX5KxGYxh25By/hTTP3Ld0KBfaxrui3Sg RNrt+kEExr4+ZMddH+7Ks7wJhru+hX2CLAPGgAAowAd4ATJYBALAEhgAw993AVhOhmVEEAKC4A9F gOFPC/otegQ9ix5HT6Of/ZHBPX/zAAl4w/gvXf/qD8vtQRz4AGv1AeF/RkNxobRRmihL+K4LfxRQ aij1P21Dyy3Lf/BvW/3gvjK/dev/tj4K1vjzD8+DlEL5g3/38fq7x3/bZAzewB7w+8OQq5dblNv6 0/+fGWOMMIYYU4wxRhJ5DNmMvI+8g3yI7EC2AAHkbWQrchDZuYt/2/VnFAIs2fXKrofDgQXsRR8Q +esX+c94/+GlyL8ZvzXQS9ErAzu4FxkEwm2kv0dw+mU16b+0RMIML3jEAJhr8Xc8ftuFEoO9q4zS R2nBfoZ9jGJDcQEZlBLscT2UDhwDZVj6TxT/czYywPeXt6N+zSUQvIXnERzhExMBryVgEBIaSyH5 +UcI6MHZ0mePgBmZuHePgIKcvCLYzb27HAC+2P3KqRDb439kwY0AqJHg59P9H5kXnBPbZeAcVv+P TKwQzncBAAyIECMpUX/pQ+1+oQENYICfCk7AB4SBBOwRBaACNIEuMALmwBo4ABfgDq9hfxAMWxwN EsARkAGywUlwGpSAClAFakEDuAZaQAe4A+6BATAMxsELMA3mwRJYAd/BJgRBWAgH4SFOiB8ShaQh BUgN0oaMIEvIDnKBPCE/iAxFQglQKpQN5UMl0HmoDroKtUF3oIfQCPQMmoEWoc/QDwQSQYdgQfAi xBCyCDWEHsIC4YA4hPBDhCHiEGmIXEQxohJxGXETcQcxgBhHTCOWEN+QAEmLZEMKImWQakgDpDXS FemLpCCTkFnIQmQl8gqyHV6LY8hp5DJyA4VB4VECKBk4kqYoRxQRFYZKQuWgSlC1qJuoPtQYaga1 gtpG49A8aGm0BtoMfQDth45GZ6AL0TXoG+i78PM8j/6OwWDYMOIYVXi1u2ACMPGYHMxZTCOmGzOC mcN8w2KxnFhprBbWGkvARmAzsGewl7G3saPYeew6FS0VP5UClTGVKxWZKoWqkOoSVRfVKNU7qk1q RmpRag1qa2pv6ljqE9TV1O3Uj6nnqTdpmGjEabRoHGgCaI7QFNNcoblL85LmCy0trRCtOq0tLYn2 MG0xbRPtA9oZ2g06ZjopOgM6N7pIuly6i3TddM/ovuBwODGcLs4VF4HLxdXhenFTuHV6PP1eejN6 b/pk+lL6m/Sj9B8ZqBlEGfQY3BniGAoZmhkeMywzUjOKMRowEhiTGEsZ2xgnGb8x4ZnkmayZgply mC4xPWRaYMYyizEbMXszpzFXMfcyz+GReGG8AZ6IT8VX4+/i51kwLOIsZiwBLNksDSxDLCuszKxK rE6sMaylrJ2s02xINjE2M7YgthNs19gm2H6w87LrsfuwZ7JfYR9lX+Pg5tDl8OHI4mjkGOf4wSnA acQZyJnH2cL5igvFJcVlyxXNVc51l2uZm4Vbk5vIncV9jfs5D4JHiseOJ56nimeQ5xsvH68Jbyjv Gd5e3mU+Nj5dvgC+Ar4uvkV+PL82P4m/gP82/3sBVgE9gSCBYoE+gRVBHkFTwUjB84JDgptC4kKO QilCjUKvhGmE1YR9hQuEe4RXRPhF9oskiNSLPBelFlUT9RctEr0vuiYmLuYsdlSsRWxBnEPcTDxO vF78pQROQkciTKJS4okkRlJNMlDyrOSwFEJKWcpfqlTqsTRCWkWaJH1WemQPeo/6HvKeyj2TMnQy ejJRMvUyM3vZ9lruTdnbsvejrIisq2ye7H3ZbTlluSC5arkX8szy5vIp8u3ynxWkFIgKpQpPFHGK xorJiq2Kq0rSSj5K5UpPlfHK+5WPKvco/1RRVaGoXFFZVBVR9VQtU51UY1GzUctRe6COVtdXT1bv UN/QUNGI0Lim8UlTRjNQ85Lmwj7xfT77qvfNaQlpEbTOa01rC2h7ap/TntYR1CHoVOrM6grreuvW 6L7Tk9QL0Lus91FfTp+if0N/zUDDINGg2xBpaGKYZThkxGzkaFRiNGUsZOxnXG+8YqJsEm/SbYo2 tTDNM5004zUjmtWZrZirmiea91nQWdhblFjMWkpZUizb9yP2m+8/tf+llagV2arFGlibWZ+yfmUj bhNmc8sWY2tjW2r71k7eLsHuvj3e3sP+kv13B32HEw4vHCUcIx17nBic3JzqnNacDZ3znacPyB5I PDDgwuVCcml1xbo6uda4fjtodPD0wXk3ZbcMt4lD4odiDj1053IPcu/0YPAgeDR7oj2dPS95bhGs CZWEb15mXmVeK0QDYhFxyVvXu8B70UfLJ9/nna+Wb77vgp+W3ym/RX8d/0L/ZZIBqYS0GmAaUBGw FmgdeDFwJ8g5qDGYKtgzuI3MTA4k94XwhcSEjIRKh2aETodphJ0OW6FYUGrCofBD4a0RLPBL7mCk RGR65EyUdlRp1Hq0U3RzDFMMOWYwVio2M/ZdnHHchXhUPDG+J0Ew4UjCTKJe4vkkKMkrqSdZODkt ef6wyeHaIzRHAo88SpFLyU/5muqc2p7Gm3Y4bS7dJL0+gz6DkjF5VPNoxTHUMdKxoUzFzDOZ21ne Wf3ZctmF2Vs5xJz+4/LHi4/v5PrmDp1QOVF+EnOSfHIiTyevNp8pPy5/7tT+UzcLBAqyCr6e9jj9 sFCpsKKIpiiyaLrYsrj1jMiZk2e2SvxLxkv1SxvLeMoyy9bOep8dLdctv1LBW5Fd8eMc6dzT8ybn b1aKVRZWYaqiqt5WO1Xfv6B2oa6Gqya75udF8sXpWrvavjrVurpLPJdO1CPqI+sXL7tdHm4wbGi9 InPlfCNbY3YTaIpsen/V8+rENYtrPc1qzVeui14vu4G/kXUTuhl7c6XFv2W61aV1pM28radds/3G rb23LnYIdpR2snae6KLpSuvauR13+1t3aPfyHb87cz0ePS96D/Q+6bPtG7prcffBPeN7vff17t9+ oPWg46HGw7Z+tf6WAZWBm4PKgzceKT+6MaQydPOx6uPWYfXh9pF9I12jOqN3xgzH7j0xezIwbjU+ MuE48XTSbXL6qffThWdBz1afRz3ffHH4Jfpl1ivGV4VTPFOVryVfN06rTHfOGM4MztrPvpgjzi29 CX+zNZ/2Fve28B3/u7oFhYWORePF4fcH388vhS5tLmd8YPpQ9lHi4/VPup8GVw6szK9SVnc+53zh /HLxq9LXnm8236a+B3/fXMta51yv3VDbuP/D+ce7zegt7FbxT8mf7dsW2y93gnd2QgkUwq93ASR8 R/j6AvD5Ivye4AIAfhgAGvq/zka/GPDrLgRzYOwE7YWWEGeR7ihR1Ht0N6YYG0plR21Eo0IrS7cX J02vxmDB6MkUyXwa38Yyw0bHrsdB4WzgWuKR5A3ga+JfFzQUOik8KyovdlT8laSy1EnpZRmjvVWy 2/JuCu1KXMoxKuNqiuq5Gsv7TLTOaf/QtdO7oL9haGFUYrxgqmQWb95lCe3XtYqzbrKZs2Oy13Lw dkx3OufcfOC2S69r98E2t8ZDNe5lHic9UwhhXu5ES29VHyFfnO+a34x/P+laQElgShAp2IasHMIe shY6FlZPSQ63juCP+BTZFZUb7RYjHfMjtj+uJJ6UoJaISRxLqkgOOqx/RCSFJZUhjTGdKYPxKO4Y dSYqcydrI/tzztLx2dznJ0ZPDuT15LedulJQdfpMYW5RanH8mdiSlNLishtnh8tnK5bPrZxfqVyp +lT98cKHmqWLC7Vv6mYuzdWvNjBdMWhMamq5+vra+nXsDfxN/hapVuU2nXazW/YdXp0xXcW373Qv 9KB68X1cdwXuSd1XfaD/UL9fov/TQNYg5+D5RzqPlocaHlOG1UegkUej5WNhT4zGOcc/TvROFj31 f6bybOd594u4l4ovl181TIW/3jeNmR6dKZv1nZOf23xzb77grc87jQXmhfeLXe9zlpyXBZcXP1z9 GPdJf4V2ZXy14XP5l+tf1777rj3f0P1RsDn9U3G7YGfnV/yFoSaEC5IZ+QCVgbbAsGJeYZupcqiD aBxpDekUcZL0ogwSjLJMyszGeCcWMmsaWxV7H8cSFxO3Ng+Jt4RvkH9HUE0oQviKyHsxaXF/iVrJ JWmZPRSZG3s35HTkjyjcV6JVtlTJVR1Rx2vYaObu69fG6OjoRunV6r8wpDXSMPYyyTStNxswX7RE 7Ge3ErdWtNGw1bBTtBdxoHf45vjcqdu5+kCWC9nV/qCqG7fbzqFZ9z6PGs8MgreXLpGHuOY94lPv m+7n7q9KYiQtBNwOLAoiBxuRucgfQm6H5oa5UoQoi+FNEdGRGpE/o7qik2N0Y1GxD+KOx9sk4BPG E4uSDsKZdeVw75GKlNRUcpprukmG0lHBY3TH1jJnswazb+acO34sl3Li0EnLPJ185VN7CyROCxXy FLEXM52hKUGVbJV+LVs6O10+WTFybvj8eOXrqqXq9RrkRfpazjqRS3L1+y4bN1hfcWn0aYq6mnOt trnv+tSN1RaolbFNsF3xlnHHwc7Qrozbpd11dxp6qntP9kXcdbincJ/p/uqDJ3BuqhhIHwx8ZDuk 9lhwmHZ4fWRu9NHYtSdF44kTxEmLp0rPeJ+jny+/ePLy1quqqeOvE6ZDZwJng+ci3iTOZ7zNe1e6 cGGx6X37Uu/yow8vPq6vqK9Wf9H/Rvv96/rCj9Gtym2X3/HngY4jJBADyGAUN2oAnYLRxqxjO6mO UrvQKNLS0y7QPcQ105czHGdMZYpjjsLHssSyJrJlsJ/gOMvZyNXH/ZTnIx+OX0RAX9BTKFW4SuSu 6KI4vYS8pKNUvHTFnj6ZRVkmOVV5V4V4xXKl28pTKttq3OrqGnaapH1JWnnaVTpXdTv07ur3Gwwa DhjdN75t0mxaaZZlTrawsBSw/Lr/nlWRNclG3RZrO2F3wT7cQdeRznHSqdo59ICmC8Zl2LXkoI/b Xrfvh7rcMzysPPGek4QSOE/wE6e9z/l4+vL7vvY75+9J4idNBZwNdAnCBw0FZ5KNQqCQW6ERYeJh TynHwlXD30UURhpGfo46F20VvRlTF+sUh4hrjD+YgE5oSjyYhE5qSnY/zHJ45Ehhik+qWhp92nx6 Z0bB0cBjepnsmR+y7mQX5PgeV82lyZ0+0XoyP4+Sb39KuYCzYPv0m8L+osbiU2eiSlxKNcq44N1y vPxGRem54+czKtOq0quPXjhak34xsTa47sAlo3rNy1oNFlcIjQlNxVevX3vUPH998yZTi1jrvjbb dr9bSR2nOy91ddy+391/52HP3d47fZ13W+813294cPFhRf+ZgfzBnEcZQ6mP04fzRmpHH46tjvNO mE1GPa18NvR846XIK/upE6+nZ0hzHG++vUMvJi33rp5aF9mN/181st09AaMCQA1cy3E6DIAt3FJr C4BoAVxuaQPABgeAgzpABKYDBNMSgMok/t4/IIAC1HDthRM+b8oCLficfRA+myeBfFADboERsAif F7kgJcgaCoSOQhegXmgWgUAII4zgk142ohHxBPEDPs+ZIsOQJcg+5Cd4DZqgIlFVqDE0Eq0En8hK 0EMYJEYdE4qpxcxiebAHsAXYUSomKluqU1Tj1JzUHtQ11B9p1GhSaYZp+WjJtN10LHQBdHdw3Lho 3Di9Cv0Z+h0GP4ZRRj3GZiYpphpmceZGvCZ+kMWD5SvrcTYptgH2UA52jl7OMC4hrgnu4zymvBje e3xZ/LYCPAIfBPuEqoSzReJEg8W8xT0k3CU9pXykg/fEymTuLZdtl5uUf6/wUfGN0hPlXpWbqlfU LqnXaVzSbNrXqtWnPaYzr7uhz2AgaWhs5GecbXLV9IU51kLB0nk/xSrV+oRNuW2L3QsHakdtp2h4 v/vsqnQwxu2OO87DzbOOsEzk9dbxcfYN9jvmf430IVA1KDP4dYhK6Mmwj/D+di2KNToipj+OPd49 oTZxJ9n/8EwKIfV1ukvG+DGXzK3shdzcvLMFXIXmxaElxWWt5UPnZiq/X6C/KFlnUR/T0N7Ed63y hnRLedtOh1vXrTsCvVl3Nx749489UnqcPTL3ZP/E0DPPFxtTRTNqc6/fpi1sLgktb3+sXhFZrfjC +bXyu/bau43iTf2tqW3Kr/wBwTUHWoAHvEASriUbA2e41pIA8sBF0AUmwCeIBq4R6EMeUBJUDnVB 03DsxRDmiFBEIaIL8RbJiNRA+iDz4KrRBxQPaj98Qr+KeoPmRFuh09Gd8OlbDhMEx/0tVhTri63F LlHJUkVSdVJjqG2oz1K/p9GgyaZ5TatEm037hk6H7izdT5wn7i69DH0RA5ohimGJkcg4zeTF9J45 Fs+Av8RiwrLAms0mz/acPYNDieMtZymXAzcj9yhPMa8Xnyw/4B8XaBDMFPITNheRF+UWoxLbFP8q 8VVySxq3R1hGe6+nbKZcm/x7RR4lG+VslUE1JnVnjTOaY1qQtpiOsa6v3jH9BoNxI4Sxgomv6Vmz SQs2S6f9hVZjNvS2JnbJ9u0Oa04qzjEHOl3RB23cKg599jD3rCb8JNrCeeq9n6J/ImkgkDcoLPhe CG9oVNhYuFJEUeRWtEdMVxxHPDnhXpJwctbh9ZSA1FfpNhm9x1QzG7KFckpy2U9U5GnkfyhoLSwq TikJK/MoNz+nVMlfTX9h5+Lnurf1TxseNHZcbWu+c+Nxy6u2pVsbXTTdAj0afQfuxT4o7W8fHB56 Mfx0dPBJx8Tlp2ef5708OpU8HTsb/SbmbfxCzPtDy2wfaj6xr5BWqz6Pf1n7xv5dcc1mPXzjzI9H W9ifttvVv+OPATjADj/98kAfri/5g0RQANeQ7oNZsAPxQvugQ3Dsz0P34LdMZoQGgog4jmhFzCPx SD24clOFnEBRw/W3SNRl1DyaH30QXYyegCsuzpgSzBRWGBuAbcZuU5lTFVMtwBWT49RzcMwLaFZo rWmb6PB0sXSzOCtcJ70c/QUGfoYyRj7Garhu0cfsgUfA8XZmxbLeYotgl2Nf4bjOmchlxs3BvczT x3uOL5mfKGApqC4kJSwowi8qKCYpriJhJukhFStdtKddZlaWWc5cPkOhVwmtbKvSoIZXT9ZY3UfS WtAJ0v2un2HIY9Ru4mFGa95hSbJCW2fbArsQ+1eOVk498J7UelDdrdvdymOGEENk8K7yVfLrJlkE TAYRg1dDjoSxUhoj9keuRJ+JNY+HElqTiMnbR3JTOdIqM2SOdmY6ZK3nXMkln5TKGzsVUPClMLLo 25nokq2yjHKWiprzmpVj1cE1NBdr60wvLV7OuaLU+Obq+eagG4YtQm2o9sWOka7O7oaeyr6SewUP 8vpPDJ4Yyh5OHHV/Ijf+bfLas+AXki/fTl2Y9p2Vmlud73iXvmj4fnX52IfPn8xWclZbPr/6svx1 49vc94dr+ev71t9upG1s/CD/mNs8sHl7i2WLtNX1k+Un6WfXNtW2zXbx9usd8Z2QnZbd+If7Kirs 7h4AotOHy49TOztfxADA5gPwM29nZ7NyZ+dnFXzYeAlAd9Bf/7vskjFwrf4cehc95J07vPv97+t/ AO7o2U2DSwTDAAABnmlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4 PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS4xLjIiPgogICA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgog ICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpleGlm PSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyI+CiAgICAgICAgIDxleGlmOlBpeGVsWERp bWVuc2lvbj4xNjgwPC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZ RGltZW5zaW9uPjE0NDwvZXhpZjpQaXhlbFlEaW1lbnNpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0 aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgrnkO6tAABAAElEQVR4AeydB5wWtdPHr3MF jnL03rt0kI6AgAjSBOmiAjaKICKCCggIIihIkSICf5GiIEgvR+9FOiq9d6TfAdff3xHeGHd38pR7 rs998HE2O5lMvskmu9kk6/7w4UM3/mMCTIAJMAEmwASYABNgAkyACTABJsAEmAATYAJMIGkQcI+J iUl4T9zdEyfdhM+pzRQZhU1ErMAEkhQBvmaTVHGwM0xAJZDiL8+Ul0HOkVqBk4Kc8kokKVBlH5gA E2ACTIAJhISECAjBwcHR0dEZMmR49OhRZGQkel7fp3+enp4+T/+8vb0hR0VEh4aFeiGOjJkwEFev Xi0SSuB0EyZ3DqXCKBzCxcpMINEJ8DWb6EXADjABikCKvzxTXgY5R1RlTqzwlFciiUWS02UCTIAJ MAEmQBHAeFzt2rXFzLmwsDAM24WGhnp4eCDcz88PQ3Zp0qTBYVRU1PGTJ2IH7PiPCTABJsAEmAAT YAJMgAkwASbABJgAE2ACTIAJMIH4I4DZcxibE1PaMbUuMDDw3r17GLPDUJ0YtoMCVNw8wuCDR/z5 wZaZABNgAkyACTABJsAEmAATYAJMgAkwASbABJgAEwABDNWJ0Tr8YoQOg3MYs8OEOwheXl4IxK8X gt1jZ9fxDDuuM0yACTABJsAEmAATYAJMgAkwASbABJgAE2ACTCB+CWA4DgnEDtq5u2MzOzGrTg0U 8++i3TyhxjPs4rcw2DoTYAJMgAkwASbABJgAE2ACTIAJMAEmwASYABNQCWDMThz+8ccfGLnDIebZ Yfc6qcMDdhIFC0yACTABJsAEmAATYAJMgAkwASbABJgAE2ACTCC+CMROrns6VCc+PXHq1KmpU6ee PHkS6SEcI3cy4X8lGcQCE2ACTIAJMAEmwASYABNgAkyACTABJsAEmAATYAKuJYBxOvGH4Tmsip0x Ywbs//zzzxEREQjBDDucFSN61gN2OXLk+Omnnww+pUuXzhDiwkMYp/5kKlCQcrwK+LZujx49XJjE wIED8bFe+w2inEaPHl26dOmcOXM2adJk48aN9sdlTSbABBKFgGzB0qdPX6xYsXfffff06dPx4Un8 tYTxZzk+OLBNJmA/AXl5FihQoGPHjuvXr7c/bmJpuuR6TI4ZtwRuoJEc82XIgmU24zUwjg44FB03 rhUrVsyQIYNDseI1+2ycCTABJsAEmEASJICBuU2bNom5defOndu+fTtG68RQHU7BYesBu5CQkLlz 5+LLsgmWpYfKHxJVjh4mmA8iIQyWNW/eHM/bLkwXD/CvvPJKeHi4nTZHjBgBN1Bahw8ffuONN4YP H25nRFZjAkwgEQmg4Xrw4MHVq1dXrVpVpUqVli1bjhs3Li7+YHAhLtE1cePPsiZRPsUEEpGAuDwP HTqEwXT0qsuXL3fOmWR37aTUjKfUfDlXLc2xErei9u7d+/vvv7979y6KyewbhzABJsAEmAATYAKC wOPHj+fPny9n20HGWJwKx3rADhqYYjZ+/HhVNdHlhOn1Bw8ejEltuNVwYX4//vhjWBs6dKidNufN m9enTx+8mcySJUubNm0w5mpnRFZjAkwgcQngfUhAQEChQoXeeustDNt99913a9euddqlf/75xxzX JS1h/Fk2O8whTCCJEMDlifdntWrVmjlz5tdff+2cV5bXjnOmEixWSs14Ss2XSypG4lbUixcvPv/8 8yggl+SFjTABJsAEmAATSKkEli5devv2bdljYrTu119/FeN3IsvkgF2zZs32799/48YNCs2KFSsq V64cFBSEXzyXUmouDFfn1QsZT8J169bFAt7XX39drDndsmVLvXr1smfPjkG3s2fPytSR7VKlSmXL lg2v1p88eSLDDcKxY8eQ6549e4rw8+fPt27dGutSkZxIUeprDO7cufOll17KmjVruXLlFi1ahCjY NbB///6TJk36+++/pQWN4OPjs3v3bkpBQ97gJCyoIZBxC9W9e/eCBQsGBgZK+2aHxSlNHmVcFpgA E6AI5MmTBxc+hgakAnVNWTY14uLFrxCkEfVQyL///nulSpXQ7mFO3+XLl6UmhODg4AYNGqDpw7PT 3r17xSkRC79CkPqGQ5tNjSZdaZMFJpAECeC2QSw9QJ237Bapyi+uEfwKQWaN0hcKVCerjyWN2xQs GxDLWDLjOKtJHbkzYBH5jc12Qm1OgkUGNWvWxK1U1apVf/vtN8vsyMBklC/psypQXYOgrWlpca9Y p04dSUmWjhDwKwQ1LXQKuE8GMXN/oarpZWGWcgxn8aQRm7ZSWzT1TZ8Wn2UCTIAJMAEmkIIJtG/f fsmSJbgTmDVr1pw5czDDDtM+xPidbkmsIDJo0KCRI0da0jl48CBmjX377bcXLlzALx5Kjxw5YqkZ f4HYmW/MmDF4SX7mzJkaNWp8/vnnq1evHjVqFHZ/w1AdBhzff/99kTrG4LD+ZcGCBSdOnChcuPCQ IUMor/Bo3aVLFznA2a1bt1atWuFWGFNa1FktGoM4hTE+cMfDwOzZs3/55ReRVu3atfGB3h9//JFK Wg0Hz3bt2iEj5p3v4kgeWPBgv2/fPizcEylSDmvyqLrKMhNgAhoCGLs/cOCAUNBcU5ZNjWhznrY9 uiVFixcv3rx5M/Yoxa4HDRs27NWrl+rPlClTsMQeTSJato8++kicsseyzaZGn67qA8tMIKkRwHpY zLMTXpm7RU3lt7x2NPpIgupk9bEcImbZgFhakBm3mboBi2XGLZNwSSDuu/B69csvv4QwefJk3Lzq zSaXfFnmQtM1QF/T0mJQFRsy9uvXD5Rw+4rbfWmfKi+oTZw4ETfPuHM29xcyuj2CxjFz6jbrmz0p sg4TYAJMgAkwgZRBIDIyEhnBoJMYd8LAnJeXFz49gT/xuQk1m+44bVgli9N4Jya6265du2JgTmzo JgOh0KlTJ2zK1rZtW2ELI4J4dWb+ToWakpQxrPbaa69Zpit01IRkLAhqOOSmTZv+73//w2Q0nML2 cHnz5m3RosWECRNkCGbGiRUB8LZRo0adO3eGJig899xzf/75p2pZyhUqVMCLXLnxR+7cuXEjhckp UkEIGoNgghExjLgZouAQE+4wZgeD8pQGBe4+sZgON2EwhXtxRJRJa8iriIS+GgIZb1bxslo6AIFy WJNHNTrLTCBVEdBcs+q1JpmgacLEtzt37iBEc01RTY2lTTUQMqbxon0TKWKIP3/+/Ddv3pQOSAH7 I6CRvHXrlghRjUgdNRDe6psaO9OVxllgAvFNwJ7LE/cAa9aswfvIhQsXFilSBHXe3C3arPziBklm R6+v6WQ1lxiMq9ejSIvKINWAqEYMGdf7bInF7I8k4LRA5eiDDz7AJwuweEJaNqQuD5NavqgcqWUh MyUElAV1j4psalpabN6C7RfAShqUWCyTw1m8hMabYzwVQMGyv7DTf71j5tT19U36zwITYAJMgAkw gdRAYNu2bZjtLibQYZwHAkburly54uvri6WZ/v7+GNFCOMb1Dh05TC6JFaQwbQ2zM8zU8K4MU8Zk ON5Uq+NQMjxeBdxziLE5pAIBn8jAXD81BB97FQ5ghguWgwkZCDCKh2dXS9/wulIdnsN7XdxqY2oe RjpVfY1BLE/ArnOqspSxJx3sy0O9gPt4fMbui6d/9evXl0/gcSRvGK2DD5TDmjzqPeezTIAJSAJo Z2WjpLmmqKZG2tEIcrQOOmjfLRs3BKZJk0azG4DZvs2mxp50zWY5hAkkFgEMMRQtWhT96Y4dO9at W4fROuGJuVu0WfkNWdDrU52sPpYhCf2hvgGxzLjN1M1Y9D649qy4kdXbTI75ssyRpmuAvqalBSVM hLS0SQXiQxBitA4KVH9BxTWEaxwzaOLQZn0zR+EQJsAEmAATYAIplYCYRvd0gt2/m72K8Tsx5078 iuzHvmTT/GGyBrZhwt0t1pyqatjbDrvXyRDIckRJBsa3gFsNQxLmEKFw/fp1vKpVlTF4qR5SMj4X +8ILLwwYMABDgfgQBJbT2jSIpaaYUEMZdDQcix3wOhQfmsQ3KOAAorucPOWw09AczSPrM4EUTACT ZPPlyycyqLmmqKYmjmQwQocdAPDKAVP81HbfHrMub2rsSZR1mED8ETBMi9Mk5Gjl1+tTnaw+lsY9 8yl9A2KZcRembvYn7iHYixP7suntJMd8WeZI0zVY6stAvIrHVnTy0B4B30SyR83lOkm8vrk8v2yQ CTABJsAEmICGAAajxKpYDNJhMhkWvGKGh5+fHw4xsQ4zzMScOwgwYmOGHTSwJPabb74xpIdpaGKR lwhHMurENINyoh9mypTp+PHjuLeTf9SzK5aM4a5CdRhflJs6dSrmu2FdqgzXGMycObPBgox17949 2JeHdgooOax62Lhxo9B3iHxERITNVCiHNXm0aZMVmAATEASwvAg7ggtZf01ZNjVxxNi3b1+s0MeG 9/j2kNy20k6bDjU1dtpkNSaQLAg4Wvn1+lQnq4/lKChHGxDXpu6otzb1cYeKZRM21cwKSTxfZocR ou8aLKOIQKzbsJxSrYmSWKeSY7kkFitOlwkwASbABFI8AdznYKAGY3b4IAS+Crhnzx4s/sCOvdgf Fg+PmJaOXZUAQcy5sz1ghxsCfInV8Iku7PWGqfgSJb7NWr58eXmY1AQ8MK9cudIerzCfDg+3Zs0P P/xQ/cCrxqCZlbCGvUJQHrBvNm4zBGOjuJ8TanryGN2T36lAAcs95jVJUA5r8qixxqeYABOQBDD9 Ydq0ae+8844IseeaMjQ1WMcal+cxtPivvvpqrly55LJc0e7DH5uW9U2NzCMLTCDlEdBXfvO1o9en Oll9LOeoGhoQjREnUjdnXGM/jqfgnrrRiv1rOJJ4viyx2NM1WEYsVaoUltPKU3h3rr6NTsjykj5Q ghPlQpnicCbABJgAE2ACyZ0AlsSiy/7rr7+wcQqGevCkhoUFWJWFdas4ha+5rl279sqVSyKbtgfs oIcHTnzeQeWCm8KhQ4diqSxegWK0btiwYfhMlVTAxiL4k4eJLmBNKyYJ4vtZmGF39OhRfICVcgnf 0MWnM+QzrVDD8Ce+91qzZk0ZS2MQExInTZqEL/Lev38fZSC+dIGIW7duBX18xEMa0QhYgIx9RjBE iGd1/II/gAt9PXlsOoOSQiwUM7JZpUoVTSriFOWwJo82bbICE0jNBHClX7t2be7cuY0bN8YeoNgU XNCweU2Zm5rixYvjZQt2VXeOJ5bn4yuxGMRHM4IrHYuh8PVqYcqmZX1T45w/HIsJJAsC+spvvnb0 +lQnq4/lBChzA6Ix4kTq5oxr7MfxFDZQHjVqFNZGoPlaunRp69at7TSYxPNlmQubXYNlLAT27Nnz s88+O3HiBCjhtTQoeXt7S+WELC+ZKCU4US6UKQ5nAkyACTABJpDcCWC0Dq/cTp8+jS3dsLsFvpWK ATt8Qwx/mGmBL6BiCh7m2eFVHHJq14Adxvy6dOmicsF8OtxL9erVC2s8MY1r7Nix+ASqqpCkZOwz jYdnjKMVLFiwR48ehryorpYuXRqvAaEpAsXII8BhUFIG4pTGIPa5w7fnMMCHDa3ff/99bEIHfTxv AxFurUqWLKkmR8kYXty1a9fLL7+M7/Ni9zp8AkwuyNWTnzhxIubUIJsDBw5ERJE6lYoIt3QYpzR5 1Bvks0wg1RIQLQbmw+K7Pxijx1gbvogtaWiuKaqpQTM7ZswYLHaTRhwSpk+fjuYIr2vQ+OAj2mj9 5HOvTcv6psYhN1iZCSQvAvrKb7529PpUJ6uP5RAxqgHRGHEidXPGNfbjeKpatWp4bYnPbuGeFYJ6 A6a3nMTzJUpK/UV2NF2DPrP4ggpeA2MHQ9yK474R95lqZ5GQ5aX3E2edKBebNlmBCTABJsAEmEAy JYDxOKwewGhdxowZ8eQIIe3Tv8DAwCxZsmAfCQzh+QekP3vuAjLojtlk2OUuIbOKESU8xCZ8unbm Ee+osWNdkyZNMBxpZxSbal999VVwcDAyLhemiShJHIXNfLECE0htBPiaTW0lzvlNRgRS/OWZ8jLI OXLh9XXmzBm8mwHSuNhMeSUSFxoclwkwASbABJhAfBDAQlWsicSnJ7B/BfY0wwfcMUyEX/HFCUz2 wlhZVET0vXt3vHx97JphFx9eJlmbWFDw+++/YyGGCz3E8tjly5cbRutcaJ9NMQEmwASYABNgAkyA CaQqAm3atMESEOxOg2U1+MqQPesqUhUfziwTYAJMgAkwgSRIABsoidE6MUiHYSKMQeEP43cIxxAe NjLyT5smc7aMcN4rCWYg0V0CpsmTJ7vQDSxMcKE1NsUEmAATYAJMgAkwASaQyglgjxdsY4ddSrF8 Bvsdd+rUKZUD4ewzASbABJgAE0j6BDAwh2WdmE8nxukwbCcE/EIWn5CKioLsc+9+KA/YJf0CZQ+Z ABNgAkyACTABJsAEmMB/CDR9+vefID5gAkyACTABJsAEkjwBDMxhJzuxBha/OMSfGLBDOMbsIiMj xcgdD9gl+cJkB5kAE2ACTIAJMAEmwASYABNgAkyACTABJsAEkjkBbFGHSXZYCSt+hSAm3GG0Dmcj I8PDwsIiI6ORUR6wS+alze4zASbABJgAE2ACTIAJMAEmwASYABNgAkyACSR5AmI+ndi6DruxYWId Ru4QKCbcYWJdVJQXFsSGP36CrMQO2MXxk1JOA0msdJ12OP4iMor4Y8uWmUB8EOBrNj6osk0m4BIC Kf7yTHkZ5By5pOa70EjKKxEXwmFTTIAJMAEmwAScINC4cWMRC3PoIGBgTvxhqE4IYsAOX4n18vAM w+w6ryioPdvTzon04hgFPsXRQoqJzihSTFFyRlIJAb5mU0lBczaTI4EUf3mmvAxyjpLahZbySiSp EWZ/mAATYAJMIBUSePjwocg1+lksfcWf2L1OyGKGHRQg4DOyHp5uCI89/Ot67PAe/yVxAiWzu1uW FBXuUHZgxKxvmZxZjUOYABNgAkyACTABJsAEmAATYAJMgAkwASbABGgCIeIUBuwwyU59PabKz3Ri MMXu6YAdbY7PJCEC1PAZFe6Q6y4x4lCKrMwEmAATYAJMgAkwASbABJgAE2ACTIAJMIHUSUAdp8MQ njKKF/vpCTeP2Kl1XiWypU44nGsmwASYABNgAkyACTABJsAEmAATYAJMgAkwASYQvwRCnk2wM6Yi hu3wKwScfipgzO7pHnZ9Lxgj8DETYAJMgAkwASbABJgAE2ACTIAJMAEmwASYABNgAnEnMDzIGRux y2L5jwkwASbABJgAE2ACTIAJMAEmwASYABNgAkyACTCBJEKAB+ySSEEkCTcubF07vWK28fktvkGR JPxLek4wq6RXJqnLI75mRXm7nANf2qnrQuLcJlUC8XQlxpPZpEoxOfnlqqJxlZ3kwi615TeeyoUx xhNYNssEmEBcCPCAXVzopbS4O7/5vPGEeX3O84eDU1rJcn5SKgG+ZkXJMoeUWsM5X0wgPgjwfU58 UGWbTCC5E+CWIbmXIPvPBFIkAS9DruS7BUOb5Wi4waz+8OL29YdmT7iyd1tURHhgrnzFXmlX8e2P vPz8ZawHVy4saFbl0e2bBq+kQooRNCjuXzize8KwSzs2PPrnZoYCRWr0/7JQwxbI+NF50/ZPH/vg 8oXA3PkqvTugdLtuCJTlJcmkSZ/xvcN35KGlcPf08ZxVaqmnKDvmcFE0j+/c2jn2s3ObVj2+fcsv KEuBui9X/2iEX6Ysqk1V1uTXMl8a+5b6aloG2ZLn1X3bD8/5/uL24Mgnj9OhKjZtW6F7P2//AENc m4eUnxQ3KtxmQgYFsx1R7uZweSnJUzLEYFM9jAgNwcjI6TWLH926ni53vvJvflD29R5CwVH+qln7 ZUNToCkvh/JlvwNmTU0dtqxjsGDJSjosk+BrVqIQgkRkrqvmtssQlw+ZgHMERK3z8vVLmyN33ur1 K703IDB3fphCeOn23V8cNV2aRQhqZmTYk4Mzxx//fe6Dy+c9PDxzVa1T/o3eeWrUl2quFeRFIc3K q0OekiHQodorKlzT5ssUWYgPApbFh4Qsuw9NVxh33/RVWlT7uKfCFqjCdZQMdf8JO1SlcjQJjf6f v/wYPKBbg9EzSrXtqlHjU0yACTABJmA/AeOAnbixk226NORouIxoj7Br3BAMM9UdNikga46Q61f2 TBi+qle7ZjOWibjRkZGre7ar9P4nW4d/aI+1ZK1Dobh3/vTCtnXKdelZtfdgPDbcPXsC42IYsDu1 atHeiV82Gj8na+kKN4/uX9O3s2/GoMKNWqo36ACy5PWXMHZmk0x46ENPbx9VTWPHcErEWtWrfabC Jdou3umfOdujf278MfVrhLw6d71qU5Wp/FL5ouxT+mpaqkzx3P71wDId3601aIx/5qwhN67uj/W/ XfMfl6tx7ZEpPxHXkpsm3J7kpI7BuFruhlOGKOZLXiqowpbhfTFujgJNmzPP/fOnceiTNrBEq86O 8ldt2i+bmwJNeYn82pkv+30wa1J1mKpjFCtDAallZ05UhqSeaxZZ1pSpmYNExAITiCMBVLyo8LCH Vy+dXb9sYZvareYGZyxYDDYvbF5z7cCuHBWqqfbX9u3s7RfQ5PuF6fMWjAh5eOWP7fumfBV/A3ZI 2tB0SGcsrxeqvaLCqTZfpsJCPBGwLD6q+9B0hXF3L+GrdNx9To4WqMJ1NC827z/j9b7oTPBSPG6c Wb+MB+wcLTjWZwJMgAlQBGJfCJvPoTV3SbjZsj0h4SEPplfK3vP4I6G8bdTHd07/jUETyit7bCZT HYlide8OWZ+rWLF7P0NGfmtfr3SHtzEnUYTjrf6fv858dd4GVe3cxpXbRvbvtOaIh9ez8VnRW6tF bOi/1VPSlGqHKovJJdN223MlTbr0IlbYg3szquXp8edDcWhOVxoXgswvlS/KPqVPpUvxNPgTdv/u D1Vy9jzxmLKDHNUfOW3n2E/x8eWiTV+r9elYrzS+UKb8pLhR4VS6CD+54pf9P3yDiUW+GTI9/8Hg Uq+9JZTlrz3lJZUtHUAgFNTKMK1C1k5rjwRkyS4iYngdA5qvLdym4a/x02wfZo8vnbd7/NCHVy7m rFi9wZiZYjKLSM5mU2AoL8SyzJewFk+/sg5TdUzDSrqklp0INLMSITKKWkwyULVDoaDqKpWuNC4E mV8qX5R9St9muoaM6DmIs2Y45nDMIkE7eWrFrzEx0ZXfH7h1RD9zLEPe+TA1EDDUt2MLZmAy2suT FiC86ZRFu78b1mHFftG3Cs1Jxf27oxNMnzFh4BjcMyeqV5DXryGiDKfafIO+Cw+pKzHiUSiuyjNr lyCtwi+1qv3ZN2IdBjKIzvfCtuDyb/a+dmD39UN7agwYhRdvULPsTaAvvDVc4AhHge74etDDqxcz FS2FKUJZSpZzYb6cM2UoPn2zKZMwd4XylBMCVaUlSWlTIqXIWxKmShxmLe0gHEnjxeqhWRMe37td vd/wCt1iX+dr7EgPVUHRj6nSc9CWYX2F/wbm8jAmKgqD78d++RF4CzZoVm/YZO+AtMKgpT/zmlZE VcxXq6HwbUbV3K+v/8s/KKvqgypThbumTydv/7T1R06F8oZB70Q8fvTSuDnCpmWfRfW5Mi2ZIxmi uU+TOvYIkY8fTa+co9PqQz83Lvf2vmvqSilzdLhhCJT1xxAuDjX8Lf2nuFkaR6D0x+AGwh1qYbBW bPuoj08snR8Tg3r16ZZhfYRByv+bfx7c+fWg60f24QVPUPHnqrw/sHDjVyknRbjldeGonzK/Mi3h p6altbx+ZXSzYFkuGvsUZ7NlDmECyZfA8KAQ4fz+/fvTpEmTNm1aX19fPz8/yD4+Pt7e3l5Ph2vc 3d2jo93Cw5+ER0acOnUqKe5hd3bDitxVXxCZOb9lzcllCxqNnS0OU9uvRHFp50YszJzTsPTEor4z axXEPSXWbIIGGvrcz9eRWPJUq3vrr0PyEAImJW378qPan38rR+vUs1JGMy1aainIU0Iw28FI1oTC PrgFwVSgs8HPpkMWatRy97ghIdcuR0dG4BcjL7ixNpjSHMr8Uvmi7FP6VFoUT6mP/N6/eHbbVwPy VK8nAy2Fc5tWYjAUw1gPr13aO3GE0KH8xFlLbppwy0QPzZ64Z+KIOp+P677vWouf1lzdv9OgZmd5 GWLZPETzgT9V7fbxozik+Nv0UzUlZKy3bT5zBZZv563VYMOg2Icu8advCuwvr/+3F1//l3WYqmMU K+mQuezkKVWQl6oU1LOQzXYs656mrhoMWh7K/FL5ouxT+papaAJl9qWgUdac2jthOB7UO6453Gn1 4Uu7Nmk0+VRqJlDwxVcu794sCOCxKl3OPFgAqwLJVaX2uv5vXd6zRfTR6ql4ki2vazvTktevQV+G U22+Qd+Fh9SViFuL0FvXcIV2XH0Ive3u776QiT7X4Z3mM5btHv8FdlNpMXvVH1NGi1OWvYmmoTix fEHLn9e9c/CfQi822/j5s90eZCpJQbDZbMZHV0hVaUlSCPiViCzJ46wlYarEoU/ZwamL24Lxcrrr jvO4NxDpauwIBcMvbtietflrDl/c8Z/33AZNcXhg5nh0Da3nb3xr21kPTy9sD6Kqmf3Bkvlj838Q Ouc2rMhR7nnNaB3UqMKtNyJ2n5bTa5eABt4W4FDYpPJL9bmqt6rsxH2aGl2VL2wPzla2cmCeAtnK VIKsnjLLstpAqN7/yyo9Bpl11BCKP+U/xU21qcrCHzVEyg61MPsmj7p37lSHlQc6rzsqOwuYovxf 8U6r4q06d91+/r1j918YPP6vxT/JdCmBui4c8pPir2lpLa9fykmqXDT2Kf+pJDicCaQeAsYlsYme 81MrF24d1rfNom3wJPTG1eCP3nx58i9Y5pnojiW8AyqKx3f/QX//8sQF6fMXxkAY3qrhHxYR4zW4 gLNpcE8c+mbKHPbwvurq4Z8mY2FO/jovqYFoptVDe2SDHWnhyb071w/v3T5qwD8nj6G7hQ+LOzU4 ODOPsImeW10PK2NZpqjml8oXZZ/SFwmZ06V4Cn353ilToeJtFsZWRfFntoPw2oPGYim3EJZ0eQl7 9kGm/JQWDNyocCpdPCKiMgAvFOAk5gIITflrZ3lJfUtBeiXP4gEVjzG1PhmNddlY8om3iBGPQ3GW 4q/302wfpvAGTyRX7o3eGJQUsr4poMpLxE3IX7UOU3WMYiX9NJSdCLdkJaNYCgY70oKh7lF11Z50 1fxS+aLsU/r2pGuZX8tAmWvDWXP48WXzW/20Vswerf3pWLS3hih8yARAwDdD0JN7tyUKVO8FzZ8v +krbdDme9XpNvv/1wIxvtwz94M6Z4+nzFYrdk7d7P/1ME2nNCUHWZMN1bY8p9fpV9dVwqs1X9V0r U1fiqdW/tZqz7tkV+tk3S7o0rvnJs4G5nJVquHvEvn7OVaUWBEz9Fi5Z9iYab/EODF0bFDDwt2/q M+Ma/YQ/pW8246krdKJKU+QtCVMlDryUHZzCjDMMDEFArRAFobEjFAy/J5bNb/m/Nfa3+Rh9azFr pZj1j6lz81+pXGfwOGnT7E/xFh3xch27iGCcDstfirfsJJUtBapwsfHIS9/NXd6tOWI1+3GZT0A6 EZ3KL9XnWiaKQP19GhXLMvzsuqWFGsT6iV+8yBeypaYauOe7YdHRURizUwPNMsWf8p/iZrZsM8Sh FubvJXPw2iBt9lwwW2vg12fW/S7sU/67ubvfOfVXuhy5M+QvkqNi9WY/LLXpD3VdOOSnTMXAX9PS Wl6/0o5BoMpFY5/y32CZD5lAKiSQhGbYYU4W5oJhyUPzWSszFiiKwlj9Qccynd7Dy73UVjBmFD6x 8+GnBRUrjRWXGfIXrvflFOx2ASzokHCbDgE9NH6f3PlHLkeNPbx3Z9/kkZheBzkufxo7WI+J0cBX pi3GIwqSWPdhl+zlnu+680KvU2H4zV6m8tq+r9tM2iK/RL4o+3oOZgconkITj0C9T4e/selk9vJV sQDBHF0NSZcrrziEEHrzmpApP2VEAzeb4VJBCHgtHFS0lCFQHtpfXjKKnQIGMjLkK/Rbpwbfl06/ qmfb/PWa4PEVcSn+ej/Nid48dgADvlPKZsKDB5Z1YHmF0NE3BQ6VlzlRl4RY1GG+Zp8ujaeuBarO uKQ4nDDy6OY15VrO54QFjpIaCGC0zjd9JplTPL1jOd7mwb1kCCp21T5DMQus59+h+Or6vQunsTJL no0/gepTLFM0t1dCzRxOtfmWZl0SSF2J6F7VKxRqMjlPnzQeXt44FAJyAZnqTWQssyBG6xCOAVbZ +5jVEjFE32zGU1foaJXWkLckTJW4xg6KQN0uQ5QIZYcqL7wIVGsUpSbDcT8zq05h3Jzg3/SK2UKu X5anIJj9wcgalpj8veh/WEJ7Zd82m6NXmsLNUb4qXr3jBQBusGWiVH6pPldGNAiO3qcZosvDmOho 7MKBxcIIwS9eeiFEnqWEXd8Oxqlqff+dMItDARm/aiyKv8Z/S26qTTtlh1qY0OtX8PlEYVlWMBxS /mN0L/TW9c1DP5hVuxD2gzq54lfplSUHzXXhkJ8iFTN/TUtref1Kbw0CVS4a+5b+G8zyIRNInQSS yoAdPqf4y6s1bp/6C7OIMZVaFAbmEmMjZLXBMjTfKbLMLFFgXwNjZmNiZ8lhj5Ure7bIU5d2b1Z3 XQG9Ys07iO2xpY4Tgk07Ht7eomPGHHjsJ5IuZ158vAK/eGN2ccd6fYqW+aXyRdmn9KmkKZ5SH3f/ +BQvdsk5v3m1DLQUsNuaCIcgXqnhkPLTYEFyszNcqqXNkQcXizw0CPaXlyGizUM8xmBSA9aD9Dr5 pPO6Y5GPQvM+/fohxV/vpzm5lT1ew4QU2MeDh/pRY5tNgf3lZU407iGWdZiqYxQr4YbNsrPTW5t2 ZN2zs66q6Vrml8oXZZ/SVxNKSDkgW85/r+Wrzy7qhHSA00oWBM6uX567Wl3V1QrdP7x38QzC1UDI 7p6eWUqUfWHId1jFZjgVf4fyutYkYXn9Qt8ynGrzNfbjeIq6EjETSr1C/f9/K1UqOao3ofSTRbjN ZjNeu0LrKo1dMp7ejkqAjpKnStyGnf/uzoHUKTvSMYPgnzWHWqPkWXwSWg7XYvG1DMeQHG5LcHMi /n1wNkqeihVM/iDsuQ5vY9fLkysXFqjXxOY0W03hYoIePqyEKXjYvEwmSuWX6nNlRIPg6H2aIbo8 xBd4MJ1wZo38eFKbWbMAZITIs5YCZiB6pvHFLsyGsxKyGk7x1/hvyU21GReZqp8B2XPdv3ROWH5w 5YJMgvJfrJLpuOrg+8cevDD0u02D/12Mb8mBSlcmZBA0+pb8HW1pDcnJQ6pcXGVfJsQCE0gxBLDx 5X/zgkMExQYmiQG740t+nvdKpYL1mmK2uV+mzNJX2VQJAeEQ5NkUKVAo8BXddR+9cfvkn/hWHZYi bvz0PbE3XNnXe2A56pW92yJCQ67s3brjq0/KdukpyOBLHadXLaraZ4gZlBgDNYdbhlja+b1L4wtb 1+LuAbc1WBKLCVDwENExpW7nmE/xXgWvuPELOXvZKtKsOV0qv1S+KPuUvkjanC7F87eOL+ITV3gd il1j7547ia8c6P2Hfejg5Rg+iQsBKyBEipSfFDcqnPK/wlt9gj/uipsh8IefqA9CE78OlZeMZSmY uS1/u6WohNjgb+/kkQd+HIe5JIhL8df4iVhm+8iOX1BW3Nc+uHxe3UKIagr05WWZKZcHUnWYqmMU KzhmWXbCYTMrTUYs7VB1jKqrVLpUfql8UfYpfSpdTX41pyhu5vBizdrjEsaFjNe/2HBAY5NPpUIC 6BEwnoU1Plg9VO3DL1QCGCKpP2LK5qG9ReCidnUx/x0tGKI8uHRu+1efYJmPqu9ambquqVSo65cK p9p8yn7cw6krEYtzRW+LDhdXaBFb+7JTvUncPUxEC1SzGa9dob5K4z0l5lVhQ32JxVHyVIm7yo50 zCAUf9rmozqJGiXPYuAMS0awNT5uYrcOj/2chfjD6Bvuu9AO4D4cd1/LusVOJdP/4QYSw3+YxFSk cWu9Js5ShYteCW40HDMLn+GCgIEwYYriRvW5lAP6+zQqljkcN88YepN3a5DxWW2zmgzB5ZwmMIPN reukPsWf8p/iJgya7wFkQnYKVP0s0bIzdnbC5kUoqR2jB0prlP+LOzfEzAA8xKFeodapM7hlXFWg 0lV1VJnSp/g72tKKtMw8qXJxzr6aI5aZQCok4GXIMy45ESIEOUDmaLjBrP5wTd/OUMCUEPyTmu8d uYumXB6mEoFCUfLVLmH37y1/u8WDyxfwdqLIy62r9RsOJhCwVda6/m/iPSGmXqODLNyopWCFfh2H cWdoaQffa989buitvw9jJh221Xuu/dtiwK7xpAXon35pVf3x7Vt+QVny1W7UeOJ8TdlR+aXyRdmn 9KmkKZ5VPxiyf/oYLCjAsxbmfmMJQ61piykjIjxn5ZpzGpTCDsTYxggflxSBlJ8UNyqcSrrcm72x X+GmIb3unj3hG5hRHZZ1qLxgn7q0LZMu0bLTindfvX/xDIbVMLcO34fFGg1oUvw1flrab/jNbPi/ 8r3WgF/j45HYYsZSTQZqysuhfEmDTghUHabqGMUKSVuWnRMuWdqh6hhVV6l0qfxS+aLsU/pUugiP 1zKt0uszjAL83KgMNtPBI4T8kI7GHz6VSgig4mGpDr4vkad6/TYLt5rXvqEXyFvzRUylARBUnoOz vls/oBuevjCFBzNrsP9U/IGirmukaHm9UNcvFU61+fGXI+pKxKK5LcP74gpF0oUaNhfvijRuUL2J JRaNncQ6Zekn1WxqusK4+6+v0tila+Nn74fcuIJlFuKRgSJPeUKVuKvskOn2/hz78DytUbFf85Rt Pj5WEDygG7bQxcJG7FUn9p+BEeyri9+lbzXFcHymIiURhbKshuPTE+hZ0D6ogZYyVbh4eVnytTfF nsUlW3fZ9HmPJt8vhAWKG9XnIoplpXL0Ps3SeQRiAztsAiDP4ssteJcvN5qU4VLYP20M5O1fDZAh 8pFThqgCxZ/yn+Km2lRlSziqgkGm6mflHgOxv/PcJhWgj5tzOWpJ+V+ha198JwevRvBpQazhbTr1 N0NChkMqXYOaPKT0Kf6OtrQyIYNAlYur7BuS40MmkLIJuOvbx5Sdec4dE2ACTIAJMAEmwASYABNg AqmZAMZr4uOBCO8d8W1Ne74kkJrhp9S84wM4v7au+db2cyk1g5wvJsAEHCUwPChERNm/f3+aNGnS pk3r6+vr5+cH2dvb28fHx8srdjqdu7t7dHRMePiTsMiI06dOJ4klsY5mlfWZABNgAkyACTABJsAE mAATYAJJkwCm2R6dO03sYJM0PWSv4oMAPjSE5S9hD+7tHj+0UMMW8ZEE22QCTCDVEIjdDs64JDbV ZJ4zygSYABNgAkyACTABJsAEmAATcD2BiUV9c1d9AZvNud40W0zCBLAd0KL29aIjwgvUa1qt37Ak 7Cm7xgSYQFIhcOfOnfDw8Fu3bqVLly5jxox58uTBNDvpXLzMAJfWWWACTIAJMAEmwASYABNgAkyA CTABJsAEmAATYAKploB5SSwWwg4dt+Ho9YALEZmifdyy+d7O6n7xhcJeA/q+6+HhHhkTdfrUGXfT F2RTLUDOOBNgAkyACTABJsAEmAATYAJMgAkwASbABJgAE3AlgZCQ/+xh5+7u/cGXRw7dyByezsct nW/aQK8Afy//NB7ZIk7VzXP/jVdfTJ8x/blz5736XnClE2yLCTABJsAEmAATYAJMgAkwASbABJgA E2ACTIAJMAFBYHjQf0h8PPzI3lPpYoI83Hy8fP08/dJ4B/inCfD1jPQqs/3qkQdTZ3/Yuxsi8Ecn /kOND5gAE2ACTIAJMAEmwASYABNgAkyACTABJsAEmEB8EPjz+N1dJwPc0vt6ZPBLk8E3fXr/TBnT Zs6UNnNQxixZggKL1jz5IODnn35G0jxgFx/8k6vNC1vXTq+YDd+2T64ZSHC/mVWCI+cE/0OAr1mB w+Uc+NL+Tz3jAyaQSATi6UqMJ7OJBClFJeuqonGVnRQF1yozDMqKSlzDmGpcCXJ8JpAKCIyddtUj 0Lfui7kavJCtdMH0gQE+mQL9MgYGZM6QNmuWLNmyZffPXf7evXsgwV+JTQXVwe4s7vzm88YT5uWp Ud/uGKzIBJhAYhLga1bQZw6JWQs5bSaQ3Aj0OR+T3Fxmf5kAE0g2BLiFSTZFxY4ygcQjcOmeb9VG OepUDIry8Lz7OGbnqSf+aX3TB6bLkD4gIK2bl7ebT1SVsO0r4aBxwE6+EzC0NZbhF7evPzR7wpW9 26IiwgNz5Sv2SruKb3/k5efvaMZt2nlw5cKCZlUe3b5p8MrRhJK+vgbF/Qtndk8YdmnHhkf/3MxQ oEiN/l8WatgCOTo6b9r+6WMfXL4QmDtfpXcHlG4Xu9RZlpfMcpr0Gd87fEceWgp3Tx/PWaWWeoqy Yw4XRfP4zq2dYz87t2nV49u3/IKyFKj7cvWPRvhlyqLaVGVNfi3zpbFvqa+mZZAteV7dt/3wnO8v bg+OfPI4Hap007YVuvfz9g8wxLV5SPlJcaPCbSZkUDDbEeVuDpeXkjwlQww21cOI0BCMjJxes/jR revpcucr/+YHZV/vIRQc5a+atV82NAWa8nIoX/Y7YNbU1GHLOgYLlqykwzIJvmYlCiFIROa6am67 DHH5kAk4R0DUOuwskjZH7rzV61d6b0Bg7vwwhfDS7bu/OGq6NIsQ1MzIsCcHZ44//vvcB5fPe3h4 5qpap/wbveP1NZhlO0O1jfIikm7Lq8nOdknqSwssxAcBWVIG4JbFRBW3SxzTV2lR7V2SEBuxLFwK C3WfSVUGzb0KlYQT4X/+8mPwgG4NRs8o1barGt1V4apNlpkAE2ACyZcAvvsaGu1TonCgn59XZIxb YIy7XxqvtL5PPzrh55YuwM3H2y1DgaCzG8KQR+OAnbgzkDcKkoJl+K5xQzA8VHfYpICsOUKuX9kz YfiqXu2azVgmY9kp6O1ER0au7tmu0vufbB3+oZ0Gk68aheLe+dML29Yp16Vn1d6D8dhw9+wJjIth wO7UqkV7J37ZaPycrKUr3Dy6f03fzr4Zgwo3amm4w1vy+ksYO7OJJTz0oae3j6qmsWM4JWKt6tU+ U+ESbRfv9M+c7dE/N/6Y+jVCXp27XrWpylR+qXxR9il9NS1Vpnhu/3pgmY7v1ho0xj9z1pAbV/fH +t+u+Y/L1bj2yJSfiGvJTRNuT3JSx2BcLXfDKUMU8yUvFVRhy/C+GDdHgabNmef++dM49EkbWKJV Z0f5qzbtl81Ngaa8RH7tzJf9Ppg1qTpM1TGKlaGA1LIzJypDUs81iyxrytTMQSJigQnEkQAqXlR4 2MOrl86uX7awTe1Wc4MzFiwGmxc2r7l2YFeOCtVU+2v7dvb2C2jy/cL0eQtGhDy88sf2fVO+ir8B O6qdsdk2qj5DptolnDI0TYaIfBhPBCybO6qYNMUdd/cSuErH3eFkaoEqXCo71H0mVRmoexXKvnPh Z4KX4nHjzPplhgE7V4U75xXHYgJMgAkkRQI+XunS+qTx9nCPdPP18fD1ifbz8fL38vbzcgvAmF06 N49ot+Ph4fA89oWwOQPUGzMqXFgID3kwvVL2nscfmQ06FGKws23Ux3dO/41BE33qDiWRXJQlitW9 O2R9rmLF7v0Mnv/Wvl7pDm9jbqMIx1v9P3+d+eq8DarauY0rt43s32nNEQ+vZ+OzYhRDLXoRImOp p2Sgaocqi8kl03bbcyVNuvQiVtiDezOq5enx50NxaE5XGheCzC+VL8o+pU+lS/E0+BN2/+4PVXL2 PPGYsoMc1R85befYT3EpFW36Wq1Px3ql8YUy5SfFjQqn0kX4yRW/7P/hG0ws8s2Q6fkPBpd67S2h LH/tKS+pbOkAAqGgVoZpFbJ2WnskIEt2ERHD9BjQfG3hNg1/jZ9m+zB7fOm83eOHPrxyMWfF6g3G zBSTWURyNpsCQ3khlmW+hLV4+pV1mKpjGlbSJbXsRKCZlQiRUdRikoGqHQoFVVepdKVxIcj8Uvmi 7FP6NtM1ZETPQZw1wzGHYxYJ2slTK36NiYmu/P7ArSP6mWMZ8s6HqYGAob4dWzADE1VenrQA4U2n LNr93bAOK/aLvlVoTiru3x2dYPqMCQOHamcMqcu20ZAdqUZdj5S+jOhygboSIx6F4qo8s3YJUiz8 Uqvan30j1nPAQ3S+F7YFl3+z97UDu68f2lNjwCi8eIOaZW8CfeGz4QJHOAp0x9eDHl69mKloKUwR ylKynMtz56hBA3+qmAxmZXEbwp07pKq0JCnNSqQUeUvCVInDrKUdhCNpvFg9NGvC43u3q/cbXqFb 7Ot8jR3poSoo+jFVeg7aMqyv8N/AXB7GREVh8P3YLz8Cb8EGzeoNm+yNNUtP/yz9mde0IqpivloN oYK0ZlTN/fr6v/yDsqo+qDJVuGv6dPL2T1t/5FQobxj0TsTjRy+NmwOZ6ltVm5CpyiD7bjhveR9r sGPPYeTjR9Mr5+i0+tDPjcu9ve+aXHHlqnBLH+C/IVzWQ0O4ONSUo+X9KsXf0jgCpT8GNxDuUEuF tWvbR318Yul8TMOp0vPTLcP6CIOU/zf/PLjz60HXj+zDi6Kg4s9VeX9g4cavUk6KcMvry1E/ZX5l WsJPTYtt2Q7I6GbBslw09inOZsscwgQSnsDwoBCR6B9//FG3793+/crlye4XHun2ODx659mIzJnS ZUofmCmTF+4iM2R0i3zitnlo5569e7nyoxNnN6zIXfWFuOdctXN+y5qTyxY0Gjs77maTowWJ4tLO jViYOadh6YlFfWfWKoh7SqzZRI7QQOd+vo7MWp5qdW/9dUgeQsCkpG1fflT782/laJ16VspoXkUL KwV5SghmOxjJmlDYB7cgmAp0NvjZtMpCjVruHjck5Nrl6MgI/GLkBTfWBlOaQ5lfKl+UfUqfSovi KfWR3/sXz277akCe6vVkoKVwbtNKDIZiGOvhtUt7J44QOpSfOGvJTRNumeih2RP3TBxR5/Nx3fdd a/HTmqv7dxrU7CwvQyybh+5P/1S128eP4pDib9NP1ZSQsd62+cwVWL6dt1aDDYNiH7rEn74psL+8 /t9efP1f1mGqjlGspEPmspOnVEFeqlJQz0I227Gse5q6ajBoeSjzS+WLsk/pW6aiCZTZl4JGWXNq 74TheFDvuOZwp9WHL+3apNHkU6mZQMEXX7m8e7MggMehdDnzYAGsCiRXldrr+r91ec8W0Uerp+JD ptoZmZa5bbRsBzTXo6W+tO9ygboScWsReusartCOqw+ht9393Rcy6ec6vNN8xrLd47/AriwtZq/6 Y8poccqyN9E0FCeWL2j587p3Dv5T6MVmGz9/ttuDTCUpCJpiEu6ZizvublNVWpIUAn5lWpbkcdaS MFXi0Kfs4NTFbcF4Od11x3ncG4h0NXaEguEXN2zP2vw1hy/u+M97boOmODwwczy6htbzN7617ayH pxe2B1HVzP5gyfyx+T8InXMbVuQo97xmtA5qVOHWGxG7T8vptUtAA28LcChsUn2r9EpfGWTfDX3L +1hpx37hwvbgbGUrB+YpkK1MJcgyoqvCpUFVkNUPQvX+X1bpMUg9a5apcqTuVyn+ZssiRPhjedah lmrf5FH3zp3qsPJA53VHZacDs5T/K95pVbxV567bz7937P4Lg8f/tfgnSx/UQOr6cshPir+mxbZs B1THVJkqF419yn/VLMtMIEkQ8PH28vGIiIqJiomJiMF0Oveo6JjIGI+oaLeISDf8RkY+c9O4JNZp 70+tXLh1WN82i7Y5bUFEVO2E3rga/NGbL0/+Bcs842g2OUZXUTy++w/6+5cnLkifvzAGwjATBP+w GBmvyAScTYN74tA3U+awh/fVzB7+aTIW5uSv85IaiOZVPbRHNtiRFp7cu3P98N7towb8c/IYukn4 sLhTg4Mz8wib6LnV9bAylmWKan6pfFH2KX2RkDldiqfQl++LMhUq3mbhv1XabAf6tQeNxZJwISzp 8hL27INM+SktGLhR4cIfeVYc4hePiKgMwAsZTmIugDwlBDvLyxDLcGhOFw+oeIyp9clorMvGUiy8 /Yt4HIpYFH+9n2b7MIU3b8KNcm/0xqCkkPVNAVVeIm5C/qp1mKpjFCvpp6HsRLglKxnFUjDYkRYM dY+qq/akq+aXyhdln9K3J13L/FoGylwbzprDjy+b3+qntWL2aO1Px6K9NUThQyYAAr4Zgp7cuy1R oHovaP580VfapsvxrNdr8v2vB2Z8u2XoB3fOHE+fr1Ds3r7d+8mZJjKiqwSqnRH2zW2jrPmGdoC6 Hil9V/lvtkNdiadW/9ZqzrpnV+hn3yzp0rjmJ88G5nJWquHuEfv6OVeVWhAw9VuYtexNzCnKELwD Q9eGQwz87Zv6zLg8mxQEqpiEb+bidonPTlRpirwlYarE4TxlB6cw4wwDQxBQK0Q2NXaEguH3xLL5 Lf+3xv42H6NvLWatFLP+MXVu/iuV6wweJ22a/SneoiNermMXEYzTYflL8ZadpLKlQBUuNh556bu5 y7s1R6xmPy7zCUgnolN9qzirrwxq3w19y/tYYceh37PrlhZqEOsnfvEiX8g4dFW43pk93w2Ljo7C mJ1ejSpH6n6V4q9PxfKsQy3V30vm4PVD2uy5YKrWwK/PrPtd2KT8d3N3v3Pqr3Q5cmfIXyRHxerN flhq6YMaSF1fDvkpDRr4a1psy3ZA2jEIVLlo7FP+GyzzIRNIfAKebl4Ylotx8/L08PJwi4lxj3Jz d3PH+J1bZLTbwzC3J0+e+eiCGXaYS4U5XFiq0HzWyowFijqdebOd1R90LNPpPbzcc9pmMo1oRuET Ox9+WlCx0lhxmSF/4XpfTsFuF8gdOhLcdkNAz43fJ3f+kctRYw/v3dk3eSSm10GOy5/GDtZjYjTw lWmL8YiCJNZ92CV7uee77rzQ61QYfrOXqby27+s2k7bIL5Evyr6eg9kBiqfQxCNK79Phb2w6mb18 VSxAMEdXQ9LlyisOIYTevCZkyk8Z0cDNZrhUEAJeCwcVLWUIlIf2l5eMYqeAgYwM+Qr91qnB96XT r+rZNn+9Jnh8RVyKv95Pc6I3jx3AgO+Usplwr4nlHlhGIXT0TYFD5WVO1CUhFnWYr9mnS+Opa4Gq My4pDieMPLp5TbmW8zlhgaOkBgIYrfNNn0nmFE/vWI63eXAvGYKKXbXPUMwC6/l3KL66fu/Caayo kmddLjjdlxn6IJvXo0Hf5RmRBqkrEd2reoVCTUbx9Enjga+pubkJAa0xZKo3kbHMghitQzgGWGXv Y1ZLxBB9McVTV+holdaQtyRMlbjGDopA3S5DlAhlhyovvAhUaxSlJsNxPzOrTmHcnODf9IrZQq5f lqcgmP3ByBqWmPy96H9YlHpl3zY5eqXGUmVN4eYoXxWv3vECADfYMgrVtwoFqjKY71Wgr3D49z5W JmSnEBMdjV04sFgY+vjFSy+EQHZVuN6NXd8OhkK1vv9OvMWhKCz8qnGpctTcr1ryV23aKTvUUoVe v4LPOQrLsoBwSPmP0b3QW9c3D/1gVu1C2J/q5IpfpVeWHDTXl0N+ilTM/DUttmU7IL01CFS5aOxb +m8wy4dMINEJYNEafIiKjMYLR4zHeXpgrC7a0y3GPcYdMsbvPGPcvP9/oC6uM+zwebJVvdv7ZcyM Wbt+mTI7nXlLO5gDjH/YJ1WaRaODTkgepkjBEgX2IzBmNiaWA/ZYubJnS9GmbcXZS7s3q7uuAF2x 5h3E9tjG6I4c27Tj4e0tOmbMe4/dvicwA8yny5kXb7qwZlaflGV+qXxR9il9KmmKp9TH3T8+xYtd cmz6j93WoImIEMSrUgA9qgAAQABJREFUMMiUn9K+ECQ3O8OlWtoceW6f+guLDmSIKthfXmose2Q8 xmBSg5zXsH/amLw16iMixV/vpznFlT1ew74b2K8dVQj3uBi5Ezo2mwL7y8ucaNxDLOswVccoVsIN m2Vnp7c27ci6Z2ddVdO1zC+VL8o+pa8mlJByQLac/17LVy8mZNKcVjIicHb98tzV6qoOV+j+4dwm FRCuBkJ29/TMUqLsC0O++7Has5c6BgWXHFLtjDSubxtlO2Dn9Sj1pX2XC9SViJlQ6hXq//9bqVIO UL0JpZ8swm0Wk76445hH6yqNRw7cjj598BD2HSVPlbgNO0qKIl3KDpVr/6w51Bol1fBJaAzXilmx WHwtwzEk1/a3HeT2lCZ/EPG5Dm+v7dPZJ136AvWa2JxmqylcTNDDh5VgEJuOFW/eQbhE9a3SYXNl sOy7of8vB+U+VtqxU8AXeDCdcGaN/FIfIZjr5KpwadYsYCYj9hM0L4a1fGCkylFzv2rJ3+yGcyFU PQ/Inuv+pXNYQwOzD65ckMYp/+VqGyyFPrVq4abBPbCVm4hlyYFKVyZkEDT6lvwdbbENyclDqlxc ZV8mxAITSGAC2J4SKUa5eXh4xK6EjU3d0xP9rLunOw7wDy8io8KfOfX/A3fPDh373/ElP897pVLB ek0xSzwuo3WUHTQx6j84Z9noOOZ00tamUOBrvOs+euP2yT/xrTosRdz46Xtib7iyr/fActQre7dF hIZc2bt1x1eflO3SU2QRX+o4vWpR1T5DzDkWL1vM4ZYhlnZ+79L4wta1mMCP2xosicUEKHiI6JhS t3PMp3gfgpd4+IWcvWwVadacLpVfKl+UfUpfJG1Ol+L5W8cX8SkrDBVht9e7507iKwd6/2EfOnip hU/iQsAKCJEi5SfFjQqn/K/wVp/gj7viNgj84Sfqg9DEr0PlJWNZCmZuy99uKSohNvjbO3nkgR/H YS4J4lL8NX4iltk+suMXlBX3tQ8un1e3EFLbAdEIiF99eVlmyuWBVB2m6hjFCo5Zlp1w2MxKkxFL O1Qdo+oqlS6VXypflH1Kn0pXk1/NKYqbObxYs/a4hHEh47UtNhzQ2ORTqZAAegQ862JtDlb9VPvw C5UAnorrj5iyeWhvEbioXV3Mf0cLhigPLp3b/tUneGRV9V0rU+0M1TZS7QB1PVL6rs2Fao26ErEh g+ht0eHiCi1iaz91qjdR00p2MlVMVHG7JIP6Ko33lJhXhY3wZVqOkqdK3FV2pGMGofjTNh/VSdQo eRYDZ1gygi3tcRO7dfiHMhyjb7jvQjuA+3DcfS3rFjuVTP+HG0gM/2HyUZHGrfWaOEsVLnoluNFw zCx8hgsCBsWEKapvpSoD1XfDmuV9rE2HDQq4ecYH0OTdGmR8Vhs6rgo3JCcP4Txe8ZpH66SCQaDK kbpfpfgLs+Z7CUNyNg+pel6iZWfsNIVNkFDiO0YPlHYo/xd3bnh+82o8DKJ+ovaqM8FlXFWg0lV1 VJnSp/g72mKLtMw8qXJxzr6aI5aZQJIggCWwGJ2L/c/DE0N2bjFYGuvl6ebj7ebpHvtP/Bln2OFS ESeEIJ6KEWIZvqZvZ5zCVA78E7Hw+96Ru2KClQyxKbjKjs2Ekr4ChaLkq13C7t9b/naLB5cv4K1C kZdbV+s3HNmBgC1s1vV/E+/HMGUaHWThRi1FNtGv49DRsjAjsrSD77XvHjf01t+HPb19sK3ec+3f FgN2jSctQL/yS6vqj2/f8gvKkq92o8YT55ttyhAqv1S+KPuUvkzIIFA8q34wZP/0MVhogGctzNnG EoZa0xYb4hoOc1auOadBKexAjG2M8HFJcZbyk+JGhRvSkofl3uyN/Qo3Del19+wJ38CM6rCsQ+UF g5aXtkzIIJRo2WnFu6/ev3gGw2qYW4fvw2KNBnQo/ho/DZbFYcNvZsP/le+1BvwaH4/EFjOWajJQ U14O5UsadEKg6jBVxyhWSNqy7JxwydIOVceoukqlS+WXyhdln9Kn0kV4vJZplV6fYRTg50ZlsAkO bv3lh3Q0/vCpVEIAFQ9LbPB9iTzV67dZuNW89g29QN6aL+IDsgCCynNw1nfrB3TDUxOm8GBmDfaf ij9QVDtDtY1UO0Bdj5R+/OWIuhKx2G3L8L64QpF0oYbNxbsijRtUbxKvzYjGH0dPWfpJFRNV3I4m aqmvr9LYXWvjZ++H3LiCZRbikYEib2kcgVSJu8oOmW7vz7Gfz9MaFfsVTtnm4yMDwQO6YQtdLEjE XnVi/xkYwb66+F36VlMMx2cqUhJRKMtqOD49gZ4F7YMaaClThYuXlyVfe1PsWVyydZdNn/fAKgRY oPpWqjJQfTdMWd7HWjqpCcRGddgEQCrgyy14l48FGa4Kl5YNApZ6IGT7VwNkuHx0lSGqQJUjdb9K 8VdtqrLllasqGGSqnlfuMRD7RGP6NvRxky9GPyFT/lfo2hff28FrdXyiEGt4m079zZCQ4ZBK16Am Dyl9ir+jLbZMyCBQ5eIq+4bk+JAJJBgBMcMuJnZynTsm2+F/UVHR2NEu2t0D35qI/egEQmL3FYj9 S/krTEU++ZcJMAEmwASYABNgAkyACTABJmAggHEW/UCPQd/OQ7x3xDcx7fkCgJ0GWS0VEsCHdH5t XfOt7edSYd45y0wghREYHhQicrR37976nz36uHuJnLn8n0S4PYly23oiLChj2syZMmTM5JUunVva QLdHD92Ojuvcs3evOC2JTWEEOTtMgAkwASbABJgAE2ACTIAJMIE4EsA026Nzp4kdbOJoiqOnQgL4 YBGW0YQ9uLd7/NBCDVukQgKcZSaQgglg7zqRu7DI2N3swiNj8InYaDfPiBiP8KjYGXbh0bGT7MQf D9il4JrAWWMCTIAJMAEmwASYABNgAkwgoQlMLOqLz3Fgk76ETpjTSxEEsK3Qovb1Zr9QBN+RqNZv WIrIE2eCCTCB/xCI3bzODethYyKjYtyxLBaLYiMh4mMUbpFRGMV7pmzcw+4/NviACTABJsAEmAAT YAJMgAkwASaQcgnEx3rY+LCZckuAc2YkUKJVZ/wzhvIxE2ACKYJA7B52jyI9vGInz+FDsZ4e7h5e 7vjyxP9vWxf79fXM6d1OP82s17h8KSLTnAkmwASYABNgAkyACTABJsAEmAATYAJMgAkwASaQxAiE PNvCDuNx7m6RkZhU54nvwmIpLD4XGw0hSq5+9fN0iwp/5r3X3zeSWD7YHSbABJgAE2ACTIAJMAEm wASYABNgAkyACTABJpAiCOQJeJaN2Bl2EW5RETHuHrHrYr283CLxP/cYD88Yjxg3hEVEuWFbO/HH S2JTROFzJpgAE2ACTIAJMAEmwASYABNgAkyACTABJsAEkjCB2Bl2YRFPQiOjw2PCo6PDwt1CQx77 p0nzyPuxj08aL89Y1zHDztMzVpLT7pJwhtg1xwmUzO4u/jkeNR5jbN+0tmbpbHAsHtNg00wgRRPg yydFFy9njgkwASaQPAi4qjNylZ3kQS31eYnyFf8MWafCDWp8yASYABNIqQTSekYeP30/KiI6NDz2 36Ow6IePwh48Cr/34NG9ELc7D9wunb3t7++P7PMMu5RZB/66HvvNkaR2GzRh9Odjp8yrWqt+yoTO uWICTIAJMAEmwASYABNgAkzgKQHqeYQKZ2xMgAkwgdRAADPs8mUO27Xtql96H/f0PlcfRD0IjfDy xABOTHQMJtxF+Hh7hZ7bXyYoCDSMM+yoNx6W4Qf2bO//XocaJbNULJj2ldqlvv9m2ONHoU4g3rV1 fY/Xmz1fLGOFAgFNa5WEnSePH6l2rl6+kKpmZv0270cAx68KIXFllxTBudPHK1atZZkRO+1zVbGk x4GJSEC2jWXzpHmxUv7hn/S4d/d2IvrjXNLIhXMRORYTSA0EzJ2yvPBx39K4etExX3x0/94doPg3 PL9/kxrFp3w7PDw8LDUg4jzGNwHDbZLN2yGX+IM7/H9uXldN3bpxDYFqSBKXKVCOPsI4qg8ssjVQ EbnKjjQuBTUVyIYKs3LJfDxhlcvr2+rF8vv3bDMo23ko01IFO+PGXU0majB16fyZgb271C2fu0we HzyNblj9OxQehYZ8Nbhv/Yr5cG+GJnrerMmGWIZDqp7IRKVgiGjgbDhrPjToU+maI4oQ6YYUqhbL pCob7KunWGYCTCDpEMAedtUq+YbeC1sVfGXl5utHT9+PiIgMC48MC3v8KCTk0cP7D+/f9rzzZ7ly 5eCzccAObzzESw9DfizDvx05sM6LTRZvOLTnxN1p81bdvnWj3zvtDBHtOZw0ZsiLL7f8fePhvSfv wQ7aGtVOVGQkDrv3+sQeUylDZ+OapbXrv7xx7bIkkh1XFUFoyENvbx9zpuy3z1XFTI9DEp2AaB4P nAudu3x7usD0eI2R6C6xA0yACbiQgGWnLC78XcdvT5r9+93b//Tp1kakKMJ3Hr/91aSfdmxZN+aL /i70hE2lTgLm2yT97ZCrKBUsUuLMqb9Va2dP/V2oaEk1JInLFChHH2Ec1QcWVz06WdqR9sVZ/KoF Ya4wwSsXfzv9l/3nQgd88e3H73dSle2X1bRU2X4LcdEUKRosXDx3unOL2gUKF/9pyZY/zjwcO3X+ 4vkzoYPRuksXzs5cuH7v6fsTZi7GKN6yhXMMcdVDqp5AR+bU7ICZs2rTLJv1Nemao5udqVm3Uc/+ Q6Wm2b48xQITYAJJjUDLJjmeLxnu9jg8KjQi/HFk2OOIJ0/CH4eGPQp9/PD+g8iLezrWL/p81Spw 2x2tj9l7DNs7FC4sPLh/t06ZnAcvPDYbdCgk5OGD2s9lP3D+2SS7scM+xv3B93OWU145ZDzpK2N2 Ye0yOTAM2qp+ua1Hrvn6xS5dRt7RxU7/bqS7h0fj5m37DxmD/Qg14SKbZmJRUVEzJn6FyQL379+t 16jZ56Mm+wektcnEsghWL/1l1pRvMGkufYZM7/cb3Kr9W9IO0oWsViERIhXUUwi0tI9wsx1pQQip vKoYaPBhohAwXGUPH9yvUzYnBu/gDE71HzxmzowJmHPXe8DwN979EIGYhjx6aL/1q5ZAbtCk1YCh 34hrHIcrFs+bPHbotcsXy1euPmL8zFx58iMwLOzJ2C/6r172a0x0dPfeA78e2k9ePtQ1aGnn76MH x40adOzgPoybFy3xHEw1bPoq7BuuTYRI+5D5jwkwAapTVq8UTK+rWy437lsMDcL1q5faNKq87eh/ 5igxUibgKAHqNknaMdwOyfA4CkP7v1O0ZJkOb/aQdjBT6eTfR4d+PRVVffyMReNHDUKfVbhYqeHf ziheOnYigKaPk0ZUgbIDHYf6MtWmRqZAOfoIY7++oU0w+Oa0Hb1ZTYU5dmhfrzdbbjp42eCJQ4fm 1PXPF2Z9kRwVrnHGEAWvSEuWqfjme/0MUWqWyvr7piOZs2YX4TeuXen3brufl9o7tVDWE0NyhlQ0 nA2a4tCmvkzXMrohcMv6lXghtHTTEU98YPLpn037Bgt8yASYQAITyBMQIlLcv3+/t7f3jVvhExfe 3HoubVSgj0+gT/p03gH+nv5pvHLEnG1Q8EnnFvV8/XxPnT5tnGHnnNMY0cd7jG+GD3i+Zj3nLKix NgevqFz9BRGyfeOaVb8vGDlhtqqQsuWdW4JLl6ucO2+BUmUrQZaZ3btzM/oezEPEDMQfJoyyGS4V VOGn6eP37Ng067eNwXvPenp6YVM59aylbFkEc3+cOHXciE+GjcOQ4vQFaw7u22kZVwbiwUY820hB nrK0L8/qhVReVfRw+GwCE0AzeO3KxYlfDy5dtpJMeufW4FmLNqz/4/z2TWtEIN6mYkkRLuQlGw5d v3Jp8tgvpPL6VYunzFmx+8SdanUafPHxuyIcS+quXrkYq485yDs2SWXNNWhpp/dbrZq17gxP8LZ5 4PDxSxf+JEzJS1II4jqVqbDABJgA1SkLMhER4bj/mTh6sOX9T3R0NANkAnEkYM9tkno7FMfk1OiY THf2ZOwMu3oV8mJ1IYQzJ/4qVKSE0MH9+Yxf1u38+5+6jZoNH/hsUE/Tx6mWVdnSDhQc6stUgxrZ DMrRRxhH9Sln4m4HbwexCBRLQd9u/9ImZVGOpsKc+OtIzzda9B3070ME5Z6j4U48XziahKX+7u0b /f0DmtUpjdW+DasUHD9y0JMnTyeOYIMofIRR+Tv191HlyIao1hMnOFta15SL1FfTlYGWAurPmKEf ffLFt3K0zh77lqY4kAkwgUQhgC/AFimUeWy/4uO6+1cIupvR47FPdEh2tyvPBxzv0zBzzy4tAwPT Ccccm0ln+Z4BgcJWwcLF5yzbljFT5rjkee3yhcMH9sQ7kPyFit68frV1w4qYwl2pam3YtEw9Lmkl zbif9nmr5HPlO3bt9fOMCcf/PDxiXOxOdsj76p0n8xUsAvnC2VPvdHx5za5TmnCRNTMxbKkzde7K PPkLQeHOPzfx5n/D/gtC2fKXKoJGzxf6ZtoCDCxaxqICzf5Q9ikLajhXFZUGy4lFALVaTTpbjtw/ LdksLjGcWrf3LAbfVYUGlQvgCUdcy+fOnHinfWPoqAqQMUOhRqmsYpoebkB/WLBW6uMSFmNq9lyD BjtNWnWo8ULDfAWKBGXJ5uHxn7c15mvT4BIfMoFUS4DqlPGY5OvrByyYtdq0VYdh3/yA2bLyUsJD I54PsSyrROnyn42alGrpccbjSMCe2yT1diiOyRmi79i8bsak0YNHf9+1TQNsuIP3T3iZhAna1es0 QFXfdPASujxEwSzU6iWziD7Lnj5OTYWyo+rY35epscyyGRRSF2p2PsI4qg/jiGJ+E+YqO7CP6b1H D+z9ZsQArL95+4NB+grT/IXn3u37GTTNcBwKMWdK/3xh1hfJUeEaZwxRnsvlVbPuSx9+9lXeAoVv XL08Zlj/bNlzockd9sn7eMzp99nobDlzY9kspp5hg4KjlyM0luUpcz3BKYc4S1NS0JeLULNMV1ow CHN++A6XJ57pRLg99g0W+JAJMIGEJ6DOsPP19Q0ICMAv/jB45/V0qmxkZCS+DOvn54c+F6+EwyMi XDPDDv3QkUvhGE4qW7EqJs87nfPIiAhs2zx6SD+0Phitg52P3+/Yrst7YrTOabPJKyLexmOGM95V wm384k2LfD+fI3dekRcIN69dkfmiwqWCKmAGUKOqhdHb4R++43Hjmo0p8VQRYMoPVkColp2TKft6 a1xV9Hz4bAITQBuIf7gRxPw1bMc5YlAv6YBY1ioPIWB6nbxmc+bOh0Nx9q+jB7q+1gCbB+PaxGd8 5Id3DPrSFHUNUnamzluFvcNHfvYBRvqw58CaZb9KUywwASZAEdB0yrjk951+gH/Lthw7fGAPZsEL I6KHrV48aEDPztVqv9h/6FjKOIczAZsE9LdJ5tshmwYdUihUtMSZk39hkilqcvXaL2LOOLa0Q6Aw IkbrIGOomuqzZB+nSdfSjmv7MgqUo48wjupTuXaVHdjHvjQ1672EbdpmT/0Wh/oKc/rEn3EfrbPM lKPPF5ZGnAjExj5Dx0wrUrx0mjS+GLMbMnrK2hWLYjkMGZsnXyHcVlUpnP7Dt9vWadAkQ8Ygm/ap eoKIDnE2J6QvF026ZlMIwejhtO9GDhgWW+LiT2///7X4/0yACSRFApgOjOWxPj4+adOmzZw5Mwbs DPMqLF77IB+43URfYs4QFS405R4u5og2Q/CJn37vtsfsPGzSLOfoITlzREvHzGrJNOTA3h2dmtVU nf952fYKVWoAhTrDDrPf1+45AzUqXFiokN9/14k76MOkQXwiat6KHYHpM8oQvUAVAWb9fPvDr+rS P70dcRbWDMVH2ddY46qigcOnEp6AoVZjD7sXyuXafzZ2hwLDKeEbviT746/BYsbc+TMnu7drFLzv HE5hJP1t7CvX5NV06TNgUxuM3ImLBeNr0+evkfov1ygmwqlrkLIjyWAZxZrlC0d+2nvHX7dkYKkc HseuRhnWj8izLDCBVEtA0ymr3RlG6/DCcsW2v0vn9FTDUy03zrirCGhukyxvh1yVrrRTuXBg8VLl 2nZ51y0mZuHPP2AcDYPUOGvo4OQh1cdJgwZBRhTh8tC5vsxgXBzaA8rRRxj79WWOLH1zlR2Ml7Ws Vw5baiA5c0Iub5TMmdI/X5ifR4STVLg5CzLEkHSn5rW+mbogW45cQgEvJlvUK7v92A2pL4SZ3485 fuzQ19/PNYSrh/bUE6c5a8rFnnRVPyF/OagXZuNgYyIZrrEvdVhgAkwg0QlYzrDDfLo0adKIMTsx zw5PZNgY1DUz7N5q8yI+nYZnS5jDkyfmGz9XPvZLFo7+LV/0c+tGlV5o0BRz6+RoHYygg1H/iRBH jScvffDEBxxkriHLbSnGDv8Y/RA+xQvh5ZbtZb6ocCgUK1X29wWzUd5S+bXOb3/Wtyv6hvDwsEN/ 7OrxeuxUPs2f9EQI0ISA39ff7vN5366wgHeqKPovBrynGkG3YdlzqDpCpuyLs2Y7XFXMDDkkiRDA hYapBLOmjC1WsozGJXzqQVyzuJyxdkN8+QH6uJQyZc7q6+9/5dL54Z/8u8M3Lnbo48KHcehLy9Q1 SNnp1rbhto2rH4WG4NrH8qL0GTNJUxCyZs+Fub1qW6GeZZkJpFoCmk5ZZVKl+gu4e8GHCNVAlplA 3AlQt0nU7VDcUzRYwPc3D+zdXq1WfUyy+2P3Vnw31qBgOKT6OIOazUPn+jKzWQqU/hHGfP/pqL7Z ExHiKjtvd2i8fdNafKMAoI4e3Nv//Y6tO3ZDElSFEanbeXNOOa8J1z9fmJ9HhCkqXJOQ4RRyPeiD NzBzEPc2WPqK5xF8zgs6+LCGCMQeo/hk3/+mjevx0VAZ11y+VD1xmrMBNVUuVLrCVbOfCMeXGDGL sEe/ITI7ECj7qg7LTIAJJGUCctoEhP+XsRNn7DsYGzOecP2LjJnbHYTv37Nt5uQx6L+xwBZ7BNR7 qTlmiGDOsKMsDMZF9D0n7mKmiWoKatIfNTwlyZg+M2bKvFJlKopM/Xlk/8fvdVy54zjy/tHgr3+Y 8BVWOL/U7DUssRHz5qhwEf3Y4T8+6fk6PuSKVdACHVb3YGu8X3+ahkEB7CX8Tp9PRcdmJ0O1CPD1 rv9N/RabcGG+Xo+Phrzaoas0AjXI5sJSo0tlVTAomO2IEDUK5NRZVQwQ+DCxCMg66eXtnSkoS5Ua dfsOGpkjV+wCdkN9Fh5iyAzbWmEUAIdoM/GCVHypGXuRjB7yIXaozJ4zd59BI/u9005cQfIrsdFR UdieRv1KrOU1SNnBaN2MiaMP79/t5x+A7Qv6fT4aS0gktJVL5uOrQTevX0ETYb5ypRoLTCC1EdB0 yoYrJXjlYozX4z2WITy1EeP8xisB2a3IrkdNznw7pJ51Th7Yuws+Mo6PniF6i7plSj5XQXwITnoi zMpDqo+jUpcRDXac68vMqVCgTh4/qnmEEbHUa1n/yGPWhyeGpIU1V9lZt2LRrCnfnPjzMJZR5c1f uE3ntzF0ZVhFJXxQcwGX1EMzLjtDzHb0zxfm5xGREBVu6YYlT2hiN7e5Myfhi3yZs2Rv9Err3gOG 4z5n3Yrfvhv16cULZ4IyZ61aqz6Gt8TmwsKyMKWiMBgXarigdm1b7xxnWFDtC4PyVwKk0hWPwGY/ YQFjiPUaNmv3xn+mSkjLQpD2DeF8yASYQOIS0Myww5JYTLLDDDsxYIfN7CKe/p08fco1DXfi5jw1 pE61vFR4amDCeWQCTIAJMAEmwASYABNgAkyACTABJsAEmEASJ+DcgN1/PhSYxHPI7jEBJsAEmAAT YAJMgAkwASbABJgAE2ACTIAJMIEUT8ArxeeQM2iTgJhxbVDTTOQ2aPIhE2ACTIAJMAEmwASYABNg AkyACTABJsAEmIALCfCAnQthxqMpaviMCnfIFZcYcShFVmYCTIAJMAEmwASYABNgAkyACTABJsAE mAAToAh4lchGneJwJsAEmAATYAJMgAkwASbABJgAE2ACTIAJMAEmwAScJxAS4kxcr74XnInGcZgA E2ACTIAJMAEmwASYABNgAkyACTABJsAEmAAT0BMYHqQ/b32WPzphzYVDmQATYAJMgAkwASbABJgA E2ACTIAJMAEmwASYQKIQ4AG7RMGeRBO9sHXt9IrZxud3T6L+JZRbLufASBOq6FJdOi6vqymeIF+M Kb6IU3MG46l6x5PZ1FxSnHeKgKsqm6vsUH5yeBInwBUgIQuIaSck7QRIK4ELNIGTSwCALk+CB+xc jjQZG9z5zeeNJ8zrcz4mGefBFa4zB1dQZBsJQYDrakJQ5jSYQOomwHcFqbv8OfdMgAkwAR0B7iN0 dPicLQJcf2wRcjN+JVaOcRrYUeEigQdXLixoVuXR7ZuGWDaTFwoXt68/NHvClb3boiLCA3PlK/ZK u4pvf+Tl5y+jx9G+tJP0BQ2K+xfO7J4w7NKODY/+uZmhQJEa/b8s1LAFcnR03rT908c+uHwhMHe+ Su8OKN2uGwJlecksp0mf8b3Dd+ShpXD39PGcVWqppyg75nBR9I/v3No59rNzm1Y9vn3LLyhLgbov V/9ohF+mLKpNVdbk1zJfGvuW+mpaBllmwVxpzRwMcfmQCUgCmjrM1ywoufCateR5dd/2w3O+v7g9 OPLJ43ToPpq2rdC9n7d/gCwgOwXKT9lQSDuixaDCpZqdgtmOaKvN4bKlkqdkiCatiNAQjOqeXrP4 0a3r6XLnK//mB2Vf7yH0HW0zNaloThm6b015OZQvTYquPSW88vL1S5sjd97q9Su9NyAwd34kgfDS 7bu/OGq6TA4hKJHIsCcHZ44//vvcB5fPe3h45qpap/wbvfPUqC/VWLBJwKErXVYbaVZeF5Y1XKMv LSS6oHFSnpLZFN5S4XHPi75KI12DJ3FPkS2kMAKWVyKVR6ovpvoOzT0YlYSj4WjMd48bemHbusd3 /smQv3CVXp8Vb94BNd+yCxDG//zlx+AB3RqMnlGqbVcRAv2spcp3WHlAHM5rUuHmnwdx7cgrV/WK rymVBsuplkBi9S8OpetE++BEgRoH7EQbYW4+qHAkGR0Zubpnu0rvf7J1+IdOeIAou8YNwTBT3WGT ArLmCLl+Zc+E4at6tWs2Y5mwFnf7znmVKLEoFPfOn17Ytk65Lj2r9h6Mx4a7Z09gXAwDdqdWLdo7 8ctG4+dkLV3h5tH9a/p29s0YVLhRS0Nbv+T1lzB2ZjNH4aEPPb19VDWNHcMpEWtVr/aZCpdou3in f+Zsj/658cfUrxHy6tz1qk1VpvJL5YuyT+mraRlkTZU2czDE5UMmIAlQdZivWdEWueqapXhu/3pg mY7v1ho0xj9z1pAbV/fHtjntmv+4XBaQnQLlJ6JbtnWacDtTFGoG42pbbTglzWraLqkjhS3D++Jd GhrhtDnz3D9/Goc+aQNLtOrsRJspbdovmLtvTXk5lC/7fYi7JhyLCg97ePXS2fXLFrap3WpucMaC xWD2wuY11w7sylGhmprE2r6dvf0Cmny/MH3eghEhD6/8sX3flK94wE5FpJeduNItrxRNDbfU13uV 8GcpJ0W4Q3fpcXSeq3QcAaby6Jor0ZIM1RdTfQd1D2Zp3IlAPI0vfK1OhW59q/Ub5heUFY9ae74b hgE7mLLsAkQSZ4KX4rHrzPplcsAO4WEP79848ke2MpVuHN4XFvJAOkNd7FKBBSbABJImAefaByfy 4oIlsTvGDPLNlLlC175OJC+itP1tR6k2b6bLmdfDyxvvrusMHocXJtJa3O1LU0lfoFDs+nZwhW4f Vn5/YPp8hTx90mQuXkYMaB6Z833NQV/nfr6OT0C63FVfqDngq8P/m2TI5rmNKx9evVim8/syHLd6 hrs9GSIFqSwFsx15SgrXD+7GlLp0OfJg4A+/1fsNv35ojzxrNk7ll8oXZZ/SF0mb05UuGQSpKQVV wTIQCuZwvJHeNKQXNgScViHLgRnfqkZYTmEEqDrM16xoi1x1zVI8X1u4rXiLjmmz54rtPnLlQ/tz Sek+zNcmqt/RedNxYU6rkHXT4J64VEWFpPx0rrpapntyxS/zm1f5vlTgzBr5//x1ptmyPW2sOZYa Yk73zLql9UdOw6RsrzS+QcVKNxw7++j82ElhmjZT46fZPkwdXzpvdt2iE4v6/ta+Hu5dVH/M3be+ vNS4SUpGt4uJFeiFn/9g8K5vhwjfcK+yYdC7GJRUXUUhIjxToeLoBDFmXahB81Y/B6sKrpWpvibi USh8Qx+Efxs/fS/y8SORLkpwVc+2U8pm2j1+KEaHp5TJeGTuVHHKshxFiePX4DZCTq/+7X91i00q 5jfvlUq3/jpkUHD60Lkr3ZycpoablTlEQ4Cq0qJuIKK5klB1ybLOUHUYli3tiBSxsuTHanknlQiQ t1gaO5a5U/SzYlasrORSELHkYUxU1N5JX86sVRBXzdp+XTB5WZqFjtmfeU0rYk6W0EFaU8tnxrsT GcVSsLRDpYv5Wb93aQyzE4ukwTUItsImjBz4cRz6OFz7m4f2xssGEa5pEyzLhbJP+WOZIwRSV+Ka Pp3QRolYGwa9gwkHQqb6YqrvoO7BYM2yrxep2P+LFgnT0su/1QdPqehGc1aq0XLOWhHdsgvAKbS3 l3dvwTSUy7s2y7YX4ZibIvpf/IrlUPa7ITVRvoZ/8pSloCkvy76eKhdL4wiUzhgUEO5QX4M1dluG 9Xn63ITr8TtEFwYp/6n6aXBDPbRsTxz1U+ZXCiIJR68v1TGDbFkuGvsUZ4NZcUjxVNrD/zy3uqpc ZIEKN+ShAaP0WYTj0KBA+S8jGgREt2zfKDtUugaz8tCJ9kHGdUiI64Dd+S1rTi5b0GjsbIdS1Suf 3bACY09CJz7s61NPUmcliks7N2KR15yGpfFQhNuFHV8PwvovuIoGC6N10uc81eoa7pvxLLHty49q f/6th5dxNqWMBQGvd8QbHimoZyGb7fxQJeeEwj4zqubGTf/Z4GfTIQs1arl73JCQa5ejIyPwi0eC wi+1MpjSHMr8Uvmi7FP6mrQsT8nsS8FSzWbg3gnDMUjacc3hTqsPX9q1yaY+K6QYArIO8zUr2iJX XbMUT1lz0Ebdv3h221cD8lSvJwMthXObVnZac6TT2iMPr13aO3GE0KH8xFnLtk4TbpnoodkT90wc Uefzcd33XWvx05qr+3ca1OxsYw2xbB66P/1T1W4fP4pDqs206adqSshYb9t85gpsuZC3VgP5AIZT +u7b/vIyp5iIIQVffOXy7s3CgcKNX02XMw8e9VV/clWpva7/W5f3bBF9tHoqPmSqr0FHHHrrGvqg jqsPoZ7v/u4LmfpzHd5pPmPZ7vFfYO+RFrNX/TFltDhlWY6arvDE8gUtf173zsF/Cr3YbOPnz9ZZ y1ScFpy40i2vUKqGwzFLfacdjqeIScdJqkrLuiEE/EoUlnUJZy3rDFWHoU/ZwamL24Jfnbeh647z aGdEuho7QsHwi8b/2X3amsMXd2wwnDUfHpg5HrdzredvfGvbWQ9PL2w1oOqY/cF6yWPzfxA65zas yFHuef+grGoUS9lsh0p3xTutirfq3HX7+feO3X9h8Pi/Fv8kDaKNQh+Hyx87Euz7fpQI17QJluVC 2af8kakbBOpKrDcidi+L02uXoJQxSwOHIqKmLxYK+r5D3oNB2bKvN7hn8xAlUrRJG0s1yy4Amhe2 B2crWzkwTwFMpoMs45Zs8ybmG4bevHZq9W+YpyLDHRLk5Qahev8vq/QYpI9OlRfV11PlQqUi/LE8 61Bfs2/yqHvnTmHJcOd1R2UnC7OU/1T9tPREBFLtiUN+Uvwdvb4oP6ly0din/LdMguJJtZ/xXS5U /ZHhErjIDuW/ZWZFoGX7Rtmh0qXsO9E+UKb04bpBHH1MnA29cTX4ozdfnvwLXiPbVLZT4dTKhVuH 9W2zaFs82bfTjaSg9n/tXQecFMXSn8sZkCQgSQVUVEBUBFRUFBBBEIwoiJieWTFhlk8UA/oMmH3m h6hgQgEBAwgqwkPFLKBIOFRAcg7H99/ro2h6unpn9naP5a7md7+9mprqqup/p5ma7h4divXLl2K8 P2no65UbNkIgbPLgG/CHtzeb1qxS4GOqCE4x1REzrnXnZ77yBBbmNDzmRJ2J6qifBqENPaRhw4pl f82cNuXeAUtn/YBhAz683bvDNy/UUzoxYunrYSmV1aKeXy5fnH5OXhly27U6Y2Vyevz8X0YN7/nK uLwataCn3a0PouysCoVZzhDQ67C0WdUXxavNcniqKoR3YorAzKbTR0SGD3X42yb47W55ENsvKOKd vidiUh5ozk/SYPR1HJ+zi7AOOnB0iRCAk9jaRknSb8A+luStBHlFV/FEgWDK0Tfdj70UsNhwyr03 bl6/Fle5PtPtp18/VHV9aqQy1+K8qxCUVLT79oArL5U2mX+zq1TbsOIf8hDV5vXuRzQ5+UzMKFfM Lk++iSk/kwZevey3XzAjPrIn70XX6XvyUtq4ENxYgwfCnq+OLxmDbnvonb6dj7qpJDCHGSIpqZGX tXu1OhoE9iFRnljL0eEkos+oVBBA4G/60yXKHfIBL4Vt6VQnjRbK1XBOPqB7ZSOWVE7GUKW5umSt M1wdBtScHlw6fvDTCIiAQD1XheLQowSM319HDe/x8ofB79MQfTvlxdFqC8sjB9w7/OTDMcGKdPr9 wdRvvFzHrDrE6bCp5f49epOwg/DrYe2mpCyb/VNB7bpVGjaufWjbbs+9R2r1Me7dfie1vmYgLjn6 BGu5eIx+1h8yvzPBtURsznDio8Pev7A7xLs9PwrrhFQ6bixWV91jh34PBnkdBxrrlZ7gv+iRcotv GKxJ/EMAxH4f/x7mVoPALyY0KBqnqGyYV/HBJafitSI2DiKFlCniUA9AHD+BlblFRVsRs/Nf0jlc eXFjPVcuus6AdKix5ud3XsULJKyWgPKjb37gt/HvKiuc/1z9dPjG9Seh/CT9Bv6h2xcp2pngysWh n/N/Z8UlZxyeXP9ZBuVi9ZNjcv5z8uBb+7cY9FhNxNA/WPVEZZYqYDf26nOa9b4UL9+imgkigDlZ n99/86wP3uz+4ug99m6CJPHVH8SHJJHxQ5GZm49lTaojw8Kc9vc8NaxzC4wT6Fhxk4oxADSc37Bs aVZBZcoFLk1/YvDpIz4jTmyEQ092laqIBu7RsPHwU45AwG78tX1rtTgCfWJujVrY4xyv7sf1P/fk 50q6Xc66Jb9Mvjj9bhw4u4njr1v8Z8Fe9ZV+bISfOEOiOUkQsNRhabPFfVG82izXB6oKgLtbFMGq BX9Me2IwFtd0fbpkcZC1emhtsz7edSsZzk/SYPR1UfkkoAhM5ajW5ECDSafB+1hKEpDACwPMrnqr dwdE0DB2YG+Ev7+fgbRcn+n202908Q9fT7lvAHRuXLlcv+oevkOVl652l9OI1mVXrkpu4Okd62Qn 3nElDXMAFo/H+MOCC7zHQvAOK4y6PvM2JYkvwY01qNhaPW8AMbKL5b2KVgQaDk65cqRUfkJF68BH OFJf9uWXDMWJuaUbLZSr4eSMIU/8pCKSwcmwVdpRl6x1hqvDDj0oIxU40wuL06PL6DS6RL2N6Jes NPrGF49pRJdU1JtO/f4gAoUlJj+PfBmLHwunT+786DASdhB+PZxdRDewDnfiwKuxq3VGbj6eApp0 PUNp1vJVnyLyjj7BWi6cfs4fLlOOllj7kNaYUoDICx4cKLl7LObGDv89GBTqONBYT4YCEjl7VEfV UtFhfxL/ELCtqAiryI+45k4I79OhG5ZRg0O15eCzL8ayJFpUqxQGCc8ZprEQD9M82/TfMXUaAhT4 0xVy5QU+d09iLRfDgSCnocaatX8VYlcTpZYKDqec/1z9RBIrDo7+JJSfykM//mHbl9Lj/+XKxaHf 6r9fs+JweHL9ZxzLhXMpFJ/z36HE2r/FoMdqIob+waonKrNUATvMWcUf9vskM2gkejdB/KgEPgo2 5qpeyDZmw+ZUra7k46g/qgPJI2CFotr+B5sebtsGTo2mLQq/mtSk65nq6oKpE8EhSRTNft3PVttj EzMGIqqe1IwMDEjQjLnfF31VmFWpCmhs94A3P1gz67ZozS+XL04/J+82nbireXvWWV04H/tGwQQ6 hcQZEs3JgIC1DkubVX1RvNoshydVAOxhhxbX7raHovY5O9pm4Xz1FgRKOD9JvyKorwvIJ7H82vX+ mf0TFsgQRyeC97F6qiA0gimYWkWzq2Y8M6R+8RdLuT7T7aff4ujLz2h12c34xgK6fcTssDmakok6 fAcvL7/RXcj5/aP367Y5Tneg5UXXDuvSEnydCTolLa3GAc2PvfNR7LRlXIrjKTfW4DXejnq+aD5e obmNcuXoTpWIq6Vs6dRCuRpu+EzyBj+pTpPESXuVTknxcDuK3+1H2LrE1eEoejSLyjKnZ7tf5n9M m9LbCF3GJ6ERgFazYrGcnPgIzWC7NHzFmzg7ET5/cBXRmXHX9MksqLx3+y5Bp9n69HB2aaY2lojO HjPi0zsup4DdjnwVzlfTyeFM2D6B08/5sxMa2omjJWLiIT7yBllsLqY+4wA66ljsHzus92BQpeNA Y73mWiCy3lEnzBo94rBLbuSkjSEAXyLCtErsVEvy4GAOlDpt0K5TbI/JpA0EZm5m5OX7F8NaNXPl 5RjrreWiO1AammvXebX2WrlgLmodlGMpN5ng/OfqJxJaceDskiGDcMhb8Q/bvgxzdMqVS7z0c3hy /We8yoXrVynjdgL94c7jC+e/PTnPjaLHZ5fTFEP/4HVqzmlz8CPLImI+0CT0P+ixNpKo+n9557/Y MHWf9l0x25yidUpbXPRHdSB5BDgo8IJu/PXn/TPrR2wfi2VN2ENa7Q2HnVCxHLVw2mRsf1s47bPP 77uped8rVHaWzfl5zpiRrYtf8hgZRFyV3j8Yl/ynVj3Y6XbeZ+Mw0R23NVgSi8kUav/UWs0O/2LI rQhR4WUXfkHXat6KdPrtcvnl8sXp5+SVab9dcikUwenx8/fr1mvyvTfiO7l4JYLFy6GsiPDuhQBX h6XNqr4oXm2Ww/Otc07A59gQKsLOuMvnzkK7c/c5qF2QWbvkLzRPEFi1pOob5yfX13F8pc3fJ7Q8 /5oJN16AG3f0mfATfTjV81B9LKWyEn6771/cQw0c2OAP0w+xGblaHsX1mQ4/YdGvH9nBh/PwLIrP Tegbmeljt7oxUL/u8rJmKhmYqF14JsRaFayCaXPtTpMa8PR4/N1PYXN35efIs47DLkVAA0lWLZg7 5b6b6FEtERnhxhoshVb1HFUdY1Djzqe6rXPl6E6ViKthWzrXErkazsknIi8x60wqJ91VGnEQzCfC fFLKbNi6xNXheOkhxwxi/+L7NDQQ1UboKgJMmBiLLd5xE/vZoGuJj+gb+nD0A7gPR08+6sJudIkj MBjhMRWTcRp3Po2Ticrn7L7dp+MfE8fi5h/+wFt95q8+xgFeZSJsn8Dp5/zhMsK1RAzBgLfjkBc7 DHkBBH2RgxuLubGDuweDPzoONNZzfnJ8zGL79uWh6PwRvQXUeOR597yTdGFjCMANCb5NRCMgaHxe XJcvJY1M4fWYP1rHqeXKixvruXJR+v33AJxdjs+16wN69MGOWNj0CTUB6+0oOec/Vz8poUFwdg0x OuXkOfzDti9lyI8nVy7x0s/hyfXD8SoXrl8lwK2Ef3zh/OfwtKoF063Hb5fTE0P/wKly880Zdqg6 KoEi1B02OBzfrT3gVfVtIEwxwB8lufS75WqiFnEqAsFB0fTUvhtXrnj/4lNWLZyHKHvjk05rc90g AAICy6fH39AP75EwhRgDQ6NOPRRQGP9wWnoMrXrwnfKpDw9c8vNMfAgP2+od3OtiFbDr/Pjr6Gff 6Nl2/T9LcqrVwKukzkOHOwqOyy+XL04/J+8wndAq3erK2/CM9N9OzbDBBIZV+iiHwx+5tJsiwNVh abOqL4pXm+XwbH31nTOeHYJFNIiPYN47Nos5OtrywzqHH/VqhwOxnARbj+HT26ricX5yfR3H56px i35XYY9RfDway5eyK+2hv0oJ1cdCf6i+64AevbFjzsr5vyGshrl1+NAeNlaDEq7PdPhpzVrHh16C /6MvPQ3gH3njYGwLZRUjpqO8QuWLFJYBAcew5ATfl6jX9nhsMYEXs4ZR1Kj6R53ww+uRfQnR4X/z 4qMfDbgQj3aYwoOZNdinyZCP4yk31uAmctKg/hiDYGvfjt1VlNZhlyvHsi+UsC2da4lcDefkHeCU /SWHk1yJcPzSO++u0tht6pPbLlvzdyGWWahHBq4ucZ5wdTheeli7V92Ob7IVt5Ftra64le7TsOn+ hAEXYjtOLNDDXnWIvysN2KMTxHvnd0U4vmrjpkjCadb5+PQE7gbRP+jMUDRnt+UF/bHtDF7J4JN0 WMOobwRR59C2GONSUtMw5w7wKnNh+wROP+cPlymuJeIFT9Mz+ql9XZue1vfT2y/HTG0o4cZibuzg 7sGgyjrWc35yfCzaPf2NSXg+nf7kfdgSATsGEqSURB8CsIFd58deo0v4Jg/mNNAkd+LrBDVeYtLT N3GIwDR50NiJgjgOYchw5cWN9Vy5kDmDIOcV4XYGabl2ffjlN2OPXUxXhwxukCjKyfnP1U/DPTrl 7JKAQXDyHP5h25dhjk65combfqYf4/rheJUL16+6649/fOHqAwEYkHDr8dvl1MbQP3jeHZw2g6++ Godf8GNcwWpolFNBQBAQBAQBQUAQEAQEAUFAEBAEdjsE8NwYNdYQQ6bwDgPfKNS/CBGDklBJEpSR UD6IsCBQGgSw8eKbpx11/pS5pVEiaeOOgJRLXCAdVG2N0jNjxozs7Oy8vDz85uTkZGVlZWZmZmRk pKenq1Dd1q1bNxcfv86eVaolsXHxW5QIAoKAICAICAKCgCAgCAgCgoAgUG4QwDTb74c9o3awKTeZ kowIAglCAB9owhKEjatWTH1k4L4dT0mQFVEbFgEpl7CIJUJeAnaJQFV0CgKCgCAgCAgCgoAgIAgI AoJABUVgaJNsfI6DdpGroChItgWBYAhgG6WRvdq/dGxjfEelzXV3BUskUglHQMol4RAHMJCQGeAB 7IqIICAICAKCgCAgCAgCgoAgIAgIAoKAICAICAKCgCBQzhGIbUls+sMNyjkukj1BQBAQBAQBQUAQ EAQEAUFAEBAEBAFBQBAQBAQBQWCXILCmZAu7cMbT+88Ll0CkBQFBQBAQBAQBQUAQEAQEAUFAEBAE BAFBQBAQBAQBQSAIAoOqBZEyZWQPOxMRORcEBAFBQBAQBAQBQUAQEAQEAUFAEBAEBAFBQBAQBHYh AhKw24XgJ53peZ+Ne/bQPfFJ+KTzrGwdijsOAmnZFmAFshb3ulrusZPGWO6LuCJnMEHVO0FqK3JJ Sd45BOJV2eKlh/NT+GWDgJRj2eBcSitSTKUEMNmSl3GBlrG5ZEM7iD8SsAuCUkWR+eKh2zs/9to1 f2yrKBlm8ik4MMAIO+kQkLqadEUiDgkC5Q4BuSsod0UqGRIEBAFBIG4IyBgRNygrpCKpP45i37Yt EpZJNyQoxmlgZ+UTk5QYqYjvJuZP+ejblx4rnDZ56+ZNlfZqsN/JZx168fXpObmUalXhvNe7tVr3 z+LY9JOe5CccUKyc99vUx+5a8PnH65YurrJ34yNvuGffjqcgR9+/9syMZx9ctXBepboNDrtkwEFn XQimv2iyKu9x6cxlbgSWz/mlTqujdRlOj5+vimb9siVfPHjb3E/HrP9nSU61Gnsfd1Lb6+/OqVpD 16nTjvxa8+XQb5XXbRk0ZcFfqfw4GGnlVBAgBBx1WNosUIpjm7XiuWj6lJmvPjl/yoQtG9YXYPjo embLi67LyM2jAgpIcH5SR0F6VI/B8UksIOHXo/pqP596KrpEHIetzWvXIKo758O31y35q6Bug0P6 Xd383MuVfNg+02HFcckYvh3lFSpfDovxvaS8Ss/Oya9dt37b4w+7dEClug1hAvyDel10wr3Pkjlw UCJbNm745oVHfnl32KqFf6Smpu3V+phDzruq3pHHk5gQbgSoGpAY1XO6RBzIcD0wx3e0CLKYPITR fIJ3U0Fu+QJm012lVbUPqErEKiYCcRlruMoPSK09QxyhRmc+9eGB8yaPX79saZWGjVpdedv+3c+G UesQoOz++MbzEwZc2OH+/xx45gWKA/maBx5y9uiv1elrXVou/vEbdGXkvO6w3sXpfKEFgQqFAFrH LmkLoezG0D+oQlSROPwaBK7u4Gxf9GgG7BQu/u7DzS9l7fny4TsRZjrursfzatZe81fhV48NGnPl Wd3+M0qpLdqyZewVZx122U2fDbq2lIaSPzkHxYo/5ow485gWfa9ofdUdeGxY/vuviIshYDd7zMhp Q+/p9MirNQ9qufj7GR/275O9R7VGnXoY9fudc09E7Cxq9jetXZ2WkamLOfQYl1SqMVf2qtrogDPf /iK3+p7rlv79v6cfAOfUYR/pOnWayy+XL04/J6/bMmiuSkPMj4ORVk4FAUKAq8PSZlVfFK82y+E5 5YGbm51zydG3DMmtXnPN34tmRPqcs7o//z4VUECC8xPJrX2dgx/QohIzlOt9tXGJ1Dr6LpIhYtKg /njXhU44v069lX/MwWlmfqUDevaJoc8kncEJ//DtKK9Q+QruQ+kl4djWTRtXL1rw+0ejRpzeruew CXvssx/Uzpv44Z9ff1m7ZRvdxLj+fTJy8ro8OaJy/X02r1ld+L8p05+6TwJ2OkRR6VA1n+uBOT7X IqJ6VfYC/ubDdVMGYno3Unq3pUqXHsOKrCFeYw1X+YFtQscOPI2POOOYlhf2b3PdXTnVauJR66tH 70LADnatQ4Aq698mvIfHrt8+GkUBO/A3rl7593f/27PZYX/PnL5xzSoliV+j/RJfCEFAEEhyBGLr H1SmiiN1kZ+ioqKtW7eqU9AgUlJS8OtFSEyvK4J8UiyJPfOtzw88vV9Bnfqp6Rl4d33MHQ/j1SiV 0OdDbsmuWr3lBf2JU44JDoov/31HywuvPfyymys32DctM6v6/s1UQPO7V5886pYH6h5xTGZeQd3W xx414L6ZLz9u4DP3k9GrF81v1ucy4iMga8RkiUMECRPh10OXiPjrm6mYUldQux4Cf/hte92gv779 iq76lXP55fLF6efklWm/XXLJIEiSCF3AyoSAn4830p/eeSU2BHymZY2v//NvXYnQ5QwBrg5Lm1V9 UbzaLIfnGSMm73/KOfm19ooMH3s1QP+zQBs+/G0T1e/7155Fw3ymZc1P77gCTVVVSM7P2Kqr1e6s D94Y3r3VkwdWeuHIhj+++YJfc5A+1p9K5/jt/jb+veMHP4NJ2elZ2dX2O6jjgy99PzwyKczRZzr8 9OuHql/ee+2l45oMbZL9Vq/2uHfR/fEP3+7y0tMmFY1hFxMrMAofcfUdX/77TuUb7lU+vuUSRFV0 V1GI4Ffdd38MgohZ79uhe8//TtAF4ktzY83mdWvhG8Yg/H1y66Vb1q9TdlGCY64486nmVac+MhBh naea7fHdsKfVJWs5qhLHr+E2OHPGvvXycfs9vl/OaycftuSnbw2BMjvlemCOz7WIMnM4uCF/8wnS TZW+GzE85Kq0qhsQ9lcSri5Z6wxXh6HZqkdZxMqS59vUf/yAPLrFcugxcqRONfmamBVLlZwIJUan 27Zunfb4PS8cvQ9azbjr+mKqJqmFjN+f17oeijlZZOvpQ6rj3QklsRJWPZxdzM96t29nqB3aOAtt ENgqnVDy9fMPY4xD25848Cq8bFB8R59gLRdOP+ePNUdgcmPNh9f0Rh+lUn18y78w4UDRWrnsdP8c pPIbPjjGMkPScYp7D0xLP+T8a/CUimG0zmFH9nh1nJK3DgG4hP524dRJmIay8MuJ1AD4xsAAAC4W SURBVPeCj7kpavzFr1oO5bDLXUL5Gn+cpOI7ysuKD1cunBVyxhAAP9RYgzV2k+66pvi5Ce3xUSR3 +8/VT8MN/dTan4T1k/JLhDIRtn3pjhm0tVwc+jmcDbXqlKsPXLuLV7lQgSo36NSAkXxWfJwaApz/ lNAgkNzav3F6OLuGWjqNoX+gtCAiAbmdDwTsVMwOIbyIQFFKUSReV+qA3XOt6jzWKPM/revizu/3 CSVz4iKKS3H8/vEHiD0pBX9M+nDWqNc7PfhSKfTtxkkJigVffIJFXq92PAgPRbhd+PyBW7D+CxlD h4VoHeWwXpvjjPtmPEtMvuf6drf/OzXdnE1JqUDg9Y56w0OEfhW0X4+16Pft1GPqw3eu+XNh0ZbN +MUjQaMTexqqHKeUXy5fnH5O3mHLeomyT4RVLCpz2mODECQ958OZvcfOXPDlp1HlRaDcIEB1WNqs 6ovi1WY5PKnmoI9aOf/3yfcNqNe2PTGtxNxPR/f+8Lve475b/eeCaUPvVjKcn7hq7escfKvRb18a +tXQu4+5/eGLpv95yisfLprxhSEWsI81UkU9xWs6HLrYP798j1Ouz4zqp65K0Vhv2/2FD7DlQv2j O9ADGC65h+/g5eW3uAs5+5xw8sKpE5UDjTqfWlCnHh71dX/2atVu/A3nL/xqkhqj9UuJoLmxBgPx 2iV/Ygw6Z+y3qOdTH/0/sn7w2f/q/p9RUx/5P+w9cspLY/731P3qkrUcHUPhr++/3uO/4//1zdJ9 T+j2ye0l66zJSmkIrsUF0Uk9sCFMfK5FGPK7/NTafBzdlHLY342UPiNclaa6oQj8ki1rXcJVa53h 6jDkOT24NH/yhFNf+/iCz/8AUMquQ48SMH7R+Zfcp304c/7nHxtX/adfv/AIbudOG/7J+ZN/T01L x1YDuozfH6yX/GH4c0pm7scf1G5xRG61mnoSK+3Xw9n94F899+/Z54Ipf1z6w8pj73jkp7dfIYXo ozDGofljSfX0J+9VfEefYC0XTj/nD1k3CG6saX93ZC+LOePeQSljlgZOVUKuHKNWfsNuDGOZoUGd okSadDndesk6BEBy3pQJezY/vFK9vTGZDjSlbXp6P8w3XLv4z9lj38I8FeKHIqi5gWh7wz2tLr/F nZwrLw4frlw4K8of69VQY830J+5dMXc2lgz3Gf89DbJQy/nP1U+rJ4rJ9Seh/OTwD9u+OD+5cnHo 5/y3muDw5NpdosuFqz/EJ8BVdjj/rZlVTGv/xunh7HL6Y+gfSJW6Oad43ZYtWxSNUJ2K1m0p2pqy bbO3ZTOSuII4pJEjkCt1acOKZX/NnDbl3gFLZ/0Qte/gtCn+7NEjPrur/+kjJ+N07d+LJlzf76Qn 3sBraneqcnlVh2L98qUY708a+nrlho0QCJs8+Ab84e3NpjWrFDiYKoJTTEXEjGsdjZmvPIGFOQ2P OVFnUsHpTDdt6CENRtHDh7d7d/jmhXpKG0YsfT0spbLa0vPL5YvTz8krQ267VmesTE6Pn//LqOE9 XxmXV6MW9LS79UGUnVWhMMsZAnodljar+qJ4tVkOT1WF8E5MEZjZdPqIyPChDn/bBL/dLQ9i+wVF vNP3REzKA835SRqMvo7jc3YR1kEHji4RAnASW9soSfoN2MeSvJUgr+gqnigQTDn6pvuxlwKWFU+5 98bN69fiKtdnuv3064eqrk+NVOZanHcVgpKKdg/fXHmptMn8m12l2oYV/5CHqDavdz+iyclnYka5 YnZ58k1M+Zk08Oplv/2CGfGRPXkvuk7fk5fSxoXgxho8EPZ8dXzJGHTbQ+/07XzUTSWBOcwQSUmN rK7Yq9XRILAPifLEWo4OJxF9RqWCAAJ/058uUe6QD3iJ6pjR4oIk13tgXV7ncy1Cl9/lNNd8uG6K HDa6EeKXhoihSnN1yVpnuDoMnzk9uHT84KcREAGBeq5y59CjBIzfX0cN7/Hyh8Hv0xB9O+XF0WoL yyMH3Dv85MMxwYp0+v3B1G+8XMesOsTpsKnl/j16k7CD8Oth7aakLJv9U0HtulUaNq59aNtuz71H avUx7t1+J7W+ZiAuOfoEa7l4jH7WHzK/M8GNNdic4cRHh71/YXeId3t+FNYJqXRcOUat/Dub9dxj mSHsOMW9R27xDYNVxj8EQOz38e9hbjUI/GIui6JxisqGeRUfXHIqXiti4yBSSAMicagbJI6fwMpc LKRDzM5/Sedw5cXhw5WLrjMgHWqs+fmdV/ECCasloPzomx/4bfy7ygrnP1c/Hb5x/UkoP0m/gX/o 9kWKdia4cnHo5/zfWXHJGYcn1+7KoFysfnJMzn9OHnxr/xaDHquJGPoH0oMIXWZmJmJziNPhNzU1 FRz8pqWlYZIdwnnFIbzUzUWRYF2pAnZkMrtKVYSE9mjYePgpR8QcsMOcrM/vv3nWB292f3H0Hns3 gfKxV5/TrPeleLlHhioI4YciMzcfy5pUR4aFOe3veWpY5xYYJ9Cx4qYWYwBogLNh2dKsgsqEEi5N f2Lw6SM+I05shEOPUfTjr+1bq8UR6BNza9TCHud4dT+u/7knP1fS7XLWLfll8sXpd+PA2U0cf93i Pwv2qq/0YyP8xBkSzUmCgKUOS5st7ovi1Wa5PlBVANzdoghWLfhj2hODsbim69Mli4Os1UNrm/Xx rlvJcH6SBqOvi8onAUVgKke1JgcaTDoN3sdSkoAEXhhgdtVbvTsgBICxA3sj/P39DKTl+ky3n36j i3/4esp9A6Bz48rl+lX38B2qvHS1u5xGtC67clVyA0/vWCc78Y4raZgDsHg8xh/uv/AKE8E7rDDq +szblCS+BDfWoGJr9bwBxMgulvcqWhFoODjlypFS+QkVrQMf4Uh92ZdfMjYO1+Ks2vw9sBLz87kW YVW7q5hc83F3U45upDQZCVulHXXJWme4OuzQg+yowJmeL06PLqPT6BL1NqJfstLoG188phFdUlFv OvX7gwgUlpj8PPJlLH4snD6586PDSNhB+PVwdhHdwDrciQOvxq7WGbn5eApo0vUMpVnLV32KyDv6 BGu5cPo5f7hMcWMN5Gsf0hpTChB5wYMDJefK0V35KTkRYccySmgQOXtUh0sqOmxcwql/CMB+VFhF fsQ1d+LqPh26YRk1OFRbDj77YqxIo0W1SmGQ8JxhGgvxMM2zTf8dU6chQIE/XSFXXg58rOViOBDk NNRYs/avQuxqotRSBcYp5z9XP5HEioOjPwnlp/LQj3/Y9qX0+H+5cnHot/rv16w4HJ5cu4tjuXAu heJz/juUWPu3GPRYTcTQP+h6IlPptm5VcTqE6kBv2rQJAqCLo3ibN27cuGVLZE1sfAJ2ynZqRgZ6 Jd2P4DQ+/zfmql7INmbD5lStrhJiTiz+sHMw6UEj1Lsh4pcnwgpFtf0PNvNY/JXfGk1bFH41qUnX M9XVBVMngkOSgG6/7mer7bGJGQMRVQ8VPeZ+X/RVYValKrCC7R7w5gfLpd0Wrfnl8sXp5+TdphN3 NW/POqsL52PfKJhAp5A4Q6I5GRCw1mFps6ovileb5fCkCoA97NDi2t32UNQ+Z0fbLJyv3oJACecn 6VcE9XUB+SSWX7veP7N/wgIZ4uhE8D5WTxWERjAFU6todtWMZ4bUL/5iKddnuv30Wxx9+RmtLrsZ 31hAt4+YHTZHUzJRh+/g5eU3ugs5v3/0ft02x+kOtLzo2mFdWoKvM0GnpKXVOKD5sXc+ip22jEtx POXGGrzG21HPF83HKzS3Ua4c3anK4CrX4nTT1h4YAlY+1yJ0hbuc5pqPu5uK2o2UMl/2Ko0V97gd 1dbdh61LXB2OokezqPLF6eFyjWlTehshMXwSGgFoNSsWy8mJj9AMNkbE53eJsxPh8wdXEZ0Zd02f zILKe7fvohTulMR64tPD2aWZ2lgHPXvMiE/vuJwCdjvyVThfTSeHqbB9Aqef88eaGzC5sQaXMPEQ H3mLEO+9pj7jAJorR3flR0LjCDuWGcnptN5RJ8waPeKwS24kjkEYQwC+RIRpldiplsTAwRwoddqg XafSP8Zi5mZGXr5/foxVM1deDnys5ULZKSXBteu8WnutXDAXtQ76sZSbrHD+c/UTCa04cHbJkEE4 5K34h21fhjk65colXvo5PLl2F69y4fpVyridQH+48/jC+W9PznOj6PHZ5TTF0D94nZorbZhDt3bt WgTmireti/wgYJeRkYH4XXp6ulowm5KSFoePTmC703mfjcNsZ4xtWBKLV4KxbaL5yzv/xYap+7Tv itnmFK1DZtDk9D/F4SArH3wOCgA7/vrz/pn1I7aPxbIm7CGt9obDTqhYiVw4bTK2vy2c9tnn993U vO8VCoplc36eM2Zk6+KXPAY4iHvS+wfjkv/Uqocr+lrNDv9iyK0IUeG1Nn5B12reinT67XL55fLF 6efklWm/XXIpFMHp8fP369Zr8r034ju5eCWCxcuhrIjw7oUAV4elzaq+KF5tlsPzrXNOwOfYECrC zrjL585Cu3P3OahdkFm75C80TxBYtaTqG+cn19dxfKXN3ye0PP+aCTdegBt3DJfwE3041fNQfSyl shJ+u+9f3EMNHNjgD9MPsRm5Wh7F9ZkOP2HRrx/ZwYfz8CyKz03oG5npY7e6e1a/7vKyZioZmKhd iP5grQpWwbS5dqdJDYg8Hn/3U9jcXfk58qzjsEsR0ECSVQvmTrnvJnpUS0RGuLEGCz9VPUdVxxjU uPOpbutcObpTJeKqu2X5LXI9MMfnWoRf8y7kcM2H66bgqrUbiUsW3FUa7zwwnwjzSclW2LrE1eF4 6SHHDGL/4vs0NBDVRugqAkyYGIst3nET+9mga4mP6Bv6cPQDuA9HTz7qwm50iSMwGOExFZNxGnc+ jZOJyufsvt2n4x8Tx+LmH/7AW33mrz7GAV5lImyfwOnn/OEywo01GIIBb8chL3YY8gII+iIHVx8c ld9q2j2WWZNYmZjF9u3LQ9H5I3oLqPG0++55J+mSxhCAGxJ8m4iaMGh8XlyXLyWNwsXrMX+0jlPL lReHD1cuSr//HoCzy/G5dn1Ajz7YEQubPqEmYL0dJef85+onJTQIzq4hRqecPId/2PalDPnx5Mol Xvo5PLl2F69y4fpVAtxK+McXzn8OT6taMN16/HY5PTH0D6QKs+dAI0i3ufhAnA7/McMOBy6tX79+ w4YN69evXbd+FcTMGXaoOkqRItQdNjhWPj5WPfXhgUt+nomvoWFvtYN7XRxbwE59GwjvBvGnrOP3 0u+Wq4laxKkIBAdF01P7bly54v2LT1m1cB6i7I1POq3NdYMACAgsnx5/Qz+8T8MUYgwMjTr1UEBh /MNp6TG06uGKvvPjr6OffaNn2/X/LMmpVgOvkjoPHe4oOC6/XL44/Zy8w7S1SjvkQ11qdeVteEb6 b6dmCJdjWI3X91hC+SDCZYMAV4elzaq+KF5tlsOz9dV3znh2CBbLID6Cee/YLOboaMsP6xx+1Ksd DsRyEmw9hk9vq3rC+cn1dRyfq3Ut+l2FPUbx8WgsX8qutIf+KiVUHwv9ofquA3r0xo45K+f/hrAa 5tbhI63YWA1KuD7T4ac1ax0fegn+j770NIB/5I2DsS2UVYyYjvIKlS9SWAYEHMOSE3xfol7b47HF BF7MGkZRo+ofdcIPr0f2JUSH/82Lj3404EI82mEKD2bWYJ8mQz6Op9xYg5vISYP6YwyCrX07dldR WoddrhzLvlAcLcvqDNcDc3yuRTjASZ5LXDcFD63dSFw8d1dp7Db1yW2Xrfm7EJME1CMDV5c4Z7g6 HC89rN2rbsc32YrbyLZWV9xK92nYdH/CgAuxHScW6GGvOsTflQbs0QnivfO7IhxftXFTJOE063x8 egJ3g+gfdGYomrPb8oL+2HYGAWh8kg5rGPWNIOoc2hZjXEpqGubcAV5lLmyfwOnn/OEyxY01eMHT 9Ix+al/Xpqf1/fT2yzFTG0q4+uCo/NaeIexYxvmPRbunvzEJz6fTn7wPWyJgx0CClJLoQwA2sOv8 2Gt0Cd/kwXQWmuROfJ0g/4lJT9/EIQLT5EFjJwriOIQhw5UXhw9XLmTOIMh5RbidQVquXR9++c3Y YxfT1SGDGySKcnL+c/XTcI9OObskYBCcPId/2PZlmKNTrlzipp/px7h2F69y4fpVd/3xjy9cfSAA AxJuPX67nNoY+gfPu0Npw151iMopmhbDqgl3WBKLCXeRVbGbi1asWJ6enVn+V5hyEAtfEBAEBAFB QBAQBAQBQUAQEAQqOAJ4bowaa4gBIrzDwDcK9S9CxKAkVJIEZSSUDyIsCJQGAWy8+OZpR50/ZW5p lEjauCMg5RIXSAdVW6P0TJs2bfHixVj9mld8gMB6WByI1kFAhfBWr1mXnZ2dkZkWYckhCAgCgoAg IAgIAoKAICAICAKCgCAQFwQwzfb7Yc+oHWziolCUCALlGAF8oAlLEDauWjH1kYH7djylHOd098qa lEuCygtz6GrWrLlu3brly5cvW7YMxJriY9WqVUuWLPn7778XLVq0bu3KffaOfIzFXBKbIJ9ErSAg CAgCgoAgIAgIAoKAICAICAIVAYGhTbLrtj6WdpGrCFmWPAoCMSOAbZRG9mpftHnT3u27trnurpj1 SML4IiDlEl88SRtWvLZs2RIT6H766aeVK1diml1WVhaYEMA2dvgeBcJ5hx12WPXq1RcULkzIDHBy RQhBQBAQBAQBQUAQEAQEAUFAEBAEBAFBQBAQBAQBQaDCIqAviT3kkEPwNdiFCxf++OOPq1evxpZ2 mGeXn59fpUqVhg0bNm/ePDc3Fx+j+Gbmt+kPR+bZySEICAKCgCAgCAgCgoAgIAgIAoKAICAICAKC gCAgCAgCcUZgTckWdh6WxGLHOmhv0KABptdhOWxmZmZOTg6YmGqHmXfY1Q5XEdHDb7r6F2dfRJ0g IAgIAoKAICAICAKCgCAgCAgCgoAgIAgIAoKAIFDhEcBMOoXBhg0bEJJTgbi6detiMayabYewHb44 gXAeTsEEAXnZw67CVxwBQBAQBAQBQUAQEAQEAUFAEBAEBAFBQBAQBAQBQSDBCKSlpamQnG5Hxe/U TnbqV12Vr8TqKFV4ulO693eBt61ShQciMACCVWCoRDAhCEibVbDGHQdp2gmpr6I0wQgkqN4mSG2C wRD1uxMCia5jidafPFiHzSknD776i1fWbsnyRufGS1n50cPhz+WQk4+hvFAcN2dxdoQvCAgCCUVA RevwqwjYojid4uCXHJCAHUEhhOcNyvLOXu+lrBIsBAFBYPdAQNqsKifBYfeor+Ll7omA3BXsnuW2 O3md6DqWaP27E9bBfAVicQQtL8Xrn+lduyGYbZEKj0AM5YXiuDbTy90RFAhvVVIIAoJAjAioLeoQ pFNxOoTn8H2J1OJDTb7T9foCdlyEnuPvm+q9nOMtLPA2VfJ+zPdOiWmN7Qnp3qhcb3mBt7bA+ynf uyPL7D4apFaUmV8OKDio/5Xpzc6P4I/fCyObF0YOKi8ilhWoK67f/VO9yVt2EqDkRCg9dEqESlYj xXsm21uQ722oFPkFDY7jcOTXmi+Hfqu8w7QVz6PSvNdyvCUF3pqCSH1GVcRNRgwH5yfBRYRSTqdE xGAUSSg5Ee7y0pMEsZif4j2c7c3L9zZW8mble5dn7kgUFv8dKcNQRlfgKC9CIIz6WGQdddhax2DD ihU5TIS0WaM8CBmDj1N/3+WXEY4gYCBANUoR+tWGqd5LOd6i4nsb3JacXTy2QuzrvB1SoMHBQXrW VfJ+yfduz/KizlrgOocd2isqRWASQUj4ObjE9cAc3zGKkaFdTlBOiVAucUMeiRERxywonajbGPSf yvbQNEpzQFtCj0Tr9zvvt+jn+FNVNE7PdG/aVu/XyGZMJQdQUn/Bu83tSS3/BXMLKNFYKA4UCopG DkFAENilCAwfPrxHjx5nnHFGv379+vTp06tXrxdeeIECebxrXMdn8BuleoUFkfm0uPXE7WmztEjc LYbj8zyvX4ZXP9XDLTFuBZ7P2UkPepIv8yJvZgzrMRhK/iQcFBzUp2V48/O9Y9K8ghTv2PRIjKyH ref9MNe7SoutcDhERZj0cJIf5XpDs716qR6s4Rc0OI6Dyy+XL04/J8+Z5vCcnOedk+HtlRKpiogN PZHtve/0PywOnDzH5/wPyI9aXqQnoAPP5Xjv5XqNU71szzso1ZuQ6/Upfo4Niz/ZDUX4u4Ko5RUw X6HcMIS5OszVsYBYUdkZ5ozTqBkkPZwk16YMQ3TK5ZfLF6efkydDHGHNiJXJaQjCj7vCIEZFZpcg 4C9r3IfgtcQ1mZHbEvR1R6Z544oHAkj+lu8dlhZx8/A0b07+joCd8jzH81qleeiXHkMy/uA6Bz5F 0Cv+vARNmTRyUbNgCHA9EsfnRrGkASDiiJFH8o0b8jh5SlgaQinHTT7qLebj4J5zv1LE7BLqqgO6 0iDgTuvPkZ/j1hDfq2Gtu+XdV4N7/maO17f4dpGSkOaA3SYltBKkzXo1mZlhPXfLu6/6cTgvw3sD BSCHICAIlBEC+OiEOiZMmLB++7F8+fJzzz33pJNOat++fYcOHXr27Pnnn39u2rQJX5/YuHHj1Glf Mc5xDd7gYy7SdQHCQIwRll0pxcP7Fjoe2B40MayTQDkmCAoO6k9yvbO0IRDBpo99AaYu6ZF5i3oc D0gaYCoO/Voh1fUYyUkeE9Mqa1PSqqR4q7WZfUo/CfsJyi+XL04/J69M+O1yeBou7ZHirdeqol8P OBdnRmbkLS7wHs+OPNqpg/MT8taD4ythv13wz8zwpuV5qwq8P/K987U6QPqDlBcJWx3w20U2a2nl i8gmnh9wOPB3+OnXD1WYyYLX+JihCZ3Gm/yoXYFRXtBmzVfE44QdVIe5OubAipzSy04x/VgpDv1S Wp3Q9XBQcHWVs6vrB0355fLF6efko9o1MkIIKMJwz8qEjJ+PxosXDNjEE80ZD6UQkKOCIOAv61dy vBtt9zaQxBvKZ4s7esR9bsoqqSeGBrys+qt44MPI27Y4ugckQWDWtjq4ziEGwLl6i7nhTxfXZ1Rp zIqiRU9wFY9nmL07MMtDNB8rGy7ZnlNr3wt59Wf4BuapGd6v+ZEh8n95Xovt2TTEYjiFZvfhFqAe yVBCfG4UM+R37ak7j+QbDXkB5SlhKMJQjpUcrxc/4aPMb83yfs+P1CIstcHURXUckuaNzfWWFkRm 4qNuoJ6oA3qMP4NfIrf9H4S5Ouauq2TFrd/RRji7213b6T/MGYfiOPzHpeuLQ59YV4ThRh0cnrhq zS/41vsrh12rHshb72OVV7hqHA4/DUn9FPUEAV/9MDRTt8mVC9IiiR83MI0/3YqfNuzSKQiu3HHJ b9eBgxVneJKE5YUX8HgLJYcgIAiUFQLb43Wr9YAdvhg7duzYLl26HH/88SeccMKIESMgFr+AHW5J cav3Q/HTNfriwVleXML06OnGbI86nZgeeZtXrfg+gHrVssJ019shKDiocZ9Ue/tNEtytk+L9owXI wEGc7ud8DzDqB5C0gmllqoSGHkiqtUJYDY2b/m7b9b+a4z2S7dUtniyJX9C4jaODs0sClF8uX5x+ Tl5p9tvl8CRPkKF9UiMPZvoWuX494GDGGYoAYSwQd29fB8X5CXkrbhyf8//KTO/7/Mi8D9zZYDHg fzSQVZKA5UX5hQP+A0yDj2e/PbX6hoDdiuL6xuHv9tOvHz6MzPGapEYeL/FgjKpFh7srsJYX0hr+ k7bEEVSHuTrGYUUuGWWn+FascMmRQUMPJK11j6urbrvkLeWXyxenn5OPateaZStT4WO9BKbBvycr 0oTRkNGLYl6tcZXyK0T5Q8Bf1n8WeHvv/Gypcg1J1BBEu9Dn4xedoUpraMDsbDR/HP+X5f17+2sc bCaAGJk6uM6h5HKYf1y9fTC7pD7D1Q9yvfu3uwFX26d7WFkJAotG26R5c7c/rXF9L9wxMqg4I3Ii 89AxBmHvCExni9cBW9aeivT7naFLIKhH0pk6nxvFDPldexoVBGPIiypfmuwYgKPaq+qNF/aYQI33 aogbYmUMarg6UKNQCojfgYGahn5VPwxtdMnPB4erY6HqqjLh1+9oI5xd8lYn/JoVx+E/LmHSLmIl 2D5l/HZ8ODxhy5pf7v7KYdeqB/LW+1gON4efOiwGjXkY9NrAqpm6Ta5ckMqKm1WbYV0/hRL9oFMQ XLlb7TpwsOKcnOWFDlyfIqMjI7QgIAgkAAFrwA7T6BCz69+/PwJ2F110EabXrVu3DkzMsEPYrtQz 7LZUitwIYmUcRmW8OXknNzLJqJTH6RmROQ54YseBByfcN7fDW4zig3rVkvPy/k+HgoN6a6XI4lMc CnnQkNSPqzN3Cjnpl/y0A2FOT9WUSDRwZp6Hzz/hwPQ6TPuCHvUHGq+1Ax56frl8cfo5ec40h6eS J/8R66zu9B+SuOVSh/6eivOT/DFwi8onAUXghRgWZDmOgOVFGpCRIMeT2ZEbR7UE/sDUSNXaXJyQ wz+qnw6juI3Ay2d1uLsCR3kFzJfDjVCX9DrM1TEOKzLElR0J6IQjg5weo+5Frau6OYPW88vli9PP yRsm/KfWLFuZ/rQODt45UVvGgq/SK3TYkktJhYC/rNGtWe9llORbOd4XeZGeEIfikAbwsCQW0Ss1 Ih9cvLQWYhhG8OoRN0vq4DqHksth/nH1FkETvT5DTB1wFWM15jwRgQ1wjUPveymVIYPkeCenDjyH U19tiJXm1OipSBWhTRwi9B6JmCB0PjeK6fLJQ1tBAALqz3+LYpUvZXYMwBErVOM+tmvEzYA6aqZE VpGrA5UNLy9x645g8fbrJZfwz9BGF/x8cKLWsSB1VZnw63e0kah2yW1rjpQth/+45H8lwOGp29Lz y91fOeySKl0P5Kmv0O9jlTCuGkcQP40kOHUE7IxukysXKLHipmz5/fT7YJWkhCC4crfaDYKDjnNy lhc8lIAdV1WELwgkAAE9YIcgHR0IzP34448I2E2aNGnp0qVr167FNyiKiorisSQWk2swxYYOvHlW r92IE4rAHSTeq+CmVm0Qg7Sf5kbe3NJBvSpxyivhh4KDGrNUADsdxgw73Loh+hl8txEO4ah6cNOG 5Q843i3eww77/iB0iF/sAQdO1MOfXy5fnH5OnjPN4UnycAk3Li/meHg2cxxAjGooCBr2OD8NVYRb QD6J4XbZeFdJl0AELy9KxRU9CSgCRjFTA7fjWLKKqbWXZZY0eQ5/t5+Gcpy2TIvsi4epK/BH/SmZ qF0BV14B8+X3JCzHX4e5OsZhpSxGLTvDMS6DUfVQ3QtYVw27/vxy+eL0c/KGIf+pNctWpj+tg4OV fdSWEawpvUKHLbmUVAj4y9oxww6ed0qPVI+OiFtsryc4VX8YArBKFBPrKN6Hh7oj0rzWaZGp7nRw nQMJBCe4eosuWq/PtLcDZdYguL5XeULC5JjBMU5JrPQE9VSkymrL3yMpeT+fG8VIfxISfhCQL8ct il++NJkyAMcMO9xY4kBtxyX6wzsYdahZ/9/kRQSwAPkM+Kodhja64ucbHDoNW1eVCUpOFqO2ES4h aVAEZZz4imNY1E9Ba3fuJek4PLn8cvdXuiGoplNODwSor9DvY5VblJxyx/lJAlZCf7VAmqEcf1Co d5tcuSAVhP24kTarXT/TyBGdEuFXaLXL4cDhnJzlhfkx9DrHj5VwBAFBIN4I6AE7tYUdYnaIyiFg hwOLYTG9DgG7NWvW4DROATtsX2UE7NQoHkPecHuB2VhYCatPaEIX6f+LQfnulcQKBQc1AhnYE4EO LEPQ97DDlky0SIFkHIQxXJFkVD2IzSHIggOv2bFvHR2gsYOV+7Dml8sXp5+T50xzeBryiHpgSHYc QEx/M4kP9aqD89NQRbgF5JMYxleKaxOTiODlRUm4oicBK3FDpjesOKDJ4e/2068Tm7hfkFFShbDK hrwC4f/zJ/eXF2nwC8eRY63DXB3jsFL+RC07w20ug1H1UN0LWFd1u9b8cvni9HPyuiErbc2ylWlN zjHx9pvaMm5hS6+QMyT8ZEPAX9ZYx83tYWc4r9L6NZAYphoNyY68jBxEz8ReZOvPeN07cfUWe5vq 9RmTVtRBrhoE1/caqShflJwTIMlSEtRTkR7DNPjWHsnBJ1UgaBTTmclG+0FQHvqHPMXn5GPLlwE4 7WGHLRoxTDsOxLR7ZUR2BdWPIibmYlhBEoNDp+66Glx/1Dai3Ca7ei50Gi+ftNvwSPALHBxGQv1U p0kVhyeXX+7+ylBOp5weCFBfAYLuY5VjuAem1w+Kw/lJGbES+OgEvm+gH+SYzgTNlQsucUlwiSt3 QzlOkSN64Y2N80gnESqJfqrTpJDDgcM5OcsLn3xE0cghCAgCZYWANWCHmF1xvG7T3LlzCwsLlyxZ snLlSqyHjVPADl/8wXQYrIzD+KSWxGJv4xiO3hmR4Q2T6ZxD/45eNQYTu0sSDgoOanxpEWPb0WmR 7UKwAAHzE+krsQekRhYU6+EzAgFjj3X4sTKterCjMGYZYLkrhj31UTx8EADHxLzIrDrcLGJcxi9o bC1Ph98ul18uX5x+Tl6Z9tvl8MSGLN3TI/egmCGIh3bsDQeLdPj1gIOV4JjkiHfOIAZufyTj/ORw 4/ic//jmL5YhY/sh4A8/9XYXqrz0rBFNhD+/yKNq79jgD4ugsdOQus/j8Hf4CSt+/VB4cnoEfGyL g33ZIWA9iO8uL2XCqiGOTK4Oc3WMwwouWctOuerHivj+vFj1cHWMq6ukn9BWHC6/XL44/Zw8Z5ey afhD8iSgEw7cDD0IrKB6oyFjGRc29DGu6jqFLmcI+Msa/Rs+uY6vxOJxDp06xji1r65fUnH8fIKo efEmcRimm2mbGHCdA6UKTnD19qHskrEJwxPqMyKG6iBXDcLd95IwOWZwjFMSi4HgeipSZdjieiSO z41ipD8ZCA4Ebsjj5OOSFwU4xmUERtEocJ+p1m2Afju3ZIsM3I2M2n6zh03ZOqdHbkqx2g7RPUye 0g+0rK7pntYaSi4axQquwaFTd10Nrj9qG1GekV09FzqNdRhoX9iCDfe9GD6gVq3MMBLqpzpNqjg8 ufxy91eGcjrl9EAAjcJ/H6sc+zIvslm5Xl6cn5QRK9Enw9yfhxwz5LlygRiXBJe4cjeU4xQbGtyW FamceEjBpnWkkwiVRD/VaVLI4cDhnJzlha4DRSOHICAIlBUCFLDDVyYwww571eFXReuwDHb27NkI 2C1evHjFihWI4m3euAUCtj3s0Cvpf+S9ztR7LmyThLcx2AMFQzg2V0YPGMNhKFen/kiTbjcGK7tF EgcUHNQYSvE+B0WAX9wb0YFe+FLcYdkOZcV/xYqwVQ8etjGK4z0VlvbgK2D4wpTaqQRDPpaR4ksU +DoYfrEPMR6A6fDbdeTXmi+Hfqu8Mu23C74VT4Q+cdOJTCFr+FYpZkbgDTYdfj3gYN9ZfOgDc0sf y4482qmD85PDjeMrbX674GM2JZDHR3jR9DArjY5Q5YVUSjn9kh66pHPwCS2s8MLE/sICDx9SxO07 HRz+nJ9W/VhlhpW2qDyYNoKpo/DKehDfUV6UI0VY9cSFaRhSp6r7stYxGOWwspadcpLLBfj+w6qH q2NcXeXsOvJrzZdDv1Weswu+YVrPuBUHSqJLKlqp0vkIaGBaIhoyVvfLV2J1ZMox7ahRiNlhnh12 +UB3h5kU6Mdw+KuZ4vj5OmgYSvBnHFznYIhFPeXqLcIl+I4tFiTiDwRO1UGuGgTX90JM/yN/KLmh lgRiJrieCgp1T8gBg6lO0QNzfMcoFrPPcU/IgcANeZx8XBxTSGKhIu728elhvE5TB/4jZoG13lhw PSPP67n9PgTROryngTxujbDRLW3dqFJhzh1uWrBoFGrVYZRUCdfX3Eieq6th9UdtI+QeuWQlsE8r Hn+whR+yjF/Q4OAgh1Uq/VSnSSeHpyO/1vsrQzmdcnogYL2PVY5hMQc6QMxfIz2cn5QRK4G3y5hr ieXSdJBC4iiCKxdc5ZLgkr9eGWrpFJ+0xs0zCguhZFRa0kmEktRPdZr0cDhwOCNhspUXXu7ihie2 J3fCQQhBQBAIgwAF7MaMGaOidfhFbA5hOyyGnTNnzvz58xctWrR8+XKsil2/fuPqtasQsNt+DxfG ksgKAoKAICAICAKCgCAgCAgCgoAgIAgIAtERuDkr8tXgLuuiS4pE2SCAmeOTt3r3biwba2JFEBAE gAACdgqHiRMntmvXbtu2bTjFHnYI22GGXWpqakZGRk5OTmZmZlZWFk6xMPaXWb9KwE4qjyAgCAgC goAgIAgIAoKAICAICAKCgCAgCAgCgoAgkBAEKGA3YcIEbFFXpUoVhOrwQdiUlJTs4iMtLQ3ROhyI 3IHeurlo7ca1KZQsIU6JUkFAEBAEBAFBQBAQBAQBQUAQEAQEAUFAEBAEBAFBQBAIg4C2m0CYZCIr CAgCgoAgIAgIAoKAICAICAKCgCAgCAgCgoAgIAgIAolAQAJ2iUBVdAoCgoAgIAgIAoKAICAICAKC gCAgCAgCgoAgIAgIAjEikI4FtGqJLJbOpqenW9VgYS22xMOmd1haq3a/gzCIzZs34xKYuIoD62yR HJdA49eqSphBEBD0gqDkl4kXbqjAfuWJ4MTL4UT4liCdZYZtgvxPZrVBqpPgn8wluDv6VgFrXZBG FASWqMUdxFBUJRCI6ky8DAVxpvQyZeZtEENRsUV+g+iJCktUQ3GxEtWNeGUHeqLmqCydCWLLLROX 7LhNxPdqXCpM8uQ6Xp7sXrDEK9dRq1aZGYrqiQhYEUABGVVXiswKVCgmIFWoAkzEu5AWBL4OgXgX QmfYfg5XQYPAN15B4GrUSBpCZx06dAjlhhJOhxl8ogKGqWhBKP90dYoJd2EJe+NNmzbz/XFLpn2z ed7SrDVb072sDA/fc0e8L9ce8tNVCS0ICAKCgCAgCAgCgoAgIAgIAoKAICAICAKCgCBQWgS2et6m zR4iS5u25KVuqldlw/X/qnPQAVVLq7YCp49E7Ion8eATEJi4pr7iun79+uXLl9esWbNly5a4ihga 4nSO6JnCD5KIoWGeXGxwpuPjFFChzODXqkW/CvqzKd//+8XF//s1J69K5TZd6uzfqHJ2XnpaRkpq ile0pWibV6wk1dsmy22taJZDpr3aJGtGdydvuSa5S7Bluodd4EvyeILMJ48zyeNJ3OrE7tRYURXi lu8yUhStxpTVVGMvPlOaA2gJIBIf7AMZCiQUxZ946IhiQi4LAmERCNQXlln/Etb7XSsvsFjxl57O CkvFY6bsfndaCS4k9BjbvDSvKC09dUta6pZNRQjYrV6z6ec5q6ZO+fPSwavbNPnrgdub5eVlJdiP cqge8TE6EK3DgVP8IquYwbZw4UKsMW3atClOKVAGASsQ4CsZhN2sAlGZ6ZguByGlKGp0AGK//Drn 8ZFLvl5UKW3PrPYd9jqyZfW0jNTUzJRtRdu2FpWYy0KcMTUlLdCIHdVDEagQCEgXbC3mqE2yOJW9 d7AqrEhMgcVS2hUVFBmNLJVhNwwxWnMRb6ZUFhui0aK7tjQVgCeVxVrIQWoL81xj1SfMio4A9xic pLiU1Z1WJFRT+iMeOkrvhWiIDYFIDMlLwerMIgRhUryMNKyS9DZuzqpdOyctN/3Tjwonz069+p7v Xh5yZFqaTKQKhzGgVeteQeBAkA6nmCUHLTjdtGnTTz/9VKlSpQYNGjj00oM8kkBMhd0c8tyl/wfI vm/1tTOQcwAAAABJRU5ErkJggg== --_003_B14A62A57AB87D45BB6DD7D9D2B78F0B114E66F5xmbrcdx06ciscoc_-- From hiroa-ha@is.naist.jp Tue Jan 29 09:23:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A901521F886E for ; Tue, 29 Jan 2013 09:23:43 -0800 (PST) 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_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS3tUiAXfH5t for ; Tue, 29 Jan 2013 09:23:42 -0800 (PST) Received: from mailrelay11.naist.jp (mailrelay11.naist.jp [163.221.80.162]) by ietfa.amsl.com (Postfix) with ESMTP id 80BF321F8734 for ; Tue, 29 Jan 2013 09:23:41 -0800 (PST) Received: from mailpost11.naist.jp (mailscan11.naist.jp [163.221.80.161]) by mailrelay11.naist.jp (Postfix) with ESMTP id AE77D6E18 for ; Wed, 30 Jan 2013 02:23:38 +0900 (JST) Received: from [192.168.2.100] (222-151-098-098.jp.fiberbit.net [222.151.98.98]) (Authenticated sender: hiroa-ha) by mailpost11.naist.jp (Postfix) with ESMTPSA id 8E8336E17 for ; Wed, 30 Jan 2013 02:23:38 +0900 (JST) Message-ID: <5108058D.2000408@is.naist.jp> Date: Wed, 30 Jan 2013 02:23:25 +0900 From: Hiroaki Hazeyama User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.8105-6.8.0.1017-19598.000 X-TM-AS-Result: No--14.201-5.0-31-1 X-imss-scan-details: No--14.201-5.0-31-1 Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:23:43 -0000 we reported it in 4.2.2.2 of http://tools.ietf.org/html/draft-hazeyama-widecamp-ipv6-only-experience-02 ---- hazeyama (2013/01/30 2:18), Rajiv Asati (rajiva) wrote: > > A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 GUA, > but no IPv4 public/private address) is intermittently causing very poor > browser internet experience on the MacBook. > > MBP nicely issues both DNS A and AAAA queries over IPv6 transport for a > given website (say, www.cnn.com) almost at the same time (e.g. opens 2 UDP > sockets), and receives both A and AAAA responses from the DNS server. > However, it may close both UDP sockets upon receiving the first DNS > response (whether A or AAAA), thereby ignoring the 2nd DNS response > (whether A or AAAA). > > Suffice to say that MBP issues an ICMPv6 Destination/port unreachable for > the 2nd DNS response (see the attached 2 screen wireshark screenshots). > > This is quite bad, since if an AAAA record was carried in the ignored DNS > message, then no TCP connection would follow => forget happy eyeballs and > recall poor internet experience. :( > > Has anybody else run into this or noticed it? > > Cheers, > Rajiv > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From farmer@umn.edu Tue Jan 29 10:15:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2664921F8A9B for ; Tue, 29 Jan 2013 10:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUkXjzhKcKIL for ; Tue, 29 Jan 2013 10:15:44 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEBC21F89FD for ; Tue, 29 Jan 2013 10:15:44 -0800 (PST) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 29 Jan 2013 12:15:33 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id 17so1338383iea.5 for ; Tue, 29 Jan 2013 10:15:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=B29q3spL8yjmgUEyc+lbBLubDkLkkAJ+FW2JX8nCs9w=; b=kXNgJeqxSQa/wLw1nSlR8/i52S1h/UtnjMRXFPyJfHJXsodttGdz6fUY+MGfgFSwTU 3E8SjbPOL6iOijeajmsnXNlNJX8nMyKmnObWfWlvm1RQiOAFRkJVf9P2fe6oVv3UtNOg nAS4RRr0avjQgobOtdR6trxRwUkUq3a24zWUyhXKtF+oM4MxmVmjH50wUmE92/diqFP9 rnuRluoqUV9b70FQBeW12ikXHt5Hjygv18vi/57sBzDZgSyFf0M9seUZPrIFMNHDa/S9 MoUN3HMKI0owpzJVJ8hL3OZfmvSK46dJ27MKyb9lKlLdEhR+RtJStwCIWrJ8GN8+qMs2 PVew== X-Received: by 10.43.125.133 with SMTP id gs5mr1221352icc.54.1359483333547; Tue, 29 Jan 2013 10:15:33 -0800 (PST) X-Received: by 10.43.125.133 with SMTP id gs5mr1221344icc.54.1359483333443; Tue, 29 Jan 2013 10:15:33 -0800 (PST) Received: from [10.92.160.79] (mobile-198-228-232-086.mycingular.net. [198.228.232.86]) by mx.google.com with ESMTPS id px5sm2465470igc.0.2013.01.29.10.15.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 10:15:32 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (10B141) From: David Farmer Date: Tue, 29 Jan 2013 12:15:29 -0600 To: "Rajiv Asati (rajiva)" X-Gm-Message-State: ALoCoQk+pXVnvff4KBkMODDOXCsoGZvp45/IUJIixuhdBgOwD+UINgNV4ZdZrslvUfaDrsjj4ohJb8NjOllK2SLWJV2mSXO96XgDph56z7Nh9GiDmDl0DYaV4dCCLf+6N6pkgvcBTpbc Cc: "v6ops@ietf.org" , Owen Delong Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:15:45 -0000 I believe this is the "ARP for everything" behavior defined in section 2.6.2= of RFC 3927 which enables a device with a link local address to communicate= with devices on the local link that are using IPv4 GUA. You will find a de= fault route to the local interface, not a router, that enables this behavior= . I learned of this from some IPv6 only experiments Ron Broersma reported on a= t a recent Internet2 IPv6 working group meeting. I believe full implementation of section 3.2 of RFC 6724 would depreference t= he IPv4 link-local address in favor of a IPv6 GUA. I've been thing about po= ssible operational work-arounds, best current thought is a device set up to p= roxy-ARP for everything and return an immediate destination unreachable, but= haven't tried it yet. =20 However, obviously the best solution is for hosts to never prefer a IPv4 lin= k-local address over an IPv6 GUA when communicating with a GUA address. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" wrote: >=20 > A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 GUA, > but no IPv4 public/private address) is intermittently causing very poor > browser internet experience on the MacBook. >=20 > MBP nicely issues both DNS A and AAAA queries over IPv6 transport for a > given website (say, www.cnn.com) almost at the same time (e.g. opens 2 UDP= > sockets), and receives both A and AAAA responses from the DNS server. > However, it may close both UDP sockets upon receiving the first DNS > response (whether A or AAAA), thereby ignoring the 2nd DNS response > (whether A or AAAA). >=20 > Suffice to say that MBP issues an ICMPv6 Destination/port unreachable for > the 2nd DNS response (see the attached 2 screen wireshark screenshots). >=20 > This is quite bad, since if an AAAA record was carried in the ignored DNS > message, then no TCP connection would follow =3D> forget happy eyeballs an= d > recall poor internet experience. :( >=20 > Has anybody else run into this or noticed it? >=20 > Cheers, > Rajiv >=20 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Tue Jan 29 10:29:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8315621F8863 for ; Tue, 29 Jan 2013 10:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeiM4Trp4lWH for ; Tue, 29 Jan 2013 10:29:13 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 04AA021F880B for ; Tue, 29 Jan 2013 10:29:12 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 393F87000109; Tue, 29 Jan 2013 19:29:12 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 1E2EF7000103; Tue, 29 Jan 2013 19:29:12 +0100 (CET) X-SFR-UUID: 20130129182912123.1E2EF7000103@msfrf2503.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 29 Jan 2013 19:29:13 +0100 Message-Id: References: To: Rajiv Asati X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:29:13 -0000 Hi, Raji, I didn't make a detailed study like you did to understand what happens, = but I observed that, while I had been reaching Google in IPv6 for = several years now, I tend to be back in IPv4 now, a real pity. Regards, RD Le 2013-01-29 =E0 18:18, Rajiv Asati (rajiva) a =E9crit= : >=20 > A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 = GUA, > but no IPv4 public/private address) is intermittently causing very = poor > browser internet experience on the MacBook. >=20 > MBP nicely issues both DNS A and AAAA queries over IPv6 transport for = a > given website (say, www.cnn.com) almost at the same time (e.g. opens 2 = UDP > sockets), and receives both A and AAAA responses from the DNS server. > However, it may close both UDP sockets upon receiving the first DNS > response (whether A or AAAA), thereby ignoring the 2nd DNS response > (whether A or AAAA). >=20 > Suffice to say that MBP issues an ICMPv6 Destination/port unreachable = for > the 2nd DNS response (see the attached 2 screen wireshark = screenshots). >=20 > This is quite bad, since if an AAAA record was carried in the ignored = DNS > message, then no TCP connection would follow =3D> forget happy = eyeballs and > recall poor internet experience. :( >=20 > Has anybody else run into this or noticed it? >=20 > Cheers, > Rajiv >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marc.blanchet@viagenie.ca Tue Jan 29 10:30:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FF621F8AB7 for ; Tue, 29 Jan 2013 10:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywvRK3Qhn6qj for ; Tue, 29 Jan 2013 10:30:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A229E21F8AA0 for ; Tue, 29 Jan 2013 10:30:53 -0800 (PST) Received: from h111.viagenie.ca (h111.viagenie.ca [206.123.31.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 16C614044C; Tue, 29 Jan 2013 13:30:53 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Tue, 29 Jan 2013 13:30:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7A2B0C7E-059F-43D5-B0B8-D4F05C1E58DF@viagenie.ca> References: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1283) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:30:54 -0000 Le 2013-01-29 =E0 13:29, R=E9mi Despr=E9s a =E9crit : > Hi, Raji, >=20 > I didn't make a detailed study like you did to understand what = happens, but I observed that, while I had been reaching Google in IPv6 = for several years now, I tend to be back in IPv4 now, a real pity. does not seem relevant, since Rajiv wrote: "but no IPv4 public/private = address" Marc. >=20 > Regards, > RD >=20 >=20 >=20 > Le 2013-01-29 =E0 18:18, Rajiv Asati (rajiva) a = =E9crit : >=20 >>=20 >> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 = GUA, >> but no IPv4 public/private address) is intermittently causing very = poor >> browser internet experience on the MacBook. >>=20 >> MBP nicely issues both DNS A and AAAA queries over IPv6 transport for = a >> given website (say, www.cnn.com) almost at the same time (e.g. opens = 2 UDP >> sockets), and receives both A and AAAA responses from the DNS server. >> However, it may close both UDP sockets upon receiving the first DNS >> response (whether A or AAAA), thereby ignoring the 2nd DNS response >> (whether A or AAAA). >>=20 >> Suffice to say that MBP issues an ICMPv6 Destination/port unreachable = for >> the 2nd DNS response (see the attached 2 screen wireshark = screenshots). >>=20 >> This is quite bad, since if an AAAA record was carried in the ignored = DNS >> message, then no TCP connection would follow =3D> forget happy = eyeballs and >> recall poor internet experience. :( >>=20 >> Has anybody else run into this or noticed it? >>=20 >> Cheers, >> Rajiv >>=20 >> _______________________________________________ >> 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 despres.remi@laposte.net Tue Jan 29 10:40:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03D121F886D for ; Tue, 29 Jan 2013 10:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEm7v2Th1u0A for ; Tue, 29 Jan 2013 10:40:29 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3911121F8858 for ; Tue, 29 Jan 2013 10:40:29 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 6B78670000F8; Tue, 29 Jan 2013 19:40:28 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 4F6D47000072; Tue, 29 Jan 2013 19:40:28 +0100 (CET) X-SFR-UUID: 20130129184028325.4F6D47000072@msfrf2503.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <7A2B0C7E-059F-43D5-B0B8-D4F05C1E58DF@viagenie.ca> Date: Tue, 29 Jan 2013 19:40:29 +0100 Message-Id: <064C8796-E4A1-4796-A2DB-CB3BCE207576@laposte.net> References: <7A2B0C7E-059F-43D5-B0B8-D4F05C1E58DF@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:40:30 -0000 2013-01-29 19:30, Marc Blanchet : > Le 2013-01-29 =E0 13:29, R=E9mi Despr=E9s a =E9crit : >=20 >> Hi, Raji, >>=20 >> I didn't make a detailed study like you did to understand what = happens, but I observed that, while I had been reaching Google in IPv6 = for several years now, I tend to be back in IPv4 now, a real pity. >=20 > does not seem relevant, since Rajiv wrote: "but no IPv4 public/private = address" Not sure I have the time to look at more details. FWIW, my IPv4 address is 192.168.0.21 (private behind a NAT). I only know that my use of IPv6 has been deteriorated, without a change = of my IPv6 and IPv4 addresses. RD >=20 > Marc. >=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> Le 2013-01-29 =E0 18:18, Rajiv Asati (rajiva) a = =E9crit : >>=20 >>>=20 >>> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 = GUA, >>> but no IPv4 public/private address) is intermittently causing very = poor >>> browser internet experience on the MacBook. >>>=20 >>> MBP nicely issues both DNS A and AAAA queries over IPv6 transport = for a >>> given website (say, www.cnn.com) almost at the same time (e.g. opens = 2 UDP >>> sockets), and receives both A and AAAA responses from the DNS = server. >>> However, it may close both UDP sockets upon receiving the first DNS >>> response (whether A or AAAA), thereby ignoring the 2nd DNS response >>> (whether A or AAAA). >>>=20 >>> Suffice to say that MBP issues an ICMPv6 Destination/port = unreachable for >>> the 2nd DNS response (see the attached 2 screen wireshark = screenshots). >>>=20 >>> This is quite bad, since if an AAAA record was carried in the = ignored DNS >>> message, then no TCP connection would follow =3D> forget happy = eyeballs and >>> recall poor internet experience. :( >>>=20 >>> Has anybody else run into this or noticed it? >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>> _______________________________________________ >>> 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 From internet-drafts@ietf.org Tue Jan 29 11:00:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A959221F8A11; Tue, 29 Jan 2013 11:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhRwqvctDq4S; Tue, 29 Jan 2013 11:00:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D2A21F89F9; Tue, 29 Jan 2013 11:00:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2013 11:00:51 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:00:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interfac= e to a LAN Author(s) : Cameron Byrne Dan Drown Filename : draft-ietf-v6ops-64share-01.txt Pages : 8 Date : 2013-01-29 Abstract: This document describes three methods for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jeroen@massar.ch Tue Jan 29 00:40:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C72B21F84EB for ; Tue, 29 Jan 2013 00:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWZT18Gis4qh for ; Tue, 29 Jan 2013 00:40:25 -0800 (PST) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 000E821F863C for ; Tue, 29 Jan 2013 00:40:24 -0800 (PST) Received: from kami.ch.unfix.org (1-19.105-92.cust.bluewin.ch [92.105.19.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id A070B801C061; Tue, 29 Jan 2013 09:40:23 +0100 (CET) Message-ID: <51078AF4.8020403@massar.ch> Date: Tue, 29 Jan 2013 09:40:20 +0100 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gert Doering References: <51024E85.5090803@viagenie.ca> <51025BB7.2060600@gmail.com> <20130125121623.GY51699@Space.Net> <20130125124331.GZ51699@Space.Net> <8AC6169E-2053-422E-8D7F-0DA513AC691B@steffann.nl> <000001cdfb91$3eabf960$bc03ec20$@com> <20130129083038.GR51699@Space.Net> In-Reply-To: <20130129083038.GR51699@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Jan 2013 14:57:45 -0800 Cc: IETF v6ops list Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 08:41:24 -0000 On 2013-01-29 09:30, Gert Doering wrote: > Hi, > > On Mon, Jan 28, 2013 at 08:03:44PM -0800, Cameron Byrne wrote: >> In any event, let us have mercy on the folks who would benefit from >> this /48 per ASN. > > Who exactly would that be? That one organization who will be hooking up a few more BGP tunnels and then claiming they are the number one global transit provider as they have so many ASNs connected. At least, that is the only one who will 'benefit' out of this it seems... everybody else can just go to their RIR and get a prefix. The ISPs that do not care will not care either. Greets, Jeroen ~~ just shove a little bit of traffic over it, just shove a ... ;) From owen@delong.com Tue Jan 29 13:18:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD69721F8726 for ; Tue, 29 Jan 2013 13:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVKex+-DNIGe for ; Tue, 29 Jan 2013 13:18:41 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E367321F870E for ; Tue, 29 Jan 2013 13:18:40 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r0TLGgoU032219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Jan 2013 13:16:42 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r0TLGgoU032219 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1359494202; bh=QRQOe1Au0f12kgdqt0gxYRXl04c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uu95KKY6K1+Wufok5ZGmSQ95dCvHC4MKyXfGSb+VCAr3Nodop2NoD8xKcIoY9Fifk qr5udHuePKj0R30ddZW94revGzR1uc15KS7v1/qYUUzGjJ7Nok5tDHvx35b8dNAOtm 3m3y1BNBzUIVSxeeRCHKOOT3NCkl1MIDKKeX6s8I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Tue, 29 Jan 2013 13:16:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Farmer X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 29 Jan 2013 13:16:42 -0800 (PST) X-Mailman-Approved-At: Tue, 29 Jan 2013 14:57:45 -0800 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:18:41 -0000 On Jan 29, 2013, at 10:15 , David Farmer wrote: > I believe this is the "ARP for everything" behavior defined in section = 2.6.2 of RFC 3927 which enables a device with a link local address to = communicate with devices on the local link that are using IPv4 GUA. You = will find a default route to the local interface, not a router, that = enables this behavior. Nope... this is more detailed and more insidious. If it is not waiting = for the second DNS response and the AAAA record happens to not be the = first answer, bad stuff happens regardless of whether IPv4 is enabled on = the interface (arp for everything problem) or not. This is an actual bug on Apple's part if they are prematurely closing = the DNS connection for the second request as he describes. Remember, getaddrinfo() actually makes two requests to the DNS server. = One for the A and one for the AAAA. The responses arrive on separate = channels as well. This sounds like a bug in Apple's implementation of getaddrinfo() or its = underlying libraries. >=20 > I learned of this from some IPv6 only experiments Ron Broersma = reported on at a recent Internet2 IPv6 working group meeting. >=20 > I believe full implementation of section 3.2 of RFC 6724 would = depreference the IPv4 link-local address in favor of a IPv6 GUA. I've = been thing about possible operational work-arounds, best current thought = is a device set up to proxy-ARP for everything and return an immediate = destination unreachable, but haven't tried it yet. =20 >=20 That doesn't help if you never get the AAAA record. Owen > However, obviously the best solution is for hosts to never prefer a = IPv4 link-local address over an IPv6 GUA when communicating with a GUA = address. >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota =20 > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" = wrote: >=20 >>=20 >> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 = GUA, >> but no IPv4 public/private address) is intermittently causing very = poor >> browser internet experience on the MacBook. >>=20 >> MBP nicely issues both DNS A and AAAA queries over IPv6 transport for = a >> given website (say, www.cnn.com) almost at the same time (e.g. opens = 2 UDP >> sockets), and receives both A and AAAA responses from the DNS server. >> However, it may close both UDP sockets upon receiving the first DNS >> response (whether A or AAAA), thereby ignoring the 2nd DNS response >> (whether A or AAAA). >>=20 >> Suffice to say that MBP issues an ICMPv6 Destination/port unreachable = for >> the 2nd DNS response (see the attached 2 screen wireshark = screenshots). >>=20 >> This is quite bad, since if an AAAA record was carried in the ignored = DNS >> message, then no TCP connection would follow =3D> forget happy = eyeballs and >> recall poor internet experience. :( >>=20 >> Has anybody else run into this or noticed it? >>=20 >> Cheers, >> Rajiv >>=20 >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Tue Jan 29 16:27:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1C221F86FF for ; Tue, 29 Jan 2013 16:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.775 X-Spam-Level: X-Spam-Status: No, score=-5.775 tagged_above=-999 required=5 tests=[AWL=4.224, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwCvEnd5ZdB1 for ; Tue, 29 Jan 2013 16:27:24 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9086F21F86F6 for ; Tue, 29 Jan 2013 16:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4319; q=dns/txt; s=iport; t=1359505644; x=1360715244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M/eX70hOTJVLlYgJipwz6tDVGcVOgKz4Dx1NbcBgS+M=; b=gWVyKUpZ/GOuTafM+fsmeGCh1fuQhH8sbsv6P7GaH89Y7EgP//bWgj6D 8foAy/8x7Vf8oXF9P/lypShgASwytnC6fArvT6QDmS9jSZDeCVLAee2rs Jt5pLn2hH/ZqQvdpRoMj/4Hdp976dX58CoZHRmxWWy1hpRIqNmxbXLJQ9 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIRoCFGtJXG+/2dsb2JhbABBA78BFnOCHgEBAQMBAQEBNw8eBwsOAgIBCBgeEBsMCyUCBA4FG4dwBgyzLo4TBI0KTYJNYQOWDZBLgmoNgW8 X-IronPort-AV: E=Sophos;i="4.84,562,1355097600"; d="scan'208";a="170156876" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 30 Jan 2013 00:27:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0U0RN1k025919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 00:27:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 18:27:23 -0600 From: "Rajiv Asati (rajiva)" To: Owen DeLong Thread-Topic: [v6ops] OSX 10.8 poor performance for IPv6-only! Thread-Index: AQHN/kSlHZLWiwT60EaYA9l3n7/StJhhAUiAgAAyoID//9Czcw== Date: Wed, 30 Jan 2013 00:27:22 +0000 Message-ID: <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:27:25 -0000 Owen, you are spot on.=20 I can't think of anything, but a possible bug in OSX 10.8.2. Really a weird= one. I wonder whether this was meant to make the happy-eyeballing implemen= tation better. ;-) My IPv6-only usage has been pathetically slow on MBP, least to say. I iPhon= e has been fine though. Cheers, Rajiv Sent from my Phone On Jan 29, 2013, at 4:18 PM, "Owen DeLong" wrote: >=20 > On Jan 29, 2013, at 10:15 , David Farmer wrote: >=20 >> I believe this is the "ARP for everything" behavior defined in section 2= .6.2 of RFC 3927 which enables a device with a link local address to commun= icate with devices on the local link that are using IPv4 GUA. You will fin= d a default route to the local interface, not a router, that enables this b= ehavior. >=20 > Nope... this is more detailed and more insidious. If it is not waiting fo= r the second DNS response and the AAAA record happens to not be the first a= nswer, bad stuff happens regardless of whether IPv4 is enabled on the inter= face (arp for everything problem) or not. >=20 > This is an actual bug on Apple's part if they are prematurely closing the= DNS connection for the second request as he describes. >=20 > Remember, getaddrinfo() actually makes two requests to the DNS server. On= e for the A and one for the AAAA. The responses arrive on separate channels= as well. >=20 > This sounds like a bug in Apple's implementation of getaddrinfo() or its = underlying libraries. >=20 >>=20 >> I learned of this from some IPv6 only experiments Ron Broersma reported = on at a recent Internet2 IPv6 working group meeting. >>=20 >> I believe full implementation of section 3.2 of RFC 6724 would deprefere= nce the IPv4 link-local address in favor of a IPv6 GUA. I've been thing ab= out possible operational work-arounds, best current thought is a device set= up to proxy-ARP for everything and return an immediate destination unreach= able, but haven't tried it yet. =20 >=20 > That doesn't help if you never get the AAAA record. >=20 > Owen >=20 >> However, obviously the best solution is for hosts to never prefer a IPv4= link-local address over an IPv6 GUA when communicating with a GUA address. >>=20 >> --=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota =20 >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >> On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" wro= te: >>=20 >>>=20 >>> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 GUA= , >>> but no IPv4 public/private address) is intermittently causing very poor >>> browser internet experience on the MacBook. >>>=20 >>> MBP nicely issues both DNS A and AAAA queries over IPv6 transport for a >>> given website (say, www.cnn.com) almost at the same time (e.g. opens 2 = UDP >>> sockets), and receives both A and AAAA responses from the DNS server. >>> However, it may close both UDP sockets upon receiving the first DNS >>> response (whether A or AAAA), thereby ignoring the 2nd DNS response >>> (whether A or AAAA). >>>=20 >>> Suffice to say that MBP issues an ICMPv6 Destination/port unreachable f= or >>> the 2nd DNS response (see the attached 2 screen wireshark screenshots). >>>=20 >>> This is quite bad, since if an AAAA record was carried in the ignored D= NS >>> message, then no TCP connection would follow =3D> forget happy eyeballs= and >>> recall poor internet experience. :( >>>=20 >>> Has anybody else run into this or noticed it? >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From lorenzo@google.com Tue Jan 29 16:34:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8489821F86EC for ; Tue, 29 Jan 2013 16:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJROv4J94POD for ; Tue, 29 Jan 2013 16:34:56 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id E5E9421F8689 for ; Tue, 29 Jan 2013 16:34:51 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id uz6so1107540obc.34 for ; Tue, 29 Jan 2013 16:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KzIZwsTLsu/IgEci/1hKD2JR3muvKBRNg/y8Er3vDr8=; b=Tqr2cYjuw41iRdmWUKkH3Iz7R0AxGZaCc8ZZMP1K1D2LxJ8NZaymWfDRlGRSX5XiVv y7S37vfOVm2XUHmB9WnSJKvEB4Vx7bURY44AgACdqt7H7plIhOkjL/csdwD5ocdyxiaq BIz7jL6ZUzQy46FyDc7etUMJEDClFDUeDvhsbsrSBsAYZYUJu9QW9faiBRQR3BSbdMsz SzobWlFNpYgzJvwLi1qrhiaoQ8tAtjOMzGZ/Pr3Wnb2E6r0vXxhMZ9pVWWttsJlJS8Z/ BUPaaE1z3N6UhQGzF0CaAL2fVmbOkKoREEj5ZhV5ONoOPo4QC3C7HHgpAInRp2F7kinM KJGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=KzIZwsTLsu/IgEci/1hKD2JR3muvKBRNg/y8Er3vDr8=; b=dKpBmxSQUj8gKjlH1Lr6GWTwookpnkA4JOksSMx914gTJCXYLaETDG+JMNan6EnPiT oT5S+mfLzsKGTOp6g43sSGtaUCFuWd8zllvGXvBB1hJihP+HcSFwhJqoE3qqTAdRgJpB /6eeb556Fzt6l0ieiYeZ/8gPsdZ9eb/jnVRt+IfFJj7LVDQIoAIMvWk2Y4gp6YMcSMDe t8AB78K/xNvtEOihoh8KAnvmQbd8CxyAlJWfoQw3m7e/+y6HGsR7MIrO68Xlq26Wccfb IgC+ESdDn7XIOFMew8GL2wKEjO1y0ZE3pXNwX+b/qi234MTkzcDsEarAcO9r5feiXkGj H0zA== X-Received: by 10.60.6.199 with SMTP id d7mr2235547oea.137.1359506091428; Tue, 29 Jan 2013 16:34:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.144.169 with HTTP; Tue, 29 Jan 2013 16:34:31 -0800 (PST) In-Reply-To: <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> References: <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> From: Lorenzo Colitti Date: Wed, 30 Jan 2013 09:34:31 +0900 Message-ID: To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=e89a8fb1fd74a64bb104d476addf X-Gm-Message-State: ALoCoQmRIBHDqxtRSJ0nyui9ni4/dwqUtmhQVRciUV7iGxQP6T9oRfniH4L+HhAG8ngVpdRVBqtVvkKcIcqJQTczVwYxhcR2SYV88NDtYVgQr9H8ESmFlFFqT44Sh4lD1UOBg0E5IVDMYfW+JYnGtPM7HpbJCK6N9etB6mOSd+t4UeGbIAx8MzlvdUzQ7Lz2HxDQ2aNv2PPG Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:34:57 -0000 --e89a8fb1fd74a64bb104d476addf Content-Type: text/plain; charset=ISO-8859-1 Why is it requesting an A record even if it has no IPv4 address? Isn't that what AI_ADDRCONFIG is for? Is it possible that the browser is not passing in AI_ADDRCONFIG? Do different browsers behave in different ways? On Wed, Jan 30, 2013 at 9:27 AM, Rajiv Asati (rajiva) wrote: > Owen, you are spot on. > > I can't think of anything, but a possible bug in OSX 10.8.2. Really a > weird one. I wonder whether this was meant to make the happy-eyeballing > implementation better. ;-) > > My IPv6-only usage has been pathetically slow on MBP, least to say. I > iPhone has been fine though. > > Cheers, > Rajiv > > Sent from my Phone > > On Jan 29, 2013, at 4:18 PM, "Owen DeLong" wrote: > > > > > On Jan 29, 2013, at 10:15 , David Farmer wrote: > > > >> I believe this is the "ARP for everything" behavior defined in section > 2.6.2 of RFC 3927 which enables a device with a link local address to > communicate with devices on the local link that are using IPv4 GUA. You > will find a default route to the local interface, not a router, that > enables this behavior. > > > > Nope... this is more detailed and more insidious. If it is not waiting > for the second DNS response and the AAAA record happens to not be the first > answer, bad stuff happens regardless of whether IPv4 is enabled on the > interface (arp for everything problem) or not. > > > > This is an actual bug on Apple's part if they are prematurely closing > the DNS connection for the second request as he describes. > > > > Remember, getaddrinfo() actually makes two requests to the DNS server. > One for the A and one for the AAAA. The responses arrive on separate > channels as well. > > > > This sounds like a bug in Apple's implementation of getaddrinfo() or its > underlying libraries. > > > >> > >> I learned of this from some IPv6 only experiments Ron Broersma reported > on at a recent Internet2 IPv6 working group meeting. > >> > >> I believe full implementation of section 3.2 of RFC 6724 would > depreference the IPv4 link-local address in favor of a IPv6 GUA. I've been > thing about possible operational work-arounds, best current thought is a > device set up to proxy-ARP for everything and return an immediate > destination unreachable, but haven't tried it yet. > > > > That doesn't help if you never get the AAAA record. > > > > Owen > > > >> However, obviously the best solution is for hosts to never prefer a > IPv4 link-local address over an IPv6 GUA when communicating with a GUA > address. > >> > >> -- > >> =============================================== > >> David Farmer Email:farmer@umn.edu > >> Networking & Telecommunication Services > >> Office of Information Technology > >> University of Minnesota > >> 2218 University Ave SE Phone: 612-626-0815 > >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 > >> =============================================== > >> > >> > >> On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" > wrote: > >> > >>> > >>> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 > GUA, > >>> but no IPv4 public/private address) is intermittently causing very poor > >>> browser internet experience on the MacBook. > >>> > >>> MBP nicely issues both DNS A and AAAA queries over IPv6 transport for a > >>> given website (say, www.cnn.com) almost at the same time (e.g. opens > 2 UDP > >>> sockets), and receives both A and AAAA responses from the DNS server. > >>> However, it may close both UDP sockets upon receiving the first DNS > >>> response (whether A or AAAA), thereby ignoring the 2nd DNS response > >>> (whether A or AAAA). > >>> > >>> Suffice to say that MBP issues an ICMPv6 Destination/port unreachable > for > >>> the 2nd DNS response (see the attached 2 screen wireshark screenshots). > >>> > >>> This is quite bad, since if an AAAA record was carried in the ignored > DNS > >>> message, then no TCP connection would follow => forget happy eyeballs > and > >>> recall poor internet experience. :( > >>> > >>> Has anybody else run into this or noticed it? > >>> > >>> Cheers, > >>> Rajiv > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > --e89a8fb1fd74a64bb104d476addf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why is it requesting an A record even if it has no IPv4 ad= dress? Isn't that what AI_ADDRCONFIG is for?

Is it p= ossible that the browser is not passing in AI_ADDRCONFIG? Do different brow= sers behave in different ways?


On Wed,= Jan 30, 2013 at 9:27 AM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
Owen, you are spot on.

I can't think of anything, but a possible bug in OSX 10.8.2. Really a w= eird one. I wonder whether this was meant to make the happy-eyeballing impl= ementation better. ;-)

My IPv6-only usage has been pathetically slow on MBP, least to say. I iPhon= e has been fine though.

Cheers,
Rajiv

Sent from my Phone

On Jan 29, 2013, at 4:18 PM, "Owen DeLong" <owen@delong.com> wrote:

>
> On Jan 29, 2013, at 10:15 , David Farmer <farmer@umn.edu> wrote:
>
>> I believe this is the "ARP for everything" behavior defi= ned in section 2.6.2 of RFC 3927 which enables a device with a link local a= ddress to communicate with devices on the local link that are using IPv4 GU= A. =A0You will find a default route to the local interface, not a router, t= hat enables this behavior.
>
> Nope... this is more detailed and more insidious. If it is not waiting= for the second DNS response and the AAAA record happens to not be the firs= t answer, bad stuff happens regardless of whether IPv4 is enabled on the in= terface (arp for everything problem) or not.
>
> This is an actual bug on Apple's part if they are prematurely clos= ing the DNS connection for the second request as he describes.
>
> Remember, getaddrinfo() actually makes two requests to the DNS server.= One for the A and one for the AAAA. The responses arrive on separate chann= els as well.
>
> This sounds like a bug in Apple's implementation of getaddrinfo() = or its underlying libraries.
>
>>
>> I learned of this from some IPv6 only experiments Ron Broersma rep= orted on at a recent Internet2 IPv6 working group meeting.
>>
>> I believe full implementation of section 3.2 of RFC 6724 would dep= reference the IPv4 link-local address in favor of a IPv6 GUA. =A0I've b= een thing about possible operational work-arounds, best current thought is = a device set up to proxy-ARP for everything and return an immediate destina= tion unreachable, but haven't tried it yet.
>
> That doesn't help if you never get the AAAA record.
>
> Owen
>
>> However, obviously the best solution is for hosts to never prefer = a IPv4 link-local address over an IPv6 GUA when communicating with a GUA ad= dress.
>>
>> --
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>> David Farmer =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email:farmer@umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE =A0 =A0 =A0 =A0Phone: 612-626-0815
>> Minneapolis, MN 55414-3029 =A0 Cell: 612-812-9952
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>
>>
>> On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
>>
>>>
>>> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with= IPv6 GUA,
>>> but no IPv4 public/private address) is intermittently causing = very poor
>>> browser internet experience on the MacBook.
>>>
>>> MBP nicely issues both DNS A and AAAA queries over IPv6 transp= ort for a
>>> given website (say, www.cnn.com) almost at the same time (e.g. opens 2 UDP
>>> sockets), and receives both A and AAAA responses from the DNS = server.
>>> However, it may close both UDP sockets upon receiving the firs= t DNS
>>> response (whether A or AAAA), thereby ignoring the 2nd DNS res= ponse
>>> (whether A or AAAA).
>>>
>>> Suffice to say that MBP issues an ICMPv6 Destination/port unre= achable for
>>> the 2nd DNS response (see the attached 2 screen wireshark scre= enshots).
>>>
>>> This is quite bad, since if an AAAA record was carried in the = ignored DNS
>>> message, then no TCP connection would follow =3D> forget ha= ppy eyeballs and
>>> recall poor internet experience. :(
>>>
>>> Has anybody else run into this or noticed it?
>>>
>>> Cheers,
>>> Rajiv
>>>
>>> <Screen Shot 2013-01-29 at 11.38.35 AM.png>
>>> <Screen Shot 2013-01-29 at 11.40.04 AM.png>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8fb1fd74a64bb104d476addf-- From owen@delong.com Tue Jan 29 16:38:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D6821F8801 for ; Tue, 29 Jan 2013 16:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miyhBJA1p74U for ; Tue, 29 Jan 2013 16:38:47 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E05021F872C for ; Tue, 29 Jan 2013 16:38:47 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r0U0cLwH018137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Jan 2013 16:38:21 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r0U0cLwH018137 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1359506302; bh=UkCHQ6cDGP2V7H6JjkGztqnDBc0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lVgUzKE2UmBDNHkuV5vZk8ccQO4zqxHk0yCAJMpChiSXrAL+za1mlcYOX4ycWt2hJ hyl8RPR3ZtIfQhLFIPt6kboCr2d/fjV5jmGJCaInVbygWBYyI4DOwkQGEbaRO/Hfcg Ypl6ePi5ZcvVRDpKeqpEmgXlGwTYF4RWmAiso83E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> Date: Tue, 29 Jan 2013 16:38:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> References: , <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 29 Jan 2013 16:38:22 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:38:48 -0000 Not so strange... I suspect the logic went something like this... Happy Eyeballs is all about returning a usable connection as fast as = possible. Most testing likely done in dual-stack and/or IPv4-only environments. DNS resolver library sends out A and AAAA requests. It's not at all hard to imagine how a developer could make the mistake = of either of the following logics: while (!timeout) { if(v4_answer_received && v6_answer_received) = return(concatenate(v4_answer, v6_answer)); if(v4_answer_received) return(v4_answer); } or while (!timeout) { if(v4_answer_received && v6_answer_received) = return(concatenate(v4_answer, v6_answer)); if(v4_answer_received) return(v4_answer); if(v6_answer_received) return(v6_answer); } In the first case, it would break on an IPv6 only network, but work in = an IPv4-only environment. In the second case, it would break in certain IPv4-only environments, = too. Obviously, the real bug is going to be more complex and integral, as = Happy Eyeballs is a combination of resolver and connection initiation, likely involving a = threaded approach, but I wanted to provide a simple illustration of the likely logic trap. = I'll leave the detailed debugging to Apple's engineers. Owen On Jan 29, 2013, at 16:27 , "Rajiv Asati (rajiva)" = wrote: > Owen, you are spot on.=20 >=20 > I can't think of anything, but a possible bug in OSX 10.8.2. Really a = weird one. I wonder whether this was meant to make the happy-eyeballing = implementation better. ;-) >=20 > My IPv6-only usage has been pathetically slow on MBP, least to say. I = iPhone has been fine though. >=20 > Cheers, > Rajiv >=20 > Sent from my Phone >=20 > On Jan 29, 2013, at 4:18 PM, "Owen DeLong" wrote: >=20 >>=20 >> On Jan 29, 2013, at 10:15 , David Farmer wrote: >>=20 >>> I believe this is the "ARP for everything" behavior defined in = section 2.6.2 of RFC 3927 which enables a device with a link local = address to communicate with devices on the local link that are using = IPv4 GUA. You will find a default route to the local interface, not a = router, that enables this behavior. >>=20 >> Nope... this is more detailed and more insidious. If it is not = waiting for the second DNS response and the AAAA record happens to not = be the first answer, bad stuff happens regardless of whether IPv4 is = enabled on the interface (arp for everything problem) or not. >>=20 >> This is an actual bug on Apple's part if they are prematurely closing = the DNS connection for the second request as he describes. >>=20 >> Remember, getaddrinfo() actually makes two requests to the DNS = server. One for the A and one for the AAAA. The responses arrive on = separate channels as well. >>=20 >> This sounds like a bug in Apple's implementation of getaddrinfo() or = its underlying libraries. >>=20 >>>=20 >>> I learned of this from some IPv6 only experiments Ron Broersma = reported on at a recent Internet2 IPv6 working group meeting. >>>=20 >>> I believe full implementation of section 3.2 of RFC 6724 would = depreference the IPv4 link-local address in favor of a IPv6 GUA. I've = been thing about possible operational work-arounds, best current thought = is a device set up to proxy-ARP for everything and return an immediate = destination unreachable, but haven't tried it yet. =20 >>=20 >> That doesn't help if you never get the AAAA record. >>=20 >> Owen >>=20 >>> However, obviously the best solution is for hosts to never prefer a = IPv4 link-local address over an IPv6 GUA when communicating with a GUA = address. >>>=20 >>> --=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> David Farmer Email:farmer@umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota =20 >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>=20 >>> On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" = wrote: >>>=20 >>>>=20 >>>> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 = GUA, >>>> but no IPv4 public/private address) is intermittently causing very = poor >>>> browser internet experience on the MacBook. >>>>=20 >>>> MBP nicely issues both DNS A and AAAA queries over IPv6 transport = for a >>>> given website (say, www.cnn.com) almost at the same time (e.g. = opens 2 UDP >>>> sockets), and receives both A and AAAA responses from the DNS = server. >>>> However, it may close both UDP sockets upon receiving the first DNS >>>> response (whether A or AAAA), thereby ignoring the 2nd DNS response >>>> (whether A or AAAA). >>>>=20 >>>> Suffice to say that MBP issues an ICMPv6 Destination/port = unreachable for >>>> the 2nd DNS response (see the attached 2 screen wireshark = screenshots). >>>>=20 >>>> This is quite bad, since if an AAAA record was carried in the = ignored DNS >>>> message, then no TCP connection would follow =3D> forget happy = eyeballs and >>>> recall poor internet experience. :( >>>>=20 >>>> Has anybody else run into this or noticed it? >>>>=20 >>>> Cheers, >>>> Rajiv >>>>=20 >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From lorenzo@google.com Tue Jan 29 16:41:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F8021F8801 for ; Tue, 29 Jan 2013 16:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ioXo+U-OxKj for ; Tue, 29 Jan 2013 16:41:12 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8962921F8718 for ; Tue, 29 Jan 2013 16:41:12 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id va7so1097814obc.13 for ; Tue, 29 Jan 2013 16:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Jsd5GZZzTKSg8kMIhDW4/awp8LYP/K8ZVu69TXkecqA=; b=e8yGuwGMR4uJjAJqKOc0creA3Q95vsMMmE706GTYgn6G+hByDAi2kF2x8iAJSb818S z77LT97ERvNXPDju2T3BSL/JKNWBtB8hhycntJL3M7XbovBQrIbM5nQsw5HsDpuzifcE A9UssjdJBR6iw0U9HZo7Rdq9sXtegtMsJ/Qx6pTdEiFFIIzm+3aw1lxKJt1PIQX0ERRH q9E51yaieSIF8EDD5For7FLb1UGZFjc9CYw1X/inMlxYc4t4npUDf1lceIYwEfOTSwcU HoAqdtUtZLSoK3Gdtk4VCbexN6lQmWenTNfLxhUU5A+HAmKy1pMYE74UqRpo/dHICfxG 6KBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Jsd5GZZzTKSg8kMIhDW4/awp8LYP/K8ZVu69TXkecqA=; b=k/iMcbF3jMO3hYvGjE3uum/bOiRTxsn90sOAkkS4SyXjhkHCgia3nQ+Gus1H4UOwO0 HDY1iR9x71mWZKKyhp8VuaebWYKh00Guw7uml5yy11bpxgz/3XL4dQhZAk7Rn5ux1ka4 dkBN3mZU4Ho/E/xzRlDrTkXL/4pBzz6B099WSsNMbm7mXih4tNUWD2xRH7FI21aHkHed lo2pvY0/d4VGG6xv9Z4cNDHwTHW4fy4wBK1BjM70HQKKlQVYruz4zSWnx0+E6JxJfCLy xdEpPZvEElyi50kSMb6oRhEN4LGFmYsu8eylHFKzx/b69YMfe4zv3LgF5fljkv/g2aon uTUQ== X-Received: by 10.60.172.178 with SMTP id bd18mr2341349oec.133.1359506471915; Tue, 29 Jan 2013 16:41:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.144.169 with HTTP; Tue, 29 Jan 2013 16:40:50 -0800 (PST) In-Reply-To: <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> References: <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> From: Lorenzo Colitti Date: Wed, 30 Jan 2013 09:40:50 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=bcaec54d49f2540f9e04d476c4d1 X-Gm-Message-State: ALoCoQkXWVPyUrtPwFlg2GP0g41Jdf0lgaYtImTGajuYQ/N6lpqldssV+3YnmoM6S/hvNL4eu8e8t11MUPMq8MvUtmvwuR9ElMyr0eg3c9eMypC2LzJ0t5vDg0Xr4DP6xEC5smNeqJa5c4W8TO849cLWAufYwQsXwHKpGqmmtpCwa7IwxLYgmtug7PYQl4kf/W+Z8kFuY9rj Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:41:17 -0000 --bcaec54d49f2540f9e04d476c4d1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 30, 2013 at 9:38 AM, Owen DeLong wrote: > I'll leave the detailed debugging to Apple's engineers. > Good luck with that. :) --bcaec54d49f2540f9e04d476c4d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 30, 2013 at 9:38 AM, Owen DeLong <owen@delong.c= om> wrote:
I'll leave the detailed=A0debugging to Apple's engineers.

Good luck with that. :)=A0
--bcaec54d49f2540f9e04d476c4d1-- From marka@isc.org Tue Jan 29 17:06:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BC521F881D for ; Tue, 29 Jan 2013 17:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB-Em6qJXZQk for ; Tue, 29 Jan 2013 17:06:45 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8721F8816 for ; Tue, 29 Jan 2013 17:06:45 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1A1AE5F9920; Wed, 30 Jan 2013 01:06:36 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1359508004; bh=qhRBQOMlrotu8zr5lj/Y5FhoMbXHPT0HmQJCl31KC0A=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=DeKKEmAq935n9vBOHGHuKokPazIVjZEAsiqTKJVDZrlJ60kLlXEqe0+kS31TW7GZW kmai8Gb95d0lNTs16y0/orhl9uoOUkiMwczXs3P9VGnLdF5zKACyt7ikEx/UlnYVUq KzhIs4SNM2mBwSPAeTNsWmXnKb4l2S72/4VL2QM8= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7DE84216C3B; Wed, 30 Jan 2013 01:06:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3895A2E8A2E2; Wed, 30 Jan 2013 12:06:31 +1100 (EST) To: Owen DeLong From: Mark Andrews References: , <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> In-reply-to: Your message of "Tue, 29 Jan 2013 16:38:17 -0800." <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> Date: Wed, 30 Jan 2013 12:06:31 +1100 Message-Id: <20130130010631.3895A2E8A2E2@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 01:06:45 -0000 Part of the problem is there is this myth that AAAA lookups fail a lot. They don't. There are a few bad (drop AAAA queries) / misconfigured (return the wrong negative answer) load balancers. If you are talking to something other than a load balancer you get valid answers. When you code for this you get all sorts of bad behaviour. If you can't configure your nameserver to respond correctly to AAAA queries the customet SHOULD get bad performance. How else does feedback get applied. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From zhenkaiw@gmail.com Tue Jan 29 19:08:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B90F21F886D for ; Tue, 29 Jan 2013 19:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xV+3rR8Yjhl3 for ; Tue, 29 Jan 2013 19:08:15 -0800 (PST) Received: from mail-ob0-f196.google.com (mail-ob0-f196.google.com [209.85.214.196]) by ietfa.amsl.com (Postfix) with ESMTP id EBDCB21F86C3 for ; Tue, 29 Jan 2013 19:08:14 -0800 (PST) Received: by mail-ob0-f196.google.com with SMTP id va7so288423obc.7 for ; Tue, 29 Jan 2013 19:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=R2qAqmNVhoUd+O+OcAwuVLf83tMUEcYf1nqlAl8O55M=; b=v5rqNdJNhwWXF27sbu0Qgi08vFNClh1mxqH1S4caIMyDIXC9bTBca4f7qidMsXGVFV q+m0fjTCwVfrVSmLjQj+OaUj2f8J5KIThzGCVo36DVQPZy0P7jOKv8i80TAlJmzk1a1T XwKIOqIc2XtyuzYHhUVeZI0na7EjuLmp0uN+uSWYjQi5qI/kikM8sCCc3gLQRF6F0P5f Z4o8NEnH//hNFR1X0FV2kSk6+f4Y6FIJCd9ZYXpeuy/gxscB87l+Z4WugtwMEWDKPMOu mqN32HZDk/8vReVbdssXcMFHYs/sx6xGgZ6ssHVfb/DzspJdXBPi9rFhzO1Pv2V6xNsg aKog== MIME-Version: 1.0 X-Received: by 10.182.12.4 with SMTP id u4mr2533739obb.74.1359515293626; Tue, 29 Jan 2013 19:08:13 -0800 (PST) Received: by 10.182.154.103 with HTTP; Tue, 29 Jan 2013 19:08:13 -0800 (PST) Date: Wed, 30 Jan 2013 11:08:13 +0800 Message-ID: From: Zhenkai Wang To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=f46d0444ee9d24b07104d478d2b8 Subject: [v6ops] China Mobile's Statement about IPR related to draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 03:08:17 -0000 --f46d0444ee9d24b07104d478d2b8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello IETF, As a company, China Mobile has spent lots of efforts like expenditure of man workforce, time, et al. on some technologies. We underline that Intellectual property Rights (IPRs) are an important part of technologies, and also respect IPRs like other companies in the industry. The disclosure about patent *http://datatracker.ietf.org/ipr/1730/* is a compliance with the rules of the IETF which are defined in RFC 3979, "Intellectual Property Rights in IETF Technology." = The licensing declaration for this Document =91c) Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee=92= made by China Mobile was in accordance with our corporate strategy, as well as industry practice. Best regards, Wang Zhengkai ------------------------------ Wang Zhenkai IP Counsel | China Mobile Research Institute Office: +86 15801696688-35235 | Mobile: +8613810187794 | NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of China Mobile, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --f46d0444ee9d24b07104d478d2b8 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hello IETF,

 

As a company, China Mobile has spent lots of efforts l= ike expenditure of man workforce, time, et al. on some technologies. We und= erline that Intellectual property Rights (IPRs) are an important part of te= chnologies, and also respect IPRs like other companies in the industry.

 

The disclosure ab= out patent http://datatracker.ietf.org/ipr/1= 730/ is a compliance with the rules of the IETF whic= h are defined in RFC 3979, "Intellectual Pro= perty Rights in IETF Technology." The licensing dec= laration for this Document ‘c)= Reasonable and Non-Discriminatory License to All Implementers with Possibl= e Royalty/Fee’&n= bsp;made by China Mobile was in accordance with our corporate strategy, as = well as industry practice.

 

Best regards,

 

Wang Zhengkai

 
Wang Zhenkai

 IP Counsel | China Mobile Research Institute

Office: +86 15801696688-35235 | Mobile: +8= 613810187794 |

NO.32 Xuanwumen West Street,Xicheng District,Beijing&n= bsp;100053.China.
 
Confidentiality Notice: The information contained in this e-= mail and any accompanying attachment(s) is intended only for the use of the= intended recipient and may be confidential and/or privileged of China Mobi= le, its subsidiaries and/or its affiliates. If any reader of this communica= tion is not the intended recipient, unauthorized use, forwarding, printing,= storing, disclosure or copying is strictly prohibited, and may be unlawful= . If you have received this communication in error, please immediately noti= fy the sender by return e-mail, and delete the original message and all cop= ies from your system. Thank you.
--f46d0444ee9d24b07104d478d2b8-- From owen@delong.com Tue Jan 29 19:09:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0137E21F886F for ; Tue, 29 Jan 2013 19:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyO25jpNJong for ; Tue, 29 Jan 2013 19:09:05 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1490E21F886D for ; Tue, 29 Jan 2013 19:09:05 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r0U35FJ3021322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Jan 2013 19:05:16 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r0U35FJ3021322 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1359515116; bh=jQnzSNgo/NMD3GXGFy+PoKBmrNY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WT83AIWQNSZfHtQp4tbNoH11FGO/piQc5zVFAl96GvCRfA0yQaAzrEdEb3YO6UeDp Jly6WCBZUwRJEkxeeu+tf2VhoLX+FmwEaRBew9F+5r+aOXpbqqVrXak/jUzvb/ELhd nvoBRS1f0iKzS6wreFeOLkkbSARdf04ifnyK4jcE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130130010631.3895A2E8A2E2@drugs.dv.isc.org> Date: Tue, 29 Jan 2013 19:04:59 -0800 Content-Transfer-Encoding: 7bit Message-Id: <2C3FC41E-7B48-4304-9BC4-ED2FDC0B6993@delong.com> References: , <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> <20130130010631.3895A2E8A2E2@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 29 Jan 2013 19:05:16 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 03:09:07 -0000 Providing feedback to the end-user about a DNS server they don't even know they are using in a way that does not allow them to easily identify the DNS server in question, let alone who is responsible for it or how to report the problem isn't useful. Feedback that reaches the person responsible for fixing the problem is like feedback heard by the sound-man in a concert hall. The sound man will take action to resolve the issue. Feedback that doesn't is just noise that makes everyone in the hall unhappy. However, regardless of how unhappy they are, they don't have any real ability to fix the problem. Owen On Jan 29, 2013, at 5:06 PM, Mark Andrews wrote: > > Part of the problem is there is this myth that AAAA lookups fail a > lot. They don't. There are a few bad (drop AAAA queries) / > misconfigured (return the wrong negative answer) load balancers. > If you are talking to something other than a load balancer you get > valid answers. When you code for this you get all sorts of bad > behaviour. > > If you can't configure your nameserver to respond correctly to AAAA > queries the customet SHOULD get bad performance. How else does > feedback get applied. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Jan 29 20:41:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6AD21F8B06 for ; Tue, 29 Jan 2013 20:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZszCZy9vHh7 for ; Tue, 29 Jan 2013 20:41:43 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 94CC521F8AF2 for ; Tue, 29 Jan 2013 20:41:43 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 99B8E5F9954; Wed, 30 Jan 2013 04:41:34 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1359520902; bh=ElACuDkwvkOTVzh+1tIS+tzWeBCEP/IuKRvRiV41uO0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=c9ZO3p6pdXOVsz0SejAlCGskWX4MzdleZEcGpJ6Tot93C3H9KWfs+Oy1DBIrDkXde TrfdusbE0A18beAAxsNIvVAN18PXgHwL7Td5vZ297ayC+ecEAzecK2uuqQZU18cBp/ Esqxy8Gnp16qJL97oF5sTRP7Ln7jp7bV424O+LPw= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6d4c:bf75:398c:382d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EDA86216C40; Wed, 30 Jan 2013 04:41:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 696F22E8DCD0; Wed, 30 Jan 2013 15:41:30 +1100 (EST) To: Owen DeLong From: Mark Andrews References: , <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> <20130130010631.3895A2E8A2E2@drugs.dv.isc.org> <2C3FC41E-7B48-4304-9BC4-ED2FDC0B6993@delong.com> In-reply-to: Your message of "Tue, 29 Jan 2013 19:04:59 -0800." <2C3FC41E-7B48-4304-9BC4-ED2FDC0B6993@delong.com> Date: Wed, 30 Jan 2013 15:41:30 +1100 Message-Id: <20130130044130.696F22E8DCD0@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 04:41:48 -0000 In message <2C3FC41E-7B48-4304-9BC4-ED2FDC0B6993@delong.com>, Owen DeLong write s: > Providing feedback to the end-user about a DNS server they don't even > know they are using in a way that does not allow them to easily identify the > DNS server in question, let alone who is responsible for it or how to report > the problem isn't useful. How does a user deal with any remote problem? They contact their ISP. The ISP should have enough clue to contact the DNS server administrator. IPv6 is being deployed wide enough that even IPv4 only sites are starting to be aware of it. Note this is also a problem that will correct itself over time as sites with broken load balancers enable IPv6. I just for interest I dumped the nameserver's cache and looked up the AAAA for every A record in the cache. I had one zone with broken AAAA lookups and one lookup failing due to DNSSEC validation failures. The servers for cedexis.net return A records in response to AAAA lookups. flipa.cedexis.net. flipd.cedexis.net. flipg.cedexis.net. Mark > Feedback that reaches the person responsible for fixing the problem is > like feedback heard by the sound-man in a concert hall. The sound man > will take action to resolve the issue. > > Feedback that doesn't is just noise that makes everyone in the hall unhappy. > However, regardless of how unhappy they are, they don't have any real > ability to fix the problem. > > Owen > > On Jan 29, 2013, at 5:06 PM, Mark Andrews wrote: > > > > > Part of the problem is there is this myth that AAAA lookups fail a > > lot. They don't. There are a few bad (drop AAAA queries) / > > misconfigured (return the wrong negative answer) load balancers. > > If you are talking to something other than a load balancer you get > > valid answers. When you code for this you get all sorts of bad > > behaviour. > > > > If you can't configure your nameserver to respond correctly to AAAA > > queries the customet SHOULD get bad performance. How else does > > feedback get applied. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pkern@spike.0x539.de Wed Jan 30 01:26:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB18721F8792 for ; Wed, 30 Jan 2013 01:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iK+CPXiQZUW for ; Wed, 30 Jan 2013 01:26:47 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE9721F886D for ; Wed, 30 Jan 2013 01:26:46 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U0TwJ-0000cD-Vl; Wed, 30 Jan 2013 10:26:44 +0100 Received: from e180089059.adsl.alicedsl.de ([85.180.89.59] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1U0TwK-0004Fa-N8; Wed, 30 Jan 2013 10:26:44 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1U0TwJ-00049p-Ma; Wed, 30 Jan 2013 10:26:43 +0100 Date: Wed, 30 Jan 2013 10:26:43 +0100 From: Philipp Kern To: Mark Andrews Message-ID: <20130130092643.GB15170@spike.0x539.de> References: <337D7140-C15F-45AD-BEB9-221AF24F455E@cisco.com> <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> <20130130010631.3895A2E8A2E2@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <20130130010631.3895A2E8A2E2@drugs.dv.isc.org> Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:26:49 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mark, am Wed, Jan 30, 2013 at 12:06:31PM +1100 hast du folgendes geschrieben: > Part of the problem is there is this myth that AAAA lookups fail a > lot. They don't. There are a few bad (drop AAAA queries) / > misconfigured (return the wrong negative answer) load balancers. and CPEs. (Which meant switching to Google DNS for the Linux clients in that network.) Feedback's useless, it doesn't get forwarded to the right places within the ISP and/or the ISP doesn't care and/or the CPE vendor doesn't put out a fix. The broken (not misconfigured) load balancers were dropped from their recursors by another ISP when I mentioned it to them. That's on the network level and somehow easier to solve. Kind regards Philipp Kern --s2ZSL+KKDSLx8OML Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJRCOdTAAoJEERuJUU10FbsCCcIAKcqpgFhd5omt53NfFfo2rek 7LXrRypsE28iEZPsCrPLLzbU+I0NxnBqkP+QZM92CnmtauvOpQax0X/fVwMbTiSE y2VHCBgmgP9q9rfGY0YVFg5tP2jeSSCbsoyFGQmvCawoYaAaIWMHpk7d817Z76O5 Q5sLzMB1UacPoX28eO1MuTyBnkeRQ74p3ssBtX2ZoRQVvIovAOazLizDdGpqktHO vHzYvNbT/FvSPiW+cYWZUU6PHyIp12a/B6K3jhOPsrbFfrz+MJtsA3LYQbMhtumd xkbC48cun8LjinWIYctv9JGj4K2/kgeJmG7o3H2SQTBY4oSV1Ltn9x+3m/Wg0p8= =diD0 -----END PGP SIGNATURE----- --s2ZSL+KKDSLx8OML-- From ales.vizdal@t-mobile.cz Wed Jan 30 02:49:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3454121F876E for ; Wed, 30 Jan 2013 02:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGfkxEvB4Ab0 for ; Wed, 30 Jan 2013 02:49:46 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3921F84F9 for ; Wed, 30 Jan 2013 02:49:46 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id D74C928581D; Wed, 30 Jan 2013 11:49:44 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 30 Jan 2013 11:49:44 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Wed, 30 Jan 2013 11:50:11 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-64share Thread-Index: Ac3+PJSj1oCM9HovS3GkRXJ1RwmrMgAkVPjA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA335E7@SRVHKE02.rdm.cz> References: <1358681491.98785.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1358883507.57517.YahooMailNeo@web142506.mail.bf1.yahoo.com> <5107F6B2.8070708@gmail.com> In-Reply-To: <5107F6B2.8070708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:49:47 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Tuesday, January 29, 2013 5:20 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-64share >=20 > Le 29/01/2013 16:25, holger.metschulat@telekom.de a =E9crit : > > -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org > > [mailto:v6ops-bounces@ietf.org] Im Auftrag von Cameron Byrne > > Gesendet: Dienstag, 22. Januar 2013 21:34 An: Mark Smith Cc: > > v6ops@ietf.org Betreff: Re: [v6ops] draft-ietf-v6ops-64share > > > > Cameron, > > > >> I think would rather avoid any of this translational bridging > >> business. And in fact, i am only trying to document running code > >> to avoid multiple divergent methods of achieving the same goal. > > > >> That said, it appears a few folks (Rajiv and Alex) have some > >> indigestion over having one IP address in multiple places. It > >> works for me, but i can accept that it may not work well for > >> others. > > > > I personally also don't like the idea of having the same IP address > > in two places. I always look at this as the UE's own IPv6 address > > attached to an internal interface int0 inside the UE, and the UE > > building a "virtual brigde" connecting the wlan0, int0 and wwan0 > > interface together. In front of the wwan0 interface, there is a > > matching logic adapting Ethernet L2 towards the WWAN L2 >=20 > The bridging of the virtual interface and the other two real interface- > I could visualize it, with a single address attributed to the virtual > interface. >=20 > However, I wonder what this bridging may mean to routing. If all the > interfaces on this machine are 'bridged' (maybe brconfig, brctl) then is > there any IP routing possible on this machine. I believe you're either bridging or routing, but not both at the same time. =20 > I guess the two subnets - the one on wwan0 and the one on wlan0 - shoudl > stay separate scope. One wouldn't want a NS sent by a Host in the WLAN > subnetwork be transmitted to the WWAN subnetwork. I am supporting the same view, so keep both wwan and lan interfaces separat= e. > Alex Cheers, Ales From mohamed.boucadair@orange.com Wed Jan 30 04:39:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78AC21F88B6 for ; Wed, 30 Jan 2013 04:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4I3xegUTwQV for ; Wed, 30 Jan 2013 04:39:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id F0D8D21F88B0 for ; Wed, 30 Jan 2013 04:39:30 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 88B773B4524 for ; Wed, 30 Jan 2013 13:39:29 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6F72B23807D for ; Wed, 30 Jan 2013 13:39:29 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 30 Jan 2013 13:39:29 +0100 From: To: IPv6 Ops WG Date: Wed, 30 Jan 2013 13:39:28 +0100 Thread-Topic: draft-binet-v6ops-cellular-host-requirements-02 Thread-Index: Ac3+5VHE9AK4f2gBSYmRsbcMNHEmuAAAQ5Rw Message-ID: <94C682931C08B048B7A8645303FDC9F36EA9C83963@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.30.112414 Subject: [v6ops] draft-binet-v6ops-cellular-host-requirements-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 12:39:32 -0000 Dear all, We submitted an updated version of this draft. The main change in this revi= sion is a new section to explain why this document is needed and to positio= n it vs. I-D.ietf-v6ops-rfc3316bis. We would appreciate if the chairs issue a call for adoption.=20 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : mercredi 30 janvier 2013 13:28 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Internet Protocol Version 6 (IPv6) Requirements for Cell= ular Hosts Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-binet-v6ops-cellular-host-requirements-02.txt Pages : 17 Date : 2013-01-30 Abstract: This document lists a set of IPv6-related requirements to be supported by cellular hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requiremen= ts There's also a htmlized version available at: http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-requirem= ents-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From cb.list6@gmail.com Wed Jan 30 06:56:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB121F8B58 for ; Wed, 30 Jan 2013 06:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6tZI+EQCiKp for ; Wed, 30 Jan 2013 06:56:35 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDEA21F8B37 for ; Wed, 30 Jan 2013 06:56:34 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id s4so2192629lbc.21 for ; Wed, 30 Jan 2013 06:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QAQKSwZM0jCN7WMa+jLm/oNdjgTeSkr1mKoIXxJ5X9A=; b=sNCXtaKlUePW3NyRzm6fO17pscybe8WsBWdp/qVqkgSsKnHmANPuUtBUMhfBfelOSI 28BI9RIrRtFOo1ThZE8qjpPyQTlc9ML/F+VF4A4goGWyY9nY+o71t+G8xbNSWc2dNXj/ OvlTydT7fhjMxp8VBBvGPHPG/l8DicItmZwcnxF+D4Lj8kAfOpqAFmPbN7ULQmM+tK4K 5ns0RlYrHsUtTYEeByyuoKDuGuYh217MaAzt4cAEsxcj9xN+9TOC7v6cemYFTkcUj1YI Wr75d84U2pmD32Limj/FqBb27mNxlQdI5KbPwjywyXvK/2Yq7F3tmroGCcJr/4DwaXgF IX2w== MIME-Version: 1.0 X-Received: by 10.112.49.66 with SMTP id s2mr2052403lbn.16.1359557793876; Wed, 30 Jan 2013 06:56:33 -0800 (PST) Received: by 10.112.7.165 with HTTP; Wed, 30 Jan 2013 06:56:33 -0800 (PST) Received: by 10.112.7.165 with HTTP; Wed, 30 Jan 2013 06:56:33 -0800 (PST) In-Reply-To: References: Date: Wed, 30 Jan 2013 06:56:33 -0800 Message-ID: From: Cameron Byrne To: Zhenkai Wang Content-Type: multipart/alternative; boundary=f46d0401677d5b0c4004d482b733 Cc: v6ops@ietf.org Subject: Re: [v6ops] China Mobile's Statement about IPR related to draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:56:36 -0000 --f46d0401677d5b0c4004d482b733 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Wang, Can you please confirm the IPR claims apply to the latest version of the 464XLAT document http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 Thanks, Cameron Sent from ipv6-only Android On Jan 29, 2013 7:08 PM, "Zhenkai Wang" wrote: > Hello IETF, > > > > As a company, China Mobile has spent lots of efforts like expenditure of > man workforce, time, et al. on some technologies. We underline that > Intellectual property Rights (IPRs) are an important part of technologies= , > and also respect IPRs like other companies in the industry. > > > > The disclosure about patent *http://datatracker.ietf.org/ipr/1730/* > is a compliance with the rules of the IETF which are defined in RFC > 3979, "Intellectual Property Rights in IETF Technology." The > licensing declaration for this Document =91c) Reasonable and > Non-Discriminatory License to All Implementers with Possible Royalty/Fee= =92 made > by China Mobile was in accordance with our corporate strategy, as well as > industry practice. > > > > Best regards, > > > > Wang Zhengkai > > ------------------------------ > Wang Zhenkai > > IP Counsel | China Mobile Research Institute > > Office: +86 15801696688-35235 | Mobile: +8613810187794 | > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. > > Confidentiality Notice: The information contained in this e-mail and any > accompanying attachment(s) is intended only for the use of the intended > recipient and may be confidential and/or privileged of China Mobile, its > subsidiaries and/or its affiliates. If any reader of this communication i= s > not the intended recipient, unauthorized use, forwarding, printing, > storing, disclosure or copying is strictly prohibited, and may be unlawfu= l. > If you have received this communication in error, please immediately noti= fy > the sender by return e-mail, and delete the original message and all copi= es > from your system. Thank you. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --f46d0401677d5b0c4004d482b733 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Wang,

Can you please confirm the IPR claims apply to the latest ve= rsion of the 464XLAT document http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-0= 9

Thanks,

Cameron

Sent from ipv6-only Android

On Jan 29, 2013 7:08 PM, "Zhenkai Wang"= ; <zhenkaiw@gmail.com> wrot= e:

Hello IETF,

=C2=A0

As a company, China Mobile has spent lots of efforts = like expenditure of man workforce, time, et al. on some technologies. We un= derline that Intellectual property Rights (IPRs) are an important part of t= echnologies, and also respect IPRs like other companies in the industry.

=C2=A0

The disclosure about patent=C2=A0= http://datatracker.ietf.org/ipr/1730/=C2=A0is a compliance with the rules of the IETF which ar= e defined in RFC 3979,=C2=A0"Intellectual P= roperty Rights in IETF Technology."=C2=A0The licen= sing declaration for this Document=C2=A0=E2=80=98c) Reasonable and Non-Discriminatory License to All Implement= ers with Possible Royalty/Fee=E2=80=99=C2=A0made by China Mobile was in accordance with our corpo= rate strategy, as well as industry practice.

=C2=A0

Best regards,

=C2=A0

Wang Zhengkai

=C2=A0
=
Wang Zhenkai

=C2=A0IP Counsel | China Mobile = Research Institute

Office: +86 15801696688-35235 = | Mobile: +8613810187794=C2=A0|

NO.32=C2=A0Xuanwumen=C2=A0West=C2=A0Street,Xicheng=C2=A0Dist= rict,Beijing=C2=A0100053.China. <= /span>
=C2=A0
Confidentiality Notice: The information containe= d in this e-mail and any accompanying attachment(s) is intended only for th= e use of the intended recipient and may be confidential and/or privileged o= f China Mobile, its subsidiaries and/or its affiliates. If any reader of th= is communication is not the intended recipient, unauthorized use, forwardin= g, printing, storing, disclosure or copying is strictly prohibited, and may= be unlawful. If you have received this communication in error, please imme= diately notify the sender by return e-mail, and delete the original message= and all copies from your system. Thank you.

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

--f46d0401677d5b0c4004d482b733-- From alexandru.petrescu@gmail.com Wed Jan 30 07:43:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2321F8B19 for ; Wed, 30 Jan 2013 07:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk78MvqjAD2f for ; Wed, 30 Jan 2013 07:43:59 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id AF63F21F8B18 for ; Wed, 30 Jan 2013 07:43:55 -0800 (PST) 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 r0UFhsmx001753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 30 Jan 2013 16:43:54 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0UFhsl3000948 for ; Wed, 30 Jan 2013 16:43:54 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0UFhoCJ027945 for ; Wed, 30 Jan 2013 16:43:54 +0100 Message-ID: <51093FB6.10302@gmail.com> Date: Wed, 30 Jan 2013 16:43:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "v6ops@ietf.org" References: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> In-Reply-To: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 15:43:59 -0000 Thank you for this new version! > 1. The user activates router functionality for a LAN on the UE. I suggest to make it router functionality for LAN _and_ for WAN on the UE (not only on LAN). This is linux equivalent to "echo 1>/proc/sys/.../all/..." If we do so, the Router will by default not self-configure address based on the prefix from the PIO in the received RA, which is good in this case. Then, Should this Router reply to RSs it may receive on its wwan interface? By sending RAs? Should it join router-specific multicast groups on it? As it stands now, I don't see a reason why it should, because the gateway in the cellular network does not send it any RS nor does it seem to query for MLDs. But should we specify it to forbid it to send RAs on its wwan0 interface? Alex Le 29/01/2013 20:00, 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 : Extending an IPv6 /64 Prefix from a 3GPP Mobile > Interface to a LAN Author(s) : Cameron Byrne Dan Drown > Filename : draft-ietf-v6ops-64share-01.txt Pages : 8 Date : > 2013-01-29 > > Abstract: This document describes three methods for extending an > IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ I-D-Announce mailing > list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From ales.vizdal@t-mobile.cz Wed Jan 30 08:23:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839BC21F89F9 for ; Wed, 30 Jan 2013 08:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoXTI5JXETDn for ; Wed, 30 Jan 2013 08:23:14 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id A4A4521F899E for ; Wed, 30 Jan 2013 08:23:12 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 6DA0328581C for ; Wed, 30 Jan 2013 17:23:11 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 30 Jan 2013 17:23:11 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Wed, 30 Jan 2013 17:24:24 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt Thread-Index: Ac3/AK7eJZKvbdThQw+vbfhmy9gYrQABMybw Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA3376B@SRVHKE02.rdm.cz> References: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> <51093FB6.10302@gmail.com> In-Reply-To: <51093FB6.10302@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:23:19 -0000 Hi Alex, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Wednesday, January 30, 2013 4:44 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt >=20 > Thank you for this new version! >=20 > > 1. The user activates router functionality for a LAN on the UE. >=20 > I suggest to make it router functionality for LAN _and_ for WAN on the > UE (not only on LAN). This is linux equivalent to "echo > 1>/proc/sys/.../all/..." >=20 > If we do so, the Router will by default not self-configure address based > on the prefix from the PIO in the received RA, which is good in this case= . >=20 > Then, >=20 > Should this Router reply to RSs it may receive on its wwan interface? > By sending RAs? Are you assuming a broken GGSN implementation or just catching a case where for whatever reason the UE sees an RS on its wwan interface?=20 The UE shall not be announcing the /64 prefix on the wwan interface=20 and even if it would have sent the RA to the GGSN/PDN-GW it shall be ignored. =20 > Should it join router-specific multicast groups on it? >=20 > As it stands now, I don't see a reason why it should, because the > gateway in the cellular network does not send it any RS nor does it seem > to query for MLDs. >=20 > But should we specify it to forbid it to send RAs on its wwan0 interface? The router/RA function (e.g. radvd) shall be bound to the lan interface onl= y. =20 > Alex Ales From alexandru.petrescu@gmail.com Wed Jan 30 09:46:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD5221F878F for ; Wed, 30 Jan 2013 09:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.91 X-Spam-Level: X-Spam-Status: No, score=-9.91 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vWHIoPyquaP for ; Wed, 30 Jan 2013 09:46:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 49FF021F84C5 for ; Wed, 30 Jan 2013 09:46:00 -0800 (PST) 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 r0UHjwwV006203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 30 Jan 2013 18:45:59 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0UHjwqZ032006 for ; Wed, 30 Jan 2013 18:45:58 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0UHjsOx012888 for ; Wed, 30 Jan 2013 18:45:58 +0100 Message-ID: <51095C52.2010309@gmail.com> Date: Wed, 30 Jan 2013 18:45:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> <51093FB6.10302@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA3376B@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA3376B@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:46:01 -0000 Le 30/01/2013 17:24, Vízdal Aleš a écrit : > Hi Alex, > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Wednesday, January 30, 2013 4:44 PM To: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt >> >> Thank you for this new version! >> >>> 1. The user activates router functionality for a LAN on the UE. >> >> I suggest to make it router functionality for LAN _and_ for WAN on >> the UE (not only on LAN). This is linux equivalent to "echo >> 1>/proc/sys/.../all/..." >> >> If we do so, the Router will by default not self-configure address >> based on the prefix from the PIO in the received RA, which is good >> in this case. >> >> Then, >> >> Should this Router reply to RSs it may receive on its wwan >> interface? By sending RAs? > > Are you assuming a broken GGSN implementation or just catching a > case where for whatever reason the UE sees an RS on its wwan > interface? Ok for GGSN, but I don't know about ADSL or cable modem setups - will the Gateway connected to the CPE send RS to or accept RA from this Router? > The UE shall not be announcing the /64 prefix on the wwan interface > and even if it would have sent the RA to the GGSN/PDN-GW it shall be > ignored. I agree. Maybe state that it should not be sending RAs altogether (not only the Prefix Information Option) on that wwan interface. I don't remember whether there's some spec which relaxes the need that a Router to send RAs. But Router specifications like RFC4861 say "Router Advertisement: Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message." >> Should it join router-specific multicast groups on it? >> >> As it stands now, I don't see a reason why it should, because the >> gateway in the cellular network does not send it any RS nor does it >> seem to query for MLDs. >> >> But should we specify it to forbid it to send RAs on its wwan0 >> interface? > > The router/RA function (e.g. radvd) shall be bound to the lan > interface only. YEs, I agree. This is worth noting. Alex > >> Alex > > Ales _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From joelja@bogus.com Wed Jan 30 11:19:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFB521F889C for ; Wed, 30 Jan 2013 11:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMdVtO0xy1mv for ; Wed, 30 Jan 2013 11:19:32 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BDEE521F87A4 for ; Wed, 30 Jan 2013 11:19:32 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0UJJUsi081900 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 30 Jan 2013 19:19:31 GMT (envelope-from joelja@bogus.com) Message-ID: <5109723D.4090905@bogus.com> Date: Wed, 30 Jan 2013 11:19:25 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG , "draft-binet-v6ops-cellular-host-requirements@tools.ietf.org" References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> In-Reply-To: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 30 Jan 2013 19:19:32 +0000 (UTC) Subject: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 19:19:33 -0000 Greetings, This kicks of a request for adoption as a working group document on draft-binet-v6ops-cellular-host-requirements-02.txt This document and a similar one were discussed during IETF 85 and were updated accordingly. Support was far from unanimous at the time and we're interested in seeing how far it has progressed. The deadline for this discussion phase is two weeks from today, 2/13. thanks joelja On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Internet Protocol Version 6 (IPv6) Requirements for Cellular Hosts > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-binet-v6ops-cellular-host-requirements-02.txt > Pages : 17 > Date : 2013-01-30 > > Abstract: > This document lists a set of IPv6-related requirements to be > supported by cellular hosts. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-host-requirements-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From iesg-secretary@ietf.org Wed Jan 30 14:51:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8304721F8820; Wed, 30 Jan 2013 14:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGp-1mWMBcHR; Wed, 30 Jan 2013 14:51:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95F921F87D4; Wed, 30 Jan 2013 14:51:29 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> Date: Wed, 30 Jan 2013 14:51:29 -0800 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 22:51:34 -0000 The IESG has approved the following document: - '464XLAT: Combination of Stateful and Stateless Translation' (draft-ietf-v6ops-464xlat-09.txt) as Best Current Practice This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ Technical Summary: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. Working Group Summary: The working group, for the most part, the working group found this uncontroversial; it is a way to deploy an IPv6-only core in a mobile network and use translation to provide access to IPv4 content. The folks working on the software "MAP" technology objected to it as it is a deployment technology simpler than MAP and takes shortcuts that may hobble such deployments in the long term. Remi Despres made suggestions on the list and had some support. However, the suggested approaches were more "different" than "better", and neither built consensus nor demonstrated issues requiring changes to the document. Document Quality: The document is a description of how to build a certain service offering. There are ways to build other service offerings, and they may or may not be better. However, the service offering described has been implemented and in fact works. Personnel: The document shepherd is Fred Baker. The area director is Ron Bonica. From lorenzo@google.com Wed Jan 30 16:56:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B8C21F87CD for ; Wed, 30 Jan 2013 16:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8R8mGQa8r9q for ; Wed, 30 Jan 2013 16:56:08 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 446B121F84B9 for ; Wed, 30 Jan 2013 16:56:08 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so2371714oag.22 for ; Wed, 30 Jan 2013 16:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EBkwcLOROzcgpolZ3dWYNb68MK6CGBJzLf9JSI0l1Mw=; b=JSfO3NKIv+NrOeRsKFk+HzlBvnu0cG4Wc8maCUelGPOWsH6zoEW+zS/fGnFwEesOKz HwslG7r6BvzPrDiMy7pE2EW5c3DiCJ8/ldBBoQJRlhCS84yZfDE8oEZvi2U2EX5HeGic ClW21u4z/SuVOgLRSfO/Szu7RBAO66GFkJ0dgxI4/J1q2uaQY4rlmnwL7dAzuzJJjcZw pZ8bGOpzhQIn+R6h3rd1G/uP0pATSMKkGKM0UYWVAyo66gC5TRUDvPvLwiOnpXXdaTws UgpM/aebwAbSsbDJTirwRCRXtpfVOWM84Vd+aXFdCWSZClhTwIiXWjdUHCMhuwWJyWw1 mNlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=EBkwcLOROzcgpolZ3dWYNb68MK6CGBJzLf9JSI0l1Mw=; b=kuF2KD0cJxQLL4+SpOdXDKoexWoS/67HRj6WJATvUvoc8c3kebLUMTWaHE6l00UrYO Vn5VXpiGnqPh/dM9OHlfMCXZMUmXdiKYUhFGK8jZyGP+GRIFNkTHVxOmHN3pL2GWXCi9 zbWbji1DzCx8cJoJOvF3MDmRgEe2+DK4ua7MLEwL0nkvETHzhaqjbhda0D58MvtzG3W6 VVvhho7mWeqkA25oPQ/IRwGzYAbfMJHSJDPByZoUBVrFUKHDDzm3W+sFN7CzXzcGET3m 2H68HSNRF+7rzk8AHpCma+rQMqFIsvdDEXmSVz1+FXSZMPtWlSShnUaY34ZYbyQKov4b dPfw== X-Received: by 10.60.172.178 with SMTP id bd18mr5311119oec.133.1359593766908; Wed, 30 Jan 2013 16:56:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.144.169 with HTTP; Wed, 30 Jan 2013 16:55:46 -0800 (PST) In-Reply-To: <5109723D.4090905@bogus.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> From: Lorenzo Colitti Date: Thu, 31 Jan 2013 09:55:46 +0900 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=bcaec54d49f283f1eb04d48b1770 X-Gm-Message-State: ALoCoQm+rc+VPgRuGkI92doPyD4KWhcAYxOPzgnHcgFCqBDZc98K93wUZfiBFXovKxfyz5q2hJcapStXHCNEbvyQmN1fVHgyS/r5c71oYWZZmdesTuuMj6qk78A6w8TLb6F+zv/6Oh9IBaLORq42pIIYgJspWRlBwBoXIASGVsKqY1nSc3rsZnbmZKqeERVjp4Y5AQqRez2N Cc: IPv6 Ops WG , "draft-binet-v6ops-cellular-host-requirements@tools.ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 00:56:09 -0000 --bcaec54d49f283f1eb04d48b1770 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 31, 2013 at 4:19 AM, joel jaeggli wrote: > This kicks of a request for adoption as a working group document on > draft-binet-v6ops-cellular-**host-requirements-02.txt > > This document and a similar one were discussed during IETF 85 and were > updated accordingly. Support was far from unanimous at the time and we're > interested in seeing how far it has progressed. > I do not support WG adoption of this document. The way I see it, the document's goal is not to define operational practices, but to define a device profile ("you must support features X, Y, and Z"). I think this sort of thing does not belong in the IETF: the IETF should define the technology, not how it's integrated. I think this sort of thing is best left to cellular standards bodies like 3GPP. --bcaec54d49f283f1eb04d48b1770 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 31, 2013 at 4:19 AM, joel jaeggli <joelja@bogu= s.com> wrote:
This kicks of a request for adoption as a working group do= cument on draft-binet-v6ops-cellular-host-requirements-02.txt

This document and a similar one were discussed during IETF 85 and were upda= ted accordingly. Support was far from unanimous at the time and we're i= nterested in seeing how far it has progressed.

I do not support WG adoption of this document.

The way I see it, the document's goal is not to define operatio= nal practices, but to define a device profile ("you must support featu= res X, Y, and Z"). I think this sort of thing does not belong in the I= ETF: the IETF should define the technology, not how it's integrated. I = think this sort of thing is best left to cellular standards bodies like 3GP= P.
--bcaec54d49f283f1eb04d48b1770-- From swmike@swm.pp.se Wed Jan 30 21:19:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4921F8613 for ; Wed, 30 Jan 2013 21:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94G5LfCnDnYc for ; Wed, 30 Jan 2013 21:19:13 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6E321F846E for ; Wed, 30 Jan 2013 21:19:12 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3342F9C; Thu, 31 Jan 2013 06:19:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2C4AC9A for ; Thu, 31 Jan 2013 06:19:08 +0100 (CET) Date: Thu, 31 Jan 2013 06:19:08 +0100 (CET) From: Mikael Abrahamsson To: IPv6 Ops WG In-Reply-To: Message-ID: References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 05:19:14 -0000 On Thu, 31 Jan 2013, Lorenzo Colitti wrote: > The way I see it, the document's goal is not to define operational > practices, but to define a device profile ("you must support features X, > Y, and Z"). I think this sort of thing does not belong in the IETF: the > IETF should define the technology, not how it's integrated. I think this > sort of thing is best left to cellular standards bodies like 3GPP. I find this device profile very useful for including in RFQ/RFI document. Whether it's correct to have it worked through the IETF or not is not is another matter, but this kind of document is definitely worthwile to have. I believe it's not wrong for the IETF should have a say in this, to re-affirm that the IETF confirms what it feels is crucial for a device that is going to be used on the Internet, especially together with a lot of migration mechanisms now that we're trying to go from IPv4 to IPv6. -- Mikael Abrahamsson email: swmike@swm.pp.se From pkern@spike.0x539.de Thu Jan 31 03:57:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B11321F8455 for ; Thu, 31 Jan 2013 03:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZzp81V8I9L5 for ; Thu, 31 Jan 2013 03:57:32 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 0627121F8432 for ; Thu, 31 Jan 2013 03:57:31 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U0slk-0003l1-OK for v6ops@ietf.org; Thu, 31 Jan 2013 12:57:28 +0100 Received: from [2001:470:720c:0:b573:362d:b330:870d] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1U0sll-00008r-Fo for v6ops@ietf.org; Thu, 31 Jan 2013 12:57:29 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1U0sli-0000k1-KG for v6ops@ietf.org; Thu, 31 Jan 2013 12:57:26 +0100 Date: Thu, 31 Jan 2013 12:57:26 +0100 From: Philipp Kern To: IPv6 Ops WG Message-ID: <20130131115726.GA387@spike.0x539.de> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 11:57:33 -0000 Lorenzo, am Thu, Jan 31, 2013 at 09:55:46AM +0900 hast du folgendes geschrieben: > The way I see it, the document's goal is not to define operational > practices, but to define a device profile ("you must support features X, Y, > and Z"). I think this sort of thing does not belong in the IETF: the IETF > should define the technology, not how it's integrated. I think this sort of > thing is best left to cellular standards bodies like 3GPP. *cough* RFC 6540. ;-) Kind regards Philipp Kern From ietfc@btconnect.com Thu Jan 31 04:20:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181B221F876E for ; Thu, 31 Jan 2013 04:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.153 X-Spam-Level: X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=-1.446, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+ALIBxim6oY for ; Thu, 31 Jan 2013 04:20:56 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD321F87B3 for ; Thu, 31 Jan 2013 04:20:56 -0800 (PST) Received: from mail234-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 Jan 2013 12:20:55 +0000 Received: from mail234-va3 (localhost [127.0.0.1]) by mail234-va3-R.bigfish.com (Postfix) with ESMTP id 524877C0252; Thu, 31 Jan 2013 12:20:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz9371I542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h1724k304l1155h) Received: from mail234-va3 (localhost.localdomain [127.0.0.1]) by mail234-va3 (MessageSwitch) id 1359634853454048_15012; Thu, 31 Jan 2013 12:20:53 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.235]) by mail234-va3.bigfish.com (Postfix) with ESMTP id 6291138004F; Thu, 31 Jan 2013 12:20:53 +0000 (UTC) Received: from DB3PRD0711HT003.eurprd07.prod.outlook.com (157.56.254.197) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 Jan 2013 12:20:52 +0000 Received: from DB3PRD0511HT004.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.183.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 31 Jan 2013 12:20:49 +0000 Message-ID: <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> From: t.petch References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2013 12:17:50 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.213] X-OriginatorOrg: btconnect.com Cc: v6ops mailing list , v6ops chair Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:20:57 -0000 Um. I thought that we were still discussing whether or not the IPR claims were acceptable, but perhaps not. Tom Petch ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: "v6ops mailing list" ; "v6ops chair" ; "RFC Editor" Sent: Wednesday, January 30, 2013 10:51 PM Subject: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) > The IESG has approved the following document: > - '464XLAT: Combination of Stateful and Stateless Translation' > (draft-ietf-v6ops-464xlat-09.txt) as Best Current Practice > > This document is the product of the IPv6 Operations Working Group. > > The IESG contact persons are Ronald Bonica and Benoit Claise. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ > > > > > Technical Summary: > > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > Working Group Summary: > > The working group, for the most part, the working group found this > uncontroversial; it is a way to deploy an IPv6-only core in a mobile > network and use translation to provide access to IPv4 content. The > folks working on the software "MAP" technology objected to it as it is > a deployment technology simpler than MAP and takes shortcuts that may > hobble such deployments in the long term. Remi Despres made > suggestions on the list and had some support. However, the suggested > approaches were more "different" than "better", and neither built > consensus nor demonstrated issues requiring changes to the document. > > Document Quality: > > The document is a description of how to build a certain service > offering. There are ways to build other service offerings, and they > may or may not be better. However, the service offering described has > been implemented and in fact works. > > Personnel: > > The document shepherd is Fred Baker. The area director is Ron Bonica. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Thu Jan 31 05:47:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB95A21F8459 for ; Thu, 31 Jan 2013 05:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQB2w1azrBDZ for ; Thu, 31 Jan 2013 05:47:14 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFA121F8439 for ; Thu, 31 Jan 2013 05:47:13 -0800 (PST) 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 r0VDlD1Q032360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 31 Jan 2013 14:47:13 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r0VDlC44006266 for ; Thu, 31 Jan 2013 14:47:12 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r0VDl8cp025759 for ; Thu, 31 Jan 2013 14:47:12 +0100 Message-ID: <510A75DA.60305@gmail.com> Date: Thu, 31 Jan 2013 14:47:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> In-Reply-To: <5109723D.4090905@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:47:25 -0000 HEllo, This draft had a competitor in the same space IIRC? What was the name of that draft? In this draft, there is a section about which I have high interest - "4. Cellular Devices with LAN Capabilities". This approaches very much to what an IPv6 Mobile Router is, whose one particular interface is cellular and others are LAN. In this respect, implementing an IPv6 Mobile Router there are several possibilities and each may have an impact on that cellular interface. For example, the use of Prefix Delegation has an impact on the cellular interface - and that is already said as REQ#27. But there are others. For example, the use of IPv6 Network Prefix Translation, or, not least, the use of Mobile IPv6 (with NEMO extensions if possible). This latter is all the more important since it is mentioned in the IPv6 Node Requirements document, and this draft also mentions that in addition to the cellular interface there is a WiFi interface - only Mobile IPv6 is able to make handovers between the two interfaces. Regards, Alex Le 30/01/2013 20:19, joel jaeggli a écrit : > Greetings, > > This kicks of a request for adoption as a working group document on > draft-binet-v6ops-cellular-host-requirements-02.txt > > This document and a similar one were discussed during IETF 85 and > were updated accordingly. Support was far from unanimous at the time > and we're interested in seeing how far it has progressed. > > The deadline for this discussion phase is two weeks from today, > 2/13. > > thanks joelja > > On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Internet Protocol Version 6 (IPv6) Requirements >> for Cellular Hosts Author(s) : David Binet Mohamed Boucadair >> Ales Vizdal Cameron Byrne Gang Chen Filename : >> draft-binet-v6ops-cellular-host-requirements-02.txt Pages >> : 17 Date : 2013-01-30 >> >> Abstract: This document lists a set of IPv6-related requirements to >> be supported by cellular hosts. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements >> >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-02 >> >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-host-requirements-02 >> >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ I-D-Announce >> mailing list I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft >> directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From etmetz@gmail.com Thu Jan 31 05:49:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29EB21F86D5 for ; Thu, 31 Jan 2013 05:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNQJaIMkpXKo for ; Thu, 31 Jan 2013 05:49:41 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id CEE9421F8694 for ; Thu, 31 Jan 2013 05:49:40 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wd20so2833623obb.23 for ; Thu, 31 Jan 2013 05:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JHCb3zYBP/4o0gwYciwffJA0aS5iuNP/Z5mHyUPtd4I=; b=zWDL4yucl3xSTECN3ilmRwhAYvxxomz14v3jreAgwBBjsOfF4NphuuGtkccMyXQq3J 35S56PbSE7ReZm1mct+TgXS48tS9Cu+e/tMvuJAXK39CSin9Vzdav+fAlHq4OwN7TQb8 Kwhe034iEH2PICskAWZmqrOZCzh7ixmtUsjUV6YLKjpN+tVprrFzqX1SptudjzF6+7i+ YgkfDVJXNWvHaUo2xrkO4xgzgvFVhJCtyN6DCoI7A260jdE/kadGyXMBsrUeDXB0+QbO ATa+Egxdtv6EQjz1OukmhbpqY9LOzdqc0nZ8NF12Tc8YbJQQ2P+Yq6puOiI8PLRZUVsV AmzQ== MIME-Version: 1.0 X-Received: by 10.182.23.101 with SMTP id l5mr6482547obf.16.1359640180372; Thu, 31 Jan 2013 05:49:40 -0800 (PST) Received: by 10.60.12.201 with HTTP; Thu, 31 Jan 2013 05:49:40 -0800 (PST) In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> Date: Thu, 31 Jan 2013 14:49:40 +0100 Message-ID: From: Eduard Metz To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=f46d043749e1f9333904d495e54b Cc: "v6ops@ietf.org" , "draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:49:42 -0000 --f46d043749e1f9333904d495e54b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Some comments and questions on the balanced IPv6 security draft: I general I think having different (defined) "security profiles" is something that could be beneficial (e.g. CPE's having multiple predefined modes of operation) so in that respect this is a good initiative. At the same time it would also be good if there would be some sort of applicability statement for these different profiles that describes which profile is most suitable for specific cases. Because, even though the draft claims this is sufficient for the proverbial grandma, I'm not convinced this category of users would also actually need this (that they would be protected is also a rather big claim). It may even be confusing since their Internet access service behaves differently for IPv4 and IPv6. Targeting for a fixed policy (Sec 3) doesn't seem realistic to me. As mentioned in the draft, the policy must be maintained to ensure it lives up to it's goals / intention. In my opinion it's also this aspect that makes it more or less unsuitable for the average user. How do the authors feel about policy maintainance (e.g. responsiblity of the end-user, or the operator/ISP)? In particular the protection of weak services, or services in general would be better I think, seems a complex task given the large variation in devices in the home environment. Some guidelines on policy maintainance would be usefull I think. Is it correct that this draft suggest to implement RFC6092 except REC-11/18/33, and proposes alternatives for these requirements? This was at least my interpretation of 3 & 4 in section 3.1 (note: 3 mentions REC-11/17/33, whereas 4 mentions REC-18 instead of 17). Section 3.2 describes that technical users could "open other applications", not sure what is meant here. I thought the point was the CPE would be open? Other applications then being the exceptions/weak services that are prohibited? Not sure the policy really prevents unauthorised access. The policy prevents (any) access to some known ports (that may have weaknesses), but other services/devices are still accessible and vulnerable to unauthorised access (e.g. a NAS using a web-based management interface, running on a different port). Also, do the statements in Section 6 mean that the balance-policy does not protect against other threats as mentioned in Section 2? There is no mention about the use of privacy extensions, although this does influence the end-to-end connectivity this draft attempts to restore. Something to include? cheers, Eduard On Fri, Jan 25, 2013 at 5:08 PM, Eric Vyncke (evyncke) w= rote: > Some explanations about this new draft... (which should also be of > interest to OPSEC WG) > > IPv6 CPE have always the issue of the default security policy especially > around allowing inbound connections: > - Some say allow (fully open) to restore end-to-end > - Some say block (fully closed/valve like) to mimick the IPv4 NAPT > stateful behavior. > > RFC6092 describe a simple security policy for IPv6 CPE. Together with Mar= k > Townsley and Andrew Yourtchenko, we wrote the advanced-security draft > something in the line of fully open but use IPS in line (what is called > Universal Threat Mitigation) but this is expensive and the I-D did not > gather momentum. > > This I-D is based on Swisscom deployment which is 'balanced' between open > and close. It is simply allowing all traffic inbound EXCEPT for well-know= n > TCP/UDP ports linked to malware or vulnerable services. > > The authors are the Swisscom engineers who initiated this balanced > security and Ragnar from Altibox (a Norvegian ISP). > > Hope this helps > > -=E9ric > > > -----Original Message----- > > From: Fred Baker (fred) > > Sent: vendredi 25 janvier 2013 14:45 > > To: v6ops@ietf.org > > Cc: draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org > > Subject: new draft: draft-v6ops-vyncke-balanced-ipv6-security > > > > > > A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops- > > vyncke-balanced-ipv6-security. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d043749e1f9333904d495e54b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Some comments and questions o= n the balanced IPv6 security draft:

I = general I think having different (defined) "security profiles" is= something that could be beneficial (e.g. CPE's having multiple predefi= ned modes of operation) so in that respect this is a good initiative. At th= e same time it would also be good if there would be some sort of applicabil= ity statement for these different profiles that describes which profile is = most suitable for specific cases. Because, even though the draft claims thi= s is sufficient for the proverbial grandma, I'm not convinced this cate= gory of users would also actually need this (that they would be protected i= s also a rather big claim). It may even be confusing since their Internet a= ccess service behaves differently for IPv4 and IPv6.

Targeting for a fixed policy (Sec 3) doesn&= #39;t seem realistic to me. As mentioned in the draft, the policy must be m= aintained to ensure it lives up to it's goals / intention. In my opinio= n it's also this aspect that makes it more or less unsuitable for the a= verage user. How do the authors feel about policy maintainance (e.g. respon= siblity of the end-user, or the operator/ISP)? In particular the protection= of weak services, or services in general would be better I think, seems a = complex task given the large variation in devices in the home environment. = Some guidelines on policy maintainance would be usefull I think.

Is it correct that this draft suggest to im= plement RFC6092 except REC-11/18/33, and proposes alternatives for these re= quirements? This was at least my interpretation of 3 & 4 in section 3.1= (note: 3 mentions REC-11/17/33, whereas 4 mentions REC-18 instead of 17).<= /div>

Section 3.2 describes that technical users = could "open other applications", not sure what is meant here. I t= hought the point was the CPE would be open? Other applications then being t= he exceptions/weak services that are prohibited?

Not sure the policy really prevents unautho= rised access. The policy prevents (any) access to some known ports (that ma= y have weaknesses), but other services/devices are still accessible and vul= nerable to unauthorised access (e.g. a NAS using a web-based management int= erface, running on a different port). Also, do =A0the statements in Section= 6 mean that the balance-policy does not protect against other threats as m= entioned in Section 2?

There is no mention about the use of privac= y extensions, although this does influence the end-to-end connectivity this= draft attempts to restore. Something to include?

cheers,
=A0 =A0Eduard

=


On Fri,= Jan 25, 2013 at 5:08 PM, Eric Vyncke (evyncke) <evyncke@cisco.com>= wrote:
Some explanations about this new draft... (w= hich should also be of interest to OPSEC WG)

IPv6 CPE have always the issue of the default security policy especially ar= ound allowing inbound connections:
- Some say allow (fully open) to restore end-to-end
- Some say block (fully closed/valve like) to mimick the IPv4 NAPT stateful= behavior.

RFC6092 describe a simple security policy for IPv6 CPE. Together with Mark = Townsley and Andrew Yourtchenko, we wrote the advanced-security draft somet= hing in the line of fully open but use IPS in line (what is called Universa= l Threat Mitigation) but this is expensive and the I-D did not gather momen= tum.

This I-D is based on Swisscom deployment which is 'balanced' betwee= n open and close. It is simply allowing all traffic inbound EXCEPT for well= -known TCP/UDP ports linked to malware or vulnerable services.

The authors are the Swisscom engineers who initiated this balanced security= and Ragnar from Altibox (a Norvegian ISP).

Hope this helps

-=E9ric

> -----Original Message-----
> From: Fred Baker (fred)
> Sent: vendredi 25 janvier 2013 14:45
> To: v6ops@ietf.org
> Cc: draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org
> Subject: new draft: draft-v6ops-vyncke-balanced-ipv6-security
>
>
> A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-=
> vyncke-balanced-ipv6-security. Please take a look at it and comment. _______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d043749e1f9333904d495e54b-- From brian.e.carpenter@gmail.com Thu Jan 31 06:22:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8972F21F8449 for ; Thu, 31 Jan 2013 06:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.851 X-Spam-Level: X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_ILLEGAL_IP=1.908, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v052uvu-OIa for ; Thu, 31 Jan 2013 06:22:17 -0800 (PST) Received: from mail-we0-x232.google.com (we-in-x0232.1e100.net [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3DC21F8439 for ; Thu, 31 Jan 2013 06:22:16 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x48so2237699wey.9 for ; Thu, 31 Jan 2013 06:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rJbbHyQxupvXuFfDvZ4UxqnVns7UCq7/sEa1S98ToJA=; b=OHWLHLsZF9m3c3pMNC0xM/UxmsjERYOrgxARTlc/I/cPzMCj2rrD2TO8oQ/F7grG6z 0a+Dr8PWTSkMHIpesgq4WEsv2+8HolWvuOf24esqO3KwrcDt2V6vqTZ08MuYx9gpbn2f s/6CZvcrpZIxc2nFAlOejPrklj/jLx3DGUeBYvpbdk3VVmyg+/WcwkFWM9E1TVu2K9Yi M4GXyJWfCsdkX1OP/p3cQGjiLkxcGtKkzG7kePDoYVyMxdrxiJAlKKmW+3OvpgwaEF4O z8jzbeJHKSM7yAUDVVmJjsV2zY4LQSOyQ81O6UdgUlMKeRW260CInkU3Ptp+ZKjDm418 SfRw== X-Received: by 10.180.97.197 with SMTP id ec5mr15022859wib.1.1359642134601; Thu, 31 Jan 2013 06:22:14 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-85.as13285.net. [2.102.217.85]) by mx.google.com with ESMTPS id bd6sm15356933wib.10.2013.01.31.06.22.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 06:22:13 -0800 (PST) Message-ID: <510A7E20.40300@gmail.com> Date: Thu, 31 Jan 2013 14:22:24 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> In-Reply-To: <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops mailing list , v6ops chair Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:22:21 -0000 Yes, I'd have expected to see a consensus call by the WG chairs before this went ahead. (Not that I'm upset, since we commonly accept RAND conditions.) Regards Brian On 31/01/2013 12:17, t.petch wrote: > Um. > > I thought that we were still discussing whether or not the IPR claims > were acceptable, but perhaps not. > > Tom Petch > > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: "v6ops mailing list" ; "v6ops chair" > ; "RFC Editor" > Sent: Wednesday, January 30, 2013 10:51 PM > Subject: [v6ops] Protocol Action: '464XLAT: Combination of Stateful > andStateless Translation' to Best CurrentPractice > (draft-ietf-v6ops-464xlat-09.txt) > > >> The IESG has approved the following document: >> - '464XLAT: Combination of Stateful and Stateless Translation' >> (draft-ietf-v6ops-464xlat-09.txt) as Best Current Practice >> >> This document is the product of the IPv6 Operations Working Group. >> >> The IESG contact persons are Ronald Bonica and Benoit Claise. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ >> >> >> >> >> Technical Summary: >> >> This document describes an architecture (464XLAT) for providing >> limited IPv4 connectivity across an IPv6-only network by combining >> existing and well-known stateful protocol translation RFC 6146 in > the >> core and stateless protocol translation RFC 6145 at the edge. > 464XLAT >> is a simple and scalable technique to quickly deploy limited IPv4 >> access service to IPv6-only edge networks without encapsulation. >> >> Working Group Summary: >> >> The working group, for the most part, the working group found this >> uncontroversial; it is a way to deploy an IPv6-only core in a mobile >> network and use translation to provide access to IPv4 content. The >> folks working on the software "MAP" technology objected to it as it > is >> a deployment technology simpler than MAP and takes shortcuts that > may >> hobble such deployments in the long term. Remi Despres made >> suggestions on the list and had some support. However, the suggested >> approaches were more "different" than "better", and neither built >> consensus nor demonstrated issues requiring changes to the document. >> >> Document Quality: >> >> The document is a description of how to build a certain service >> offering. There are ways to build other service offerings, and they >> may or may not be better. However, the service offering described > has >> been implemented and in fact works. >> >> Personnel: >> >> The document shepherd is Fred Baker. The area director is Ron > Bonica. >> _______________________________________________ >> 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 warren@kumari.net Thu Jan 31 06:30:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2925421F89FD for ; Thu, 31 Jan 2013 06:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKLU7pj1K4m1 for ; Thu, 31 Jan 2013 06:30:04 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA6B21F88DB for ; Thu, 31 Jan 2013 06:30:04 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8F9E51B40706; Thu, 31 Jan 2013 09:30:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Thu, 31 Jan 2013 09:30:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:30:05 -0000 On Jan 31, 2013, at 12:19 AM, Mikael Abrahamsson = wrote: > On Thu, 31 Jan 2013, Lorenzo Colitti wrote: >=20 >> The way I see it, the document's goal is not to define operational = practices, but to define a device profile ("you must support features X, = Y, and Z"). I think this sort of thing does not belong in the IETF: the = IETF should define the technology, not how it's integrated. I think this = sort of thing is best left to cellular standards bodies like 3GPP. >=20 > I find this device profile very useful for including in RFQ/RFI = document. >=20 > Whether it's correct to have it worked through the IETF or not is not = is another matter, but this kind of document is definitely worthwile to = have. I agree that this would be a useful doc, but I don't think it is a good = fit for the IETF / don't think the IETF is a good fit for it. >=20 > I believe it's not wrong for the IETF should have a say in this, to = re-affirm that the IETF confirms what it feels is crucial for a device = that is going to be used on the Internet, especially together with a lot = of migration mechanisms now that we're trying to go from IPv4 to IPv6. Seems reasonable, but to me this document reads much more like a = certification profile. It could simply be the fact that it is a list of = requirements (filled with MUSTs), with no real justification for each / = a discussion of under what cases you can simply ignore the MUSTs. For example: REQ#33: Applications MUST be independent of the underlying IP address family. If I make a widget that conforms to this profile and then some user = loads an app that only runs on v6 (or v4) does someone come and pull off = the sticker that says "Whee, device is compliant with RFC xxxx"? W >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- Some people are like Slinkies......Not really good for anything but they = still bring a smile to your face when you push them down the stairs. From rajiva@cisco.com Thu Jan 31 10:02:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5FC21F8528 for ; Thu, 31 Jan 2013 10:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIgkyKYe7z78 for ; Thu, 31 Jan 2013 10:02:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BF3EB21F8442 for ; Thu, 31 Jan 2013 10:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5339; q=dns/txt; s=iport; t=1359655355; x=1360864955; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Cvk6Ro+y2PdtKt/mj1jM7D+pcOuWA8WzBsX6zX0RW9I=; b=R4xCXGU8tSZxDSvfsx7jL0GqyurFsLD1hIvkJ7rw4oiK/P08R1S8GHO6 eEcWC2aK2VOeQ8cB8fD0XMips0ox7IR0XoiwWhB6nWuFY5e8x5zCTHpu4 OicmAS+ktrKHVwcZcT9zCSvkmlLUPSoJlUDmgo5C3rddh4fivYuBTOppS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAexClGtJV2b/2dsb2JhbABCA78lFnOCHgEBAQQBAQE3Dx4HCwwCBAEIEQMBAgEKFAkiDAsUCQgCBA4FCBOHdgzCKwSNDU2CTWEDpl6Ce4FvNQ X-IronPort-AV: E=Sophos;i="4.84,578,1355097600"; d="scan'208";a="168265541" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 31 Jan 2013 18:02:35 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0VI2Zob026028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 18:02:35 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 12:02:34 -0600 From: "Rajiv Asati (rajiva)" To: Lorenzo Colitti Thread-Topic: [v6ops] OSX 10.8 poor performance for IPv6-only! Thread-Index: AQHN/kSlHZLWiwT60EaYA9l3n7/StJhhAUiAgAAyoID//9Czc4AAZpSAgAJjUwA= Date: Thu, 31 Jan 2013 18:02:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 18:02:37 -0000 Lorenzo, The host does have an IPv4 LLA, so AI_ADDRCONFIG flag would cause A query to happen. Cheers, Rajiv -----Original Message----- From: Lorenzo Colitti Date: Tuesday, January 29, 2013 7:34 PM To: Rajiv Asati Cc: Owen DeLong , "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! >Why is it requesting an A record even if it has no IPv4 address? Isn't >that what AI_ADDRCONFIG is for? > > >Is it possible that the browser is not passing in AI_ADDRCONFIG? Do >different browsers behave in different ways? > > > >On Wed, Jan 30, 2013 at 9:27 AM, Rajiv Asati (rajiva) > wrote: > >Owen, you are spot on. > >I can't think of anything, but a possible bug in OSX 10.8.2. Really a >weird one. I wonder whether this was meant to make the happy-eyeballing >implementation better. ;-) > >My IPv6-only usage has been pathetically slow on MBP, least to say. I >iPhone has been fine though. > >Cheers, >Rajiv > >Sent from my Phone > >On Jan 29, 2013, at 4:18 PM, "Owen DeLong" wrote: > >> >> On Jan 29, 2013, at 10:15 , David Farmer wrote: >> >>> I believe this is the "ARP for everything" behavior defined in section >>>2.6.2 of RFC 3927 which enables a device with a link local address to >>>communicate with devices on the local link that are using IPv4 GUA. >>>You will find a default route to the local interface, > not a router, that enables this behavior. >> >> Nope... this is more detailed and more insidious. If it is not waiting >>for the second DNS response and the AAAA record happens to not be the >>first answer, bad stuff happens regardless of whether IPv4 is enabled on >>the interface (arp for everything problem) > or not. >> >> This is an actual bug on Apple's part if they are prematurely closing >>the DNS connection for the second request as he describes. >> >> Remember, getaddrinfo() actually makes two requests to the DNS server. >>One for the A and one for the AAAA. The responses arrive on separate >>channels as well. >> >> This sounds like a bug in Apple's implementation of getaddrinfo() or >>its underlying libraries. >> >>> >>> I learned of this from some IPv6 only experiments Ron Broersma >>>reported on at a recent Internet2 IPv6 working group meeting. >>> >>> I believe full implementation of section 3.2 of RFC 6724 would >>>depreference the IPv4 link-local address in favor of a IPv6 GUA. I've >>>been thing about possible operational work-arounds, best current >>>thought is a device set up to proxy-ARP for everything > and return an immediate destination unreachable, but haven't tried it >yet. >> >> That doesn't help if you never get the AAAA record. >> >> Owen >> >>> However, obviously the best solution is for hosts to never prefer a >>>IPv4 link-local address over an IPv6 GUA when communicating with a GUA >>>address. >>> >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> David Farmer Email:farmer@umn.edu >>> >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: >612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: >612-812-9952 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" >>>wrote: >>> >>>> >>>> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 >>>>GUA, >>>> but no IPv4 public/private address) is intermittently causing very >>>>poor >>>> browser internet experience on the MacBook. >>>> >>>> MBP nicely issues both DNS A and AAAA queries over IPv6 transport for >>>>a >>>> given website (say, www.cnn.com ) almost at the >>>>same time (e.g. opens 2 UDP >>>> sockets), and receives both A and AAAA responses from the DNS server. >>>> However, it may close both UDP sockets upon receiving the first DNS >>>> response (whether A or AAAA), thereby ignoring the 2nd DNS response >>>> (whether A or AAAA). >>>> >>>> Suffice to say that MBP issues an ICMPv6 Destination/port unreachable >>>>for >>>> the 2nd DNS response (see the attached 2 screen wireshark >>>>screenshots). >>>> >>>> This is quite bad, since if an AAAA record was carried in the ignored >>>>DNS >>>> message, then no TCP connection would follow =3D> forget happy eyeball= s >>>>and >>>> recall poor internet experience. :( >>>> >>>> Has anybody else run into this or noticed it? >>>> >>>> Cheers, >>>> Rajiv >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 rajiva@cisco.com Thu Jan 31 10:05:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5871D21F861F for ; Thu, 31 Jan 2013 10:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzweWe3aJZzz for ; Thu, 31 Jan 2013 10:05:47 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2D13721F8619 for ; Thu, 31 Jan 2013 10:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6453; q=dns/txt; s=iport; t=1359655547; x=1360865147; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xsD//oo3zWcdSYM37OGWi5u4XkdVXuewn0CX5LBK/dw=; b=KeMQeb7HpRfwJ7FFQ/x7x59GeYU5bZ+LAPTpGT0g3UhxWB9j4k9HOtUg 3z4m0ubqOagjdqhTKKm3p3E2cjS4NTmlyr6sxARhzcIzwmU4kcDgyyeWB dQPEXKf/zdaM/unaQxhRMQXZqkE0lYhBd7WiWHkr0XlPWjHB5t8rPNSa9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOyxClGtJV2b/2dsb2JhbABCA78lFnOCHgEBAQQBAQE3Dx4HCwwCBAEIEQMBAgEKFCsMCx0IAgQOBQgTh3YMwiEEjQ1Ngk1hA6ZegnuBbzU X-IronPort-AV: E=Sophos;i="4.84,578,1355097600"; d="scan'208";a="171262511" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jan 2013 18:05:46 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0VI5kSG000652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 18:05:46 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 12:05:46 -0600 From: "Rajiv Asati (rajiva)" To: Owen DeLong Thread-Topic: [v6ops] OSX 10.8 poor performance for IPv6-only! Thread-Index: AQHN/kSlHZLWiwT60EaYA9l3n7/StJhhAUiAgAAyoID//9Czc4AAZ6GAgAJjJ4A= Date: Thu, 31 Jan 2013 18:05:45 +0000 Message-ID: In-Reply-To: <67D4B284-B453-4C7F-B04F-633354E8A80A@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <9FE238B6E009BA438D55DA41F421CD92@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 18:05:48 -0000 Owen, That's a fair guesswork. Hopefully, someone from OSX could chime in. I will try to disable IPv4 altogether and check if I see a different behavior. Cheers, Rajiv -----Original Message----- From: Owen DeLong Date: Tuesday, January 29, 2013 7:38 PM To: Rajiv Asati Cc: David Farmer , "v6ops@ietf.org" , Ron Broersma Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! >Not so strange... I suspect the logic went something like this... > >Happy Eyeballs is all about returning a usable connection as fast as >possible. > >Most testing likely done in dual-stack and/or IPv4-only environments. > >DNS resolver library sends out A and AAAA requests. > >It's not at all hard to imagine how a developer could make the mistake of >either of the following logics: > >while (!timeout) >{ > if(v4_answer_received && v6_answer_received) >return(concatenate(v4_answer, v6_answer)); > if(v4_answer_received) return(v4_answer); >} > >or > >while (!timeout) >{ > if(v4_answer_received && v6_answer_received) >return(concatenate(v4_answer, v6_answer)); > if(v4_answer_received) return(v4_answer); > if(v6_answer_received) return(v6_answer); >} > >In the first case, it would break on an IPv6 only network, but work in an >IPv4-only environment. >In the second case, it would break in certain IPv4-only environments, too. > >Obviously, the real bug is going to be more complex and integral, as >Happy Eyeballs is >a combination of resolver and connection initiation, likely involving a >threaded approach, >but I wanted to provide a simple illustration of the likely logic trap. >I'll leave the detailed >debugging to Apple's engineers. > >Owen > >On Jan 29, 2013, at 16:27 , "Rajiv Asati (rajiva)" >wrote: > >> Owen, you are spot on. >>=20 >> I can't think of anything, but a possible bug in OSX 10.8.2. Really a >>weird one. I wonder whether this was meant to make the happy-eyeballing >>implementation better. ;-) >>=20 >> My IPv6-only usage has been pathetically slow on MBP, least to say. I >>iPhone has been fine though. >>=20 >> Cheers, >> Rajiv >>=20 >> Sent from my Phone >>=20 >> On Jan 29, 2013, at 4:18 PM, "Owen DeLong" wrote: >>=20 >>>=20 >>> On Jan 29, 2013, at 10:15 , David Farmer wrote: >>>=20 >>>> I believe this is the "ARP for everything" behavior defined in >>>>section 2.6.2 of RFC 3927 which enables a device with a link local >>>>address to communicate with devices on the local link that are using >>>>IPv4 GUA. You will find a default route to the local interface, not a >>>>router, that enables this behavior. >>>=20 >>> Nope... this is more detailed and more insidious. If it is not waiting >>>for the second DNS response and the AAAA record happens to not be the >>>first answer, bad stuff happens regardless of whether IPv4 is enabled >>>on the interface (arp for everything problem) or not. >>>=20 >>> This is an actual bug on Apple's part if they are prematurely closing >>>the DNS connection for the second request as he describes. >>>=20 >>> Remember, getaddrinfo() actually makes two requests to the DNS server. >>>One for the A and one for the AAAA. The responses arrive on separate >>>channels as well. >>>=20 >>> This sounds like a bug in Apple's implementation of getaddrinfo() or >>>its underlying libraries. >>>=20 >>>>=20 >>>> I learned of this from some IPv6 only experiments Ron Broersma >>>>reported on at a recent Internet2 IPv6 working group meeting. >>>>=20 >>>> I believe full implementation of section 3.2 of RFC 6724 would >>>>depreference the IPv4 link-local address in favor of a IPv6 GUA. I've >>>>been thing about possible operational work-arounds, best current >>>>thought is a device set up to proxy-ARP for everything and return an >>>>immediate destination unreachable, but haven't tried it yet. >>>=20 >>> That doesn't help if you never get the AAAA record. >>>=20 >>> Owen >>>=20 >>>> However, obviously the best solution is for hosts to never prefer a >>>>IPv4 link-local address over an IPv6 GUA when communicating with a GUA >>>>address. >>>>=20 >>>> --=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> David Farmer Email:farmer@umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE Phone: 612-626-0815 >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>>=20 >>>> On Jan 29, 2013, at 11:18, "Rajiv Asati (rajiva)" >>>>wrote: >>>>=20 >>>>>=20 >>>>> A weird behavior of OSX 10.8.2 wrt DNS A and AAAA lookup (with IPv6 >>>>>GUA, >>>>> but no IPv4 public/private address) is intermittently causing very >>>>>poor >>>>> browser internet experience on the MacBook. >>>>>=20 >>>>> MBP nicely issues both DNS A and AAAA queries over IPv6 transport >>>>>for a >>>>> given website (say, www.cnn.com) almost at the same time (e.g. opens >>>>>2 UDP >>>>> sockets), and receives both A and AAAA responses from the DNS server. >>>>> However, it may close both UDP sockets upon receiving the first DNS >>>>> response (whether A or AAAA), thereby ignoring the 2nd DNS response >>>>> (whether A or AAAA). >>>>>=20 >>>>> Suffice to say that MBP issues an ICMPv6 Destination/port >>>>>unreachable for >>>>> the 2nd DNS response (see the attached 2 screen wireshark >>>>>screenshots). >>>>>=20 >>>>> This is quite bad, since if an AAAA record was carried in the >>>>>ignored DNS >>>>> message, then no TCP connection would follow =3D> forget happy >>>>>eyeballs and >>>>> recall poor internet experience. :( >>>>>=20 >>>>> Has anybody else run into this or noticed it? >>>>>=20 >>>>> Cheers, >>>>> Rajiv >>>>>=20 >>>>> >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 > From rajiva@cisco.com Thu Jan 31 10:06:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB95221F863B for ; Thu, 31 Jan 2013 10:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[AWL=2.412, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JZsweJozpGp for ; Thu, 31 Jan 2013 10:06:31 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B501121F862A for ; Thu, 31 Jan 2013 10:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2864; q=dns/txt; s=iport; t=1359655591; x=1360865191; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=felDmeaCQvFRdxc+9XblyktR3XxCO6nj/acb8BkgA2c=; b=En3BZ8ZDZus7g782EKMBxOYBuis5HXK7VF5OD9GHw3teiNWP5owQQKEE vjDIoPva021AOdtrVNBFKVqUbAIr7hKg1YIzHkhrvJtxb5jLXKO4ZIqar 7/uaDqpvLqqAp5/d3vzg68v76HoVATvrCpRlQFUWhIwHGNhbPO9w7HAkP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAexClGtJXHB/2dsb2JhbAA7Cr8lFnOCHgEBAQRlFAwCBAEIEQMBAgEKPxcdCAIEAQ0FCIgJwjcEjRODFGEDly6PMIJ7gWgkGA X-IronPort-AV: E=Sophos;i="4.84,578,1355097600"; d="scan'208";a="171266835" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jan 2013 18:06:31 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0VI6Vgv006923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 18:06:31 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 12:06:30 -0600 From: "Rajiv Asati (rajiva)" To: Mark Andrews , Owen DeLong Thread-Topic: [v6ops] OSX 10.8 poor performance for IPv6-only! Thread-Index: AQHN/kSlHZLWiwT60EaYA9l3n7/StJhhAUiAgAAyoID//9Czc4AAZ6GA//+jZFeAAIWZgP//tnW8AFB9PoA= Date: Thu, 31 Jan 2013 18:06:29 +0000 Message-ID: In-Reply-To: <20130130044130.696F22E8DCD0@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: <13162448D361C74F9BBED3865980B995@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 18:06:35 -0000 Hi Mark, Hmmm=8A is it valid to return AAAA record for A query? Cheers, Rajiv -----Original Message----- From: Mark Andrews Date: Tuesday, January 29, 2013 11:41 PM To: Owen DeLong Cc: Rajiv Asati , "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! > >In message <2C3FC41E-7B48-4304-9BC4-ED2FDC0B6993@delong.com>, Owen DeLong >write >s: >> Providing feedback to the end-user about a DNS server they don't even >> know they are using in a way that does not allow them to easily >>identify the >> DNS server in question, let alone who is responsible for it or how to >>report >> the problem isn't useful. > >How does a user deal with any remote problem? They contact their >ISP. The ISP should have enough clue to contact the DNS server >administrator. IPv6 is being deployed wide enough that even IPv4 >only sites are starting to be aware of it. > >Note this is also a problem that will correct itself over time as >sites with broken load balancers enable IPv6. > >I just for interest I dumped the nameserver's cache and looked up >the AAAA for every A record in the cache. I had one zone with >broken AAAA lookups and one lookup failing due to DNSSEC validation >failures. > >The servers for cedexis.net return A records in response to AAAA >lookups. > > flipa.cedexis.net. > flipd.cedexis.net. > flipg.cedexis.net. > >Mark > >> Feedback that reaches the person responsible for fixing the problem is >> like feedback heard by the sound-man in a concert hall. The sound man >> will take action to resolve the issue. >>=20 >> Feedback that doesn't is just noise that makes everyone in the hall >>unhappy. >> However, regardless of how unhappy they are, they don't have any real >> ability to fix the problem. >>=20 >> Owen >>=20 >> On Jan 29, 2013, at 5:06 PM, Mark Andrews wrote: >>=20 >> >=20 >> > Part of the problem is there is this myth that AAAA lookups fail a >> > lot. They don't. There are a few bad (drop AAAA queries) / >> > misconfigured (return the wrong negative answer) load balancers. >> > If you are talking to something other than a load balancer you get >> > valid answers. When you code for this you get all sorts of bad >> > behaviour. >> >=20 >> > If you can't configure your nameserver to respond correctly to AAAA >> > queries the customet SHOULD get bad performance. How else does >> > feedback get applied. >> >=20 >> > Mark >> > --=20 >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >--=20 >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Thu Jan 31 10:17:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4880821F87A4; Thu, 31 Jan 2013 10:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUeUj9Zut4ah; Thu, 31 Jan 2013 10:17:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B6C21F86EA; Thu, 31 Jan 2013 10:17:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130131181729.3733.16395.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2013 10:17:29 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 18:17:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Deployment Considerations Author(s) : Gang Chen Zhen Cao Cameron Byrne Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-01.txt Pages : 16 Date : 2013-01-31 Abstract: This document summarizes NAT64 deployment scenarios and operational experience with stateful NAT64-CGN(NAT64 Carrier Grade NATs) and NAT64-FE (NAT64 server Front End). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhw@apple.com Thu Jan 31 10:54:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8821F86A9 for ; Thu, 31 Jan 2013 10:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWpTCEeJ1b6B for ; Thu, 31 Jan 2013 10:54:46 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3436221F8651 for ; Thu, 31 Jan 2013 10:54:46 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MHI003BH76TE160@mail-out.apple.com> for v6ops@ietf.org; Thu, 31 Jan 2013 10:54:45 -0800 (PST) X-AuditID: 11807136-b7f5e6d000000e0b-b1-510acc05989f Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id C4.34.03595.50CCA015; Thu, 31 Jan 2013 11:54:45 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MHI003N17775W60@marigold.apple.com> for v6ops@ietf.org; Thu, 31 Jan 2013 10:54:45 -0800 (PST) From: james woodyatt In-reply-to: <5109723D.4090905@bogus.com> Date: Thu, 31 Jan 2013 10:54:43 -0800 Message-id: <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUi2FDcost6hivQ4NtlPovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY92TZtaC+7wVd/dsZmtgfM3VxcjJISFgIrH5yGxGCFtM4sK9 9WxdjFwcQgLTmSQalu9hhnBmMUkcaZvJClLFLKAlsX7ncSYQm1dAT2Lb3G1gHcICXYwS2xa9 AytiE1CR+Hb5LlgRp4CmxJb+qWwgNouAqsSSY9vZIAZpSzx5d4EVYpCNxLaZC9hBbCGBBIkV vx+B9YoIKEjs+L+TCeI8WYnXz9+wTGDkn4XkjllI7piFZOwCRuZVjIJFqTmJlYameokFBTmp esn5uZsYwWFWaLaDccdfuUOMAhyMSjy8j3w4A4VYE8uKK3MPMUpwMCuJ8N6dxBUoxJuSWFmV WpQfX1Sak1p8iFGag0VJnJdhAkegkEB6YklqdmpqQWoRTJaJg1OqgVGQz+bsnXqVAwelp076 2K8eXjhjd/ma/vVF7x4VfSuck+iwwsfzTYj31q9ZJw9XSCY5fn4u7HvbP7AtxuKr7rYzrcwz brko8T29c9rvXdzzDM+NV4sVT510/B1xoCtpq/rhiJ5nopuue2nvS1htpz49iedq4uznSg/u f+TmeOX08/nb53d9fiYrsRRnJBpqMRcVJwIA4Vj5jy8CAAA= Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 18:54:46 -0000 On Jan 30, 2013, at 11:19 , joel jaeggli wrote: > > This kicks of a request for adoption as a working group document on draft-binet-v6ops-cellular-host-requirements-02.txt I'm going to echo the sentiments of others by questioning whether 3GPP would be a better venue than IETF for defining this sort of device profile. As a supporting argument, I would point out that this draft uses RFC 2119 normative keywords while asserting that it is Informational category. That makes it a bit peculiar in the same way that an early draft of what became RFC 6092 was peculiar, which entailed adding section 1.2 during working group deliberations. >> 1.2. Use of Normative Keywords >> >> NOTE WELL: This document is not a standard, and conformance with >> it is not required in order to claim conformance with IETF >> standards for IPv6. It uses the normative keywords defined in the >> previous section only for precision. We added that language because there were several different standards bodies that were interested in having a baseline of IETF consensus defined about what sorts of requirements are a reasonable starting point, and we were hoping to facilitate all those external organizations at once in setting requirements standards that could reference an IETF document in common with specific amendments applicable in their own domains. The way I see it, there is no need for IETF to do that in this case. There is only one standards body with an ambit that covers the topic of this draft, i.e. 3GPP, and it would be a much better fit for this work to be done there. -- james woodyatt core os networking From cb.list6@gmail.com Thu Jan 31 11:05:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FFE21F86A9 for ; Thu, 31 Jan 2013 11:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXfi8jpZKXnv for ; Thu, 31 Jan 2013 11:05:40 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7121F8651 for ; Thu, 31 Jan 2013 11:05:39 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so3749908lbj.3 for ; Thu, 31 Jan 2013 11:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=49qpFnbKW9ZA9g0hWkuzEwIYkQ/HPCU9PwT41Rml+J4=; b=M3FWpOBiZmeVHglsUMJayGorJYcvn3DbVY5zk04NlvQl7HR/+LWJJx+AW2LsTzf6JW 7JoslFsvZo731D6XsRbGYCZhYKiSur7gkovrVfhKOLRa4pQEttlzJDbJzNQ8uTREChrW iUnklk3EP42XkGsBU9y6d2e9Pg9Fo+Bg84XUNdvXEvkNsSrXhM/AsJrNNg3cWBpPwYrn eh9ndJdoDu95UPnWAu1lUTV7fTf0A3v9gW5kY59cNgyS+IjpiRuRcVJGKUdF0jrQDTjY 3gNRKbQMLXL1vvKu0WNMHnlG/PpX0hELfag8mNqrErrGGWdJGReVNZSkYFAmDYlb7NpL lvNA== MIME-Version: 1.0 X-Received: by 10.112.38.67 with SMTP id e3mr3656452lbk.105.1359659138342; Thu, 31 Jan 2013 11:05:38 -0800 (PST) Received: by 10.112.7.165 with HTTP; Thu, 31 Jan 2013 11:05:38 -0800 (PST) In-Reply-To: <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> Date: Thu, 31 Jan 2013 11:05:38 -0800 Message-ID: From: Cameron Byrne To: james woodyatt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:05:40 -0000 On Thu, Jan 31, 2013 at 10:54 AM, james woodyatt wrote: > On Jan 30, 2013, at 11:19 , joel jaeggli wrote: >> >> This kicks of a request for adoption as a working group document on draf= t-binet-v6ops-cellular-host-requirements-02.txt > > > I'm going to echo the sentiments of others by questioning whether 3GPP wo= uld be a better venue than IETF for defining this sort of device profile. > > As a supporting argument, I would point out that this draft uses RFC 2119= normative keywords while asserting that it is Informational category. That= makes it a bit peculiar in the same way that an early draft of what became= RFC 6092 was peculiar, which entailed adding section 1.2 during working gr= oup deliberations. > >>> 1.2. Use of Normative Keywords >>> >>> NOTE WELL: This document is not a standard, and conformance with >>> it is not required in order to claim conformance with IETF >>> standards for IPv6. It uses the normative keywords defined in th= e >>> previous section only for precision. > > We added that language because there were several different standards bod= ies that were interested in having a baseline of IETF consensus defined abo= ut what sorts of requirements are a reasonable starting point, and we were = hoping to facilitate all those external organizations at once in setting re= quirements standards that could reference an IETF document in common with s= pecific amendments applicable in their own domains. > > The way I see it, there is no need for IETF to do that in this case. Ther= e is only one standards body with an ambit that covers the topic of this dr= aft, i.e. 3GPP, and it would be a much better fit for this work to be done = there. > So, i cannot speak for others, but i will not be doing this work in 3GPP. Keep in mind, 3GPP is not an open standards group. CB From marka@isc.org Thu Jan 31 12:37:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8D221F85D7 for ; Thu, 31 Jan 2013 12:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfjpZHByC+8F for ; Thu, 31 Jan 2013 12:37:34 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AB8E121F843C for ; Thu, 31 Jan 2013 12:37:33 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 45A50C9479; Thu, 31 Jan 2013 20:37:24 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1359664652; bh=YBNpoo0DDbbAUqB8HS3Z2Bn/c3tiJ7uUHHdjXbLAwNE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=KbqRWzVwLyOkrOAgQ9CXGvltXjb8/TN8A1vQuvLvDfq6Efz1iU1RjcKN91IC27Oyx D7VJZy6F/pzaTnHf+axf3nQh4QcYQ+vGgEkSY87qwYqlbPAPKokndKkZXlUC6hBqOU 4Bk5y1uIwnq2TUBRcaAEnBV59egkmxAxwRmwySf4= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 31 Jan 2013 20:37:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e16b:c982:e981:1713]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 06994216C3B; Thu, 31 Jan 2013 20:37:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5DC292E9806F; Fri, 1 Feb 2013 07:37:21 +1100 (EST) To: "Rajiv Asati (rajiva)" From: Mark Andrews References: In-reply-to: Your message of "Thu, 31 Jan 2013 18:06:29 -0000." Date: Fri, 01 Feb 2013 07:37:21 +1100 Message-Id: <20130131203721.5DC292E9806F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 20:37:38 -0000 In message , "R ajiv Asati (rajiva)" writes: > Hi Mark, > > Hmmm=8A is it valid to return AAAA record for A query? No. The owner of the servers is looking into the issue. Got a polite thank you for informing us, we will look into it. I don't expect a instant fix as they will need to talk with their name server vendor. Mark > Cheers, > Rajiv > > -----Original Message----- > From: Mark Andrews > Date: Tuesday, January 29, 2013 11:41 PM > To: Owen DeLong > Cc: Rajiv Asati , "v6ops@ietf.org" > Subject: Re: [v6ops] OSX 10.8 poor performance for IPv6-only! > > > > >In message <2C3FC41E-7B48-4304-9BC4-ED2FDC0B6993@delong.com>, Owen DeLong > >write > >s: > >> Providing feedback to the end-user about a DNS server they don't even > >> know they are using in a way that does not allow them to easily > >>identify the > >> DNS server in question, let alone who is responsible for it or how to > >>report > >> the problem isn't useful. > > > >How does a user deal with any remote problem? They contact their > >ISP. The ISP should have enough clue to contact the DNS server > >administrator. IPv6 is being deployed wide enough that even IPv4 > >only sites are starting to be aware of it. > > > >Note this is also a problem that will correct itself over time as > >sites with broken load balancers enable IPv6. > > > >I just for interest I dumped the nameserver's cache and looked up > >the AAAA for every A record in the cache. I had one zone with > >broken AAAA lookups and one lookup failing due to DNSSEC validation > >failures. > > > >The servers for cedexis.net return A records in response to AAAA > >lookups. > > > > flipa.cedexis.net. > > flipd.cedexis.net. > > flipg.cedexis.net. > > > >Mark > > > >> Feedback that reaches the person responsible for fixing the problem is > >> like feedback heard by the sound-man in a concert hall. The sound man > >> will take action to resolve the issue. > >> > >> Feedback that doesn't is just noise that makes everyone in the hall > >>unhappy. > >> However, regardless of how unhappy they are, they don't have any real > >> ability to fix the problem. > >> > >> Owen > >> > >> On Jan 29, 2013, at 5:06 PM, Mark Andrews wrote: > >> > >> > > >> > Part of the problem is there is this myth that AAAA lookups fail a > >> > lot. They don't. There are a few bad (drop AAAA queries) / > >> > misconfigured (return the wrong negative answer) load balancers. > >> > If you are talking to something other than a load balancer you get > >> > valid answers. When you code for this you get all sorts of bad > >> > behaviour. > >> > > >> > If you can't configure your nameserver to respond correctly to AAAA > >> > queries the customet SHOULD get bad performance. How else does > >> > feedback get applied. > >> > > >> > Mark > >> > -- > >> > Mark Andrews, ISC > >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > >> > >-- > >Mark Andrews, ISC > >1 Seymour St., Dundas Valley, NSW 2117, Australia > >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Thu Jan 31 13:31:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B257D21F87CC for ; Thu, 31 Jan 2013 13:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSh-6rhjLGBD for ; Thu, 31 Jan 2013 13:31:10 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD621F8722 for ; Thu, 31 Jan 2013 13:31:08 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 232421B40429; Thu, 31 Jan 2013 16:31:08 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Thu, 31 Jan 2013 16:31:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 21:31:10 -0000 On Jan 31, 2013, at 2:05 PM, Cameron Byrne wrote: > On Thu, Jan 31, 2013 at 10:54 AM, james woodyatt = wrote: >> On Jan 30, 2013, at 11:19 , joel jaeggli wrote: >>>=20 >>> This kicks of a request for adoption as a working group document on = draft-binet-v6ops-cellular-host-requirements-02.txt >>=20 >>=20 >> I'm going to echo the sentiments of others by questioning whether = 3GPP would be a better venue than IETF for defining this sort of device = profile. >>=20 >> As a supporting argument, I would point out that this draft uses RFC = 2119 normative keywords while asserting that it is Informational = category. That makes it a bit peculiar in the same way that an early = draft of what became RFC 6092 was peculiar, which entailed adding = section 1.2 during working group deliberations. >>=20 >>>> 1.2. Use of Normative Keywords >>>>=20 >>>> NOTE WELL: This document is not a standard, and conformance = with >>>> it is not required in order to claim conformance with IETF >>>> standards for IPv6. It uses the normative keywords defined in = the >>>> previous section only for precision. >>=20 >> We added that language because there were several different standards = bodies that were interested in having a baseline of IETF consensus = defined about what sorts of requirements are a reasonable starting = point, and we were hoping to facilitate all those external organizations = at once in setting requirements standards that could reference an IETF = document in common with specific amendments applicable in their own = domains. >>=20 >> The way I see it, there is no need for IETF to do that in this case. = There is only one standards body with an ambit that covers the topic of = this draft, i.e. 3GPP, and it would be a much better fit for this work = to be done there. >>=20 >=20 > So, i cannot speak for others, but i will not be doing this work in = 3GPP. >=20 > Keep in mind, 3GPP is not an open standards group. Hmm=85. Ok, good point=85 When I wrote that I though that this should be done somewhere else, I = didn't actually stop and figure out *where* else=85 If the choice is between it being adopted by v6ops or just not being = published, then I (somewhat reluctantly) support adoption. I still think that it will need some more fleshing out, but that can be = done by the WG (if it chooses to adopt, etc blah blah blah=85) W >=20 > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --=20 No man is an island, But if you take a bunch of dead guys and tie them = together, they make a pretty good raft. --Anon. From sm@resistor.net Thu Jan 31 14:25:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D0821F844F for ; Thu, 31 Jan 2013 14:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn+R-qs0fIfq for ; Thu, 31 Jan 2013 14:25:25 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7778121F8446 for ; Thu, 31 Jan 2013 14:25:25 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0VMPH70010259; Thu, 31 Jan 2013 14:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359671123; bh=EOwyICILi29JSIWdUw0SER0covbUcxPM3YCccxtDLeo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CNfGYHSuqsA3z7UC0VZPVzsCNhfwRkD1Z2DduXHTzbSpXX0S/lvaJVRehZ6hg05D4 2+DxFWuEh7RGJbBFMP9Ry0BXS82MqZeh6Vlv+bRfShpNeyGIseHukvRRhZzCEJuyqY Rr59yCT4+f9oxFXIgdKpM2GEu747IS0IWB3NPWDc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359671123; i=@resistor.net; bh=EOwyICILi29JSIWdUw0SER0covbUcxPM3YCccxtDLeo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VyNJ6dUowAKL5sp9Oxl+RZk1L5AfuPcMMe0irDZcm7WrY0WcxoXnuGyOrAvoDch8z 36znZUDaj3T8le6zdj+kNsnX2vsHy/Ec/psu1fFtintzOP1AudWNvzqRZaVF3wxSs2 PhiFpJB/3Qq4YufIQQQwZfm2YN2f6uQiJpUem9sA= Message-Id: <6.2.5.6.2.20130131141627.0a209458@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 31 Jan 2013 14:20:17 -0800 To: "t.petch" From: SM In-Reply-To: <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 22:25:27 -0000 Hi Tom, At 04:17 31-01-2013, t.petch wrote: >I thought that we were still discussing whether or not the IPR claims >were acceptable, but perhaps not. That was my understanding too. Regards, -sm From joelja@bogus.com Thu Jan 31 15:27:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7135421F842C for ; Thu, 31 Jan 2013 15:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0BnBd+nJVPn for ; Thu, 31 Jan 2013 15:27:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1520421F841A for ; Thu, 31 Jan 2013 15:27:07 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0VNR2jV000623 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 31 Jan 2013 23:27:02 GMT (envelope-from joelja@bogus.com) Message-ID: <510AFDC0.5020300@bogus.com> Date: Thu, 31 Jan 2013 15:26:56 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: SM , "t.petch" References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> In-Reply-To: <6.2.5.6.2.20130131141627.0a209458@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 31 Jan 2013 23:27:03 +0000 (UTC) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:27:08 -0000 On 1/31/13 2:20 PM, SM wrote: > Hi Tom, > At 04:17 31-01-2013, t.petch wrote: >> I thought that we were still discussing whether or not the IPR claims >> were acceptable, but perhaps not. The discussion was instigated by Ron after dicussion in the IESG, after some time on the list the v6ops chairs and AD have discussed it and the AD has cleared it, thus the IESG has no outstanding issues. Draft-09 addresses the issues raised by IESG during review. the WG should review the diffs associated with 09 http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-09 Given an intended status of BCP, the next big step is IETF last call, which should not be construed as a reason to stop this discussion, quite the contrary. > > That was my understanding too. > Regards, > -sm > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From sm@resistor.net Thu Jan 31 16:25:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5421F8A43 for ; Thu, 31 Jan 2013 16:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4dBT59YsI2d for ; Thu, 31 Jan 2013 16:25:11 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 400B721F8A42 for ; Thu, 31 Jan 2013 16:25:11 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r110OrBY029060; Thu, 31 Jan 2013 16:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359678302; bh=625G5+sfqeRbbGFF45X3W/r/wCB6/UJLVtVCcAFRIuI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VfJL4r5HICkwvWZYRslSvPzs2WHn82Ua3814jVGSSrW6y0q50X8j+vA+xgIUnMnrb kL7uib9GSvqGBD/WJsWuokqocPlckRECvqilGEOdjlFsubOglIp9kgPjyrEL4MvQWP 9R+VO2Zv5NdZ0xbbcqS2botelhGzgg0nJmxBAoiI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359678302; i=@resistor.net; bh=625G5+sfqeRbbGFF45X3W/r/wCB6/UJLVtVCcAFRIuI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=t+0yQj/2Gt0YIBGIEfLS8Spq72V9PunVDEjihR96BRObAxgJBQ4N6iVet+aUufblZ FZ4pdkDL2OK1u46Jnna6GM6nkF+qVeLNC3PvXb+jXYFDWy2VdualBVzo6hnQRtxCO2 pwtHUtZVOCCxhZwav8QWnnLcwNOo4XxAj315rOto= Message-Id: <6.2.5.6.2.20130131161657.09f16650@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 31 Jan 2013 16:24:32 -0800 To: joel jaeggli From: SM In-Reply-To: <510AFDC0.5020300@bogus.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:25:11 -0000 Hi Joel, At 15:26 31-01-2013, joel jaeggli wrote: >Given an intended status of BCP, the next big step is IETF last >call, which should not be construed as a reason to stop this >discussion, quite the contrary. The message at http://www.ietf.org/mail-archive/web/v6ops/current/msg15027.html mentions that the draft has been approved for publication by the IESG. According to the above there will be another IETF Last Call. The state in the datatracker may be incorrect. Regards, -sm From Ted.Lemon@nominum.com Thu Jan 31 17:47:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C22F21F8840 for ; Thu, 31 Jan 2013 17:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ozp9g0sHFih0 for ; Thu, 31 Jan 2013 17:47:20 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE4A21F8838 for ; Thu, 31 Jan 2013 17:47:20 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUQseqGkQ4Ah6xZuTLU7GP4Qa4YEy2upa@postini.com; Thu, 31 Jan 2013 17:47:20 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 183CD1B841E for ; Thu, 31 Jan 2013 17:47:20 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0D2D5190043; Thu, 31 Jan 2013 17:47:20 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 17:47:20 -0800 From: Ted Lemon To: joel jaeggli Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOAAqEbF1EDOGb3EeKRfA7jixtSphkwikA Date: Fri, 1 Feb 2013 01:47:19 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> In-Reply-To: <510AFDC0.5020300@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 01:47:21 -0000 On Jan 31, 2013, at 6:26 PM, joel jaeggli wrote: > Given an intended status of BCP, the next big step is IETF last call, whi= ch should not be construed as a reason to stop this discussion, quite the c= ontrary. Someone, I can't remember who (sorry!), pointed out that this statement is = true of Informational, but perhaps not of BCP. That is, if the document i= s merely intended to document the existing practice that some vendor follow= s, that is a good thing which we should publish; however, it shouldn't be a= BCP if the IPR terms are not found to be acceptable. I haven't looked at it in depth, but a brief skim of the updated IPR report= that went by yesterday looked like it was a bit outside of the norm for IE= TF standards, since it mentions charging royalties. From joelja@bogus.com Thu Jan 31 21:12:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2FD21F8896 for ; Thu, 31 Jan 2013 21:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NiJvIIsMdhf for ; Thu, 31 Jan 2013 21:12:52 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D0B1D21F895B for ; Thu, 31 Jan 2013 21:12:52 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r115ChlA004390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 1 Feb 2013 05:12:44 GMT (envelope-from joelja@bogus.com) Message-ID: <510B4EC6.5050308@bogus.com> Date: Thu, 31 Jan 2013 21:12:38 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Ted Lemon References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 01 Feb 2013 05:12:48 +0000 (UTC) Cc: "" , "" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 05:12:53 -0000 On 1/31/13 5:47 PM, Ted Lemon wrote: > On Jan 31, 2013, at 6:26 PM, joel jaeggli wrote: >> Given an intended status of BCP, the next big step is IETF last call, which should not be construed as a reason to stop this discussion, quite the contrary. > Someone, I can't remember who (sorry!), pointed out that this statement is true of Informational, but perhaps not of BCP. I think you mean vice-versa. if I'm wrong about it's current state then I missed something. version 9 and 8 still request the status of bcp as the wglc validated as well. we have hypothetically discussed whether the ipr is more palatable with an informational document. > That is, if the document is merely intended to document the existing practice that some vendor follows, that is a good thing which we should publish; however, it shouldn't be a BCP if the IPR terms are not found to be acceptable. > > I haven't looked at it in depth, but a brief skim of the updated IPR report that went by yesterday looked like it was a bit outside of the norm for IETF standards, since it mentions charging royalties. Definition of what is RAND is somewhat fungible. It clearly is not in the style of non-assert clause which I would have no problems at all with. > >