From otroan@employees.org Fri Nov 1 08:35: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 EE90121E80F2 for ; Fri, 1 Nov 2013 08:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0PP+IDxEm0l for ; Fri, 1 Nov 2013 08:34:48 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A9A0B21E80CC for ; Fri, 1 Nov 2013 08:34:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAALJc1KQ/khN/2dsb2JhbABZgwc4vyOBFIEeFnSCJQEBAQMBAQEBawsFCwsSKQshBiIOBhMZAodaAwkGDbNEDYlrjGiBJoEXMweDIIEOA5YfgxqLI4U3gWiBPzs X-IronPort-AV: E=Sophos;i="4.93,617,1378857600"; d="scan'208";a="18712933" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 01 Nov 2013 15:34:44 +0000 Received: from dhcp-10-61-97-40.cisco.com (dhcp-10-61-97-40.cisco.com [10.61.97.40]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA1FYdh4032729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 15:34:40 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <526662F2.1060808@gmail.com> Date: Fri, 1 Nov 2013 16:34:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6295EF56-0D28-4A86-8D6C-F4AA8B44C07C@employees.org> References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> <5253B80E.7030008@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz> <5253C891.7090009@gmail.com> <526662F2.1060808@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1816) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Announcing draft-petrescu-relay-route-pd-problem-00 (was: Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering) 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 Nov 2013 15:35:01 -0000 Alexandru, with regards to your solutions; 5.3. draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for prefix pool of PD isn't standalone, that has to be combined with solution in 5.1 or 5.2. I think you could add some text where you draw an analogy to having a = statically configured aggregate route, with configuring a prefix (/64) for address assignment. routing is set = up very similarly. that could go in section 3.1. "Allocating a prefix is an operation = different..." should we ask Markus to kick = http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00 back into life? cheers, Ole On 22 Oct 2013, at 13:35 , Alexandru Petrescu = wrote: > Hello participants to v6ops WG, >=20 > We have just submitted draft-petrescu-relay-route-pd-problem-00 > http://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00 > "Route Problem at Relay during DHCPv6 Prefix Delegation" > M. Boucadair (France Telecom) > L. Yeh (Freelancer Technologies) > A. Petrescu (CEA). >=20 > It presents a problem of routing at Relay during Prefix Delegation of > DHCPv6; also lists some solutions I-Ds. The problem may be relevant = in > the DHC WG, at the Broadband Forum and maybe at 3GPP. >=20 > Please comment on this draft. >=20 > Thanks, >=20 > Alex >=20 > Le 08/10/2013 10:55, Alexandru Petrescu a =E9crit : >> Le 08/10/2013 10:49, V=EDzdal Ale=9A a =E9crit : >>>>> The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP >>>>> through all the intermediate nodes. >>>>=20 >>>> Ah, right, there is a GTP tunnel above all the intermediary IP >>>> nodes. >>>>=20 >>>> However, even when a tunnel is dynamically set up, a routing >>>> table entry is added in the Relay's routing table (or other >>>> similar entry). The parameters of that entry necessarily >>>> include, among others, the prefix which is allocated. >>>>=20 >>>> No? >>>=20 >>> The tunnel stays up for the lifetime of the PDP/PDN context. >>=20 >> Ok. >>=20 >>> There is no relay in the 3GPP access architecture. >>=20 >> Ok. >>=20 >>> If the tunnel drops, the PGW/GGSN will remove the route from their >>> routing table, once a new tunnel is setup the routing table is >>> updated accordingly. >>=20 >> The route associated with that tunnel should contain a parameter >> containing the Delegated Prefix. When there is no delegated prefix, >> that route entry should be updated. >>=20 >> The tunnel could stay up but only for the Smartphone. Or it could >> stay up for both the Smartphone _and_ the Hosts in the smartphone's >> LAN. These are two different things. >>=20 >> Alex >>=20 >>=20 >>>=20 >>>> Alex >>>=20 >>> Ales >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Lee@asgard.org Fri Nov 1 12:41: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 C22CA21E80DE for ; Fri, 1 Nov 2013 12:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.071 X-Spam-Level: * X-Spam-Status: No, score=1.071 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqk7rT7DkYyb for ; Fri, 1 Nov 2013 12:41:25 -0700 (PDT) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5CC11E817A for ; Fri, 1 Nov 2013 12:41:20 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id rA1JfHDS010596 for ; Fri, 1 Nov 2013 15:41:17 -0400 Received: (qmail 28084 invoked by uid 0); 1 Nov 2013 19:41:17 -0000 X-TCPREMOTEIP: 65.114.90.17 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?172.26.29.84?) (lee@asgard.org@65.114.90.17) by 0 with ESMTPA; 1 Nov 2013 19:41:15 -0000 User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Fri, 01 Nov 2013 14:41:15 +0200 From: Lee Howard To: "'IPv6 Operations'" Message-ID: Thread-Topic: comments on draft-ietf-v6ops-nat64-experience Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3466161678_9595586" Subject: [v6ops] comments on draft-ietf-v6ops-nat64-experience 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 Nov 2013 19:41:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3466161678_9595586 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Please define the acronym NAT64-FE. "Front End"? "Functional Equivalent"? "Fire Engine"? Clarify this sentence: Some failure cases may be occurred once NAT64 serves a IPv6 gateway while is configured only with IPv4 on WAN links. What is an "IPv6 gateway"? Is that "IPv4 on WAN links" on the gateway, or on the NAT64 server? I can't quite picture the topology being described in this example. I'm not sure you've made this point: It's desirable to find the solutions that will allow introducing IPv6/IPv4 translation service to IPv6-only hosts while keeping dual-stack hosts unaffected and IPv4 service unchanged. I think what you want to say is that it's preferable to have at least one address family accessible via native service, when possible. If you want to say that IPv4 service should remain unchanged, and that IPv6 hosts should use NAT64, I would not agree with that. I don't think that's consistent with the rest of the draft, either. Since this section is about the coexistence of NAT44 and NAT64, and the previous sentence is how hard it is to troubleshoot, maybe you want to say more about how to find the solutions that will facilitate the best network. That might mean having both, but upgrading hosts aggressively to support IPv6-only, and making sure native IPv6 was available. I'm not sure where you want to put it, but another NAT64-FE consideration is the use of x-forwarded-for header. A load balancer using an IPv4 VIP may be used to sending an IPv4 x-forwarded-for. A front-end server used to that has no problem, but the server, logs, or log parsing tools (rDNS looking, whois) may be affected by seeing an IPv6 address when they're used to seeing IPv4. This is related, but not the same, as the geo-location issue. I don't like the use of IPv6 subdomains beyond the testing phase. Nobody will ever see it; you might as well not have a AAAA if you're only going to public ipv6.example.com. It's fine to recommend it for testing, but when ready for production, the same name should be available over A and AAAA, and let the client choose the address family. Section 4.1 is an excellent discussion of the pros and cons of each mode, with supporting data. It would be good to have a sense of the scale of sync data for hot standby instances. Section 5.1 needs some paragraph breaks. Use of XFF header for geo-location would work if the server could parse the original address out of the XFF header. "Geo-location based on shared IPv4 address is rather inaccurate in that case." Depending on the geographic range of the NAT64. A NAT64-CGN covering a university or apartment complex, or even a small one covering a neighborhood, may provide as much detail as in the old days. I think the detail in Section 6.1 is pretty light. I would expect that the same things documented as problems in rfc7021 are also problematic in NAT64-CGN. These sentences: Operators may consider to add additional site-specific rows to the default table to steer traffic flows going through NAT64-CGN. However, it involves significant costs to change terminal's behavior. I think you mean that operators might consider making changes to host (client) behavior, but I wasn't clear on the first couple of readings whether we were talking about host address selection or routing somehow. Based on the above, I think this document needs another rewrite, but is good. Lee --B_3466161678_9595586 Content-type: text/html; name="default.html" Content-disposition: attachment; filename="default.html" Content-transfer-encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5z aXRpb25hbC5kdGQiPgo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRt bCIgeG1sOmxhbmc9ImVuIiBsYW5nPSJlbiI+PGhlYWQgcHJvZmlsZT0iaHR0cDovL2R1Ymxp bmNvcmUub3JnL2RvY3VtZW50cy8yMDA4LzA4LzA0L2RjLWh0bWwvIj4KICAgIDxtZXRhIGh0 dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVU Ri04Ij4KICAgIDxtZXRhIG5hbWU9InJvYm90cyIgY29udGVudD0iaW5kZXgsZm9sbG93Ij4K ICAgIDxtZXRhIG5hbWU9ImNyZWF0b3IiIGNvbnRlbnQ9InJmY21hcmt1cCB2ZXJzaW9uIDEu MTA0Ij4KICAgIDxsaW5rIHJlbD0ic2NoZW1hLkRDIiBocmVmPSJodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLyI+CjxtZXRhIG5hbWU9IkRDLlJlbGF0aW9uLlJlcGxhY2VzIiBj b250ZW50PSJkcmFmdC1jaGVuLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UiPgo8bWV0YSBuYW1l PSJEQy5JZGVudGlmaWVyIiBjb250ZW50PSJ1cm46aWV0ZjppZDppZXRmLXY2b3BzLW5hdDY0 LWV4cGVyaWVuY2UiPgo8bWV0YSBuYW1lPSJEQy5EYXRlLklzc3VlZCIgY29udGVudD0iMTk5 OS0wMC0yMCI+CjxtZXRhIG5hbWU9IkRDLkNyZWF0b3IiIGNvbnRlbnQ9IkJpbmV0LCBEYXZp ZCI+CjxtZXRhIG5hbWU9IkRDLkNyZWF0b3IiIGNvbnRlbnQ9IkNoZW4sIEdhbmciPgo8bWV0 YSBuYW1lPSJEQy5DcmVhdG9yIiBjb250ZW50PSJDYW8sIFpoZW4iPgo8bWV0YSBuYW1lPSJE Qy5DcmVhdG9yIiBjb250ZW50PSJYaWUsIENob25nZmVuZyI+CjxtZXRhIG5hbWU9IkRDLkRl c2NyaXB0aW9uLkFic3RyYWN0IiBjb250ZW50PSJUaGlzIGRvY3VtZW50IHN1bW1hcml6ZXMg TkFUNjQgZnVuY3Rpb24gZGVwbG95bWVudCBzY2VuYXJpb3MgYW5kXG5vcGVyYXRpb25hbCBl eHBlcmllbmNlLiBCb3RoIE5BVDY0IENhcnJpZXIgR3JhZGUgTkFUIChOQVQ2NC1DR04pIGFu ZFxuTkFUNjQgc2VydmVyIEZyb250IEVuZCAoTkFUNjQtRkUpIGFyZSBjb25zaWRlcmVkIGlu IHRoaXMgZG9jdW1lbnQuIj4KPG1ldGEgbmFtZT0iREMuVGl0bGUiIGNvbnRlbnQ9Ik5BVDY0 IE9wZXJhdGlvbmFsIEV4cGVyaWVuY2VzIj4KCiAgICA8bGluayByZWw9Imljb24iIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pbWFnZXMvaWQucG5nIiB0eXBlPSJpbWFnZS9wbmci PgogICAgPGxpbmsgcmVsPSJzaG9ydGN1dCBpY29uIiBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaW1hZ2VzL2lkLnBuZyIgdHlwZT0iaW1hZ2UvcG5nIj4KICAgIDx0aXRsZT5kcmFm dC1pZXRmLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UtMDQgLSBOQVQ2NCBPcGVyYXRpb25hbCBF eHBlcmllbmNlczwvdGl0bGU+CiAgICAKICAgIAogICAgPHN0eWxlIHR5cGU9InRleHQvY3Nz Ij4KCWJvZHkgewoJICAgIG1hcmdpbjogMHB4IDhweDsKICAgICAgICAgICAgZm9udC1zaXpl OiAxZW07Cgl9CiAgICAgICAgaDEsIGgyLCBoMywgaDQsIGg1LCBoNiwgLmgxLCAuaDIsIC5o MywgLmg0LCAuaDUsIC5oNiB7CgkgICAgZm9udC13ZWlnaHQ6IGJvbGQ7CiAgICAgICAgICAg IGxpbmUtaGVpZ2h0OiAwcHQ7CiAgICAgICAgICAgIGRpc3BsYXk6IGlubGluZTsKICAgICAg ICAgICAgd2hpdGUtc3BhY2U6IHByZTsKICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbm9z cGFjZTsKICAgICAgICAgICAgZm9udC1zaXplOiAxZW07CgkgICAgZm9udC13ZWlnaHQ6IGJv bGQ7CiAgICAgICAgfQogICAgICAgIHByZSB7CiAgICAgICAgICAgIGZvbnQtc2l6ZTogMWVt OwogICAgICAgICAgICBtYXJnaW4tdG9wOiAwcHg7CiAgICAgICAgICAgIG1hcmdpbi1ib3R0 b206IDBweDsKICAgICAgICB9CgkucHJlIHsKCSAgICB3aGl0ZS1zcGFjZTogcHJlOwoJICAg IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Cgl9CgkuaGVhZGVyewoJICAgIGZvbnQtd2VpZ2h0 OiBib2xkOwoJfQogICAgICAgIC5uZXdwYWdlIHsKICAgICAgICAgICAgcGFnZS1icmVhay1i ZWZvcmU6IGFsd2F5czsKICAgICAgICB9CiAgICAgICAgLmludmlzaWJsZSB7CiAgICAgICAg ICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICAgICAgY29sb3I6IHdoaXRlOwog ICAgICAgIH0KICAgICAgICBhLnNlbGZsaW5rIHsKICAgICAgICAgIGNvbG9yOiBibGFjazsK ICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICB9CiAgICAgICAgQG1l ZGlhIHByaW50IHsKICAgICAgICAgICAgYm9keSB7CiAgICAgICAgICAgICAgICBmb250LWZh bWlseTogbW9ub3NwYWNlOwogICAgICAgICAgICAgICAgZm9udC1zaXplOiAxMC41cHQ7CiAg ICAgICAgICAgIH0KICAgICAgICAgICAgaDEsIGgyLCBoMywgaDQsIGg1LCBoNiB7CiAgICAg ICAgICAgICAgICBmb250LXNpemU6IDFlbTsKICAgICAgICAgICAgfQogICAgICAgIAogICAg ICAgICAgICBhOmxpbmssIGE6dmlzaXRlZCB7CiAgICAgICAgICAgICAgICBjb2xvcjogaW5o ZXJpdDsKICAgICAgICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICAg ICAgfQogICAgICAgICAgICAubm9wcmludCB7CiAgICAgICAgICAgICAgICBkaXNwbGF5OiBu b25lOwogICAgICAgICAgICB9CiAgICAgICAgfQoJQG1lZGlhIHNjcmVlbiB7CgkgICAgLmdy ZXksIC5ncmV5IGE6bGluaywgLmdyZXkgYTp2aXNpdGVkIHsKCQljb2xvcjogIzc3NzsKCSAg ICB9CiAgICAgICAgICAgIC5kb2NpbmZvIHsKICAgICAgICAgICAgICAgIGJhY2tncm91bmQt Y29sb3I6ICNFRUU7CiAgICAgICAgICAgIH0KICAgICAgICAgICAgLnRvcCB7CiAgICAgICAg ICAgICAgICBib3JkZXItdG9wOiA3cHggc29saWQgI0VFRTsKICAgICAgICAgICAgfQogICAg ICAgICAgICAuYmd3aGl0ZSAgeyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgfQogICAgICAg ICAgICAuYmdyZWQgICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRjQ0OyB9CiAgICAgICAgICAg IC5iZ2dyZXkgICB7IGJhY2tncm91bmQtY29sb3I6ICM2NjY7IH0KICAgICAgICAgICAgLmJn YnJvd24gIHsgYmFja2dyb3VuZC1jb2xvcjogIzg0MDsgfSAgICAgICAgICAgIAogICAgICAg ICAgICAuYmdvcmFuZ2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkEwOyB9CiAgICAgICAgICAg IC5iZ3llbGxvdyB7IGJhY2tncm91bmQtY29sb3I6ICNFRTA7IH0KICAgICAgICAgICAgLmJn bWFnZW50YXsgYmFja2dyb3VuZC1jb2xvcjogI0Y0RjsgfQogICAgICAgICAgICAuYmdibHVl ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjNjZGOyB9CiAgICAgICAgICAgIC5iZ2N5YW4gICB7 IGJhY2tncm91bmQtY29sb3I6ICM0REQ7IH0KICAgICAgICAgICAgLmJnZ3JlZW4gIHsgYmFj a2dyb3VuZC1jb2xvcjogIzRGNDsgfQoKICAgICAgICAgICAgLmxlZ2VuZCAgIHsgZm9udC1z aXplOiA5MCU7IH0KICAgICAgICAgICAgLmNwbGF0ZSAgIHsgZm9udC1zaXplOiA3MCU7IGJv cmRlcjogc29saWQgZ3JleSAxcHg7IH0KCX0KICAgIDwvc3R5bGU+CiAgICA8IS0tW2lmIElF XT4KICAgIDxzdHlsZT4KICAgIGJvZHkgewogICAgICAgZm9udC1zaXplOiAxM3B4OwogICAg ICAgbWFyZ2luOiAxMHB4IDEwcHg7CiAgICB9CiAgICA8L3N0eWxlPgogICAgPCFbZW5kaWZd LS0+CgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPjwhLS0KICAgIGZ1bmN0 aW9uIGFkZEhlYWRlclRhZ3MoKSB7Cgl2YXIgc3BhbnMgPSBkb2N1bWVudC5nZXRFbGVtZW50 c0J5VGFnTmFtZSgic3BhbiIpOwoJZm9yICh2YXIgaT0wOyBpIDwgc3BhbnMubGVuZ3RoOyBp KyspIHsKCSAgICB2YXIgZWxlbSA9IHNwYW5zW2ldOwoJICAgIGlmIChlbGVtKSB7CgkJdmFy IGxldmVsID0gZWxlbS5nZXRBdHRyaWJ1dGUoImNsYXNzIik7CiAgICAgICAgICAgICAgICBp ZiAobGV2ZWwgPT0gImgxIiB8fCBsZXZlbCA9PSAiaDIiIHx8IGxldmVsID09ICJoMyIgfHwg bGV2ZWwgPT0gImg0IiB8fCBsZXZlbCA9PSAiaDUiIHx8IGxldmVsID09ICJoNiIpIHsKICAg ICAgICAgICAgICAgICAgICBlbGVtLmlubmVySFRNTCA9ICI8IitsZXZlbCsiPiIrZWxlbS5p bm5lckhUTUwrIjwvIitsZXZlbCsiPiI7CQkKICAgICAgICAgICAgICAgIH0KCSAgICB9Cgl9 CiAgICB9CiAgICB2YXIgbGVnZW5kX2h0bWwgPSAiQ29sb3VyIGxlZ2VuZDo8YnIgLz4gICAg ICA8dGFibGU+ICAgICAgICAgPHRyPjx0ZD5Vbmtub3duOjwvdGQ+ICAgICAgICAgICAgICAg ICAgIDx0ZD48c3BhbiBjbGFzcz0nY3BsYXRlIGJnd2hpdGUnPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzwvc3Bhbj48L3RkPjwvdHI+ICAgICAgICAgPHRyPjx0ZD5EcmFmdDo8L3RkPiAg ICAgICAgICAgICAgICAgICAgIDx0ZD48c3BhbiBjbGFzcz0nY3BsYXRlIGJncmVkJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC90ZD48L3RyPiAgICAgICAgIDx0cj48dGQ+ SW5mb3JtYXRpb25hbDo8L3RkPiAgICAgICAgICAgICA8dGQ+PHNwYW4gY2xhc3M9J2NwbGF0 ZSBiZ29yYW5nZSc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvdGQ+PC90cj4g ICAgICAgICA8dHI+PHRkPkV4cGVyaW1lbnRhbDo8L3RkPiAgICAgICAgICAgICAgPHRkPjxz cGFuIGNsYXNzPSdjcGxhdGUgYmd5ZWxsb3cnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv c3Bhbj48L3RkPjwvdHI+ICAgICAgICAgPHRyPjx0ZD5CZXN0IENvbW1vbiBQcmFjdGljZTo8 L3RkPiAgICAgIDx0ZD48c3BhbiBjbGFzcz0nY3BsYXRlIGJnbWFnZW50YSc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvdGQ+PC90cj4gICAgICAgICA8dHI+PHRkPlByb3Bv c2VkIFN0YW5kYXJkOjwvdGQ+ICAgICAgICAgPHRkPjxzcGFuIGNsYXNzPSdjcGxhdGUgYmdi bHVlJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC90ZD48L3RyPiAgICAgICAg IDx0cj48dGQ+RHJhZnQgU3RhbmRhcmQgKG9sZCBkZXNpZ25hdGlvbik6PC90ZD4gPHRkPjxz cGFuIGNsYXNzPSdjcGxhdGUgYmdjeWFuJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3Nw YW4+PC90ZD48L3RyPiAgICAgICAgIDx0cj48dGQ+SW50ZXJuZXQgU3RhbmRhcmQ6PC90ZD4g ICAgICAgICA8dGQ+PHNwYW4gY2xhc3M9J2NwbGF0ZSBiZ2dyZWVuJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PC90ZD48L3RyPiAgICAgICAgIDx0cj48dGQ+SGlzdG9yaWM6 PC90ZD4gICAgICAgICAgICAgICAgICA8dGQ+PHNwYW4gY2xhc3M9J2NwbGF0ZSBiZ2dyZXkn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3RkPjwvdHI+ICAgICAgICAgPHRy Pjx0ZD5PYnNvbGV0ZTo8L3RkPiAgICAgICAgICAgICAgICAgIDx0ZD48c3BhbiBjbGFzcz0n Y3BsYXRlIGJnYnJvd24nPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3RkPjwv dHI+ICAgICA8L3RhYmxlPiI7CiAgICBmdW5jdGlvbiBzaG93RWxlbShpZCkgewogICAgICAg IHZhciBlbGVtID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoaWQpOwogICAgICAgIGVsZW0u aW5uZXJIVE1MID0gZXZhbChpZCsiX2h0bWwiKTsKICAgICAgICBlbGVtLnN0eWxlLnZpc2li aWxpdHk9J3Zpc2libGUnOwogICAgfQogICAgZnVuY3Rpb24gaGlkZUVsZW0oaWQpIHsKICAg ICAgICB2YXIgZWxlbSA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKGlkKTsKICAgICAgICBl bGVtLnN0eWxlLnZpc2liaWxpdHk9J2hpZGRlbic7ICAgICAgICAKICAgICAgICBlbGVtLmlu bmVySFRNTCA9ICIiOwogICAgfQogICAgLy8gLS0+CiAgICA8L3NjcmlwdD4KPC9oZWFkPgo8 Ym9keSBvbmxvYWQ9ImFkZEhlYWRlclRhZ3MoKSI+CiAgIDxkaXYgc3R5bGU9ImhlaWdodDog MTNweDsiPgogICAgICA8ZGl2IG9ubW91c2VvdmVyPSJ0aGlzLnN0eWxlLmN1cnNvcj0ncG9p bnRlcic7IiBvbmNsaWNrPSJzaG93RWxlbSgnbGVnZW5kJyk7IiBvbm1vdXNlb3V0PSJoaWRl RWxlbSgnbGVnZW5kJykiIHN0eWxlPSJoZWlnaHQ6IDZweDsgcG9zaXRpb246IGFic29sdXRl OyIgY2xhc3M9InByZSBub3ByaW50IGRvY2luZm8gYmdyZWQiIHRpdGxlPSJDbGljayBmb3Ig Y29sb3VyIGxlZ2VuZC4iPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICA8ZGl2IGlk PSJsZWdlbmQiIGNsYXNzPSJkb2NpbmZvIG5vcHJpbnQgcHJlIGxlZ2VuZCIgc3R5bGU9InBv c2l0aW9uOmFic29sdXRlOyB0b3A6IDRweDsgbGVmdDogNGV4OyB2aXNpYmlsaXR5OmhpZGRl bjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IHBhZGRpbmc6IDRweCA5cHggNXB4IDdweDsg Ym9yZGVyOiBzb2xpZCAjMzQ1IDFweDsgIiBvbm1vdXNlb3Zlcj0ic2hvd0VsZW0oJ2xlZ2Vu ZCcpOyIgb25tb3VzZW91dD0iaGlkZUVsZW0oJ2xlZ2VuZCcpOyI+CiAgICAgIDwvZGl2Pgog ICA8L2Rpdj4KPHNwYW4gY2xhc3M9InByZSBub3ByaW50IGRvY2luZm8gdG9wIj5bPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvIiB0aXRsZT0iRG9jdW1lbnQgc2VhcmNo IGFuZCByZXRyaWV2YWwgcGFnZSI+RG9jczwvYT5dIFs8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlLTA0LnR4dCIg dGl0bGU9IlBsYWludGV4dCB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQiPnR4dDwvYT58PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9kcmFmdC1pZXRmLXY2b3BzLW5hdDY0 LWV4cGVyaWVuY2UtMDQudHh0IiB0aXRsZT0iUERGIHZlcnNpb24gb2YgdGhpcyBkb2N1bWVu dCI+cGRmPC9hPl0gWzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZSIgdGl0bGU9IklFU0cgRGF0YXRy YWNrZXIgaW5mb3JtYXRpb24gZm9yIHRoaXMgZG9jdW1lbnQiPlRyYWNrZXI8L2E+XSBbPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3Y2b3BzIiB0aXRsZT0iVGhlIHdvcmtp bmcgZ3JvdXAgaGFuZGxpbmcgdGhpcyBkb2N1bWVudCI+V0c8L2E+XSBbPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZUB0b29scy5pZXRmLm9yZz9z dWJqZWN0PWRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZSUyMCIgdGl0bGU9IlNl bmQgZW1haWwgdG8gdGhlIGRvY3VtZW50IGF1dGhvcnMiPkVtYWlsPC9hPl0gWzxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdkaWZmJmFtcDt1 cmwyPWRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wNC50eHQiIHRpdGxlPSJJ bmxpbmUgZGlmZiAod2RpZmYpIj5EaWZmMTwvYT5dIFs8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5j ZS0wNC50eHQiIHRpdGxlPSJTaWRlLWJ5LXNpZGUgZGlmZiI+RGlmZjI8L2E+XSBbPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkbml0cz91cmw9aHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wNC50eHQiIHRpdGxl PSJSdW4gYW4gaWRuaXRzIGNoZWNrIG9mIHRoaXMgZG9jdW1lbnQiPk5pdHM8L2E+XSAgICAg ICAgICA8L3NwYW4+PGJyPgo8c3BhbiBjbGFzcz0icHJlIG5vcHJpbnQgZG9jaW5mbyI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC9zcGFuPjxicj4KPHNwYW4gY2xhc3M9InByZSBub3ByaW50IGRv Y2luZm8iPlZlcnNpb25zOiAoPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlIiB0aXRsZT0iUHJlY3Vyc29yIj5k cmFmdC1jaGVuLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2U8L2E+KSAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlLTAwIj4wMDwvYT4gPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1l eHBlcmllbmNlLTAxIj4wMTwvYT4gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlLTAyIj4wMjwvYT4gPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1l eHBlcmllbmNlLTAzIj4wMzwvYT4gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlLTA0Ij4wNDwvYT4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PGJyPgo8 c3BhbiBjbGFzcz0icHJlIG5vcHJpbnQgZG9jaW5mbyI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9z cGFuPjxicj4KPHByZT5JbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEcuIENoZW4KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWi4gQ2FvCklu dGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIENoaW5hIE1vYmlsZQpFeHBpcmVzOiBBcHJpbCAxNywgMjAxNCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDLiBYaWUKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGluYSBUZWxlY29t CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBELiBCaW5ldAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGcmFuY2UgVGVsZWNvbS1PcmFuZ2UKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDE0LCAy MDEzCgoKICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9ImgxIj48aDE+TkFUNjQg T3BlcmF0aW9uYWwgRXhwZXJpZW5jZXM8L2gxPjwvc3Bhbj4KICAgICAgICAgICAgICAgICAg PHNwYW4gY2xhc3M9ImgxIj48aDE+ZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1leHBlcmllbmNl LTA0PC9oMT48L3NwYW4+CgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVudCBzdW1tYXJpemVz IE5BVDY0IGZ1bmN0aW9uIGRlcGxveW1lbnQgc2NlbmFyaW9zIGFuZAogICBvcGVyYXRpb25h bCBleHBlcmllbmNlLiAgQm90aCBOQVQ2NCBDYXJyaWVyIEdyYWRlIE5BVCAoTkFUNjQtQ0dO KSBhbmQKICAgTkFUNjQgc2VydmVyIEZyb250IEVuZCAoTkFUNjQtRkUpIGFyZSBjb25zaWRl cmVkIGluIHRoaXMgZG9jdW1lbnQuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIElu dGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhl CiAgIHByb3Zpc2lvbnMgb2YgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv YmNwNzgiPkJDUCA3ODwvYT4gYW5kIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2JjcDc5Ij5CQ1AgNzk8L2E+LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAo SUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3Vy cmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kcmFmdHMvY3VycmVudC88L2E+LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQg d2lsbCBleHBpcmUgb24gQXByaWwgMTcsIDIwMTQuCgpDb3B5cmlnaHQgTm90aWNlCgogICBD b3B5cmlnaHQgKGMpIDIwMTMgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmll ZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgog ICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvYmNwNzgiPkJDUCA3ODwvYT4gYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoPGEgaHJl Zj0iaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvIj5odHRwOi8vdHJ1c3Rl ZS5pZXRmLm9yZy9saWNlbnNlLWluZm88L2E+KSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YK ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2Ug ZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBh bmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29k ZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNs dWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gPGEgaHJl Zj0iI3NlY3Rpb24tNCI+U2VjdGlvbiA0PC9hPi5lIG9mCgoKCjxzcGFuIGNsYXNzPSJncmV5 Ij5DaGVuLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAxNCAgICAg ICAgICAgICAgICAgW1BhZ2UgMV08L3NwYW4+CjwvcHJlPjwhLS1OZXdQYWdlLS0+PHByZSBj bGFzcz0ibmV3cGFnZSI+PGEgbmFtZT0icGFnZS0yIiBpZD0icGFnZS0yIiBocmVmPSIjcGFn ZS0yIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPgo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIE5BVDY0IEV4cGVyaWVuY2VzICAgICAgICAgICAgICAg T2N0b2JlciAyMDEzPC9zcGFuPgoKCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFu ZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgPGEgaHJl Zj0iI3NlY3Rpb24tMSI+MTwvYT4uICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPGEgaHJlZj0iI3BhZ2UtMiI+Mjwv YT4KICAgPGEgaHJlZj0iI3NlY3Rpb24tMiI+MjwvYT4uICBUZXJtaW5vbG9neSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPGEgaHJlZj0i I3BhZ2UtMyI+MzwvYT4KICAgPGEgaHJlZj0iI3NlY3Rpb24tMyI+MzwvYT4uICBOQVQ2NCBO ZXR3b3JraW5nIEV4cGVyaWVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgPGEgaHJlZj0iI3BhZ2UtNCI+NDwvYT4KICAgICA8YSBocmVmPSIjc2VjdGlvbi0zLjEi PjMuMTwvYT4uICBOQVQ2NC1DR04gQ29uc2lkZXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA8YSBocmVmPSIjcGFnZS00Ij40PC9hPgogICAgICAgPGEgaHJl Zj0iI3NlY3Rpb24tMy4xLjEiPjMuMS4xPC9hPi4gIE5BVDY0LUNHTiBVc2FnZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPGEgaHJlZj0iI3BhZ2UtNCI+NDwv YT4KICAgICAgIDxhIGhyZWY9IiNzZWN0aW9uLTMuMS4yIj4zLjEuMjwvYT4uICBETlM2NCBE ZXBsb3ltZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxhIGhy ZWY9IiNwYWdlLTQiPjQ8L2E+CiAgICAgICA8YSBocmVmPSIjc2VjdGlvbi0zLjEuMyI+My4x LjM8L2E+LiAgTkFUNjQgUGxhY2VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA8YSBocmVmPSIjcGFnZS00Ij40PC9hPgogICAgICAgPGEgaHJlZj0iI3Nl Y3Rpb24tMy4xLjQiPjMuMS40PC9hPi4gIENvLWV4aXN0ZW5jZSBvZiBOQVQ2NCBhbmQgTkFU NDQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPGEgaHJlZj0iI3BhZ2UtNSI+NTwvYT4KICAg ICA8YSBocmVmPSIjc2VjdGlvbi0zLjIiPjMuMjwvYT4uICBOQVQ2NC1GRSBDb25zaWRlcmF0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8YSBocmVmPSIjcGFn ZS02Ij42PC9hPgogICA8YSBocmVmPSIjc2VjdGlvbi00Ij40PC9hPi4gIEhpZ2ggQXZhaWxh YmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8 YSBocmVmPSIjcGFnZS03Ij43PC9hPgogICAgIDxhIGhyZWY9IiNzZWN0aW9uLTQuMSI+NC4x PC9hPi4gIFJlZHVuZGFuY3kgRGVzaWduIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDxhIGhyZWY9IiNwYWdlLTciPjc8L2E+CiAgICAgPGEgaHJlZj0iI3Nl Y3Rpb24tNC4yIj40LjI8L2E+LiAgTG9hZCBCYWxhbmNpbmcgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPGEgaHJlZj0iI3BhZ2UtOCI+ODwvYT4KICAg PGEgaHJlZj0iI3NlY3Rpb24tNSI+NTwvYT4uICBTb3VyY2UgQWRkcmVzcyBUcmFuc3BhcmVu Y3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPGEgaHJlZj0iI3BhZ2Ut OSI+OTwvYT4KICAgICA8YSBocmVmPSIjc2VjdGlvbi01LjEiPjUuMTwvYT4uICBUcmFjZWFi aWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8 YSBocmVmPSIjcGFnZS05Ij45PC9hPgogICAgIDxhIGhyZWY9IiNzZWN0aW9uLTUuMiI+NS4y PC9hPi4gIEdlby1sb2NhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgPGEgaHJlZj0iI3BhZ2UtMTAiPjEwPC9hPgogICA8YSBocmVmPSIjc2Vj dGlvbi02Ij42PC9hPi4gIFF1YWxpdHkgb2YgRXhwZXJpZW5jZSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxhIGhyZWY9IiNwYWdlLTEwIj4xMDwvYT4KICAg ICA8YSBocmVmPSIjc2VjdGlvbi02LjEiPjYuMTwvYT4uICBTZXJ2aWNlIFJlYWNoYWJpbGl0 eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxhIGhyZWY9IiNwYWdl LTExIj4xMTwvYT4KICAgICA8YSBocmVmPSIjc2VjdGlvbi02LjIiPjYuMjwvYT4uICBSZXNv dXJjZSBSZXNlcnZhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDxhIGhyZWY9IiNwYWdlLTExIj4xMTwvYT4KICAgPGEgaHJlZj0iI3NlY3Rpb24tNyI+Nzwv YT4uICBNVFUgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA8YSBocmVmPSIjcGFnZS0xMiI+MTI8L2E+CiAgIDxhIGhyZWY9IiNz ZWN0aW9uLTgiPjg8L2E+LiAgVUxBIFVzYWdlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPGEgaHJlZj0iI3BhZ2UtMTIiPjEyPC9hPgog ICA8YSBocmVmPSIjc2VjdGlvbi05Ij45PC9hPi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxhIGhyZWY9IiNwYWdl LTEzIj4xMzwvYT4KICAgPGEgaHJlZj0iI3NlY3Rpb24tMTAiPjEwPC9hPi4gSUFOQSBDb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg PGEgaHJlZj0iI3BhZ2UtMTQiPjE0PC9hPgogICA8YSBocmVmPSIjc2VjdGlvbi0xMSI+MTE8 L2E+LiBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA8YSBocmVmPSIjcGFnZS0xNCI+MTQ8L2E+CiAgIDxhIGhyZWY9IiNz ZWN0aW9uLTEyIj4xMjwvYT4uIEFkZGl0aW9uYWwgQXV0aG9yIExpc3QgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxhIGhyZWY9IiNwYWdlLTE0Ij4xNDwvYT4K ICAgPGEgaHJlZj0iI3NlY3Rpb24tMTMiPjEzPC9hPi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPGEgaHJlZj0iI3Bh Z2UtMTQiPjE0PC9hPgogICAgIDxhIGhyZWY9IiNzZWN0aW9uLTEzLjEiPjEzLjE8L2E+LiAg Tm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDxhIGhyZWY9IiNwYWdlLTE1Ij4xNTwvYT4KICAgICA8YSBocmVmPSIjc2VjdGlvbi0x My4yIj4xMy4yPC9hPi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA8YSBocmVmPSIjcGFnZS0xNiI+MTY8L2E+CiAgIDxhIGhy ZWY9IiNhcHBlbmRpeC1BIj5BcHBlbmRpeCBBPC9hPi4gIFRlc3RpbmcgUmVzdWx0cyBvZiBB cHBsaWNhdGlvbiBCZWhhdmlvciAgLiAuIC4gLiAuIC4gIDxhIGhyZWY9IiNwYWdlLTE4Ij4x ODwvYT4KICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxhIGhyZWY9IiNwYWdlLTE5Ij4xOTwvYT4KCjxzcGFu IGNsYXNzPSJoMiI+PGgyPjxhIGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2VjdGlvbi0xIiBo cmVmPSIjc2VjdGlvbi0xIj4xPC9hPi4gIEludHJvZHVjdGlvbjwvaDI+PC9zcGFuPgoKICAg SVB2NiBpcyB0aGUgb25seSBzdXN0YWluYWJsZSBzb2x1dGlvbiBmb3IgbnVtYmVyaW5nIG5v ZGVzIG9uIEludGVybmV0CiAgIGR1ZSB0byB0aGUgSVB2NCBkZXBsZXRpb24uICBOZXR3b3Jr IG9wZXJhdG9ycyBoYXZlIHRvIGRlcGxveQogICBJUHY2LW9ubHkgbmV0d29ya3MgaW4gb3Jk ZXIgdG8gbWVldCB0aGUgbmVlZHMgb2YgdGhlIGV4cGFuZGluZwogICBpbnRlcm5ldCB3aXRo b3V0IGF2YWlsYWJsZSBJUHY0IGFkZHJlc3Nlcy4KCiAgIFNpbmdsZSBzdGFjayBJUHY2IG5l dHdvcmsgZGVwbG95bWVudCBjYW4gc2ltcGxpZnkgbmV0d29yaydzCiAgIHByb3Zpc2lvbmlu Zy4gIFNvbWUganVzdGlmaWNhdGlvbnMgaGF2ZSBiZWVuIGRlc2NyaWJlZCBpbiA0NjR4bGF0 CiAgIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODc3IiB0aXRs ZT0iJnF1b3Q7NDY0WExBVDogQ29tYmluYXRpb24gb2YgU3RhdGVmdWwgYW5kIFN0YXRlbGVz cyBUcmFuc2xhdGlvbiZxdW90OyI+UkZDNjg3NzwvYT5dLiAgQXMgYW4gZXhhbXBsZSwgSVB2 Ni1vbmx5IGNvbm5lY3Rpdml0eSBjb25mZXJzIHNvbWUKICAgYmVuZWZpdHMgdG8gbW9iaWxl IG9wZXJhdG9ycy4gIEluIHN1Y2ggbW9iaWxlIGNvbnRleHQsIGl0IGVuYWJsZXMgdGhlCiAg IHVzZSBvZiBhIHNpbmdsZSBJUHY2IFBhY2tldCBEYXRhIFByb3RvY29sKFBEUCkgY29udGV4 dCBvciBFdm9sdmVkCiAgIFBhY2tldCBTeXN0ZW0gKEVQUykgYmVhcmVyIGlmIExvbmcgVGVy bSBFdm9sdXRpb24gKExURSkgbmV0d29yayBpcwoKCgo8c3BhbiBjbGFzcz0iZ3JleSI+Q2hl biwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMTQgICAgICAgICAg ICAgICAgIFtQYWdlIDJdPC9zcGFuPgo8L3ByZT48IS0tTmV3UGFnZS0tPjxwcmUgY2xhc3M9 Im5ld3BhZ2UiPjxhIG5hbWU9InBhZ2UtMyIgaWQ9InBhZ2UtMyIgaHJlZj0iI3BhZ2UtMyIg Y2xhc3M9ImludmlzaWJsZSI+IDwvYT4KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBOQVQ2NCBFeHBlcmllbmNlcyAgICAgICAgICAgICAgIE9jdG9i ZXIgMjAxMzwvc3Bhbj4KCgogICBjb25zaWRlcmVkLCB3aGljaCBlbGltaW5hdGVzIHNpZ25p ZmljYW50IG5ldHdvcmsgY29zdHMgY2F1c2VkIGJ5CiAgIGRvdWJsaW5nIHRoZSBudW1iZXIg b2YgUERQIGNvbnRleHRzIGluIHNvbWUgY2FzZXMgYW5kIHRoZSBuZWVkIG9mCiAgIElQdjQg YWRkcmVzc2VzIHRvIGJlIGFzc2lnbmVkIHRvIGN1c3RvbWVycy4gIEluIGJyb2FkYmFuZCBu ZXR3b3JrcwogICBvdmVyYWxsLCBpdCBjYW4gYWxsb3cgZm9yIHRoZSBzY2FsaW5nIG9mIGVk Z2UtbmV0d29yayBncm93dGgKICAgZGVjb3VwbGVkIGZyb20gSVB2NCBudW1iZXJpbmcgbGlt aXRhdGlvbnMuCgogICBJbiBhIHRyYW5zaXRpb24gc2NlbmFyaW8sIHNvbWUgZXhpc3Rpbmcg bmV0d29ya3MgYXJlIGxpa2VseSB0byBiZQogICBJUHY0LW9ubHkgY29uZmlndXJlZCBmb3Ig cXVpdGUgYSBsb25nIHRpbWUuICBJUHY2IG5ldHdvcmtzIGFuZCBob3N0cwogICB3aWxsIG5l ZWQgdG8gY29leGlzdCB3aXRoIElQdjQgbnVtYmVyZWQgcmVzb3VyY2VzLiAgV2lkZXNwcmVh ZCBkdWFsLQogICBzdGFjayBkZXBsb3ltZW50cyBoYXZlIG5vdCBtYXRlcmlhbGl6ZWQgYXQg dGhlIGFudGljaXBhdGVkIHJhdGUgb3ZlcgogICB0aGUgbGFzdCAxMCB5ZWFycywgb25lIHBv c3NpYmxlIGNvbmNsdXNpb24gYmVpbmcgdGhhdCBsZWdhY3kgbmV0d29ya3MKICAgd2lsbCBu b3QgbWFrZSB0aGUganVtcCBxdWlja2x5LiAgVGhlIEludGVybmV0IHdpbGwgaW5jbHVkZSBu b2RlcyB0aGF0CiAgIGFyZSBkdWFsLXN0YWNrLCBub2RlcyB0aGF0IHJlbWFpbiBJUHY0LW9u bHksIGFuZCBub2RlcyB0aGF0IGNhbiBiZQogICBkZXBsb3llZCBhcyBJUHY2LW9ubHkgbm9k ZXMuICBBIHRyYW5zbGF0aW9uIG1lY2hhbmlzbSBiYXNlZCBvbiBhCiAgIE5BVDY0W1JGQzYx NDZdIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTQ1IiB0aXRs ZT0iJnF1b3Q7SVAvSUNNUCBUcmFuc2xhdGlvbiBBbGdvcml0aG0mcXVvdDsiPlJGQzYxNDU8 L2E+XWZ1bmN0aW9uIGlzIGxpa2VseSB0byBiZSBhIGtleSBlbGVtZW50IG9mIHRoZQogICBJ bnRlcm5ldCBmb3IgSVB2Ni1JUHY0IGludGVyb3BlcmFiaWxpdHkuCgogICBbPGEgbmFtZT0i cmVmLVJGQzYwMzYiIGlkPSJyZWYtUkZDNjAzNiI+UkZDNjAzNjwvYT5dIHJlcG9ydHMgYXQg bGVhc3QgMzAlIG9mIG9wZXJhdG9ycyBwbGFuIHRvIHJ1biBzb21lIGtpbmQgb2YKICAgdHJh bnNsYXRvciAocHJlc3VtYWJseSBOQVQ2NC9ETlM2NCkuICBBZHZpY2Ugb24gTkFUNjQgZGVw bG95bWVudCBhbmQKICAgb3BlcmF0aW9ucyBhcmUgdGhlcmVmb3JlIG9mIHNvbWUgaW1wb3J0 YW5jZS4gIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTg2IiB0 aXRsZT0iJnF1b3Q7RXhwZXJpZW5jZXMgZnJvbSBhbiBJUHY2LU9ubHkgTmV0d29yayZxdW90 OyI+UkZDNjU4NjwvYT5dIGRvY3VtZW50cyB0aGUKICAgaW1wbGljYXRpb25zIGZvciBJUHY2 IG9ubHkgbmV0d29ya3MuICBUaGlzIGRvY3VtZW50IGludGVuZHMgdG8gYmUKICAgc3BlY2lm aWMgdG8gTkFUNjQgbmV0d29yayBwbGFubmluZy4KCjxzcGFuIGNsYXNzPSJoMiI+PGgyPjxh IGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2VjdGlvbi0yIiBocmVmPSIjc2VjdGlvbi0yIj4y PC9hPi4gIFRlcm1pbm9sb2d5PC9oMj48L3NwYW4+CgogICBJbiByZWdhcmRzIHRvIElQdjQv SVB2NiB0cmFuc2xhdGlvbiwgWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzYxNDQiIHRpdGxlPSImcXVvdDtGcmFtZXdvcmsgZm9yIElQdjQvSVB2NiBUcmFuc2xh dGlvbiZxdW90OyI+UkZDNjE0NDwvYT5dIGhhcyBkZXNjcmliZWQgYQogICBmcmFtZXdvcmsg b2YgZW5hYmxpbmcgbmV0d29ya3MgdG8gbWFrZSBpbnRlcndvcmtpbmcgcG9zc2libGUgYmV0 d2VlbgogICBJUHY0IGFuZCBJUHY2IG5ldHdvcmtzLiAgVGhpcyBkb2N1bWVudCBoYXMgZnVy dGhlciBjYXRlZ29yaXplZAogICBkaWZmZXJlbnQgTkFUNjQgZnVuY3Rpb24gbG9jYXRpb25z IGFuZCB1c2UgY2FzZXMuICBUaGUgcHJpbmNpcGxlCiAgIGRpc3RpbmN0aW9uIG9mIGxvY2F0 aW9uIGlzIGlmIHRoZSBOQVQ2NCBpcyBsb2NhdGVkIGluIGEgQ2FycmllciBHcmFkZQogICBO QVQgb3Igc2VydmVyIEZyb250IEVuZC4gVGhlIHRlcm1zIG9mIE5BVC1DR04vRkUgYXJlIHVu ZGVyc3Rvb2QgdG8gYmUKICAgYSB0b3BvbG9naWNhbCBkaXN0aW5jdGlvbiBpbmRpY2F0aW5n IGRpZmZlcmVudCBmZWF0dXJlcyBlbXBsb3llZCBpbiBhCiAgIE5BVDY0IGRlcGxveW1lbnQu CgogICBOQVQ2NC1DR046ICBBIE5BVDY0LUNHTiBpcyBwbGFjZWQgaW4gYW4gSVNQIG5ldHdv cmsuICBJUHY2CiAgICAgIHN1YnNjcmliZXJzIGxldmVyYWdlIHRoZSBOQVQ2NC1DR04gdG8g YWNjZXNzIGV4aXN0aW5nIElQdjQKICAgICAgaW50ZXJuZXQgc2VydmljZXMuICBUaGUgSVNQ IGFzIGFuIGFkbWluaXN0cmF0aXZlIGVudGl0eSB0YWtlcyBmdWxsCiAgICAgIGNvbnRyb2wg b24gdGhlIElQdjYgc2lkZSwgYnV0IGhhcyBsaW1pdGVkIG9yIG5vIGNvbnRyb2wgb24gdGhl CiAgICAgIElQdjQgc2lkZS4gIE5BVDY0LUNHTiBtYXkgaGF2ZSB0byBjb25zaWRlciB0aGUg SVB2NCBJbnRlcm5ldAogICAgICBlbnZpcm9ubWVudCBhbmQgc2VydmljZXMgdG8gbWFrZSBh cHByb3ByaWF0ZSBjb25maWd1cmF0aW9ucy4KCiAgIE5BVDY0LUZFOiAgQSBOQVQ2NC1GRSBp cyBnZW5lcmFsbHkgYSBkZXZpY2Ugd2l0aCBOQVQ2NCBmdW5jdGlvbmFsaXR5CiAgICAgIGlu IGEgY29udGVudCBwcm92aWRlciBvciBkYXRhIGNlbnRlciBuZXR3b3JrLiAgSXQgY291bGQg YmUgZm9yCiAgICAgIGV4YW1wbGUgYSB0cmFmZmljIGxvYWQgYmFsYW5jZXIgb3IgYSBmaXJl d2FsbC4gIFRoZSBvcGVyYXRvciBvZgogICAgICB0aGUgTkFUNjQtRkUgaGFzIGZ1bGwgY29u dHJvbCBvdmVyIHRoZSBJUHY0IG5ldHdvcmsgd2l0aGluIHRoZQogICAgICBkYXRhIGNlbnRl ciwgYnV0IG9ubHkgbGltaXRlZCBpbmZsdWVuY2Ugb3IgY29udHJvbCBvdmVyIHRoZQogICAg ICBleHRlcm5hbCBJUHY2IG5ldHdvcmsuCgoKCgo8c3BhbiBjbGFzcz0iZ3JleSI+Q2hlbiwg ZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMTQgICAgICAgICAgICAg ICAgIFtQYWdlIDNdPC9zcGFuPgo8L3ByZT48IS0tTmV3UGFnZS0tPjxwcmUgY2xhc3M9Im5l d3BhZ2UiPjxhIG5hbWU9InBhZ2UtNCIgaWQ9InBhZ2UtNCIgaHJlZj0iI3BhZ2UtNCIgY2xh c3M9ImludmlzaWJsZSI+IDwvYT4KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBOQVQ2NCBFeHBlcmllbmNlcyAgICAgICAgICAgICAgIE9jdG9iZXIg MjAxMzwvc3Bhbj4KCgo8c3BhbiBjbGFzcz0iaDIiPjxoMj48YSBjbGFzcz0ic2VsZmxpbmsi IG5hbWU9InNlY3Rpb24tMyIgaHJlZj0iI3NlY3Rpb24tMyI+MzwvYT4uICBOQVQ2NCBOZXR3 b3JraW5nIEV4cGVyaWVuY2VzPC9oMj48L3NwYW4+Cgo8c3BhbiBjbGFzcz0iaDMiPjxoMz48 YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMy4xIiBocmVmPSIjc2VjdGlvbi0z LjEiPjMuMTwvYT4uICBOQVQ2NC1DR04gQ29uc2lkZXJhdGlvbjwvaDM+PC9zcGFuPgoKPHNw YW4gY2xhc3M9Img0Ij48aDQ+PGEgY2xhc3M9InNlbGZsaW5rIiBuYW1lPSJzZWN0aW9uLTMu MS4xIiBocmVmPSIjc2VjdGlvbi0zLjEuMSI+My4xLjE8L2E+LiAgTkFUNjQtQ0dOIFVzYWdl czwvaDQ+PC9zcGFuPgoKICAgRml4ZWQgbmV0d29yayBvcGVyYXRvcnMgYW5kIG1vYmlsZSBv cGVyYXRvcnMgbWF5IGxvY2F0ZSBOQVQ2NCBpbgogICBhY2Nlc3MgbmV0d29ya3Mgb3IgaW4g bW9iaWxlIGNvcmUgbmV0d29ya3MuICBJdCBjYW4gYmUgYnVpbHQgaW50bwogICB2YXJpb3Vz IGRldmljZXMsIGluY2x1ZGluZyByb3V0ZXJzLCBnYXRld2F5cyBvciBmaXJld2FsbHMgaW4g b3JkZXIgdG8KICAgY29ubmVjdCBJUHY2IHVzZXJzIHRvIHRoZSBJUHY0IEludGVybmV0LiAg V2l0aCByZWdhcmQgdG8gdGhlIG51bWJlcnMKICAgb2YgdXNlcnMgYW5kIHRoZSBzaG9ydGFn ZSBvZiBwdWJsaWMgSVB2NCBhZGRyZXNzZXMsIHN0YXRlZnVsCiAgIE5BVDY0W1JGQzYxNDZd IGlzIG1vcmUgYWRhcHRlZCB0byBwZXJmb3JtIHNvbWUgbWF4aW1hbCBzaGFyaW5nIG9mCiAg IHB1YmxpYyBJUHY0IGFkZHJlc3Nlcy4gIFRoZSB1c2FnZSBvZiBzdGF0ZWxlc3MgTkFUNjQg Y2FuIGJlIHNlZW4gd2l0aAogICBiZXR0ZXIgdHJhbnNwYXJlbmN5IGZlYXR1cmVzCiAgIFs8 YSBocmVmPSIjcmVmLUktRC5pZXRmLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlv biI+SS1ELmlldGYtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uPC9hPl0sIHdo aWxlIGl0IGhhcyB0byBiZQogICBjb29yZGluYXRlZCB3aXRoIEErUFtSRkM2MzQ2XSBwcm9j ZXNzZXMgYXMgc3BlY2lmaWVkIGluCiAgIFs8YSBocmVmPSIjcmVmLUktRC5pZXRmLXNvZnR3 aXJlLW1hcC10Ij5JLUQuaWV0Zi1zb2Z0d2lyZS1tYXAtdDwvYT5dYW5kIFs8YSBocmVmPSIj cmVmLUktRC5pZXRmLXNvZnR3aXJlLTRyZCI+SS1ELmlldGYtc29mdHdpcmUtNHJkPC9hPl0g aW4gb3JkZXIgdG8gY29wZQogICB3aXRoIElQdjQgc2hvcnRhZ2UuCgo8c3BhbiBjbGFzcz0i aDQiPjxoND48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMy4xLjIiIGhyZWY9 IiNzZWN0aW9uLTMuMS4yIj4zLjEuMjwvYT4uICBETlM2NCBEZXBsb3ltZW50PC9oND48L3Nw YW4+CgogICBETlM2NFtSRkM2MTQ3XSBpcyByZWNvbW1lbmRlZCBmb3IgdXNlIGluIGNvbWJp bmF0aW9uIHdpdGggc3RhdGVmdWwKICAgTkFUNjQsIGFuZCB3aWxsIGxpa2VseSBiZSBhbiBl c3NlbnRpYWwgcGFydCBvZiBhbiBJUHY2IHNpbmdsZS1zdGFjawogICBuZXR3b3JrIHRoYXQg Y291cGxlcyB0byB0aGUgSVB2NCBJbnRlcm5ldC4gNDY0eGxhdFtSRkM2ODc3XSBpcwogICBw cm9wb3NlZCB0byBlbmFibGUgYWNjZXNzIG9mIElQdjQgb25seSBhcHBsaWNhdGlvbnMgb3Ig YXBwbGljYXRpb25zCiAgIHRoYXQgY2FsbCBJUHY0IGxpdGVyYWwgYWRkcmVzc2VzLiAgVXNp bmcgRE5TNjQgd2lsbCBoZWxwIDQ2NHhsYXQgdG8KICAgYXV0b21hdGljYWxseSBkaXNjb3Zl ciBOQVQ2NCBwcmVmaXggdGhyb3VnaAogICBbPGEgaHJlZj0iI3JlZi1JLUQuaWV0Zi1iZWhh dmUtbmF0NjQtZGlzY292ZXJ5LWhldXJpc3RpYyI+SS1ELmlldGYtYmVoYXZlLW5hdDY0LWRp c2NvdmVyeS1oZXVyaXN0aWM8L2E+XS4gIEJlcmtlbGV5IEludGVybmV0IE5hbWUKICAgRGFl bW9uIChCSU5EKSBzb2Z0d2FyZSBzdXBwb3J0cyB0aGUgZnVuY3Rpb24uICBJdCdzIGltcG9y dGFudCB0byBub3RlCiAgIHRoYXQgRE5TNjQgZ2VuZXJhdGVzIHRoZSBzeW50aGV0aWMgQUFB QSByZXBseSB3aGVuIHNlcnZpY2VzIG9ubHkKICAgcmVnaXN0ZXIgQSByZWNvcmRzLiAgT3Bl cmF0b3JzIHNob3VsZCBub3QgZXhwZWN0IHRvIGFjY2VzcyBJUHY0IHBhcnRzCiAgIG9mIGEg ZHVhbC1zdGFjayBzZXJ2ZXIgdXNpbmcgTkFUNjQvRE5TNjQuICBUaGUgdHJhZmZpYyBpcyBm b3J3YXJkZWQKICAgb24gSVB2NiBwYXRocyBpZiBkdWFsLXN0YWNrIHNlcnZlcnMgYXJlIHRh cmdldGVkLiAgSVB2NiB0cmFmZmljIG1heQogICBiZSByb3V0ZWQgbm90IGdvaW5nIHRocm91 Z2ggTkFUNjQuICBPbmx5IHRoZSB0cmFmZmljIGdvaW5nIHRvCiAgIElQdjQtb25seSBzZXJ2 aWNlIHdvdWxkIHRyYXZlcnNlIE5BVDY0LiAgSW4gc29tZSBzZW5zZSwgaXQgZW5jb3VyYWdl cwogICBJUHY2IHRyYW5zbWlzc2lvbiBhbmQgcmVzdHJhaW5zIE5BVCB1c2VzIGNvbXBhcmVk IHRvIE5BVDQ0KGlmIHVzZWQpLAogICBvbiB3aGljaCBhbGwgdHJhZmZpYyBmbG93cyBoYXZl IHRvIGJlIHRyYXZlcnNlZCBhbmQgdHJhbnNsYXRlZC4gIEluCiAgIHNvbWUgY2FzZXMsIE5B VDY0LUNHTiBtYXkgc2VydmUgZG91YmxlIHJvbGVzLCBpLmUuIGEgdHJhbnNsYXRvciBhbmQK ICAgSVB2NiBmb3J3YXJkZXIuICBTb21lIGZhaWx1cmUgY2FzZXMgbWF5IGJlIG9jY3VycmVk IG9uY2UgTkFUNjQgc2VydmVzCiAgIGEgSVB2NiBnYXRld2F5IHdoaWxlIGlzIGNvbmZpZ3Vy ZWQgb25seSB3aXRoIElQdjQgb24gV0FOIGxpbmtzLiAgV2UKICAgdGVzdGVkIG9uIFRvcDEw MCB3ZWJzaXRlcyAocmVmZXJyaW5nIHRvIFs8YSBocmVmPSIjcmVmLUFsZXhhIiB0aXRsZT0i JnF1b3Q7aHR0cDovL3d3dy5hbGV4YS5jb20vdG9wc2l0ZXMmcXVvdDsiPkFsZXhhPC9hPl0g c3RhdGlzdGljcykgaW4gc3VjaAogICBjb25kaXRpb24uIDQzJSBvZiB3ZWJzaXRlcyBhcmUg ZmFpbGVkIHRvIGJlIGNvbm5lY3RlZCBzaW5jZSB0aG9zZQogICB3ZWJzaXRlcyBoYXZlIGJv dGggQUFBQSBhbmQgQSByZWNvcmRzLiAgVGhlcmVmb3JlLCBpdCdzIHJlY29tbWVuZGVkCiAg IHRvIGVuYWJsZSBOQVQ2NCBXQU4gbGlua3Mgd2l0aCBkdWFsLXN0YWNrIGNvbm5lY3Rpb25z IGluIHN1Y2ggY2FzZS4KCjxzcGFuIGNsYXNzPSJoNCI+PGg0PjxhIGNsYXNzPSJzZWxmbGlu ayIgbmFtZT0ic2VjdGlvbi0zLjEuMyIgaHJlZj0iI3NlY3Rpb24tMy4xLjMiPjMuMS4zPC9h Pi4gIE5BVDY0IFBsYWNlbWVudDwvaDQ+PC9zcGFuPgoKCgoKCjxzcGFuIGNsYXNzPSJncmV5 Ij5DaGVuLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAxNCAgICAg ICAgICAgICAgICAgW1BhZ2UgNF08L3NwYW4+CjwvcHJlPjwhLS1OZXdQYWdlLS0+PHByZSBj bGFzcz0ibmV3cGFnZSI+PGEgbmFtZT0icGFnZS01IiBpZD0icGFnZS01IiBocmVmPSIjcGFn ZS01IiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPgo8c3BhbiBjbGFzcz0iZ3JleSI+SW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIE5BVDY0IEV4cGVyaWVuY2VzICAgICAgICAgICAgICAg T2N0b2JlciAyMDEzPC9zcGFuPgoKCiAgIEFsbCBjb25uZWN0aW9ucyB0byBJUHY0IHNlcnZp Y2VzIGZyb20gSVB2Ni1vbmx5IGNsaWVudHMgbXVzdCB0cmF2ZXJzZQogICB0aGUgTkFUNjQt Q0dOLiAgSXQgY2FuIGJlIGFkdmFudGFnZW91cyBmcm9tIHRoZSB2YW50YWdlLXBvaW50IG9m CiAgIHRyb3VibGVzaG9vdGluZyBhbmQgdHJhZmZpYyBlbmdpbmVlcmluZyB0byBjYXJyeSB0 aGUgSVB2NiB0cmFmZmljCiAgIG5hdGl2ZWx5IGZvciBhcyBsb25nIGFzIHBvc3NpYmxlIHdp dGhpbiBhbiBhY2Nlc3MgbmV0d29yayBhbmQKICAgdHJhbnNsYXRlIHBhY2tldHMgb25seSBh dCBvciBuZWFyIHRoZSBuZXR3b3JrIGVncmVzcy4gIE5BVDY0IGNhbiBiZQogICBjb25zaWRl cmVkIGFzIGEgZmVhdHVyZSBvZiB0aGUgQXV0b25vbW91cyBTeXN0ZW0gKEFTKSBib3JkZXIg aW4gZml4ZWQKICAgbmV0d29ya3MuICBBbmQsIGl0IGlzIGxpa2VseSB0byBiZSBkZXBsb3ll ZCBpbiBhbiBJUCBub2RlIGJleW9uZCB0aGUKICAgR2F0ZXdheSBHUFJTIFN1cHBvcnQgTm9k ZSAoR0dTTikgb3IgUHVibGljIERhdGEgTmV0d29yay0gR2F0ZXdheQogICAoUEROLUdXKSBp biBtb2JpbGUgbmV0d29ya3Mgb3IgZGlyZWN0bHkgaW4gdGhlIGdhdGV3YXkgaXRzZWxmIGlu IHNvbWUKICAgc2l0dWF0aW9ucy4gIFRoaXMgYWxsb3dzIGNvbnNpc3RlbnQgYXR0cmlidXRp b24gYW5kIHRyYWNlYWJpbGl0eQogICB3aXRoaW4gdGhlIHNlcnZpY2UgcHJvdmlkZXIgbmV0 d29yay4gIEl0IGhhcyBiZWVuIG9ic2VydmVkIHRoYXQgdGhlCiAgIHByb2Nlc3Mgb2YgY29y cmVsYXRpbmcgbG9nIGluZm9ybWF0aW9uIGlzIHByb2JsZW1hdGljIGZyb20gbXVsdGlwbGUt CiAgIHZlbmRvcidzIGVxdWlwbWVudCBkdWUgdG8gaW5jb25zaXN0ZW50IGZvcm1hdHMgb2Yg bG9nIHJlY29yZHMuCiAgIFBsYWNpbmcgTkFUNjQgaW4gYSBjZW50cmFsaXplZCBsb2NhdGlv biBtYXkgcmVkdWNlIGRpdmVyc2l0eSBvZiBsb2cKICAgZm9ybWF0IGFuZCBzaW1wbGlmeSB0 aGUgbmV0d29yayBwcm92aXNpb25pbmcuICBNb3Jlb3Zlciwgc2luY2UgTkFUNjQKICAgaXMg b25seSB0YXJnZXRlZCBhdCBzZXJ2aW5nIHRyYWZmaWMgZmxvd3MgZnJvbSBJUHY2IHRvIElQ djQtb25seQogICBzZXJ2aWNlcywgdGhlIHVzZXIgdHJhZmZpYyB2b2x1bWUgc2hvdWxkIG5v dCBiZSBhcyBoaWdoIGFzIGluIGEgTkFUNDQKICAgc2NlbmFyaW8sIGFuZCB0aGVyZWZvcmUs IHRoZSBnYXRld2F5J3MgY2FwYWNpdHkgaW4gc3VjaCBsb2NhdGlvbiBtYXkKICAgbm90IGJl IGFzIG11Y2ggb2YgYSBjb25jZXJuIG9yIGEgaHVyZGxlIHRvIGRlcGxveW1lbnQuICBPbiB0 aGUgb3RoZXIKICAgaGFuZCwgdGhlIHBsYWNlbWVudCBpbiBhIGNlbnRyYWxpemVkIHdheSB3 b3VsZCByZXF1aXJlIG1vcmUgc3RyaWN0CiAgIGhpZ2ggYXZhaWxhYmlsaXR5IChIQSkgZGVz aWduLiAgSXQgd291bGQgYWxzbyBtYWtlIGdlby1sb2NhdGlvbiBiYXNlZAogICBvbiBJUHY0 IGFkZHJlc3NlcyByYXRoZXIgaW5hY2N1cmF0ZSBhcyBpdCBpcyBjdXJyZW50bHkgdGhlIGNh c2UgZm9yCiAgIE5BVDQ0IENHTiBhbHJlYWR5IGRlcGxveWVkIGluIElTUCBuZXR3b3Jrcy4g IE1vcmUgY29uc2lkZXJhdGlvbnMgb3IKICAgd29ya2Fyb3VuZHMgb24gSEEgYW5kIHRyYWNl YWJpbGl0eSBjb3VsZCBiZSBmb3VuZCBhdCA8YSBocmVmPSIjc2VjdGlvbi00Ij5TZWN0aW9u IDQ8L2E+IGFuZAogICA8YSBocmVmPSIjc2VjdGlvbi01Ij5TZWN0aW9uIDU8L2E+LgoKPHNw YW4gY2xhc3M9Img0Ij48aDQ+PGEgY2xhc3M9InNlbGZsaW5rIiBuYW1lPSJzZWN0aW9uLTMu MS40IiBocmVmPSIjc2VjdGlvbi0zLjEuNCI+My4xLjQ8L2E+LiAgQ28tZXhpc3RlbmNlIG9m IE5BVDY0IGFuZCBOQVQ0NDwvaDQ+PC9zcGFuPgoKICAgTkFUNjQgY291bGQgbGlrZWx5IGNv LWV4aXN0IHdpdGggTkFUNDQgaW4gYSBkdWFsLXN0YWNrIG5ldHdvcmsgbW9zdGx5CiAgIGJl Y2F1c2UgSVB2NCBwcml2YXRlIGFkZHJlc3NlcyBhcmUgYWxsb2NhdGVkIHRvIGN1c3RvbWVy cy4gIFRoZQogICBjb2V4aXN0ZW5jZSBoYXMgYWxyZWFkeSBhcHBlYXJlZCBpbiBtb2JpbGUg bmV0d29ya3MsIGluIHdoaWNoIGR1YWwKICAgc3RhY2sgbW9iaWxlIHBob25lcyBub3JtYWxs eSBpbml0aWF0ZSBzb21lIGR1YWwtc3RhY2sgUEROL1BEUAogICBUeXBlW1JGQzY0NTldIHRv IHF1ZXJ5IGJvdGggSVB2NC9JUHY2IGFkZHJlc3MgYW5kIElQdjQgYWxsb2NhdGVkCiAgIGFk ZHJlc3NlcyBhcmUgdmVyeSBvZnRlbiBwcml2YXRlIG9uZXMuICBbPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjcyNCIgdGl0bGU9IiZxdW90O0RlZmF1bHQgQWRk cmVzcyBTZWxlY3Rpb24gZm9yIEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNiAoSVB2Nikm cXVvdDsiPlJGQzY3MjQ8L2E+XSBhbHdheXMgcHJpb3JpdGl6ZXMKICAgSVB2NiBjb25uZWN0 aW9ucyByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIGVuZC10by1lbmQgcGF0aCBpcyBuYXRp dmUKICAgSVB2NiBvciBJUHY2IHRyYW5zbGF0ZWQgdG8gSVB2NCB2aWEgTkFUNjQvRE5TNjQu ICBDb252ZXJzZWx5LCBIYXBweQogICBFeWViYWxsc1tSRkM2NTU1XSB3aWxsIGRpcmVjdCBz b21lIElQIGZsb3dzIGFjcm9zcyBJUHY0IHBhdGhzLiAgVGhlCiAgIHNlbGVjdGlvbiBvZiBJ UHY0L0lQdjYgcGF0aHMgbWF5IGRlcGVuZCBvbiBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9u CiAgIGNob2ljZXMgb3Igc2V0dGluZ3Mgb24gYSBob3N0LWJ5LWhvc3QgYmFzaXMsIGFuZCBt YXkgZGlmZmVyIGZyb20gYW4KICAgb3BlcmF0b3IncyBkZXRlcm1pbmlzdGljIHNjaGVtZS4g IE91ciB0ZXN0cyB2ZXJpZmllZCB0aGF0IGhvc3RzIG1heQogICBmaW5kIHRoZW1zZWx2ZXMg c3dpdGNoaW5nIGJldHdlZW4gSVB2NCBhbmQgSVB2NiBwYXRocyBhcyB0aGV5IGFjY2Vzcwog ICBpZGVudGljYWwgc2VydmljZSwgYnV0IGF0IGRpZmZlcmVudCB0aW1lcwogICBbPGEgaHJl Zj0iI3JlZi1JLUQua2FsaXdvZGEtc3Vuc2V0NC1kdWFsLWlwdjYtY29leGlzdCI+SS1ELmth bGl3b2RhLXN1bnNldDQtZHVhbC1pcHY2LWNvZXhpc3Q8L2E+XS4gIFNpbmNlIHRoZSB0b3Bv bG9neSBvbiBlYWNoCiAgIHBhdGggaXMgZGlmZmVyZW50LCBpdCBtYXkgY2F1c2UgdW5zdGFi bGUgdXNlciBleHBlcmllbmNlcyBhbmQgc29tZQogICBkZWdyYWRhdGlvbiBvZiBRdWFsaXR5 IG9mIEV4cGVyaWVuY2UgKFFvRSkgd2hlbiBmYWxsYmFjayB0byB0aGUgb3RoZXIKICAgcHJv dG9jb2wgaXMgbm90IHBvd2VyZnVsIGVub3VnaCBmb3IgZXhhbXBsZS4gIEl0J3MgYWxzbyBk aWZmaWN1bHQgZm9yCiAgIG9wZXJhdG9ycyB0byBkZWJ1ZyB0aGUgaXNzdWUgYW5kIG1ha2Ug b3B0aW1hbCByZXNvdXJjZSB1c2FnZXMgb24gYm90aAogICBOQVQ0NCBhbmQgTkFUNjQuICBJ dCdzIGRlc2lyYWJsZSB0byBmaW5kIHRoZSBzb2x1dGlvbnMgdGhhdCB3aWxsCgoKCjxzcGFu IGNsYXNzPSJncmV5Ij5DaGVuLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAx NywgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgNV08L3NwYW4+CjwvcHJlPjwhLS1OZXdQ YWdlLS0+PHByZSBjbGFzcz0ibmV3cGFnZSI+PGEgbmFtZT0icGFnZS02IiBpZD0icGFnZS02 IiBocmVmPSIjcGFnZS02IiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPgo8c3BhbiBjbGFzcz0i Z3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIE5BVDY0IEV4cGVyaWVuY2VzICAg ICAgICAgICAgICAgT2N0b2JlciAyMDEzPC9zcGFuPgoKCiAgIGFsbG93IGludHJvZHVjaW5n IElQdjYvSVB2NCB0cmFuc2xhdGlvbiBzZXJ2aWNlIHRvIElQdjYtb25seSBob3N0cwogICB3 aGlsZSBrZWVwaW5nIGR1YWwtc3RhY2sgaG9zdHMgdW5hZmZlY3RlZCBhbmQgSVB2NCBzZXJ2 aWNlIHVuY2hhbmdlZC4KCjxzcGFuIGNsYXNzPSJoMyI+PGgzPjxhIGNsYXNzPSJzZWxmbGlu ayIgbmFtZT0ic2VjdGlvbi0zLjIiIGhyZWY9IiNzZWN0aW9uLTMuMiI+My4yPC9hPi4gIE5B VDY0LUZFIENvbnNpZGVyYXRpb248L2gzPjwvc3Bhbj4KCiAgIFNvbWUgSW50ZXJuZXQgQ29u dGVudCBQcm92aWRlcnMgKElDUHMpIG1heSBsb2NhdGUgTkFUNjQgaW4gZnJvbnQgb2YKICAg YW4gSW50ZXJuZXQgRGF0YSBDZW50ZXIgKElEQyksIGZvciBleGFtcGxlIGNvLWxvY2F0ZWQg d2l0aCBsb2FkCiAgIGJhbGFuY2luZyBmdW5jdGlvbi4gIExvYWQgYmFsYW5jZXJzIGFyZSBl bXBsb3llZCB0byBjb25uZWN0IGRpZmZlcmVudAogICBJUCBmYW1pbHkgZG9tYWlucywgbWVh bndoaWxlIGRpc3RyaWJ1dGUgd29ya2xvYWRzIGFjcm9zcyBtdWx0aXBsZQogICBkb21haW5z IG9yIGludGVybmFsIHNlcnZlcnMgYWN0dWFsbHkuICBJbiBzb21lIGNhc2VzLCBJUHY0IGFk ZHJlc3NlcwogICBleGhhdXN0aW9uIG1heSBub3QgYmUgYSBwcm9ibGVtIGluIHNvbWUgSURD J3MgbmV0d29ya3MuICBJUHY2IHN1cHBvcnQKICAgZm9yIHNvbWUgYXBwbGljYXRpb25zIG1h eSByZXF1aXJlIHNvbWUgaW52ZXN0bWVudHMgYW5kIHdvcmtsb2FkcyBzbwogICBJUHY2IHN1 cHBvcnQgbWF5IG5vdCBiZSBhIHByaW9yaXR5LiAgVGhlIHVzZSBvZiBOQVQ2NCBtYXkgYmUg c2VydmVkCiAgIHRvIHN1cHBvcnQgd2lkZXNwcmVhZCBJUHY2IGFkb3B0aW9uIG9uIHRoZSBJ bnRlcm5ldCB3aGlsZSBtYWludGFpbmluZwogICBJUHY0LW9ubHkgYXBwbGljYXRpb25zIGFj Y2Vzcy4KCiAgIERpZmZlcmVudCBzdHJhdGVneSBoYXMgYmVlbiBkZXNjcmliZWQgaW4gWzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4ODMiIHRpdGxlPSImcXVv dDtJUHY2IEd1aWRhbmNlIGZvciBJbnRlcm5ldCBDb250ZW50IFByb3ZpZGVycyBhbmQgQXBw bGljYXRpb24gU2VydmljZSBQcm92aWRlcnMmcXVvdDsiPlJGQzY4ODM8L2E+XXJlZmVycmVk IHRvIGFzCiAgICJpbnNpZGUgb3V0IiBhbmQgIm91dHNpZGUgaW4iLiAgQW4gSURDIG9wZXJh dG9yIG1heSBpbXBsZW1lbnQgdGhlCiAgIGZvbGxvd2luZyBwcmFjdGljZXMgaW4gdGhlIE5B VDY0LUZFIG5ldHdvcmtpbmcuCgogICBvICBTb21lIElDUHMgd2hvIGFscmVhZHkgaGF2ZSBz YXRpc2ZhY3Rvcnkgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZXMKICAgICAgd291bGQgYWRvcHQg c2luZ2xlIHN0YWNrIElQdjYgb3BlcmF0aW9ucyB0byBidWlsZCB1cCB0aGVpciBkYXRhCiAg ICAgIGNlbnRlciBuZXR3b3JrLCBzZXJ2ZXJzIGFuZCBhcHBsaWNhdGlvbnMgc2luY2UgaXQg YWxsb3dzIG5ldwogICAgICBzZXJ2aWNlcyBkZWxpdmVyeSB3aXRob3V0IGhhdmluZyB0byBp bnRlZ3JhdGUgY29uc2lkZXJhdGlvbiBvZgogICAgICBJUHY0IE5BVCBhbmQgYWRkcmVzcyBs aW1pdGF0aW9ucyBvZiBJUHY0IG5ldHdvcmtzLiAgU3RhdGVsZXNzCiAgICAgIE5BVDY0W1JG QzYxNDVdaXMgdXNlZCB0byBwcm92aWRlIHNlcnZpY2VzIGZvciBJUHY0LW9ubHkKICAgICAg c3Vic2NyaWJlcnMuICBbPGEgaHJlZj0iI3JlZi1JLUQuYW5kZXJzb24tc2lpdC1kYyI+SS1E LmFuZGVyc29uLXNpaXQtZGM8L2E+XWhhcyBwcm92aWRlZCBmdXJ0aGVyCiAgICAgIGRlc2Ny aXB0aW9ucyBhbmQgZ3VpZGVsaW5lcy4KCiAgIG8gIElDUHMgd2hvIGF0dGVtcHQgdG8gb2Zm ZXIgY3VzdG9tZXJzIElQdjYgc3VwcG9ydCBpbiB0aGVpcgogICAgICBhcHBsaWNhdGlvbiBm YXJtcyBhdCBhbiBlYXJseSBzdGFnZSBtYXkgbGlrZWx5IHJ1biBzb21lIHByb3hpZXMsCiAg ICAgIHdoaWNoIGFyZSBjb25maWd1cmVkIHRvIGhhbmRsZSBpbmNvbWluZyBJUHY2IGZsb3dz IGFuZCBwcm94eSB0aGVtCiAgICAgIHRvIElQdjQgYmFjay1lbmQgc3lzdGVtcy4gIE1hbnkg bG9hZCBiYWxhbmNlcnMgaGF2ZSBhbHJlYWR5CiAgICAgIGludGVncmF0ZWQgc29tZSBwcm94 eSBmdW5jdGlvbmFsaXR5LiAgSVB2NCBhZGRyZXNzZXMgY29uZmlndXJlZCBpbgogICAgICB0 aGUgcHJveHkgY2FuIGJlIG11bHRpcGxleGVkIGxpa2UgYSBzdGF0ZWZ1bCBOQVQ2NCBwZXJm b3Jtcy4gIEEKICAgICAgc2ltaWxhciBjaGFsbGVuZ2UgZXhpc3RzIG9uY2UgaW5jcmVhc2lu Z2x5IG51bWVyb3VzIHVzZXJzIGluIElQdjYKICAgICAgSW50ZXJuZXQgYWNjZXNzIGFuIElQ djQgbmV0d29yay4gIEhpZ2ggbG9hZHMgb24gbG9hZC1iYWxhbmNlcnMgbWF5CiAgICAgIGJl IGFwdCB0byBjYXVzZSBhZGRpdGlvbmFsIGxhdGVuY3ksIElQdjQgcG9vbCBleGhhdXN0aW9u LCBldGMuCiAgICAgIFRoZXJlZm9yZSwgdGhpcyBhcHByb2FjaCBpcyBvbmx5IHJlYXNvbmFi bGUgYXQgYW4gZWFybHkgc3RhZ2UuCiAgICAgIElDUHMgbWF5IGxlYXJuIGZyb20gdGhlIGV4 cGVyaWVuY2VzIGFuZCBtb3ZlIG9uIHRvIGR1YWwtc3RhY2sgb3IKICAgICAgSVB2NiBzaW5n bGUgc3RhY2sgaW4gYSBmdXJ0aGVyIHN0YWdlLCBzaW5jZSB0aGUgbmF0aXZlIElQdjYgaXMK ICAgICAgYWx3YXlzIG1vcmUgZGVzaXJhYmxlIHRoYW4gdHJhbnNpdGlvbiBzb2x1dGlvbnMu CgogICBbPGEgbmFtZT0icmVmLVJGQzYxNDQiIGlkPSJyZWYtUkZDNjE0NCI+UkZDNjE0NDwv YT5dIHJlY29tbWVuZHMgdGhhdCBBQUFBIHJlY29yZHMgb2YgbG9hZC1iYWxhbmNlcnMgb3IK ICAgYXBwbGljYXRpb24gc2VydmVycyBjYW4gYmUgZGlyZWN0bHkgcmVnaXN0ZXJlZCBpbiB0 aGUgYXV0aG9yaXRhdGl2ZQogICBETlMgc2VydmVycyByZXF1aXJpbmcgdG8gcG9wdWxhdGUg dGhlc2Ugc2VydmVycyB3aXRoIGNvcnJlc3BvbmRpbmcKICAgQUFBQSByZWNvcmRzLiAgSW4g dGhpcyBjYXNlLCB0aGVyZSBpcyBubyBuZWVkIHRvIGRlcGxveSBETlM2NAogICBzZXJ2ZXJz LiAgVGhvc2UgQUFBQSByZWNvcmRzIGNhbiBiZSBzb21lIG5hdGl2ZSBJUHY2IGFkZHJlc3Nl cyBvcgoKCgo8c3BhbiBjbGFzcz0iZ3JleSI+Q2hlbiwgZXQgYWwuICAgICAgICAgICAgIEV4 cGlyZXMgQXByaWwgMTcsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDZdPC9zcGFuPgo8 L3ByZT48IS0tTmV3UGFnZS0tPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxhIG5hbWU9InBhZ2Ut NyIgaWQ9InBhZ2UtNyIgaHJlZj0iI3BhZ2UtNyIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4K PHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBOQVQ2NCBF eHBlcmllbmNlcyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxMzwvc3Bhbj4KCgogICBzb21l IElQdjQtY29udmVydGVkIElQdjYgYWRkcmVzc2VzW1JGQzYwNTJdLiAgVGhlIHR5cGUgb2Yg SVB2NgogICBhZGRyZXNzIGRvZXMgbm90IGdpdmUgdGhlIHBvc3NpYmlsaXR5IHRvIG5vZGVz IHRvIGdldCBhbnkgaW5mb3JtYXRpb24KICAgYWJvdXQgTkFUNjQgcHJlc2VuY2Ugb24gY29t bXVuaWNhdGlvbiBwYXRoIGFuZCB0aGUgcG9zc2liaWxpdHkgdG8KICAgcHJlZmVyIElQdjQg cGF0aCBvciB0aGUgSVB2NiBwYXRoIGluIGR1YWwtc3RhY2sgbmV0d29ya3MuICBVc2luZyBh bgogICBpbmRlcGVuZGVudCBzdWIgZG9tYWluIGUuZy4gaXB2NmV4cC54eHgueHh4IG1heSBo ZWxwIHRvIGlkZW50aWZ5CiAgIGV4cGVyaW1lbnRhbCBpcHY2IHNlcnZpY2VzIHRvIHVzZXJz LiAgSG93IHRvIGRlc2lnbiB0aGUgRlFETiBmb3IgdGhlCiAgIElQdjYgc2VydmljZSBpcyBv dXQtb2Ytc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCjxzcGFuIGNsYXNzPSJoMiI+PGgyPjxh IGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2VjdGlvbi00IiBocmVmPSIjc2VjdGlvbi00Ij40 PC9hPi4gIEhpZ2ggQXZhaWxhYmlsaXR5PC9oMj48L3NwYW4+Cgo8c3BhbiBjbGFzcz0iaDMi PjxoMz48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tNC4xIiBocmVmPSIjc2Vj dGlvbi00LjEiPjQuMTwvYT4uICBSZWR1bmRhbmN5IERlc2lnbjwvaDM+PC9zcGFuPgoKICAg SGlnaCBBdmFpbGFiaWxpdHkgKEhBKSBpcyBhIG1ham9yIHJlcXVpcmVtZW50IGZvciBldmVy eSBzZXJ2aWNlIGFuZAogICBuZXR3b3JrIHNlcnZpY2VzLiAgVGhlIGRlcGxveW1lbnQgb2Yg cmVkdW5kYW5jeSBtZWNoYW5pc20gaXMgYW4KICAgZXNzZW50aWFsIGFwcHJvYWNoIHRvIGF2 b2lkIHNpbmdsZS1wb2ludCBmYWlsdXJlIGFuZCBzaWduaWZpY2FudGx5CiAgIGluY3JlYXNl IHRoZSBuZXR3b3JrIHJlbGlhYmlsaXR5LiAgSXQncyBub3Qgb25seSB1c2VmdWwgdG8gc3Rh dGVmdWwKICAgTkFUNjQgY2FzZXMsIGJ1dCBhbHNvIHRvIHN0YXRlbGVzcyBOQVQ2NCBnYXRl d2F5cy4KCiAgIFRocmVlIHJlZHVuZGFuY3kgbW9kZXMgYXJlIG1haW5seSB1c2VkIGhlcmVh ZnRlcjogY29sZCBzdGFuZGJ5LCB3YXJtCiAgIHN0YW5kYnkgYW5kIGhvdCBzdGFuZGJ5LgoK ICAgbyAgQ29sZCBzdGFuZGJ5IGNhbid0IHJlcGxpY2F0ZSB0aGUgTkFUNjQgc3RhdGVzIGZy b20gdGhlIHByaW1hcnkKICAgICAgZXF1aXBtZW50IHRvIHRoZSBiYWNrdXAuICBBZG1pbmlz dHJhdG9ycyBzd2l0Y2ggb24gdGhlIGJhY2t1cAogICAgICBOQVQ2NCBvbmx5IGlmIHRoZSBw cmltYXJ5IE5BVDY0IGZhaWxzLiAgQXMgdGhlIHJlc3VsdHMsIGFsbCB0aGUKICAgICAgZXhp c3RpbmcgZXN0YWJsaXNoZWQgc2Vzc2lvbnMgd2lsbCBiZSBkaXNjb25uZWN0ZWQuICBUaGUg aW50ZXJuYWwKICAgICAgaG9zdHMgYXJlIHJlcXVpcmVkIHRvIHJlLWVzdGFibGlzaCBzZXNz aW9ucyB0byB0aGUgZXh0ZXJuYWwgaG9zdHMuCiAgICAgIFNpbmNlIHRoZSBiYWNrdXAgTkFU NjQgaXMgbWFudWFsbHkgY29uZmlndXJlZCB0byBzd2l0Y2ggb3ZlciB0bwogICAgICBhY3Rp dmUgTkFUNjQsIGl0IG1heSBoYXZlIHVucHJlZGljdGFibGUgaW1wYWN0cyB0byB0aGUgb25n b2luZwogICAgICBzZXJ2aWNlcy4gIE5vcm1hbGx5LCB0aGUgaGFuZG92ZXIgd291bGQgdGFr ZSBzZXZlcmFsIG1pbnV0ZXMgc28gYXMKICAgICAgdG8gd2FpdCBmb3IgdGhlIHdob2xlIHBy b2Nlc3Mgb2YgTkFUNjQgYm9vdHN0cmFwIGxvYWRlci4KCiAgIG8gIFdhcm0gc3RhbmRieSBp cyBhIGZsYXZvciBvZiB0aGUgY29sZCBzdGFuZGJ5IG1vZGUuICBCYWNrdXAgTkFUNjQKICAg ICAgd291bGQga2VlcCBydW5uaW5nIG9uY2UgdGhlIHByaW1hcnkgTkFUNjQgaXMgd29ya2lu Zy4gIFRoaXMgbWFrZXMKICAgICAgd2FybSBzdGFuZGJ5IGxlc3MgdGltZSBjb25zdW1pbmcg ZHVyaW5nIHRoZSB0cmFmZmljIGZhaWxvdmVyLgogICAgICBWaXJ0dWFsIFJvdXRlciBSZWR1 bmRhbmN5IFByb3RvY29sIChWUlJQKVs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1Nzk4IiB0aXRsZT0iJnF1b3Q7VmlydHVhbCBSb3V0ZXIgUmVkdW5kYW5jeSBQ cm90b2NvbCAoVlJSUCkgVmVyc2lvbiAzIGZvciBJUHY0IGFuZCBJUHY2JnF1b3Q7Ij5SRkM1 Nzk4PC9hPl0gY2FuIGJlIGEKICAgICAgc29sdXRpb24gdG8gZW5hYmxlIGF1dG9tYXRpYyBo YW5kb3ZlciBpbiB0aGUgd2FybSBzdGFuZGJ5LiAgSXQgd2FzCiAgICAgIHRlc3RlZCB0aGF0 IHRoZSBoYW5kb3ZlciB0YWtlcyBhcyBtYXhpbXVtIGFzIDEgbWludXRlIGlmIHRoZQogICAg ICBiYWNrdXAgTkFUNjQgbmVlZHMgdG8gdGFrZSBvdmVyIHJvdXRpbmcgYW5kIHJlLWNvbnN0 cnVjdCB0aGUKICAgICAgQmluZGluZyBJbmZvcm1hdGlvbiBCYXNlcyAoQklCcykgZm9yIDMw IG1pbGxpb24gc2Vzc2lvbnMuICBJbgogICAgICBkZXBsb3ltZW50IHBoYXNlLCBvcGVyYXRv cnMgY291bGQgYmFsYW5jZSBsb2FkcyBvbiBkaXN0aW5jdCBOQVQ2NHMKICAgICAgZGV2aWNl cy4gIFRob3NlIE5BVDY0cyBtYWtlIGEgd2FybSBiYWNrdXAgb2YgZWFjaCBvdGhlci4KCiAg IG8gIEhvdCBzdGFuZGJ5IG11c3Qgc3luY2hyb25pemUgdGhlIEJJQnMgYmV0d2VlbiB0aGUg cHJpbWFyeSBOQVQ2NAogICAgICBhbmQgYmFja3VwLiAgV2hlbiB0aGUgcHJpbWFyeSBOQVQ2 NCBmYWlscywgYmFja3VwIE5BVDY0IHdvdWxkIHRha2UKICAgICAgb3ZlciBhbmQgbWFpbnRh aW4gdGhlIHN0YXRlIG9mIGFsbCBleGlzdGluZyBzZXNzaW9ucy4gIFRoZQogICAgICBpbnRl cm5hbCBob3N0cyBkb24ndCBoYXZlIHRvIHJlLWNvbm5lY3QgdGhlIGV4dGVybmFsIGhvc3Rz LiAgVGhlCiAgICAgIGhhbmRvdmVyIHRpbWUgaGFzIGJlZW4gZXh0cmVtZWx5IHJlZHVjZWQu ICBUaGFua3MgdG8gQmlkaXJlY3Rpb25hbAogICAgICBGb3J3YXJkaW5nIERldGVjdGlvbiAo QkZEKSBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCIgdGl0 bGU9IiZxdW90O0JpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkmcXVv dDsiPlJGQzU4ODA8L2E+XSBjb21iaW5pbmcgd2l0aCBWUlJQLCBhIGRlbGF5CgoKCjxzcGFu IGNsYXNzPSJncmV5Ij5DaGVuLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAx NywgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgN108L3NwYW4+CjwvcHJlPjwhLS1OZXdQ YWdlLS0+PHByZSBjbGFzcz0ibmV3cGFnZSI+PGEgbmFtZT0icGFnZS04IiBpZD0icGFnZS04 IiBocmVmPSIjcGFnZS04IiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPgo8c3BhbiBjbGFzcz0i Z3JleSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIE5BVDY0IEV4cGVyaWVuY2VzICAg ICAgICAgICAgICAgT2N0b2JlciAyMDEzPC9zcGFuPgoKCiAgICAgIG9mIG9ubHkgMzVtcyBm b3IgMzAgbWlsbGlvbiBzZXNzaW9ucyBoYW5kb3ZlciB3YXMgb2JzZXJ2ZWQgZHVyaW5nCiAg ICAgIHRlc3RpbmcuICBJbiBzb21lIHNlbnNlLCBpdCBjb3VsZCBndWFyYW50ZWUgdGhlIHNl c3Npb24gY29udGludWl0eQogICAgICBmb3IgZXZlcnkgc2VydmljZS4gIEluIG9yZGVyIHRv IHRpbWVseSB0cmFuc21pdCBzdGF0ZXMKICAgICAgaW5mb3JtYXRpb24sIG9wZXJhdG9ycyBt YXkgaGF2ZSB0byBkZXBsb3kgZXh0cmEgdHJhbnNwb3J0IGxpbmtzCiAgICAgIGJldHdlZW4g cHJpbWFyeSBOQVQ2NCBhbmQgZGlzdGFudCBiYWNrdXAuCgogICBJbiBnZW5lcmFsLCBjb2xk LXN0YW5kYnkgYW5kIHdhcm0tc3RhbmRieSBpcyBzaW1wbGVyIGFuZCBsZXNzCiAgIHJlc291 cmNlIGludGVuc2l2ZSwgYnV0IGl0IHJlcXVpcmVzIGNsaWVudHMgdG8gcmUtZXN0YWJsaXNo IHNlc3Npb25zCiAgIHdoZW4gYSBmYWlsLW92ZXIgb2NjdXJzLiAgSG90IHN0YW5kYnkgZG91 YmxlcyByZXNvdXJjZSdzIGNvbnN1bXB0aW9uCiAgIHRvIHN5bmNocm9uaXplIHRoZSBzdGF0 ZXMsIGJ1dCBpdCBhY2hpZXZlIHNlYW1sZXNzIGhhbmRvdmVyLiAgVGhlCiAgIGNvbnNpZGVy YXRpb24gb2YgcmVkdW5kYW5jeSBtb2RlIGZvciBzdGF0ZWxlc3MgTkFUNjQgaXMgc2ltcGxl LAogICBiZWNhdXNlIGl0IGRvZXNuJ3QgaGF2ZSB0byBjb25zaWRlciB0aW1lIGNvbnN1bWlu ZyBmb3Igc3RhdGVzCiAgIG1haW50ZW5hbmNlLiAgVGhlIHdhcm0gc3RhbmRieSBpcyBzdWZm aWNpZW50IGZvciBzdGF0ZWxlc3MgTkFUNjQuICBJbgogICByZWdhcmRzIHRvIHN0YXRlZnVs IE5BVDY0LCBpdCBtYXliZSB1c2VmdWwgdG8gaW52ZXN0aWdhdGUgcGVyZm9ybWFuY2UKICAg dG9sZXJhbmNlIG9mIGFwcGxpY2F0aW9ucyBhbmQgdGhlIHRyYWZmaWMgY2hhcmFjdGVyaXN0 aWNzIGluIGEKICAgcGFydGljdWxhciBuZXR3b3JrLiAgU29tZSB0ZXN0aW5nIHJlc3VsdHMg YXJlIHNob3duIGluIHRoZQogICA8YSBocmVmPSIjYXBwZW5kaXgtQSI+QXBwZW5kaXggQTwv YT4uCgogICBPdXIgc3RhdGlzdGljcyBpbiBhIG1vYmlsZSBuZXR3b3JrIHNob3duIHRoYXQg YWxtb3N0IDkxLjIxJSBvZiBhbW91bnQKICAgb2YgdHJhZmZpYyBpcyBhY2NvdW50ZWQgYnkg YnJvd3Npbmcgc2VydmljZXMuICBUaG9zZSBzZXJ2aWNlcyBkb24ndAogICByZXF1aXJlIHNl c3Npb24gY29udGludWl0eS4gIFRoZSBoYW5kb3ZlciB0aW1lIG9mIHdhcm0gc3RhbmRieSBp cwogICBxdWFsaWZpZWQgdG8gdGhlIGRlbGF5IHRvbGVyYW5jZS4gIEhvdC1zdGFuZGJ5IGRv ZXMgbm90IG9mZmVyIG11Y2gKICAgYmVuZWZpdCBmb3IgdGhvc2Ugc2Vzc2lvbnMgb24gdGhp cyBwb2ludC4gIEluIGEgZml4ZWQgbmV0d29yaywgSFRUUAogICBzdHJlYW1pbmcsIHAycCBh bmQgb25saW5lIGdhbWVzIHdvdWxkIGJlIHRoZSBtYWpvcgogICB0cmFmZmljW0Npc2NvLVZO SV0uICBDb25zaWRlcmF0aW9uIHNob3VsZCBiZSBnaXZlbiB0byB0aGUgaW1wb3J0YW5jZQog ICBvZiBtYWludGFpbmluZyBiaW5kaW5ncyBmb3IgdGhvc2Ugc2Vzc2lvbnMgYWNyb3NzIGZh aWxvdmVyLgogICBPcGVyYXRvcnMgbWF5IGFsc28gY29uc2lkZXIgdGhlIEF2ZXJhZ2UgUmV2 ZW51ZSBQZXIgVXNlciAoQVJQVSkKICAgZmFjdG9ycyB0byBkZXBsb3kgc3VpdGFibGUgcmVk dW5kYW5jeSBtb2RlLiAgV2FybSBzdGFuZGJ5IG1heSBzdGlsbAogICBiZSBhZG9wdGVkIHRv IGNvdmVyIG1vc3Qgc2VydmljZXMgd2hpbGUgaG90IHN0YW5kYnkgY291bGQgYmUgdXNlZCB0 bwogICB1cGdyYWRlIFF1YWxpdHkgb2YgRXhwZXJpZW5jZSAoUW9FKSB1c2luZyBETlM2NCB3 aXRoIGRpZmZlcmVudAogICBzeW50aGV0aWMgcmVzcG9uc2VzIGZvciBsaW1pdGVkIHRyYWZm aWMuICBGdXJ0aGVyIGNvbnNpZGVyYXRpb25zIGFyZQogICBkaXNjdXNzZWQgYXQgPGEgaHJl Zj0iI3NlY3Rpb24tNiI+U2VjdGlvbiA2PC9hPi4KCjxzcGFuIGNsYXNzPSJoMyI+PGgzPjxh IGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2VjdGlvbi00LjIiIGhyZWY9IiNzZWN0aW9uLTQu MiI+NC4yPC9hPi4gIExvYWQgQmFsYW5jaW5nPC9oMz48L3NwYW4+CgogICBMb2FkIGJhbGFu Y2luZyBpcyB1c2VkIHRvIGFjY29tcGFueSByZWR1bmRhbmN5IGRlc2lnbiBzbyB0aGF0IGJl dHRlcgogICBzY2FsYWJpbGl0eSBhbmQgcmVzaWxpZW5jeSBjb3VsZCBiZSBhY2hpZXZlZC4g IFN0YXRlbGVzcyBOQVQ2NHMgYWxsb3cKICAgYXN5bW1ldHJpYyByb3V0aW5nIHdoaWxlIGFu eWNhc3QtYmFzZWQgc29sdXRpb25zIGFyZSByZWNvbW1lbmRlZCBpbgogICBbPGEgaHJlZj0i I3JlZi1JLUQuaWV0Zi1zb2Z0d2lyZS1tYXAtZGVwbG95bWVudCI+SS1ELmlldGYtc29mdHdp cmUtbWFwLWRlcGxveW1lbnQ8L2E+XS4gIFRoZSBkZXBsb3ltZW50IG9mIGxvYWQgYmFsYW5j aW5nCiAgIG1heSBtYWtlIG1vcmUgc2Vuc2UgdG8gc3RhdGVmdWwgTkFUNjRzIGZvciB0aGUg c2FrZSBvZiBzaW5nbGUtcG9pbnQKICAgZmFpbHVyZSBhdm9pZGFuY2UuICBTaW5jZSB0aGUg TkFUNjQtQ0dOIGFuZCBOQVQ2NC1GRSBoYXZlIGRpc3RpbmN0CiAgIGZhY2lsaXRpZXMsIHRo ZSBmb2xsb3dpbmcgbGlzdHMgdGhlIGNvbnNpZGVyYXRpb25zIGZvciBlYWNoIGNhc2UuCgog ICBvICBOQVQ2NC1DR04gZXF1aXBtZW50IGRvZXNuJ3QgaW1wbGVtZW50IGxvYWQgYmFsYW5j ZXIgZnVuY3Rpb25zIG9uIGEKICAgICAgYm9hcmQgY2FyZC4gIFRoZXJlZm9yZSwgdGhlIGdh dGV3YXlzIGhhdmUgdG8gcmVzb3J0IHRvIEROUzY0IG9yCiAgICAgIGludGVybmFsIGhvc3Qn cyBiZWhhdmlvci4gIE9uY2UgRE5TNjQgaXMgZGVwbG95ZWQsIHRoZSBsb2FkCiAgICAgIGJh bGFuY2luZyBjYW4gYmUgcGVyZm9ybWVkIGJ5IHN5bnRoZXNpemluZyBBQUFBIHJlc3BvbnNl IHdpdGgKICAgICAgZGlmZmVyZW50IElQdjYgcHJlZml4ZXMuICBGb3IgdGhlIGFwcGxpY2F0 aW9ucyBub3QgcmVxdWlyaW5nIEROUwoKCgo8c3BhbiBjbGFzcz0iZ3JleSI+Q2hlbiwgZXQg YWwuICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMTQgICAgICAgICAgICAgICAg IFtQYWdlIDhdPC9zcGFuPgo8L3ByZT48IS0tTmV3UGFnZS0tPjxwcmUgY2xhc3M9Im5ld3Bh Z2UiPjxhIG5hbWU9InBhZ2UtOSIgaWQ9InBhZ2UtOSIgaHJlZj0iI3BhZ2UtOSIgY2xhc3M9 ImludmlzaWJsZSI+IDwvYT4KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBOQVQ2NCBFeHBlcmllbmNlcyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAx Mzwvc3Bhbj4KCgogICAgICByZXNvbHZlciwgaW50ZXJuYWwgaG9zdHMgY291bGQgbGVhcm4g bXVsdGlwbGUgSVB2NiBwcmVmaXhlcwogICAgICB0aHJvdWdoIHRoZSBhcHByb2FjaGVzIGRl ZmluZWQKICAgICAgaW5bSS1ELmlldGYtYmVoYXZlLW5hdDY0LWRpc2NvdmVyeS1oZXVyaXN0 aWNdIGFuZCB0aGVuIHNlbGVjdCBvbmUKICAgICAgYmFzZWQgb24gYSBnaXZlbiBwcmVmaXgg c2VsZWN0aW9uIHBvbGljeS4KCiAgIG8gIEEgZGVkaWNhdGVkIExvYWQgQmFsYW5jZXIgY291 bGQgYmUgZGVwbG95ZWQgYXQgZnJvbnQgb2YgYSBOQVQ2NC1GRQogICAgICBmYXJtLiAgTG9h ZCBCYWxhbmNlciB1c2VzIHByb3h5IG1vZGUgdG8gcmVkaXJlY3QgdGhlIGZsb3dzIHRvIHRo ZQogICAgICBhcHByb3ByaWF0ZSBOQVQ2NCBpbnN0YW5jZS4gIFN0YXRlZnVsIE5BVDY0cyBy ZXF1aXJlIGEKICAgICAgZGV0ZXJtaW5pc3RpYyBwYXR0ZXJuIHRvIGFycmFuZ2UgdGhlIHRy YWZmaWMgaW4gb3JkZXIgdG8gZW5zdXJlCiAgICAgIG91dGJvdW5kL2luYm91bmQgZmxvd3Mg dHJhdmVyc2UgdGhlIGlkZW50aWNhbCBOQVQ2NC4gIFRoZXJlZm9yZSwKICAgICAgc3RhdGlj IHNjaGVkdWxpbmcgYWxnb3JpdGhtcywgZm9yIGV4YW1wbGUgc291cmNlLWFkZHJlc3MgYmFz ZWQKICAgICAgcG9saWN5LCBpcyBwcmVmZXJyZWQuICBBIGR5bmFtaWMgYWxnb3JpdGhtLCBm b3IgZXhhbXBsZSBSb3VuZC0KICAgICAgUm9iaW4sIG1heSBoYXZlIGltcGFjdHMgb24gYXBw bGljYXRpb25zIHNlZWtpbmcgc2Vzc2lvbgogICAgICBjb250aW51aXR5LCB3aGljaCBkZXNj cmliZWQgaW4gdGhlIFRhYmxlIDEuCgo8c3BhbiBjbGFzcz0iaDIiPjxoMj48YSBjbGFzcz0i c2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tNSIgaHJlZj0iI3NlY3Rpb24tNSI+NTwvYT4uICBT b3VyY2UgQWRkcmVzcyBUcmFuc3BhcmVuY3k8L2gyPjwvc3Bhbj4KCjxzcGFuIGNsYXNzPSJo MyI+PGgzPjxhIGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2VjdGlvbi01LjEiIGhyZWY9IiNz ZWN0aW9uLTUuMSI+NS4xPC9hPi4gIFRyYWNlYWJpbGl0eTwvaDM+PC9zcGFuPgoKICAgVHJh Y2VhYmlsaXR5IGlzIHJlcXVpcmVkIGluIG1hbnkgY2FzZXMgc3VjaCBhcyBpZGVudGlmeWlu ZyBtYWxpY2lvdXMKICAgYXR0YWNrcyBzb3VyY2VzIGFuZCBhY2NvdW50aW5nIHJlcXVpcmVt ZW50cy4gIE9wZXJhdG9ycyBhcmUgYXNrZWQgdG8KICAgcmVjb3JkIHRoZSBOQVQ2NCBsb2cg aW5mb3JtYXRpb24gZm9yIHNwZWNpZmljIHBlcmlvZHMgb2YgdGltZS4gIEluCiAgIG91ciBs YWIgdGVzdGluZywgdGhlIGxvZyBpbmZvcm1hdGlvbiBmcm9tIDIwMCwwMDAgc3Vic2NyaWJl cnMgaGF2ZQogICBiZWVuIGNvbGxlY3RlZCBmcm9tIGEgc3RhdGVmdWwgTkFUNjQgZ2F0ZXdh eSBmb3IgNjAgZGF5cy4KICAgU3lzbG9nW1JGQzU0MjRdIGhhcyBiZWVuIGFkb3B0ZWQgdG8g dHJhbnNtaXQgbG9nIG1lc3NhZ2UgZnJvbSBOQVQ2NAogICB0byBhIGxvZyBzdGF0aW9uLiAg RWFjaCBsb2cgbWVzc2FnZSBjb250YWlucyB0cmFuc3BvcnQgcHJvdG9jb2wsCiAgIHNvdXJj ZSBJUHY2IGFkZHJlc3M6cG9ydCwgdHJhbnNsYXRlZCBJUHY0IGFkZHJlc3M6IHBvcnQgYW5k CiAgIHRpbWVzdGFtcC4gIEl0IHRha2VzIGFsbW9zdCAxMjUgYnl0ZXMgbG9uZyBpbiBBU0NJ SSBmb3JtYXQuICBJdCBoYXMKICAgYmVlbiB2ZXJpZmllZCB0aGF0IHRoZSB2b2x1bWUgb2Yg cmVjb3JkZWQgaW5mb3JtYXRpb24gcmVhY2ggdXAgdG8KICAgNDIuNSB0ZXJhYnl0ZXMgaW4g dGhlIHJhdyBmb3JtYXQgYW5kIDI5LjA3IHRlcmFieXRlcyBpbiBhIGNvbXBhY3QKICAgZm9y bWF0LiAgT3BlcmF0b3JzIGhhdmUgdG8gYnVpbGQgdXAgZGVkaWNhdGVkIHRyYW5zcG9ydCBs aW5rcywKICAgc3RvcmFnZSBzeXN0ZW0gYW5kIHNlcnZlcnMgZm9yIHRoZSBwdXJwb3NlLiAg VGhlcmUgYXJlIGFsc28gc2V2ZXJhbAogICBpbXBsZW1lbnRhdGlvbnMgdG8gbWl0aWdhdGUg dGhlIGlzc3VlLiAgRm9yIGV4YW1wbGUsIHN0YXRlZnVsIE5BVDY0CiAgIGNvdWxkIGNvbmZp Z3VyZSB3aXRoIGJ1bGsgcG9ydCBhbGxvY2F0aW9uIG1ldGhvZC4gIE9uY2UgYSBzdWJzY3Jp YmVyCiAgIGNyZWF0ZXMgdGhlIGZpcnN0IHNlc3Npb24sIGEgbnVtYmVyIG9mIHBvcnRzIGFy ZSBwcmUtYWxsb2NhdGVkLiAgQQogICBidWxrIGFsbG9jYXRpb24gbWVzc2FnZSBpcyBsb2dn ZWQgaW5kaWNhdGluZyB0aGlzIGFsbG9jYXRpb24uCiAgIFN1YnNlcXVlbnQgc2Vzc2lvbiBj cmVhdGlvbnMgd2lsbCB1c2Ugb25lIG9mIHRoZSBwcmUtYWxsb2NhdGVkIHBvcnQKICAgYW5k IGhlbmNlIGRvZXMgbm90IHJlcXVpcmUgbG9nZ2luZy4gIFRoZSBsb2cgdm9sdW1lIGluIHRo aXMgY2FzZSBtYXkKICAgYmUgb25seSBvbmUgdGhvdXNhbmR0aCBvZiBkeW5hbWljIHBvcnQg YWxsb2NhdGlvbi4gIFNvbWUKICAgaW1wbGVtZW50YXRpb25zIG1heSBhZG9wdCBzdGF0aWMg cG9ydC1yYW5nZSBhbGxvY2F0aW9ucwogICBbPGEgaHJlZj0iI3JlZi1JLUQuZG9ubGV5LWJl aGF2ZS1kZXRlcm1pbmlzdGljLWNnbiI+SS1ELmRvbmxleS1iZWhhdmUtZGV0ZXJtaW5pc3Rp Yy1jZ248L2E+XSB3aGljaCBlbGltaW5hdGVzIHRoZSBuZWVkIGZvcgogICBwZXItc3Vic2Ny aWJlciBsb2dnaW5nLiAgQXMgYSBzaWRlIGVmZmVjdCwgdGhlIElQdjQgbXVsdGlwbGV4aW5n CiAgIGVmZmljaWVuY3kgaXMgZGVjcmVhc2VkIHJlZ2FyZGluZyB0byB0aG9zZSBtZXRob2Rz LiAgRm9yIGV4YW1wbGUsIHRoZQogICB1dGlsaXphdGlvbiByYXRpbyBvZiBwdWJsaWMgSVB2 NCBhZGRyZXNzIGlzIGRyb3BwZWQgYXBwcm94aW1hdGVseSB0bwogICA3NSUgd2hlbiBOQVQ2 NCBnYXRld2F5IGlzIGNvbmZpZ3VyZWQgd2l0aCBidWxrIHBvcnQgYWxsb2NhdGlvbiAoVGhl CiAgIGxhYiB0ZXN0aW5nIGFsbG9jYXRlcyBlYWNoIHN1YnNjcmliZXIgd2l0aCA0MDAgcG9y dHMpLiAgSW4gYWRkaXRpb24sCiAgIHBvcnQtcmFuZ2UgYmFzZWQgYWxsb2NhdGlvbiBzaG91 bGQgYWxzbyBjb25zaWRlciBwb3J0IHJhbmRvbWl6YXRpb24KICAgZGVzY3JpYmVkIGluIFs8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDU2IiB0aXRsZT0iJnF1 b3Q7UmVjb21tZW5kYXRpb25zIGZvciBUcmFuc3BvcnQtIFByb3RvY29sIFBvcnQgUmFuZG9t aXphdGlvbiZxdW90OyI+UkZDNjA1NjwvYT5dIC4gQSB0cmFkZS1vZmYgYW1vbmcgYWRkcmVz cyBtdWx0aXBsZXhpbmcKCgoKPHNwYW4gY2xhc3M9ImdyZXkiPkNoZW4sIGV0IGFsLiAgICAg ICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSA5 XTwvc3Bhbj4KPC9wcmU+PCEtLU5ld1BhZ2UtLT48cHJlIGNsYXNzPSJuZXdwYWdlIj48YSBu YW1lPSJwYWdlLTEwIiBpZD0icGFnZS0xMCIgaHJlZj0iI3BhZ2UtMTAiIGNsYXNzPSJpbnZp c2libGUiPiA8L2E+CjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgTkFUNjQgRXhwZXJpZW5jZXMgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTM8L3Nw YW4+CgoKICAgZWZmaWNpZW5jeSwgbG9nZ2luZyBzdG9yYWdlIGNvbXByZXNzaW9uIGFuZCBw b3J0IGFsbG9jYXRpb24KICAgY29tcGxleGl0eSBzaG91bGQgYmUgY29uc2lkZXJlZC4gIE1v cmUgZGlzY3Vzc2lvbnMgY291bGQgYmUgZm91bmQgaW4KICAgWzxhIGhyZWY9IiNyZWYtSS1E LmNoZW4tc3Vuc2V0NC1jZ24tcG9ydC1hbGxvY2F0aW9uIj5JLUQuY2hlbi1zdW5zZXQ0LWNn bi1wb3J0LWFsbG9jYXRpb248L2E+XS5CYXNpY2FsbHksIHRoZSBkZWNpc2lvbgogICBkZXBl bmRzIG9uIHVzYWJsZSBJUHY0IHJlc291cmNlIGFuZCBpbnZlc3RtZW50cyBvZiBsb2cgc3lz dGVtcy4KCjxzcGFuIGNsYXNzPSJoMyI+PGgzPjxhIGNsYXNzPSJzZWxmbGluayIgbmFtZT0i c2VjdGlvbi01LjIiIGhyZWY9IiNzZWN0aW9uLTUuMiI+NS4yPC9hPi4gIEdlby1sb2NhdGlv bjwvaDM+PC9zcGFuPgoKICAgSVAgYWRkcmVzc2VzIGFyZSB1c3VhbGx5IHVzZWQgYXMgaW5w dXRzIHRvIGdlby1sb2NhdGlvbiBzZXJ2aWNlcy4KICAgVGhlIHVzZSBvZiBhZGRyZXNzIHNo YXJpbmcgd2lsbCBwcmV2ZW50IHRoZXNlIHN5c3RlbXMgZnJvbSByZXNvbHZpbmcKICAgdGhl IGxvY2F0aW9uIG9mIGEgaG9zdCBiYXNlZCBvbiBJUCBhZGRyZXNzIGFsb25lLiAgQXBwbGlj YXRpb25zIHRoYXQKICAgYXNzdW1lIHN1Y2ggZ2VvZ3JhcGhpYyBpbmZvcm1hdGlvbiBtYXkg bm90IHdvcmsgYXMgaW50ZW5kZWQuICBUaGUKICAgcG9zc2libGUgc29sdXRpb25zIGxpc3Rl ZCBpbiBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk2NyIgdGl0 bGU9IiZxdW90O0FuYWx5c2lzIG9mIFBvdGVudGlhbCBTb2x1dGlvbnMgZm9yIFJldmVhbGlu ZyBhIEhvc3QgSWRlbnRpZmllciAoSE9TVF9JRCkgaW4gU2hhcmVkIEFkZHJlc3MgRGVwbG95 bWVudHMmcXVvdDsiPlJGQzY5Njc8L2E+XSBhcmUgaW50ZW5kZWQgdG8gYnJpZGdlIHRoZQog ICBnYXAuICBIb3dldmVyLCB0aG9zZSBzb2x1dGlvbnMgY2FuIG9ubHkgcHJvdmlkZSBhIHN1 Yi1vcHRpbWFsCiAgIHN1YnN0aXR1dGlvbiB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBob3N0 IGlkZW50aWZpY2F0aW9uLCBpbgogICBwYXJ0aWN1bGFyIGl0IG1heSBub3QgdG9kYXkgc29s dmUgcHJvYmxlbXMgd2l0aCBzb3VyY2UgaWRlbnRpZmljYXRpb24KICAgdGhyb3VnaCB0cmFu c2xhdGlvbi4gIFRoZSBmb2xsb3dpbmcgbGlzdHMgY3VycmVudCBwcmFjdGljZXMgdG8KICAg bWl0aWdhdGUgdGhlIGlzc3VlLgoKICAgbyAgT3BlcmF0b3JzIHdobyBhZG9wdCBOQVQ2NC1G RSBtYXkgbGV2ZXJhZ2UgdGhlIGFwcGxpY2F0aW9uIGxheWVyCiAgICAgIHByb3hpZXMsIGUu Zy4gWC1Gb3J3YXJkZWQtRm9yIChYRkYpCiAgICAgIFs8YSBocmVmPSIjcmVmLUktRC5pZXRm LWFwcHNhd2ctaHR0cC1mb3J3YXJkZWQiPkktRC5pZXRmLWFwcHNhd2ctaHR0cC1mb3J3YXJk ZWQ8L2E+XSwgdG8gY29udmV5IHRoZSBJUHY2IHNvdXJjZQogICAgICBhZGRyZXNzIGluIEhU VFAgaGVhZGVycy4gIFRob3NlIG1lc3NhZ2VzIHdvdWxkIGJlIHBhc3NlZCBvbiB0bwogICAg ICB3ZWItc2VydmVycy4gIFRoZSBxdWVyaWVkIHNlcnZlciBjYW4gbG9va3VwIFJhZGl1cyBz ZXJ2ZXJzIGZvciB0aGUKICAgICAgdGFyZ2V0IHN1YnNjcmliZXJzIGJhc2VkIG9uIElQdjYg YWRkcmVzc2VzIGluY2x1ZGVkIGluIFhGRiBIVFRQCiAgICAgIGhlYWRlcnMuICBYRkYgaXMg dGhlIGRlIGZhY3RvIHN0YW5kYXJkIHdoaWNoIGhhcyBiZWVuIGludGVncmF0ZWQKICAgICAg aW4gbW9zdCBMb2FkIEJhbGFuY2Vycy4gIFRoZXJlZm9yZSwgaXQgbWF5IGJlIHN1cGVyaW9y IHRvIHVzZSBpbiBhCiAgICAgIE5BVC1GRSBlbnZpcm9ubWVudC4gIEluIHRoZSBkb3duc2lk ZXMsIFhGRiBpcyBzcGVjaWZpYyB0byBIVFRQLgogICAgICBJdCByZXN0cmljdHMgdGhlIHVz YWdlcyBzbyB0aGF0IHRoZSBzb2x1dGlvbiBjYW4ndCBiZSBhcHBsaWVkIHRvCiAgICAgIHJl cXVlc3RzIG1hZGUgb3ZlciBIVFRQcy4gIFRoaXMgbWFrZXMgZ2VvLWxvY2F0aW9uIHByb2Js ZW1hdGljIGZvcgogICAgICBIVFRQcyBiYXNlZCBzZXJ2aWNlcy4KCiAgIG8gIFRoZSBOQVQ2 NC1DR04gZXF1aXBtZW50IG1heSBub3QgaW1wbGVtZW50IFhGRi4gIEdlby1sb2NhdGlvbiBi YXNlZAogICAgICBvbiBzaGFyZWQgSVB2NCBhZGRyZXNzIGlzIHJhdGhlciBpbmFjY3VyYXRl IGluIHRoYXQgY2FzZS4KICAgICAgT3BlcmF0b3JzIGNvdWxkIHN1YmRpdmlkZSB0aGUgb3V0 c2lkZSBJUHY0IGFkZHJlc3MgcG9vbCBzbyBhbiBJUHY2CiAgICAgIGFkZHJlc3MgY2FuIGJl IHRyYW5zbGF0ZWQgZGVwZW5kaW5nIG9uIHRoZWlyIGdlb2dyYXBoaWNhbAogICAgICBsb2Nh dGlvbnMuICBBcyBjb25zZXF1ZW5jZSwgbG9jYXRpb24gaW5mb3JtYXRpb24gY2FuIGJlIGlk ZW50aWZpZWQKICAgICAgZnJvbSBhIGNlcnRhaW4gSVB2NCBhZGRyZXNzIHJhbmdlLiAgWzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NjciIHRpdGxlPSImcXVv dDtBbmFseXNpcyBvZiBQb3RlbnRpYWwgU29sdXRpb25zIGZvciBSZXZlYWxpbmcgYSBIb3N0 IElkZW50aWZpZXIgKEhPU1RfSUQpIGluIFNoYXJlZCBBZGRyZXNzIERlcGxveW1lbnRzJnF1 b3Q7Ij5SRkM2OTY3PC9hPl0gYWxzbyBlbnVtZXJhdGVzCiAgICAgIHNldmVyYWwgb3B0aW9u cyB0byByZXZlYWwgdGhlIGhvc3QgaWRlbnRpZmllci4gIEVhY2ggc29sdXRpb24KICAgICAg bGlrZWx5IGhhcyB0aGVpci1vd24gc3BlY2lmaWMgdXNhZ2UuICBGb3IgdGhlIGdlby1sb2Nh dGlvbiBzeXN0ZW1zCiAgICAgIHJlbHlpbmcgb24gYSBSYWRpdXMgZGF0YWJhc2VbUkZDNTU4 MF0sIHdlIGhhdmUgaW52ZXN0aWdhdGVkIHRvCiAgICAgIGRlbGl2ZXIgTkFUNjQgQklCcyBh bmQgU2Vzc2lvbiBUYWJsZSBFbnRyeXMgKFNURXMpIHRvIGEgUmFkaXVzCiAgICAgIHNlcnZl cltJLUQuY2hlbi1iZWhhdmUtbmF0NjQtcmFkaXVzLWV4dGVuc2lvbl0uICBUaGlzIG1ldGhv ZCBjb3VsZAogICAgICBwcm92aWRlIGdlby1sb2NhdGlvbiBzeXN0ZW0gd2l0aCBhbiBpbnRl cm5hbCBJUHY2IGFkZHJlc3MgdG8KICAgICAgaWRlbnRpZnkgZWFjaCB1c2VyLiAgSXQgY2Fu IGdldCBhbG9uZyB3aXRoIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1NTgwIiB0aXRsZT0iJnF1b3Q7Q2FycnlpbmcgTG9jYXRpb24gT2JqZWN0cyBpbiBSQURJ VVMgYW5kIERpYW1ldGVyJnF1b3Q7Ij5SRkM1NTgwPC9hPl0gdG8gY29udmV5CiAgICAgIG9y aWdpbmFsIHNvdXJjZSBhZGRyZXNzIHRocm91Z2ggc2FtZSBtZXNzYWdlIGJ1cy4KCjxzcGFu IGNsYXNzPSJoMiI+PGgyPjxhIGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2VjdGlvbi02IiBo cmVmPSIjc2VjdGlvbi02Ij42PC9hPi4gIFF1YWxpdHkgb2YgRXhwZXJpZW5jZTwvaDI+PC9z cGFuPgoKCgoKPHNwYW4gY2xhc3M9ImdyZXkiPkNoZW4sIGV0IGFsLiAgICAgICAgICAgICBF eHBpcmVzIEFwcmlsIDE3LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDEwXTwvc3Bhbj4K PC9wcmU+PCEtLU5ld1BhZ2UtLT48cHJlIGNsYXNzPSJuZXdwYWdlIj48YSBuYW1lPSJwYWdl LTExIiBpZD0icGFnZS0xMSIgaHJlZj0iI3BhZ2UtMTEiIGNsYXNzPSJpbnZpc2libGUiPiA8 L2E+CjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgTkFU NjQgRXhwZXJpZW5jZXMgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTM8L3NwYW4+CgoKPHNw YW4gY2xhc3M9ImgzIj48aDM+PGEgY2xhc3M9InNlbGZsaW5rIiBuYW1lPSJzZWN0aW9uLTYu MSIgaHJlZj0iI3NlY3Rpb24tNi4xIj42LjE8L2E+LiAgU2VydmljZSBSZWFjaGFiaWxpdHk8 L2gzPjwvc3Bhbj4KCiAgIE5BVDY0IGlzIHByb3ZpZGluZyBhIHRyYW5zbGF0aW9uIGNhcGFi aWxpdHkgYmV0d2VlbiBJUHY2IGFuZCBJUHY0CiAgIGVuZC1ub2Rlcy4gIEluIG9yZGVyIHRv IHByb3ZpZGUgdGhlIHJlYWNoYWJpbGl0eSBiZXR3ZWVuIHR3byBJUAogICBhZGRyZXNzIGZh bWlsaWVzLCBOQVQ2NC1DR04gaGFzIHRvIGltcGxlbWVudCBhcHByb3ByaWF0ZSBhcHBsaWNh dGlvbgogICBhd2FyZSBmdW5jdGlvbnMsIGkuZS4gQXBwbGljYXRpb24gTGF5ZXIgR2F0ZXdh eSAoQUxHKSwgd2hlcmUgYWRkcmVzcwogICB0cmFuc2xhdGlvbiBpcyBub3QgaXRzZWxmIHN1 ZmZpY2llbnQgYW5kIHNlY3VyaXR5IG1lY2hhbmlzbXMgZG8gbm90CiAgIHJlbmRlciBpdCBp bmZlYXNpYmxlLiAgTW9zdCBOQVQ2NC1DR05zIG1haW5seSBwcm92aWRlIEZUUC0KICAgQUxH W1JGQzYzODRdLiAgTkFUNjQtRkVzIG1heSBoYXZlIGZ1bmN0aW9uYWwgcmljaG5lc3Mgb24g TG9hZAogICBCYWxhbmNlciwgZm9yIGV4YW1wbGUgSFRUUC1BTEcsIEhUVFBzLUFMRywgUlRT UC1BTEcgYW5kIFNNVFAtQUxHIGhhdmUKICAgYmVlbiBzdXBwb3J0ZWQuICBJdCBzaG91bGQg YmUgbm90ZWQgdGhhdCBBTEdzIG1heSBpbXBhY3QgdGhlCiAgIHBlcmZvcm1hbmNlIG9uIGEg TkFUNjQgYm94IHRvIHNvbWUgZXh0ZW50LiAgSVNQcyBhcyB3ZWxsIGFzIGNvbnRlbnQKICAg cHJvdmlkZXJzIG1pZ2h0IGNob29zZSB0byBhdm9pZCBzaXR1YXRpb25zIHdoZXJlIHRoZSBp bXBvc2l0aW9uIG9mIGFuCiAgIEFMRyBtaWdodCBiZSByZXF1aXJlZC4gIEF0IHRoZSBzYW1l IHRpbWUsIGl0IGlzIGFsc28gaW1wb3J0YW50IHRvCiAgIHJlbWluZCBjdXN0b21lcnMgYW5k IGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgdGhhdCBJUHY2IGVuZC10by1lbmQKICAgdXNhZ2Ug ZG9lcyBub3QgcmVxdWlyZSBBTEcgaW1wb3NpdGlvbiBhbmQgdGhlcmVmb3JlIHJlc3VsdHMg aW4gYQogICBiZXR0ZXIgb3ZlcmFsbCB1c2VyIGV4cGVyaWVuY2UuCgo8c3BhbiBjbGFzcz0i aDMiPjxoMz48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tNi4yIiBocmVmPSIj c2VjdGlvbi02LjIiPjYuMjwvYT4uICBSZXNvdXJjZSBSZXNlcnZhdGlvbjwvaDM+PC9zcGFu PgoKICAgU2Vzc2lvbiBzdGF0dXMgbm9ybWFsbHkgaXMgbWFuYWdlZCBieSBhIHN0YXRpYyB0 aW1lci4gIEZvciBleGFtcGxlLAogICB0aGUgdmFsdWUgb2YgdGhlICJlc3RhYmxpc2hlZCBj b25uZWN0aW9uIGlkbGUtdGltZW91dCIgZm9yIFRDUAogICBzZXNzaW9ucyBtdXN0IG5vdCBi ZSBsZXNzIHRoYW4gMiBob3VycyA0IG1pbnV0ZXNbUkZDNTM4Ml0gYW5kIDUKICAgbWludXRl cyBmb3IgVURQIHNlc3Npb25zW1JGQzQ3ODddLiAgSW4gc29tZSBjYXNlcywgTkFUIHJlc291 cmNlIG1heWJlCiAgIHNpZ25pZmljYW50bHkgY29uc3VtZWQgYnkgbGFyZ2VseSBpbmFjdGl2 ZSB1c2Vycy4gIFRoZSBOQVQgdHJhbnNsYXRvcgogICBhbmQgb3RoZXIgY3VzdG9tZXJzIHdv dWxkIHN1ZmZlciBmcm9tIHNlcnZpY2UgZGVncmFkYXRpb24gZHVlIHRvIHBvcnQKICAgY29u c3VtbWF0aW9uIGJ5IG90aGVyIHN1YnNjcmliZXJzIHVzaW5nIHRoZSBzYW1lIE5BVDY0IGRl dmljZS4gIEEKICAgZmxleGlibGUgTkFUIHNlc3Npb24gY29udHJvbCBpcyBkZXNpcmFibGUg dG8gcmVzb2x2ZSB0aGUgaXNzdWVzLgogICBQQ1BbUkZDNjg4N10gY291bGQgYmUgYSBjYW5k aWRhdGUgdG8gcHJvdmlkZSBzdWNoIGNhcGFiaWxpdHkuICBBCiAgIE5BVDY0LUNHTiBzaG91 bGQgaW50ZWdyYXRlIHdpdGggYSBQQ1Agc2VydmVyLCB0byBhbGxvY2F0ZSBhdmFpbGFibGUK ICAgSVB2NCBhZGRyZXNzL3BvcnQgcmVzb3VyY2VzLiAgUmVzb3VyY2VzIGNvdWxkIGJlIGFz c2lnbmVkIHRvIFBDUAogICBjbGllbnRzIHRocm91Z2ggUENQIE1BUC9QRUVSIG1vZGUuICBT dWNoIGFiaWxpdHkgY2FuIGJlIGNvbnNpZGVyZWQgdG8KICAgdXBncmFkZSB1c2VyIGV4cGVy aWVuY2VzLCBmb3IgZXhhbXBsZSBhc3NpZ25pbmcgZGlmZmVyZW50IHNpemVzIG9mCiAgIHBv cnQgcmFuZ2VzIGZvciBkaWZmZXJlbnQgc3Vic2NyaWJlcnMuICBUaG9zZSBtZWNoYW5pc21z IGFyZSBhbHNvCiAgIGhlbHBmdWwgdG8gbWluaW1pemUgdGVybWluYWwgYmF0dGVyeSBjb25z dW1wdGlvbiBhbmQgcmVkdWNlIHRoZQogICBudW1iZXIgb2Yga2VlcC1hbGl2ZSBtZXNzYWdl cyB0byBiZSBzZW50IGJ5IG1vYmlsZSB0ZXJtaW5hbCBkZXZpY2VzLgoKICAgU3Vic2NyaWJl cnMgY2FuIGFsc28gYmVuZWZpdCBmcm9tIG5ldHdvcmsgcmVsaWFiaWxpdHkuICBJdCBoYXMg YmVlbgogICBkaXNjdXNzZWQgdGhhdCBob3Qtc3RhbmRieSBvZmZlcnMgc2F0aXNmYWN0b3J5 IGV4cGVyaWVuY2Ugb25jZSBvdXRhZ2UKICAgb2YgcHJpbWFyeSBOQVQ2NCBpcyBvY2N1cnJl ZC4gIE9wZXJhdG9ycyBtYXkgcmlnaHRseSBiZSBjb25jZXJuZWQKICAgYWJvdXQgdGhlIGNv bnNpZGVyYWJsZSBpbnZlc3RtZW50IHJlcXVpcmVkIGZvciBOQVQ2NCBlcXVpcG1lbnQKICAg cmVsYXRpdmUgdG8gbG93IEFSUFUgaW5jb21lLiAgRm9yIGV4YW1wbGUsIHRyYW5zcG9ydCBs aW5rcyBtYXkgY29zdAogICBtdWNoLCBiZWNhdXNlIHByaW1hcnkgTkFUNjQgYW5kIGJhY2t1 cCBhcmUgbm9ybWFsbHkgbG9jYXRlZCBhdAogICBkaWZmZXJlbnQgbG9jYXRpb25zLCBzZXBh cmF0ZWQgYnkgYSByZWxhdGl2ZWx5IGxhcmdlIGRpc3RhbmNlLgogICBBZGRpdGlvbmFsIG1h aW50ZW5hbmNlIGhhcyB0byBiZSBzcGVudCB0byBlbnN1cmUgdGhlIGNvbm5lY3Rpdml0eQog ICBxdWFsaXR5LiAgSG93ZXZlciwgdGhhdCBtYXkgYmUgbmVjZXNzYXJ5IHRvIHNvbWUgYXBw bGljYXRpb25zLCB3aGljaAogICBhcmUgZGVsYXktc2Vuc2l0aXZlIGFuZCBzZWVrIHNlc3Np b24gY29udGludWl0eSwgZm9yIGV4YW1wbGUgb24tbGluZQogICBnYW1lcyBhbmQgbGl2ZS1z dHJlYW1pbmcuICBPcGVyYXRvcnMgbWF5IGJlIGFibGUgdG8gZ2V0IGFkZGVkLXZhbHVlcwoK Cgo8c3BhbiBjbGFzcz0iZ3JleSI+Q2hlbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMg QXByaWwgMTcsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMTFdPC9zcGFuPgo8L3ByZT48 IS0tTmV3UGFnZS0tPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxhIG5hbWU9InBhZ2UtMTIiIGlk PSJwYWdlLTEyIiBocmVmPSIjcGFnZS0xMiIgY2xhc3M9ImludmlzaWJsZSI+IDwvYT4KPHNw YW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBOQVQ2NCBFeHBl cmllbmNlcyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxMzwvc3Bhbj4KCgogICBmcm9tIHRo b3NlIHNlcnZpY2VzIGJ5IG9mZmVyaW5nIGZpcnN0LWNsYXNzIHNlcnZpY2VzLiAgSXQgY2Fu IGJlIHByZS0KICAgY29uZmlndXJlZCBvbiB0aGUgZ2F0ZXdheSB0byBob3Qtc3RhbmRieSBt b2RlcyBkZXBlbmRpbmcgb24KICAgc3Vic2NyaWJlcidzIHByb2ZpbGUuICBUaGUgcmVzdCBv ZiBvdGhlciBzZXNzaW9ucyBjYW4gYmUgY292ZXJlZCBieQogICBjb2xkL3dhcm0gc3RhbmRi eS4KCjxzcGFuIGNsYXNzPSJoMiI+PGgyPjxhIGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2Vj dGlvbi03IiBocmVmPSIjc2VjdGlvbi03Ij43PC9hPi4gIE1UVSBDb25zaWRlcmF0aW9uczwv aDI+PC9zcGFuPgoKICAgSVB2NiByZXF1aXJlcyB0aGF0IGV2ZXJ5IGxpbmsgaW4gdGhlIGlu dGVybmV0IGhhdmUgYW4gTWF4aW11bQogICBUcmFuc21pc3Npb24gVW5pdCAoTVRVKSBvZiAx MjgwIG9jdGV0cyBvciBncmVhdGVyW1JGQzI0NjBdLiAgSG93ZXZlciwKICAgaW4gY2FzZSBv ZiBOQVQ2NCB0cmFuc2xhdGlvbiBkZXBsb3ltZW50LCBzb21lIElQdjQgTVRVIGNvbnN0cmFp bmVkCiAgIGxpbmsgd2lsbCBiZSB1c2VkIGluIHNvbWUgY29tbXVuaWNhdGlvbiBwYXRoIGFu ZCBvcmlnaW5hdGluZyBJUHY2CiAgIG5vZGVzIG1heSB0aGVyZWZvcmUgcmVjZWl2ZSBhbiBJ Q01QIFBhY2tldCBUb28gQmlnIChQVEIpIG1lc3NhZ2UsCiAgIHJlcG9ydGluZyBhIE5leHQt SG9wIE1UVSBsZXNzIHRoYW4gMTI4MCBieXRlcy4gIFRoZSByZXN1bHQgd291bGQgYmUKICAg dGhhdCBJUHY2IGFsbG93cyBwYWNrZXRzIHRvIGNvbnRhaW4gYSBmcmFnbWVudGF0aW9uIGhl YWRlciwgd2l0aG91dAogICB0aGUgcGFja2V0IGJlaW5nIGZyYWdtZW50ZWQgaW50byBtdWx0 aXBsZSBwaWVjZXMuICBBIE5BVDY0IHdvdWxkCiAgIHJlY2VpdmUgSVB2NiBwYWNrZXRzIHdp dGggZnJhZ21lbnRhdGlvbiBoZWFkZXIgaW4gd2hpY2ggIk0iIGZsYWcKICAgZXF1YWwgdG8g MCBhbmQgIkZyYWdtZW50IE9mZnNldCIgZXF1YWwgdG8gMC4gIFRob3NlIHBhY2tldHMgbGlr ZWx5CiAgIGltcGFjdCBvdGhlciBmcmFnbWVudHMgYWxyZWFkeSBxdWV1ZWQgd2l0aCB0aGUg c2FtZSBzZXQgb2Yge0lQdjYKICAgU291cmNlIEFkZHJlc3MsIElQdjYgRGVzdGluYXRpb24g QWRkcmVzcywgRnJhZ21lbnQgSWRlbnRpZmljYXRpb259LgogICBJZiB0aGUgTkFUNjQgYm94 IGlzIGNvbXBsaWFudCB3aXRoIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1NzIyIiB0aXRsZT0iJnF1b3Q7SGFuZGxpbmcgb2YgT3ZlcmxhcHBpbmcgSVB2NiBG cmFnbWVudHMmcXVvdDsiPlJGQzU3MjI8L2E+XSwgdGhlcmUgaXMgcmlzayB0aGF0IGFsbAog ICB0aGUgZnJhZ21lbnRzIGhhdmUgdG8gYmUgZHJvcHBlZC4KCiAgIFs8YSBuYW1lPSJyZWYt UkZDNjk0NiIgaWQ9InJlZi1SRkM2OTQ2Ij5SRkM2OTQ2PC9hPl0gZGlzY3Vzc2VzIGhvdyB0 aGlzIHNpdHVhdGlvbiBjb3VsZCBiZSBleHBsb2l0ZWQgYnkgYW4KICAgYXR0YWNrZXIgdG8g cGVyZm9ybSBmcmFnbWVudGF0aW9uLWJhc2VkIGF0dGFja3MsIGFuZCBhbHNvIHByb3Bvc2Vz IGFuCiAgIGltcHJvdmVkIGhhbmRsaW5nIG9mIHN1Y2ggcGFja2V0cy4gIEl0IHJlcXVpcmVk IGVuaGFuY2VtZW50cyBvbiBOQVQ2NAogICBnYXRld2F5IGltcGxlbWVudGF0aW9ucyB0byBp c29sYXRlIHBhY2tldCdzIHByb2Nlc3NpbmcuICBOQVQ2NCBzaG91bGQKICAgZm9sbG93IHRo ZSByZWNvbW1lbmRhdGlvbiBhbmQgdGFrZSBzdGVwcyB0byBwcmV2ZW50IHRoZSByaXNrcyBv ZgogICBmcmFnbWVudGF0aW9uLgoKICAgQW5vdGhlciBhcHByb2FjaCB0aGF0IHBvdGVudGlh bGx5IGF2b2lkcyB0aGlzIGlzc3VlIGlzIHRvIGNvbmZpZ3VyZQogICBJUHY0IE1UVSBtb3Jl IHRoYW4gMTI2MCBieXRlcy4gIEl0IHdvdWxkIGZvcmJpZCB0aGUgb2NjdXJyZW5jZSBvZiBQ VEIKICAgc21hbGxlciB0aGFuIDEyODAgYnl0ZXMuICBTdWNoIGFuIG9wZXJhdGlvbmFsIGNv bnNpZGVyYXRpb24gaXMgaGFyZAogICB0byB1bml2ZXJzYWxseSBhcHBseSB0byB0aGUgbGVn YWN5ICJJUHY0IEludGVybmV0IiBOQVQ2NC1DR04gYnJpZGdlZC4KICAgSG93ZXZlciwgaXQn cyBhIGZlYXNpYmxlIGFwcHJvYWNoIGluIE5BVDY0LUZFIGNhc2VzLCBzaW5jZSBhIElQdjQK ICAgbmV0d29yayBOQVQ2NC1GRSBjb25uZWN0ZWQgaXMgcmF0aGVyIHdlbGwtb3JnYW5pemVk IGFuZCBvcGVyYXRlZCBieSBhCiAgIElEQyBvcGVyYXRvciBvciBjb250ZW50IHByb3ZpZGVy LiAgVGhlcmVmb3JlLCB0aGUgTVRVIG9mIElQdjQgbmV0d29yawogICBpbiBOQVQ2NC1GRSBj YXNlIGFyZSBzdHJvbmdseSByZWNvbW1lbmRlZCB0byBzZXQgdG8gbW9yZSB0aGFuIDEyNjAK ICAgYnl0ZXMuCgo8c3BhbiBjbGFzcz0iaDIiPjxoMj48YSBjbGFzcz0ic2VsZmxpbmsiIG5h bWU9InNlY3Rpb24tOCIgaHJlZj0iI3NlY3Rpb24tOCI+ODwvYT4uICBVTEEgVXNhZ2VzPC9o Mj48L3NwYW4+CgoKCgoKCgoKCgoKPHNwYW4gY2xhc3M9ImdyZXkiPkNoZW4sIGV0IGFsLiAg ICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdl IDEyXTwvc3Bhbj4KPC9wcmU+PCEtLU5ld1BhZ2UtLT48cHJlIGNsYXNzPSJuZXdwYWdlIj48 YSBuYW1lPSJwYWdlLTEzIiBpZD0icGFnZS0xMyIgaHJlZj0iI3BhZ2UtMTMiIGNsYXNzPSJp bnZpc2libGUiPiA8L2E+CjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgTkFUNjQgRXhwZXJpZW5jZXMgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTM8 L3NwYW4+CgoKICAgVW5pcXVlIExvY2FsIEFkZHJlc3NlcyAoVUxBcykgYXJlIGRlZmluZWQg aW4gWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxOTMiIHRpdGxl PSImcXVvdDtVbmlxdWUgTG9jYWwgSVB2NiBVbmljYXN0IEFkZHJlc3NlcyZxdW90OyI+UkZD NDE5MzwvYT5dIHRvIGJlCiAgIHJlbnVtYmVyZWQgd2l0aGluIGEgbmV0d29yayBzaXRlIGZv ciBsb2NhbCBjb21tdW5pY2F0aW9ucy4gIE9wZXJhdG9ycwogICBtYXkgdXNlIFVMQXMgYXMg TkFUNjQgcHJlZml4ZXMgdG8gcHJvdmlkZSBzaXRlLWxvY2FsIElQdjYKICAgY29ubmVjdGl2 aXR5LiAgVGhvc2UgVUxBIHByZWZpeGVzIGFyZSBzdHJpcHBlZCB3aGVuIHRoZSBwYWNrZXRz IGdvaW5nCiAgIHRvIHRoZSBJUHY0IEludGVybmV0LCB0aGVyZWZvcmUgVUxBcyBhcmUgb25s eSB2YWxpZCBpbiB0aGUgSVB2NiBzaXRlLgogICBUaGUgdXNlIG9mIFVMQXMgY291bGQgaGVs cCBpbiBpZGVudGlmeWluZyB0aGUgdHJhbnNsYXRpb24KICAgdHJhZmZpYy5bPGEgaHJlZj0i I3JlZi1JLUQuaWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zIj5JLUQuaWV0 Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zPC9hPl0gaGFzIHByb3ZpZGVkCiAg IGZ1cnRoZXIgZ3VpZGFuY2UgZm9yIHRoZSBVTEFzIHVzYWdlcy4KCiAgIFdlIGNvbmZpZ3Vy ZSBVTEFzIGFzIE5BVDY0IHByZWZpeGVzIG9uIGEgTkFUNjQtQ0dOLiAgSWYgYSBob3N0IGlz CiAgIG9ubHkgYXNzaWduZWQgd2l0aCBhbiBJUHY2IGFkZHJlc3MgYW5kIGNvbm5lY3RlZCB0 byBOQVQ2NC1DR04sIHdoZW4KICAgY29ubmVjdCB0byBhbiBJUHY0IHNlcnZpY2UsIGl0IHdv dWxkIHJlY2VpdmUgQUFBQSByZWNvcmQgZ2VuZXJhdGVkIGJ5CiAgIHRoZSBETlM2NCB3aXRo IHRoZSBVTEEgcHJlZml4LiAgQSBHbG9iYWwgVW5pY2FzdCBBZGRyZXNzIChHVUEpIHdpbGwK ICAgYmUgc2VsZWN0ZWQgYXMgdGhlIHNvdXJjZSBhZGRyZXNzIHRvIHRoZSBVTEEgZGVzdGlu YXRpb24gYWRkcmVzcy4KICAgV2hlbiB0aGUgaG9zdCBoYXMgYm90aCBJUHY0IGFuZCBJUHY2 IGFkZHJlc3MsIGl0IHdvdWxkIGluaXRpYXRlIGJvdGgKICAgQSBhbmQgQUFBQSByZWNvcmQg bG9va3VwLCB0aGVuIGJvdGggb3JpZ2luYWwgQSByZWNvcmQgYW5kCiAgIEROUzY0LWdlbmVy YXRlZCBBQUFBIHJlY29yZCB3b3VsZCBiZSByZWNlaXZlZC4gIEEgaG9zdCwgd2hpY2ggaXMK ICAgY29tcGxpYW50IHdpdGggWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzY3MjQiIHRpdGxlPSImcXVvdDtEZWZhdWx0IEFkZHJlc3MgU2VsZWN0aW9uIGZvciBJ bnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDYgKElQdjYpJnF1b3Q7Ij5SRkM2NzI0PC9hPl0s IHdpbGwgbmV2ZXIgcHJlZmVyIFVMQSBvdmVyIElQdjQuICBBbiBJUHY0CiAgIHBhdGggd2ls bCBiZSBhbHdheXMgc2VsZWN0ZWQuICBJdCBtYXkgYmUgdW5kZXNpcmFibGUgYmVjYXVzZSB0 aGUKICAgTkFUNjQtQ0dOIHdpbGwgbmV2ZXIgYmUgdXNlZC4gIE9wZXJhdG9ycyBtYXkgY29u c2lkZXIgdG8gYWRkCiAgIGFkZGl0aW9uYWwgc2l0ZS1zcGVjaWZpYyByb3dzIHRvIHRoZSBk ZWZhdWx0IHRhYmxlIHRvIHN0ZWVyIHRyYWZmaWMKICAgZmxvd3MgZ29pbmcgdGhyb3VnaCBO QVQ2NC1DR04uICBIb3dldmVyLCBpdCBpbnZvbHZlcyBzaWduaWZpY2FudAogICBjb3N0cyB0 byBjaGFuZ2UgdGVybWluYWwncyBiZWhhdmlvci4gIFRoZXJlZm9yZSwgb3BlcmF0b3JzIGFy ZSBub3QKICAgc3VnZ2VzdGVkIHRvIGNvbmZpZ3VyZSBVTEFzIG9uIGEgTkFUNjQtQ0dOLgoK ICAgVUxBcyBjYW4ndCB3b3JrIHdoZW4gaG9zdHMgdHJhbnNpdCB0aGUgSW50ZXJuZXQgdG8g Y29ubmVjdCB3aXRoCiAgIE5BVDY0LiAgVGhlcmVmb3JlLCBVTEFzIGFyZSBpbmFwcGxpY2Fi bGUgdG8gdGhlIGNhc2Ugb2YgTkFUNjQtRkUuCgo8c3BhbiBjbGFzcz0iaDIiPjxoMj48YSBj bGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tOSIgaHJlZj0iI3NlY3Rpb24tOSI+OTwv YT4uICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvaDI+PC9zcGFuPgoKICAgaGlzIGRvY3Vt ZW50IHByZXNlbnRzIHRoZSBkZXBsb3ltZW50IGV4cGVyaWVuY2VzIG9mIE5BVDY0IGluIENH TiBhbmQKICAgRkUgc2NlbmFyaW9zLiAgSW4gZ2VuZXJhbCwgPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjE0NiI+UkZDIDYxNDY8L2E+WzxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDYiIHRpdGxlPSImcXVvdDtTdGF0ZWZ1bCBO QVQ2NDogTmV0d29yayBBZGRyZXNzIGFuZCBQcm90b2NvbCBUcmFuc2xhdGlvbiBmcm9tIElQ djYgQ2xpZW50cyB0byBJUHY0IFNlcnZlcnMmcXVvdDsiPlJGQzYxNDY8L2E+XSBwcm92aWRl cyBUQ1AtdHJhY2tpbmcsCiAgIGFkZHJlc3MtZGVwZW5kZW50IGZpbHRlcmluZyBtZWNoYW5p c21zIHRvIHByb3RlY3QgTkFUNjQgZnJvbQogICBEaXN0cmlidXRlZCBEZW5pYWwgb2YgU2Vy dmljZSAoRERvUykuICBJbiBOQVQ2NC1DR04gY2FzZXMsIG9wZXJhdG9ycwogICBhbHNvIGNv dWxkIGFkb3B0IHVuaWNhc3QgUmV2ZXJzZSBQYXRoIEZvcndhcmRpbmcgKHVSUEYpWzxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM3MDQiIHRpdGxlPSImcXVvdDtJ bmdyZXNzIEZpbHRlcmluZyBmb3IgTXVsdGlob21lZCBOZXR3b3JrcyZxdW90OyI+UkZDMzcw NDwvYT5dIGFuZAogICBibGFjay93aGl0ZS1saXN0IHRvIGVuaGFuY2UgdGhlIHNlY3VyaXR5 IGJ5IHNwZWNpZnlpbmcgYWNjZXNzCiAgIHBvbGljaWVzLiAgRm9yIGV4YW1wbGUsIE5BVDY0 LUNHTiBzaG91bGQgZm9yYmlkIGVzdGFibGlzaCBOQVQ2NCBCSUIKICAgZm9yIGluY29taW5n IElQdjYgcGFja2V0cyBpZiB1UlBGIGluIFN0cmljdCBvciBMb29zZSBtb2RlIGNoZWNrIGRv ZXMKICAgbm90IHBhc3Mgb3Igd2hvc2Ugc291cmNlIElQdjYgYWRkcmVzcyBpcyBhc3NvY2lh dGVkIHRvIGJsYWNrLWxpc3RzLgoKICAgVGhlIHN0YXRlZnVsIE5BVDY0LUZFIGNyZWF0ZXMg c3RhdGUgYW5kIG1hcHMgdGhhdCBjb25uZWN0aW9uIHRvIGFuCiAgIGludGVybmFsbHktZmFj aW5nIElQdjQgYWRkcmVzcyBhbmQgcG9ydC4gIEFuIGF0dGFja2VyIGNhbiBjb25zdW1lIHRo ZQogICByZXNvdXJjZXMgb2YgdGhlIE5BVDY0LUZFIGRldmljZSBieSBzZW5kaW5nIGFuIGV4 Y2Vzc2l2ZSBudW1iZXIgb2YKICAgY29ubmVjdGlvbiBhdHRlbXB0cy4gIFdpdGhvdXQgYSBE RG9TIGxpbWl0YXRpb24gbWVjaGFuaXNtLCB0aGUKICAgTkFUNjQtRkUgaXMgZXhwb3NlZCB0 byBhdHRhY2tzLiAgTG9hZCBCYWxhbmNlciBpcyByZWNvbW1lbmRlZCB0bwogICBlbmFibGUg dGhlIGNhcGFiaWxpdGllcyBvZiBsaW5lIHJhdGUgRERPUyBkZWZlbnNlLCBzdWNoIGFzIHRo ZQogICBlbXBsb3ltZW50IG9mIFNZTiBQUk9YWS1DT09LSUUuICBTZWN1cml0eSBkb21haW4g ZGl2aXNpb24gaXMKICAgbmVjZXNzYXJ5IGFzIHdlbGwgaW4gdGhpcyBjYXNlLiAgVGhlcmVm b3JlLCBMb2FkIEJhbGFuY2VycyBjb3VsZCBub3QKCgoKPHNwYW4gY2xhc3M9ImdyZXkiPkNo ZW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDE0ICAgICAgICAg ICAgICAgIFtQYWdlIDEzXTwvc3Bhbj4KPC9wcmU+PCEtLU5ld1BhZ2UtLT48cHJlIGNsYXNz PSJuZXdwYWdlIj48YSBuYW1lPSJwYWdlLTE0IiBpZD0icGFnZS0xNCIgaHJlZj0iI3BhZ2Ut MTQiIGNsYXNzPSJpbnZpc2libGUiPiA8L2E+CjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgTkFUNjQgRXhwZXJpZW5jZXMgICAgICAgICAgICAgICBP Y3RvYmVyIDIwMTM8L3NwYW4+CgoKICAgb25seSBzZXJ2ZSBmb3Igb3B0aW1pemF0aW9uIG9m IHRyYWZmaWMgZGlzdHJpYnV0aW9uLCBidXQgYWxzbyBwcmV2ZW50CiAgIHNlcnZpY2UgZnJv bSBxdWFsaXR5IGRldGVyaW9yYXRpb24gZHVlIHRvIHNlY3VyaXR5IGF0dGFja3MuCgo8c3Bh biBjbGFzcz0iaDIiPjxoMj48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMTAi IGhyZWY9IiNzZWN0aW9uLTEwIj4xMDwvYT4uICBJQU5BIENvbnNpZGVyYXRpb25zPC9oMj48 L3NwYW4+CgogICBUaGlzIG1lbW8gaW5jbHVkZXMgbm8gcmVxdWVzdCB0byBJQU5BLgoKPHNw YW4gY2xhc3M9ImgyIj48aDI+PGEgY2xhc3M9InNlbGZsaW5rIiBuYW1lPSJzZWN0aW9uLTEx IiBocmVmPSIjc2VjdGlvbi0xMSI+MTE8L2E+LiAgQWNrbm93bGVkZ2VtZW50czwvaDI+PC9z cGFuPgoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBKYXJpIEFya2tvLCBE YW4gV2luZywgUmVtaSBEZXNwcmVzLAogICBGcmVkIEJha2VyLCBIdWkgRGVuZywgTGVlIEhv d2FyZCwgSWxqaXRzY2ggdmFuIEJlaWpudW0sIFBoaWxpcAogICBNYXR0aGV3cywgUmFuZHkg QnVzaCwgTWlrYWVsIEFicmFoYW1zc29uLCBMb3JlbnpvIENvbGl0dGkgYW5kIFNoZW5nCiAg IEppYW5nIGZvciB0aGVpciBoZWxwZnVsIGNvbW1lbnRzLgoKICAgTWFueSB0aGFua3MgdG8g V2VzbGV5IEdlb3JnZSBhbmQgU2F0b3J1IE1hdHN1c2hpbWEgZm9yIHRoZWlyIGRldGFpbGVk CiAgIHJldmlld3MuCgogICBUaGUgYXV0aG9ycyBlc3BlY2lhbGx5IHRoYW5rIEpvZWwgSmFl Z2dsaSBhbmQgUmF5IEh1bnRlciBmb3IgaGlzCiAgIGVmZm9ydHMgYW5kIGNvbnRyaWJ1dGlv bnMgb24gZWRpdGluZyB3aGljaCBzdWJzdGFudGlhbGx5IGltcHJvdmVzIHRoZQogICBsZWdp YmlsaXR5IG9mIHRoZSBkb2N1bWVudC4KCiAgIFRoYW5rcyB0byBDYW1lcm9uIEJ5cm5lIHdo byB3YXMgYW4gYWN0aXZlIGNvLWF1dGhvciBvZiBzb21lIGVhcmxpZXIKICAgdmVyc2lvbnMg b2YgdGhpcyBkcmFmdC4KCjxzcGFuIGNsYXNzPSJoMiI+PGgyPjxhIGNsYXNzPSJzZWxmbGlu ayIgbmFtZT0ic2VjdGlvbi0xMiIgaHJlZj0iI3NlY3Rpb24tMTIiPjEyPC9hPi4gIEFkZGl0 aW9uYWwgQXV0aG9yIExpc3Q8L2gyPjwvc3Bhbj4KCiAgIFRoZSBmb2xsb3dpbmcgYXJlIGV4 dGVuZGVkIGF1dGhvcnMgd2hvIGNvbnRyaWJ1dGVkIHRvIHRoZSBlZmZvcnQ6CgogICBRaW9u ZyBTdW4KICAgQ2hpbmEgVGVsZWNvbQogICBSb29tIDcwOCwgTm8uMTE4LCBYaXpoaW1lbm5l aSBTdHJlZXQKICAgQmVpamluZyAxMDAwMzUKICAgUC5SLkNoaW5hCiAgIFBob25lOiArODYt MTAtNTg1NTI5MzYKICAgRW1haWw6IHN1bnFpb25nQGN0YnJpLmNvbS5jbgoKCiAgIFFpQm8g Tml1CiAgIFpURQogICA1MCxSdWFuSmlhbiBSb2FkLgogICBZdUh1YSBEaXN0cmljdCwKICAg TmFuIEppbmcgIDIxMDAxMgogICBQLlIuQ2hpbmEKICAgRW1haWw6IG5pdS5xaWJvQHp0ZS5j b20uY24KCgo8c3BhbiBjbGFzcz0iaDIiPjxoMj48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9 InNlY3Rpb24tMTMiIGhyZWY9IiNzZWN0aW9uLTEzIj4xMzwvYT4uICBSZWZlcmVuY2VzPC9o Mj48L3NwYW4+CgoKCgo8c3BhbiBjbGFzcz0iZ3JleSI+Q2hlbiwgZXQgYWwuICAgICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMTcsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMTRdPC9z cGFuPgo8L3ByZT48IS0tTmV3UGFnZS0tPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxhIG5hbWU9 InBhZ2UtMTUiIGlkPSJwYWdlLTE1IiBocmVmPSIjcGFnZS0xNSIgY2xhc3M9ImludmlzaWJs ZSI+IDwvYT4KPHNwYW4gY2xhc3M9ImdyZXkiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBOQVQ2NCBFeHBlcmllbmNlcyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxMzwvc3Bhbj4K Cgo8c3BhbiBjbGFzcz0iaDMiPjxoMz48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rp b24tMTMuMSIgaHJlZj0iI3NlY3Rpb24tMTMuMSI+MTMuMTwvYT4uICBOb3JtYXRpdmUgUmVm ZXJlbmNlczwvaDM+PC9zcGFuPgoKICAgWzxhIG5hbWU9InJlZi1JLUQuaWV0Zi1hcHBzYXdn LWh0dHAtZm9yd2FyZGVkIiBpZD0icmVmLUktRC5pZXRmLWFwcHNhd2ctaHR0cC1mb3J3YXJk ZWQiPkktRC5pZXRmLWFwcHNhd2ctaHR0cC1mb3J3YXJkZWQ8L2E+XQogICAgICAgICAgICAg IFBldGVyc3NvbiwgQS4gYW5kIE0uIE5pbHNzb24sICJGb3J3YXJkZWQgSFRUUCBFeHRlbnNp b24iLAogICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtYXBwc2F3Zy1odHRwLWZvcndhcmRlZC0xMCI+ZHJhZnQtaWV0Zi1hcHBz YXdnLWh0dHAtZm9yd2FyZGVkLTEwPC9hPiAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAg ICAgICAgT2N0b2JlciAyMDEyLgoKICAgWzxhIG5hbWU9InJlZi1JLUQuaWV0Zi1iZWhhdmUt bmF0NjQtZGlzY292ZXJ5LWhldXJpc3RpYyIgaWQ9InJlZi1JLUQuaWV0Zi1iZWhhdmUtbmF0 NjQtZGlzY292ZXJ5LWhldXJpc3RpYyI+SS1ELmlldGYtYmVoYXZlLW5hdDY0LWRpc2NvdmVy eS1oZXVyaXN0aWM8L2E+XQogICAgICAgICAgICAgIFNhdm9sYWluZW4sIFQuLCBLb3Job25l biwgSi4sIGFuZCBELiBXaW5nLCAiRGlzY292ZXJ5IG9mCiAgICAgICAgICAgICAgdGhlIElQ djYgUHJlZml4IFVzZWQgZm9yIElQdjYgQWRkcmVzcyBTeW50aGVzaXMiLCA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJlaGF2ZS1uYXQ2NC1kaXNj b3ZlcnktaGV1cmlzdGljLTE3Ij5kcmFmdC08L2E+CiAgICAgICAgICAgICAgPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZWhhdmUtbmF0NjQtZGlz Y292ZXJ5LWhldXJpc3RpYy0xNyI+aWV0Zi1iZWhhdmUtbmF0NjQtZGlzY292ZXJ5LWhldXJp c3RpYy0xNzwvYT4gKHdvcmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyksIEFwcmlsIDIw MTMuCgogICBbPGEgbmFtZT0icmVmLVJGQzI0NjAiIGlkPSJyZWYtUkZDMjQ2MCI+UkZDMjQ2 MDwvYT5dICBEZWVyaW5nLCBTLiBhbmQgUi4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2ws IFZlcnNpb24gNgogICAgICAgICAgICAgIChJUHY2KSBTcGVjaWZpY2F0aW9uIiwgPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjQ2MCI+UkZDIDI0NjA8L2E+LCBE ZWNlbWJlciAxOTk4LgoKICAgWzxhIG5hbWU9InJlZi1SRkMzNzA0IiBpZD0icmVmLVJGQzM3 MDQiPlJGQzM3MDQ8L2E+XSAgQmFrZXIsIEYuIGFuZCBQLiBTYXZvbGEsICJJbmdyZXNzIEZp bHRlcmluZyBmb3IgTXVsdGlob21lZAogICAgICAgICAgICAgIE5ldHdvcmtzIiwgPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvYmNwODQiPkJDUCA4NDwvYT4sIDxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM3MDQiPlJGQyAzNzA0PC9hPiwg TWFyY2ggMjAwNC4KCiAgIFs8YSBuYW1lPSJyZWYtUkZDNDE5MyIgaWQ9InJlZi1SRkM0MTkz Ij5SRkM0MTkzPC9hPl0gIEhpbmRlbiwgUi4gYW5kIEIuIEhhYmVybWFuLCAiVW5pcXVlIExv Y2FsIElQdjYgVW5pY2FzdAogICAgICAgICAgICAgIEFkZHJlc3NlcyIsIDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxOTMiPlJGQyA0MTkzPC9hPiwgT2N0b2Jl ciAyMDA1LgoKICAgWzxhIG5hbWU9InJlZi1SRkM0Nzg3IiBpZD0icmVmLVJGQzQ3ODciPlJG QzQ3ODc8L2E+XSAgQXVkZXQsIEYuIGFuZCBDLiBKZW5uaW5ncywgIk5ldHdvcmsgQWRkcmVz cyBUcmFuc2xhdGlvbgogICAgICAgICAgICAgIChOQVQpIEJlaGF2aW9yYWwgUmVxdWlyZW1l bnRzIGZvciBVbmljYXN0IFVEUCIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2JjcDEyNyI+QkNQIDEyNzwvYT4sCiAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDc4NyI+UkZDIDQ3ODc8L2E+LCBKYW51YXJ5IDIw MDcuCgogICBbPGEgbmFtZT0icmVmLVJGQzUzODIiIGlkPSJyZWYtUkZDNTM4MiI+UkZDNTM4 MjwvYT5dICBHdWhhLCBTLiwgQmlzd2FzLCBLLiwgRm9yZCwgQi4sIFNpdmFrdW1hciwgUy4s IGFuZCBQLgogICAgICAgICAgICAgIFNyaXN1cmVzaCwgIk5BVCBCZWhhdmlvcmFsIFJlcXVp cmVtZW50cyBmb3IgVENQIiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv YmNwMTQyIj5CQ1AgMTQyPC9hPiwKICAgICAgICAgICAgICA8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzgyIj5SRkMgNTM4MjwvYT4sIE9jdG9iZXIgMjAwOC4K CiAgIFs8YSBuYW1lPSJyZWYtUkZDNTQyNCIgaWQ9InJlZi1SRkM1NDI0Ij5SRkM1NDI0PC9h Pl0gIEdlcmhhcmRzLCBSLiwgIlRoZSBTeXNsb2cgUHJvdG9jb2wiLCA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDI0Ij5SRkMgNTQyNDwvYT4sIE1hcmNoIDIw MDkuCgogICBbPGEgbmFtZT0icmVmLVJGQzU1ODAiIGlkPSJyZWYtUkZDNTU4MCI+UkZDNTU4 MDwvYT5dICBUc2Nob2ZlbmlnLCBILiwgQWRyYW5naSwgRi4sIEpvbmVzLCBNLiwgTGlvciwg QS4sIGFuZCBCLgogICAgICAgICAgICAgIEFib2JhLCAiQ2FycnlpbmcgTG9jYXRpb24gT2Jq ZWN0cyBpbiBSQURJVVMgYW5kIERpYW1ldGVyIiwKICAgICAgICAgICAgICA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NTgwIj5SRkMgNTU4MDwvYT4sIEF1Z3Vz dCAyMDA5LgoKICAgWzxhIG5hbWU9InJlZi1SRkM1NzIyIiBpZD0icmVmLVJGQzU3MjIiPlJG QzU3MjI8L2E+XSAgS3Jpc2huYW4sIFMuLCAiSGFuZGxpbmcgb2YgT3ZlcmxhcHBpbmcgSVB2 NiBGcmFnbWVudHMiLAogICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzU3MjIiPlJGQyA1NzIyPC9hPiwgRGVjZW1iZXIgMjAwOS4KCiAgIFs8 YSBuYW1lPSJyZWYtUkZDNTc5OCIgaWQ9InJlZi1SRkM1Nzk4Ij5SRkM1Nzk4PC9hPl0gIE5h ZGFzLCBTLiwgIlZpcnR1YWwgUm91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wgKFZSUlApCiAg ICAgICAgICAgICAgVmVyc2lvbiAzIGZvciBJUHY0IGFuZCBJUHY2IiwgPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc5OCI+UkZDIDU3OTg8L2E+LCBNYXJjaCAy MDEwLgoKICAgWzxhIG5hbWU9InJlZi1SRkM1ODgwIiBpZD0icmVmLVJGQzU4ODAiPlJGQzU4 ODA8L2E+XSAgS2F0eiwgRC4gYW5kIEQuIFdhcmQsICJCaWRpcmVjdGlvbmFsIEZvcndhcmRp bmcgRGV0ZWN0aW9uCiAgICAgICAgICAgICAgKEJGRCkiLCA8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgwIj5SRkMgNTg4MDwvYT4sIEp1bmUgMjAxMC4KCiAg IFs8YSBuYW1lPSJyZWYtUkZDNjA1MiIgaWQ9InJlZi1SRkM2MDUyIj5SRkM2MDUyPC9hPl0g IEJhbywgQy4sIEh1aXRlbWEsIEMuLCBCYWdudWxvLCBNLiwgQm91Y2FkYWlyLCBNLiwgYW5k IFguCiAgICAgICAgICAgICAgTGksICJJUHY2IEFkZHJlc3Npbmcgb2YgSVB2NC9JUHY2IFRy YW5zbGF0b3JzIiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA1 MiI+UkZDIDYwNTI8L2E+LAogICAgICAgICAgICAgIE9jdG9iZXIgMjAxMC4KCgoKPHNwYW4g Y2xhc3M9ImdyZXkiPkNoZW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3 LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDE1XTwvc3Bhbj4KPC9wcmU+PCEtLU5ld1Bh Z2UtLT48cHJlIGNsYXNzPSJuZXdwYWdlIj48YSBuYW1lPSJwYWdlLTE2IiBpZD0icGFnZS0x NiIgaHJlZj0iI3BhZ2UtMTYiIGNsYXNzPSJpbnZpc2libGUiPiA8L2E+CjxzcGFuIGNsYXNz PSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgTkFUNjQgRXhwZXJpZW5jZXMg ICAgICAgICAgICAgICBPY3RvYmVyIDIwMTM8L3NwYW4+CgoKICAgWzxhIG5hbWU9InJlZi1S RkM2MTQ1IiBpZD0icmVmLVJGQzYxNDUiPlJGQzYxNDU8L2E+XSAgTGksIFguLCBCYW8sIEMu LCBhbmQgRi4gQmFrZXIsICJJUC9JQ01QIFRyYW5zbGF0aW9uCiAgICAgICAgICAgICAgQWxn b3JpdGhtIiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0NSI+ UkZDIDYxNDU8L2E+LCBBcHJpbCAyMDExLgoKICAgWzxhIG5hbWU9InJlZi1SRkM2MTQ2IiBp ZD0icmVmLVJGQzYxNDYiPlJGQzYxNDY8L2E+XSAgQmFnbnVsbywgTS4sIE1hdHRoZXdzLCBQ LiwgYW5kIEkuIHZhbiBCZWlqbnVtLCAiU3RhdGVmdWwKICAgICAgICAgICAgICBOQVQ2NDog TmV0d29yayBBZGRyZXNzIGFuZCBQcm90b2NvbCBUcmFuc2xhdGlvbiBmcm9tIElQdjYKICAg ICAgICAgICAgICBDbGllbnRzIHRvIElQdjQgU2VydmVycyIsIDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDYiPlJGQyA2MTQ2PC9hPiwgQXByaWwgMjAxMS4K CiAgIFs8YSBuYW1lPSJyZWYtUkZDNjE0NyIgaWQ9InJlZi1SRkM2MTQ3Ij5SRkM2MTQ3PC9h Pl0gIEJhZ251bG8sIE0uLCBTdWxsaXZhbiwgQS4sIE1hdHRoZXdzLCBQLiwgYW5kIEkuIHZh bgogICAgICAgICAgICAgIEJlaWpudW0sICJETlM2NDogRE5TIEV4dGVuc2lvbnMgZm9yIE5l dHdvcmsgQWRkcmVzcwogICAgICAgICAgICAgIFRyYW5zbGF0aW9uIGZyb20gSVB2NiBDbGll bnRzIHRvIElQdjQgU2VydmVycyIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzYxNDciPlJGQyA2MTQ3PC9hPiwKICAgICAgICAgICAgICBBcHJpbCAyMDExLgoK ICAgWzxhIG5hbWU9InJlZi1SRkM2Mzg0IiBpZD0icmVmLVJGQzYzODQiPlJGQzYzODQ8L2E+ XSAgdmFuIEJlaWpudW0sIEkuLCAiQW4gRlRQIEFwcGxpY2F0aW9uIExheWVyIEdhdGV3YXkg KEFMRykKICAgICAgICAgICAgICBmb3IgSVB2Ni10by1JUHY0IFRyYW5zbGF0aW9uIiwgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjM4NCI+UkZDIDYzODQ8L2E+ LCBPY3RvYmVyIDIwMTEuCgogICBbPGEgbmFtZT0icmVmLVJGQzY1NTUiIGlkPSJyZWYtUkZD NjU1NSI+UkZDNjU1NTwvYT5dICBXaW5nLCBELiBhbmQgQS4gWW91cnRjaGVua28sICJIYXBw eSBFeWViYWxsczogU3VjY2VzcyB3aXRoCiAgICAgICAgICAgICAgRHVhbC1TdGFjayBIb3N0 cyIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NTUiPlJGQyA2 NTU1PC9hPiwgQXByaWwgMjAxMi4KCiAgIFs8YSBuYW1lPSJyZWYtUkZDNjcyNCIgaWQ9InJl Zi1SRkM2NzI0Ij5SRkM2NzI0PC9hPl0gIFRoYWxlciwgRC4sIERyYXZlcywgUi4sIE1hdHN1 bW90bywgQS4sIGFuZCBULiBDaG93biwKICAgICAgICAgICAgICAiRGVmYXVsdCBBZGRyZXNz IFNlbGVjdGlvbiBmb3IgSW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA2CiAgICAgICAgICAg ICAgKElQdjYpIiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjcy NCI+UkZDIDY3MjQ8L2E+LCBTZXB0ZW1iZXIgMjAxMi4KCiAgIFs8YSBuYW1lPSJyZWYtUkZD Njg4NyIgaWQ9InJlZi1SRkM2ODg3Ij5SRkM2ODg3PC9hPl0gIFdpbmcsIEQuLCBDaGVzaGly ZSwgUy4sIEJvdWNhZGFpciwgTS4sIFBlbm5vLCBSLiwgYW5kIFAuCiAgICAgICAgICAgICAg U2Vsa2lyaywgIlBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKSIsIDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4ODciPlJGQyA2ODg3PC9hPiwgQXByaWwKICAg ICAgICAgICAgICAyMDEzLgoKICAgWzxhIG5hbWU9InJlZi1SRkM2OTQ2IiBpZD0icmVmLVJG QzY5NDYiPlJGQzY5NDY8L2E+XSAgR29udCwgRi4sICJQcm9jZXNzaW5nIG9mIElQdjYgIkF0 b21pYyIgRnJhZ21lbnRzIiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjk0NiI+UkZDPC9hPgogICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY5NDYiPjY5NDY8L2E+LCBNYXkgMjAxMy4KCjxzcGFuIGNsYXNz PSJoMyI+PGgzPjxhIGNsYXNzPSJzZWxmbGluayIgbmFtZT0ic2VjdGlvbi0xMy4yIiBocmVm PSIjc2VjdGlvbi0xMy4yIj4xMy4yPC9hPi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXM8L2gz Pjwvc3Bhbj4KCiAgIFs8YSBuYW1lPSJyZWYtQWxleGEiIGlkPSJyZWYtQWxleGEiPkFsZXhh PC9hPl0gICAgQWxleGEsICI8YSBocmVmPSJodHRwOi8vd3d3LmFsZXhhLmNvbS90b3BzaXRl cyI+aHR0cDovL3d3dy5hbGV4YS5jb20vdG9wc2l0ZXM8L2E+IiwgQXByaWwgMjAxMy4KCiAg IFs8YSBuYW1lPSJyZWYtQ2lzY28tVk5JIiBpZD0icmVmLUNpc2NvLVZOSSI+Q2lzY28tVk5J PC9hPl0KICAgICAgICAgICAgICBDaXNjbywgIkNpc2NvIFZpc3VhbCBOZXR3b3JraW5nIElu ZGV4OiBGb3JlY2FzdCBhbmQKICAgICAgICAgICAgICBNZXRob2RvbG9neSwgMjAxMi0yMDE3 LAogICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHA6Ly9jaXNjb3ZuaS5jb20vZm9yZWNhc3Qt d2lkZ2V0L2luZGV4Lmh0bWwiPmh0dHA6Ly9jaXNjb3ZuaS5jb20vZm9yZWNhc3Qtd2lkZ2V0 L2luZGV4Lmh0bWw8L2E+IiwgTWF5IDIwMTMuCgogICBbPGEgbmFtZT0icmVmLUktRC5hbmRl cnNvbi1zaWl0LWRjIiBpZD0icmVmLUktRC5hbmRlcnNvbi1zaWl0LWRjIj5JLUQuYW5kZXJz b24tc2lpdC1kYzwvYT5dCiAgICAgICAgICAgICAgQW5kZXJzb24sIFQuLCAiU3RhdGVsZXNz IElQL0lDTVAgVHJhbnNsYXRpb24gaW4gSVB2NiBEYXRhCiAgICAgICAgICAgICAgQ2VudHJl IEVudmlyb25tZW50cyIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWFuZGVyc29uLXNpaXQtZGMtMDAiPmRyYWZ0LWFuZGVyc29uLXNpaXQtZGMtMDA8L2E+ ICh3b3JrIGluCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBOb3ZlbWJlciAyMDEyLgoKICAg WzxhIG5hbWU9InJlZi1JLUQuY2hlbi1iZWhhdmUtbmF0NjQtcmFkaXVzLWV4dGVuc2lvbiIg aWQ9InJlZi1JLUQuY2hlbi1iZWhhdmUtbmF0NjQtcmFkaXVzLWV4dGVuc2lvbiI+SS1ELmNo ZW4tYmVoYXZlLW5hdDY0LXJhZGl1cy1leHRlbnNpb248L2E+XQogICAgICAgICAgICAgIENo ZW4sIEcuIGFuZCBELiBCaW5ldCwgIlJhZGl1cyBBdHRyaWJ1dGVzIGZvciBTdGF0ZWZ1bAog ICAgICAgICAgICAgIE5BVDY0IiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtY2hlbi1iZWhhdmUtbmF0NjQtcmFkaXVzLWV4dGVuc2lvbi0wMCI+ZHJhZnQt Y2hlbi1iZWhhdmUtbmF0NjQtcmFkaXVzLWV4dGVuc2lvbi0wMDwvYT4gKHdvcmsKICAgICAg ICAgICAgICBpbiBwcm9ncmVzcyksIEp1bHkgMjAxMy4KCgoKCjxzcGFuIGNsYXNzPSJncmV5 Ij5DaGVuLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAxNCAgICAg ICAgICAgICAgICBbUGFnZSAxNl08L3NwYW4+CjwvcHJlPjwhLS1OZXdQYWdlLS0+PHByZSBj bGFzcz0ibmV3cGFnZSI+PGEgbmFtZT0icGFnZS0xNyIgaWQ9InBhZ2UtMTciIGhyZWY9IiNw YWdlLTE3IiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPgo8c3BhbiBjbGFzcz0iZ3JleSI+SW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIE5BVDY0IEV4cGVyaWVuY2VzICAgICAgICAgICAg ICAgT2N0b2JlciAyMDEzPC9zcGFuPgoKCiAgIFs8YSBuYW1lPSJyZWYtSS1ELmNoZW4tc3Vu c2V0NC1jZ24tcG9ydC1hbGxvY2F0aW9uIiBpZD0icmVmLUktRC5jaGVuLXN1bnNldDQtY2du LXBvcnQtYWxsb2NhdGlvbiI+SS1ELmNoZW4tc3Vuc2V0NC1jZ24tcG9ydC1hbGxvY2F0aW9u PC9hPl0KICAgICAgICAgICAgICBDaGVuLCBHLiwgIkFuYWx5c2lzIG9mIE5BVDY0IFBvcnQg QWxsb2NhdGlvbiBNZXRob2QiLAogICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tc3Vuc2V0NC1jZ24tcG9ydC1hbGxvY2F0aW9u LTAyIj5kcmFmdC1jaGVuLXN1bnNldDQtY2duLXBvcnQtYWxsb2NhdGlvbi0wMjwvYT4gKHdv cmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyksIEp1bHkgMjAxMy4KCiAgIFs8YSBuYW1l PSJyZWYtSS1ELmRvbmxleS1iZWhhdmUtZGV0ZXJtaW5pc3RpYy1jZ24iIGlkPSJyZWYtSS1E LmRvbmxleS1iZWhhdmUtZGV0ZXJtaW5pc3RpYy1jZ24iPkktRC5kb25sZXktYmVoYXZlLWRl dGVybWluaXN0aWMtY2duPC9hPl0KICAgICAgICAgICAgICBEb25sZXksIEMuLCBHcnVuZGVt YW5uLCBDLiwgU2FyYXdhdCwgVi4sIFN1bmRhcmVzYW4sIEsuLAogICAgICAgICAgICAgIGFu ZCBPLiBWYXV0cmluLCAiRGV0ZXJtaW5pc3RpYyBBZGRyZXNzIE1hcHBpbmcgdG8gUmVkdWNl CiAgICAgICAgICAgICAgTG9nZ2luZyBpbiBDYXJyaWVyIEdyYWRlIE5BVCBEZXBsb3ltZW50 cyIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmxleS1i ZWhhdmUtZGV0ZXJtaW5pc3RpYy1jZ24tMDYiPmRyYWZ0LWRvbmxleS08L2E+CiAgICAgICAg ICAgICAgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9ubGV5 LWJlaGF2ZS1kZXRlcm1pbmlzdGljLWNnbi0wNiI+YmVoYXZlLWRldGVybWluaXN0aWMtY2du LTA2PC9hPiAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxMy4KCiAgIFs8YSBuYW1lPSJy ZWYtSS1ELmlldGYtc29mdHdpcmUtNHJkIiBpZD0icmVmLUktRC5pZXRmLXNvZnR3aXJlLTRy ZCI+SS1ELmlldGYtc29mdHdpcmUtNHJkPC9hPl0KICAgICAgICAgICAgICBEZXNwcmVzLCBS LiwgSmlhbmcsIFMuLCBQZW5ubywgUi4sIExlZSwgWS4sIENoZW4sIEcuLCBhbmQKICAgICAg ICAgICAgICBNLiBDaGVuLCAiSVB2NCBSZXNpZHVhbCBEZXBsb3ltZW50IHZpYSBJUHY2IC0g YSBTdGF0ZWxlc3MKICAgICAgICAgICAgICBTb2x1dGlvbiAoNHJkKSIsIDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc29mdHdpcmUtNHJkLTA3Ij5k cmFmdC1pZXRmLXNvZnR3aXJlLTRyZC0wNzwvYT4gKHdvcmsgaW4KICAgICAgICAgICAgICBw cm9ncmVzcyksIE9jdG9iZXIgMjAxMy4KCiAgIFs8YSBuYW1lPSJyZWYtSS1ELmlldGYtc29m dHdpcmUtbWFwLWRlcGxveW1lbnQiIGlkPSJyZWYtSS1ELmlldGYtc29mdHdpcmUtbWFwLWRl cGxveW1lbnQiPkktRC5pZXRmLXNvZnR3aXJlLW1hcC1kZXBsb3ltZW50PC9hPl0KICAgICAg ICAgICAgICBTdW4sIFEuLCBDaGVuLCBNLiwgQ2hlbiwgRy4sIFRzb3UsIFQuLCBhbmQgUy4g UGVycmVhdWx0LAogICAgICAgICAgICAgICJNYXBwaW5nIG9mIEFkZHJlc3MgYW5kIFBvcnQg KE1BUCkgLSBEZXBsb3ltZW50CiAgICAgICAgICAgICAgQ29uc2lkZXJhdGlvbnMiLCA8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNvZnR3aXJlLW1h cC1kZXBsb3ltZW50LTAyIj5kcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC1kZXBsb3ltZW50LTAy PC9hPgogICAgICAgICAgICAgICh3b3JrIGluIHByb2dyZXNzKSwgSnVseSAyMDEzLgoKICAg WzxhIG5hbWU9InJlZi1JLUQuaWV0Zi1zb2Z0d2lyZS1tYXAtdCIgaWQ9InJlZi1JLUQuaWV0 Zi1zb2Z0d2lyZS1tYXAtdCI+SS1ELmlldGYtc29mdHdpcmUtbWFwLXQ8L2E+XQogICAgICAg ICAgICAgIExpLCBYLiwgQmFvLCBDLiwgRGVjLCBXLiwgVHJvYW4sIE8uLCBNYXRzdXNoaW1h LCBTLiwgYW5kCiAgICAgICAgICAgICAgVC4gTXVyYWthbWksICJNYXBwaW5nIG9mIEFkZHJl c3MgYW5kIFBvcnQgdXNpbmcKICAgICAgICAgICAgICBUcmFuc2xhdGlvbiAoTUFQLVQpIiwg PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2Z0d2ly ZS1tYXAtdC0wNCI+ZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtdC0wNDwvYT4gKHdvcmsKICAg ICAgICAgICAgICBpbiBwcm9ncmVzcyksIFNlcHRlbWJlciAyMDEzLgoKICAgWzxhIG5hbWU9 InJlZi1JLUQuaWV0Zi1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb24iIGlkPSJy ZWYtSS1ELmlldGYtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uIj5JLUQuaWV0 Zi1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb248L2E+XQogICAgICAgICAgICAg IEJvdWNhZGFpciwgTS4sIE1hdHN1c2hpbWEsIFMuLCBMZWUsIFkuLCBCb25uZXNzLCBPLiwK ICAgICAgICAgICAgICBCb3JnZXMsIEkuLCBhbmQgRy4gQ2hlbiwgIk1vdGl2YXRpb25zIGZv ciBDYXJyaWVyLXNpZGUKICAgICAgICAgICAgICBTdGF0ZWxlc3MgSVB2NCBvdmVyIElQdjYg TWlncmF0aW9uIFNvbHV0aW9ucyIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTA1Ij5k cmFmdC1pZXRmLTwvYT4KICAgICAgICAgICAgICA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlv bi0wNSI+c29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTA1PC9hPiAod29yayBp biBwcm9ncmVzcyksCiAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMi4KCiAgIFs8YSBuYW1l PSJyZWYtSS1ELmlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aW9ucyIgaWQ9InJl Zi1JLUQuaWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zIj5JLUQuaWV0Zi12 Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zPC9hPl0KICAgICAgICAgICAgICBMaXUs IEIuLCBKaWFuZywgUy4sIGFuZCBDLiBCeXJuZSwgIlJlY29tbWVuZGF0aW9ucyBvZgogICAg ICAgICAgICAgIFVzaW5nIFVuaXF1ZSBMb2NhbCBBZGRyZXNzZXMiLCA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNv bW1lbmRhdGlvbnMtMDAiPmRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLTwvYT4KICAgICAg ICAgICAgICA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMtMDAiPnJlY29tbWVuZGF0aW9ucy0w MDwvYT4gKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXkgMjAxMy4KCiAgIFs8YSBuYW1lPSJyZWYt SS1ELmthbGl3b2RhLXN1bnNldDQtZHVhbC1pcHY2LWNvZXhpc3QiIGlkPSJyZWYtSS1ELmth bGl3b2RhLXN1bnNldDQtZHVhbC1pcHY2LWNvZXhpc3QiPkktRC5rYWxpd29kYS1zdW5zZXQ0 LWR1YWwtaXB2Ni1jb2V4aXN0PC9hPl0KICAgICAgICAgICAgICBLYWxpd29kYSwgQS4gYW5k IEQuIEJpbmV0LCAiQ28tZXhpc3RlbmNlIG9mIGJvdGggZHVhbC0KICAgICAgICAgICAgICBz dGFjayBhbmQgSVB2Ni1vbmx5IGhvc3RzIiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQta2FsaXdvZGEtc3Vuc2V0NC1kdWFsLWlwdjYtY29leGlzdC0wMSI+ ZHJhZnQta2FsaXdvZGEtc3Vuc2V0NC1kdWFsLTwvYT4KICAgICAgICAgICAgICA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rYWxpd29kYS1zdW5zZXQ0LWR1 YWwtaXB2Ni1jb2V4aXN0LTAxIj5pcHY2LWNvZXhpc3QtMDE8L2E+ICh3b3JrIGluIHByb2dy ZXNzKSwgT2N0b2JlciAyMDEyLgoKICAgWzxhIG5hbWU9InJlZi1SRkMzNDg0IiBpZD0icmVm LVJGQzM0ODQiPlJGQzM0ODQ8L2E+XSAgRHJhdmVzLCBSLiwgIkRlZmF1bHQgQWRkcmVzcyBT ZWxlY3Rpb24gZm9yIEludGVybmV0CiAgICAgICAgICAgICAgUHJvdG9jb2wgdmVyc2lvbiA2 IChJUHY2KSIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM0ODQi PlJGQyAzNDg0PC9hPiwgRmVicnVhcnkgMjAwMy4KCgoKPHNwYW4gY2xhc3M9ImdyZXkiPkNo ZW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE3LCAyMDE0ICAgICAgICAg ICAgICAgIFtQYWdlIDE3XTwvc3Bhbj4KPC9wcmU+PCEtLU5ld1BhZ2UtLT48cHJlIGNsYXNz PSJuZXdwYWdlIj48YSBuYW1lPSJwYWdlLTE4IiBpZD0icGFnZS0xOCIgaHJlZj0iI3BhZ2Ut MTgiIGNsYXNzPSJpbnZpc2libGUiPiA8L2E+CjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgTkFUNjQgRXhwZXJpZW5jZXMgICAgICAgICAgICAgICBP Y3RvYmVyIDIwMTM8L3NwYW4+CgoKICAgWzxhIG5hbWU9InJlZi1SRkM2MDM2IiBpZD0icmVm LVJGQzYwMzYiPlJGQzYwMzY8L2E+XSAgQ2FycGVudGVyLCBCLiBhbmQgUy4gSmlhbmcsICJF bWVyZ2luZyBTZXJ2aWNlIFByb3ZpZGVyCiAgICAgICAgICAgICAgU2NlbmFyaW9zIGZvciBJ UHY2IERlcGxveW1lbnQiLCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2MDM2Ij5SRkMgNjAzNjwvYT4sIE9jdG9iZXIgMjAxMC4KCiAgIFs8YSBuYW1lPSJyZWYt UkZDNjA1NiIgaWQ9InJlZi1SRkM2MDU2Ij5SRkM2MDU2PC9hPl0gIExhcnNlbiwgTS4gYW5k IEYuIEdvbnQsICJSZWNvbW1lbmRhdGlvbnMgZm9yIFRyYW5zcG9ydC0KICAgICAgICAgICAg ICBQcm90b2NvbCBQb3J0IFJhbmRvbWl6YXRpb24iLCA8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9iY3AxNTYiPkJDUCAxNTY8L2E+LCA8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDU2Ij5SRkMgNjA1NjwvYT4sIEphbnVhcnkKICAgICAg ICAgICAgICAyMDExLgoKICAgWzxhIG5hbWU9InJlZi1SRkM2MTQ0IiBpZD0icmVmLVJGQzYx NDQiPlJGQzYxNDQ8L2E+XSAgQmFrZXIsIEYuLCBMaSwgWC4sIEJhbywgQy4sIGFuZCBLLiBZ aW4sICJGcmFtZXdvcmsgZm9yCiAgICAgICAgICAgICAgSVB2NC9JUHY2IFRyYW5zbGF0aW9u IiwgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0NCI+UkZDIDYx NDQ8L2E+LCBBcHJpbCAyMDExLgoKICAgWzxhIG5hbWU9InJlZi1SRkM2MjY5IiBpZD0icmVm LVJGQzYyNjkiPlJGQzYyNjk8L2E+XSAgRm9yZCwgTS4sIEJvdWNhZGFpciwgTS4sIER1cmFu ZCwgQS4sIExldmlzLCBQLiwgYW5kIFAuCiAgICAgICAgICAgICAgUm9iZXJ0cywgIklzc3Vl cyB3aXRoIElQIEFkZHJlc3MgU2hhcmluZyIsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzYyNjkiPlJGQyA2MjY5PC9hPiwgSnVuZQogICAgICAgICAgICAgIDIw MTEuCgogICBbPGEgbmFtZT0icmVmLVJGQzYzNDYiIGlkPSJyZWYtUkZDNjM0NiI+UkZDNjM0 NjwvYT5dICBCdXNoLCBSLiwgIlRoZSBBZGRyZXNzIHBsdXMgUG9ydCAoQStQKSBBcHByb2Fj aCB0byB0aGUKICAgICAgICAgICAgICBJUHY0IEFkZHJlc3MgU2hvcnRhZ2UiLCA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MzQ2Ij5SRkMgNjM0NjwvYT4sIEF1 Z3VzdCAyMDExLgoKICAgWzxhIG5hbWU9InJlZi1SRkM2NDU5IiBpZD0icmVmLVJGQzY0NTki PlJGQzY0NTk8L2E+XSAgS29yaG9uZW4sIEouLCBTb2luaW5lbiwgSi4sIFBhdGlsLCBCLiwg U2F2b2xhaW5lbiwgVC4sCiAgICAgICAgICAgICAgQmFqa28sIEcuLCBhbmQgSy4gSWlzYWtr aWxhLCAiSVB2NiBpbiAzcmQgR2VuZXJhdGlvbgogICAgICAgICAgICAgIFBhcnRuZXJzaGlw IFByb2plY3QgKDNHUFApIEV2b2x2ZWQgUGFja2V0IFN5c3RlbSAoRVBTKSIsCiAgICAgICAg ICAgICAgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQ1OSI+UkZD IDY0NTk8L2E+LCBKYW51YXJ5IDIwMTIuCgogICBbPGEgbmFtZT0icmVmLVJGQzY1ODYiIGlk PSJyZWYtUkZDNjU4NiI+UkZDNjU4NjwvYT5dICBBcmtrbywgSi4gYW5kIEEuIEtlcmFuZW4s ICJFeHBlcmllbmNlcyBmcm9tIGFuIElQdjYtT25seQogICAgICAgICAgICAgIE5ldHdvcmsi LCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTg2Ij5SRkMgNjU4 NjwvYT4sIEFwcmlsIDIwMTIuCgogICBbPGEgbmFtZT0icmVmLVJGQzY4NzciIGlkPSJyZWYt UkZDNjg3NyI+UkZDNjg3NzwvYT5dICBNYXdhdGFyaSwgTS4sIEthd2FzaGltYSwgTS4sIGFu ZCBDLiBCeXJuZSwgIjQ2NFhMQVQ6CiAgICAgICAgICAgICAgQ29tYmluYXRpb24gb2YgU3Rh dGVmdWwgYW5kIFN0YXRlbGVzcyBUcmFuc2xhdGlvbiIsIDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY4NzciPlJGQzwvYT4KICAgICAgICAgICAgICA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODc3Ij42ODc3PC9hPiwgQXByaWwg MjAxMy4KCiAgIFs8YSBuYW1lPSJyZWYtUkZDNjg4MyIgaWQ9InJlZi1SRkM2ODgzIj5SRkM2 ODgzPC9hPl0gIENhcnBlbnRlciwgQi4gYW5kIFMuIEppYW5nLCAiSVB2NiBHdWlkYW5jZSBm b3IgSW50ZXJuZXQKICAgICAgICAgICAgICBDb250ZW50IFByb3ZpZGVycyBhbmQgQXBwbGlj YXRpb24gU2VydmljZSBQcm92aWRlcnMiLCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2ODgzIj5SRkM8L2E+CiAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjg4MyI+Njg4MzwvYT4sIE1hcmNoIDIwMTMuCgog ICBbPGEgbmFtZT0icmVmLVJGQzY5NjciIGlkPSJyZWYtUkZDNjk2NyI+UkZDNjk2NzwvYT5d ICBCb3VjYWRhaXIsIE0uLCBUb3VjaCwgSi4sIExldmlzLCBQLiwgYW5kIFIuIFBlbm5vLAog ICAgICAgICAgICAgICJBbmFseXNpcyBvZiBQb3RlbnRpYWwgU29sdXRpb25zIGZvciBSZXZl YWxpbmcgYSBIb3N0CiAgICAgICAgICAgICAgSWRlbnRpZmllciAoSE9TVF9JRCkgaW4gU2hh cmVkIEFkZHJlc3MgRGVwbG95bWVudHMiLCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2OTY3Ij5SRkM8L2E+CiAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk2NyI+Njk2NzwvYT4sIEp1bmUgMjAxMy4KCjxz cGFuIGNsYXNzPSJoMiI+PGgyPjxhIGNsYXNzPSJzZWxmbGluayIgbmFtZT0iYXBwZW5kaXgt QSIgaHJlZj0iI2FwcGVuZGl4LUEiPkFwcGVuZGl4IEE8L2E+LiAgVGVzdGluZyBSZXN1bHRz IG9mIEFwcGxpY2F0aW9uIEJlaGF2aW9yPC9oMj48L3NwYW4+CgogICBXZSB0ZXN0IHNldmVy YWwgYXBwbGljYXRpb24gYmVoYXZpb3JzIGluIGEgbGFiIGVudmlyb25tZW50IHRvCiAgIGV2 YWx1YXRlIHRoZSBpbXBhY3Qgd2hlbiBhIHByaW1hcnkgTkFUNjQgaXMgb3V0IG9mIHNlcnZp Y2UuICBJbiB0aGlzCiAgIHRlc3RpbmcsIHBhcnRpY2lwYW50cyBhcmUgYXNrZWQgdG8gY29u bmVjdCBhIElQdjYtb25seSBXaUZpIG5ldHdvcmsKICAgdXNpbmcgbGFwdG9wcywgdGFibGV0 cyBvciBtb2JpbGUgcGhvbmVzLiAgTkFUNjQgaXMgZGVwbG95ZWQgYXMgdGhlCiAgIGdhdGV3 YXkgdG8gY29ubmVjdCBJbnRlcm5ldCBzZXJ2aWNlLiAgVGhlIHRlc3RlZCBhcHBsaWNhdGlv bnMgYXJlCiAgIHNob3duIGluIHRoZSBiZWxvdyB0YWJsZS4gIENvbGQgc3RhbmRieSwgd2Fy bSBzdGFuZGJ5IGFuZCBob3Qgc3RhbmRieQogICBhcmUgdGFrZW4gdHJ1bnMgdG8gYmUgdGVz dGVkLiAgVGhlIHBhcnRpcGFudHMgbWF5IGV4cGVyaWVuY2Ugc2VydmljZQogICBpbnRlcnJ1 cHRpb24gZHVlIHRvIHRoZSBOQVQ2NCBoYW5kb3Zlci4gIERpZmZlcmVudCBpbnRlcnJ1cHRp b24KCgoKPHNwYW4gY2xhc3M9ImdyZXkiPkNoZW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBp cmVzIEFwcmlsIDE3LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDE4XTwvc3Bhbj4KPC9w cmU+PCEtLU5ld1BhZ2UtLT48cHJlIGNsYXNzPSJuZXdwYWdlIj48YSBuYW1lPSJwYWdlLTE5 IiBpZD0icGFnZS0xOSIgaHJlZj0iI3BhZ2UtMTkiIGNsYXNzPSJpbnZpc2libGUiPiA8L2E+ CjxzcGFuIGNsYXNzPSJncmV5Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgTkFUNjQg RXhwZXJpZW5jZXMgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTM8L3NwYW4+CgoKICAgaW50 ZXJ2YWxzIGFyZSB0ZXN0ZWQgdG8gZ2F1Z2UgYXBwbGljYXRpb24gYmVoYXZpb3JzLiAgVGhl IHJlc3VsdHMgYXJlCiAgIGlsbHVtaW5hdGVkIGFzIGJlbG93LgoKICAgICAgICAgICAgICAg ICAgVGFibGUgMTogVGhlIGFjY2VwdGFibGUgZGVsYXkgb2YgYXBwbGljYXRpb25zCiAgICst LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwogICB8ICAgICBBUFBzICAgICAgIHwgQWNjZXB0YWJsZSBJbnRlcnJ1 cHQgICB8ICAgU2Vzc2lvbiBDb250aW51aXR5ICAgIHwKICAgfCAgICAgICAgICAgICAgICB8 ICAgICAgICBSZWNvdmVyeSAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwogICB8IFdlYiBCcm93c2UgICAgIHxBcyBtYXhpbXVtIGFzIDZz ICAgICAgICB8ICBObyAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CiAgIHxIdHRwIHN0cmVhbWluZyAgfEFzIG1heGltdW0gYXMgMTBzKGNhY2hlKXwgIFllcyAg ICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCBHYW1pbmcgICAg ICAgICB8IDIwMG1zfjQwMG1zICAgICAgICAgICAgfCAgWWVzICAgICAgICAgICAgICAgICAg ICB8CiAgICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IFAyUCAgICAgICAgICAgIHwgMTB+MTZzICAg ICAgICAgICAgICAgICB8ICBZZXMgICAgICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgIHxJbnN0YW50IE1lc3NhZ2UgfDEgbWludXRlICAgICAgICAgICAgICAgIHwg IFllcyAgICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfE1haWwg ICAgICAgICAgICB8MzAgc2Vjb25kcyAgICAgICAgICAgICAgfCAgTm8gICAgICAgICAgICAg ICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8RG93bmxvYWRpbmcgICAgIHwxIG1p bnV0ZXMgICAgICAgICAgICAgICB8ICBObyAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBHYW5nIENoZW4KICAgQ2hp bmEgTW9iaWxlCiAgIDUzQSxYaWJpYW5tZW5uZWkgQXZlLiwKICAgWHVhbnd1IERpc3RyaWN0 LAogICBCZWlqaW5nICAxMDAwNTMKICAgQ2hpbmEKCiAgIEVtYWlsOiBwaGRnYW5nQGdtYWls LmNvbQoKCiAgIFpoZW4gQ2FvCiAgIENoaW5hIE1vYmlsZQogICA1M0EsWGliaWFubWVubmVp IEF2ZS4sCiAgIFh1YW53dSBEaXN0cmljdCwKICAgQmVpamluZyAgMTAwMDUzCiAgIENoaW5h CgogICBFbWFpbDogY2FvemhlbkBjaGluYW1vYmlsZS5jb20KCgoKCgoKCjxzcGFuIGNsYXNz PSJncmV5Ij5DaGVuLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAx NCAgICAgICAgICAgICAgICBbUGFnZSAxOV08L3NwYW4+CjwvcHJlPjwhLS1OZXdQYWdlLS0+ PHByZSBjbGFzcz0ibmV3cGFnZSI+PGEgbmFtZT0icGFnZS0yMCIgaWQ9InBhZ2UtMjAiIGhy ZWY9IiNwYWdlLTIwIiBjbGFzcz0iaW52aXNpYmxlIj4gPC9hPgo8c3BhbiBjbGFzcz0iZ3Jl eSI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIE5BVDY0IEV4cGVyaWVuY2VzICAgICAg ICAgICAgICAgT2N0b2JlciAyMDEzPC9zcGFuPgoKCiAgIENob25nZmVuZyBYaWUKICAgQ2hp bmEgVGVsZWNvbQogICBSb29tIDcwOCBOby4xMTgsIFhpemhpbWVubmVpZGFqaWUKICAgQmVp amluZyAgMTAwMDM1CiAgIFAuUi5DaGluYQoKICAgRW1haWw6IHhpZWNoZkBjdGJyaS5jb20u Y24KCgogICBEYXZpZCBCaW5ldAogICBGcmFuY2UgVGVsZWNvbS1PcmFuZ2UKICAgUmVubmVz CiAgIDM1MDAwCiAgIEZyYW5jZQoKICAgRW1haWw6IGRhdmlkLmJpbmV0QG9yYW5nZS5jb20K CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDaGVuLCBldCBhbC4gICAgICAg ICAgICAgRXhwaXJlcyBBcHJpbCAxNywgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAyMF0K CjwvcHJlPjxicj4KPHNwYW4gY2xhc3M9Im5vcHJpbnQiPjxzbWFsbD48c21hbGw+SHRtbCBt YXJrdXAgcHJvZHVjZWQgYnkgcmZjbWFya3VwIDEuMTA0LCBhdmFpbGFibGUgZnJvbQo8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjbWFya3VwLyI+aHR0cDovL3Rv b2xzLmlldGYub3JnL3Rvb2xzL3JmY21hcmt1cC88L2E+Cjwvc21hbGw+PC9zbWFsbD48L3Nw YW4+Cgo8L2JvZHk+PC9odG1sPg== --B_3466161678_9595586-- From mellon@fugue.com Wed Oct 30 05:07: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 83A1221F9CEA for ; Wed, 30 Oct 2013 05:07:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PafdbJbABDQT for ; Wed, 30 Oct 2013 05:07:44 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29F21F93BA for ; Wed, 30 Oct 2013 05:07:43 -0700 (PDT) Received: from [IPv6:2001:470:88a3::68c9:8d27:9147:2bb6] (unknown [IPv6:2001:470:88a3:0:68c9:8d27:9147:2bb6]) by toccata.fugue.com (Postfix) with ESMTPSA id B1B0823803AE; Wed, 30 Oct 2013 08:07:34 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ted Lemon In-Reply-To: <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 30 Oct 2013 08:07:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9631E070-0CC7-4D19-9FC7-3E8091A5395A@fugue.com> References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Sun, 03 Nov 2013 08:09:31 -0800 Cc: "v6ops@ietf.org" , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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 Oct 2013 12:07:50 -0000 On Oct 30, 2013, at 4:22 AM, Mark ZZZ Smith = wrote: > I think DHCPv6 is really solving the application layer configuration = problem, which is independent of and not specific to the underlying = links and network layer parameters. Actually DHCPv6 is a poor solution to that problem, because application = configuration is not typically network-specific. This has been = discussed at some length recently on the IETF mailing list. From mellon@fugue.com Wed Oct 30 14:24: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 308B011E819F for ; Wed, 30 Oct 2013 14:24:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPsZAM7MGx0a for ; Wed, 30 Oct 2013 14:24:01 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD3821F9D5F for ; Wed, 30 Oct 2013 14:24:01 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 927B123803AE; Wed, 30 Oct 2013 17:23:57 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ted Lemon In-Reply-To: <1383163564.25414.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 30 Oct 2013 17:23:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63042B8A-0C08-435F-8C94-D33BF8F936F6@fugue.com> References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> <9631E070-0CC7-4D19-9FC7-3E8091A5395A@fugue.com> <1383163564.25414.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Sun, 03 Nov 2013 08:09:31 -0800 Cc: "v6ops@ietf.org" , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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 Oct 2013 21:24:07 -0000 On Oct 30, 2013, at 4:06 PM, Mark ZZZ Smith = wrote: > I have recently been thinking a bit more about that in the context of = the DHCPv6 option transparency draft I posted, and have started to = wonder if LDAP or SLP style directories would be better, with a special = well known directory branch to represent network or subnet local = application parameters. No, that's not the issue at all. The issue is that there is typically = nothing the local network can tell you about, e.g., which SMTP server = will work with your email address, or which POP or IMAP server might = store your email. In the general case, those services are not even = present on the local network, so the local network has no way to tell = you about them, and even if it did, why would you trust it to do so? From leaf.yeh.sdo@gmail.com Sun Nov 3 08:34: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 5DFCC11E8147 for ; Sun, 3 Nov 2013 08:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D75U1XgKW6a for ; Sun, 3 Nov 2013 08:34:13 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9B09B21E80C5 for ; Sun, 3 Nov 2013 08:34:13 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so6277756pbb.1 for ; Sun, 03 Nov 2013 08:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=LvrnrHQVfDRRUFdIbKp+SGdSmvrZAT40q/660vI/XiI=; b=oWd3tfsQxKLmkHmtaoA649VyXbrskpMqa8UHPThEtjrnnGaRlY7V7gtzgP7PQGOPn+ +xr/RDGSFpIlooykYTkg4qRzRdBXqfMSEQt9j7pSI9nxc7xX7qEZHEutACjOsKC6q+MC jwEFbbWw3CZiVB716uG7030Vqs/ePKLGcoNBkJUF+Kccp97XNJifNdaeQWjK6e53Txes GMtGK179lxDXElUe4JkZbbXrDw0KqmfAtog5+t/HqDArmAunv+A9RT4g5PQYjtKF/JEe 0K6oQAljym2K9N+UInXLeaKFKVhPoWsvNN9rvGTSx4EGpu9YdRYu61rPDGqn4B9i6Y3W eJ5A== X-Received: by 10.66.197.135 with SMTP id iu7mr1558150pac.149.1383496453278; Sun, 03 Nov 2013 08:34:13 -0800 (PST) Received: from PC ([218.18.197.14]) by mx.google.com with ESMTPSA id pl1sm23019258pbb.20.2013.11.03.08.34.05 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Nov 2013 08:34:12 -0800 (PST) From: "Leaf Yeh" To: "'Alexandru Petrescu'" , "'Ole Troan'" References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> <5253B80E.7030008@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz> <5253C891.7090009@gmail.com> <526662F2.1060808@gmail.com> <52752B8A.4000907@gmail.com> In-Reply-To: <52752B8A.4000907@gmail.com> Date: Mon, 4 Nov 2013 00:33:56 +0800 Message-ID: <52767b04.a186440a.6603.ffffbd7b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7X6pYLAi3YOFT/Qf6pzW0xnhnTeQAwjkNA Content-Language: zh-cn Cc: v6ops@ietf.org Subject: Re: [v6ops] Announcing draft-petrescu-relay-route-pd-problem-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: Sun, 03 Nov 2013 16:34:14 -0000 Ole - should we ask Markus to kick http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00 back = into life? Alex - With respect to the need of combining that other solution, not = being independent, I think Leaf could explain that. Right? I read draft-petrescu here targets the routing issue on the relay, which sounds a network component not included in the Fig.1 titled 'Possible = prefix delegation deployment cases' in the draft-stenberg. I guess the draft-stenberg might intend to suggest some so-called 'approaches' for the Requesting Routers (RR) or Delegating Routers (DR), = or even Backend provisioning system against some (frankly speaking, vague) issues, but not for the relay agent of DHCPv6. I also have not read out the solid protocol enhancement for DHCPv6 from draft-stenberg yet. Best Regards, Leaf -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Sunday, November 03, 2013 12:43 AM To: Ole Troan Cc: Leaf Yeh; mohamed.boucadair@orange.com Subject: Re: [v6ops] Announcing draft-petrescu-relay-route-pd-problem-00 Ole, Thank you for the comment. Yes, I think such text with that analogy = could help clarify. I will be happy to include you as co-author if you provided text. Yes, why not ask Markus to kick that other draft back into life? With respect to the need of combining that other solution, not being independent, I think Leaf could explain that. Right? Alex Le 01/11/2013 16:33, Ole Troan a =E9crit : > Alexandru, > > with regards to your solutions; 5.3. > draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for prefix pool of PD isn't=20 > standalone, that has to be combined with solution in 5.1 or 5.2. > > I think you could add some text where you draw an analogy to having a=20 > statically configured aggregate route, with configuring a prefix > (/64) for address assignment. routing is set up very similarly. that=20 > could go in section 3.1. "Allocating a prefix is an operation=20 > different..." > > should we ask Markus to kick > http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00 > back into life? > > cheers, Ole > > On 22 Oct 2013, at 13:35 , Alexandru Petrescu=20 > wrote: > >> Hello participants to v6ops WG, >> >> We have just submitted draft-petrescu-relay-route-pd-problem-00 >> http://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00 >> >> "Route Problem at Relay during DHCPv6 Prefix Delegation" >> M. Boucadair (France Telecom) L. Yeh (Freelancer Technologies) A. >> Petrescu (CEA). >> >> It presents a problem of routing at Relay during Prefix Delegation of = >> DHCPv6; also lists some solutions I-Ds. The problem may be relevant=20 >> in the DHC WG, at the Broadband Forum and maybe at 3GPP. >> >> Please comment on this draft. >> >> Thanks, >> >> Alex >> >> Le 08/10/2013 10:55, Alexandru Petrescu a =E9crit : >>> Le 08/10/2013 10:49, V=EDzdal Ale=B9 a =E9crit : >>>>>> The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP=20 >>>>>> through all the intermediate nodes. >>>>> >>>>> Ah, right, there is a GTP tunnel above all the intermediary IP=20 >>>>> nodes. >>>>> >>>>> However, even when a tunnel is dynamically set up, a routing table = >>>>> entry is added in the Relay's routing table (or other similar=20 >>>>> entry). The parameters of that entry necessarily include, among=20 >>>>> others, the prefix which is allocated. >>>>> >>>>> No? >>>> >>>> The tunnel stays up for the lifetime of the PDP/PDN context. >>> >>> Ok. >>> >>>> There is no relay in the 3GPP access architecture. >>> >>> Ok. >>> >>>> If the tunnel drops, the PGW/GGSN will remove the route from their=20 >>>> routing table, once a new tunnel is setup the routing table is=20 >>>> updated accordingly. >>> >>> The route associated with that tunnel should contain a parameter=20 >>> containing the Delegated Prefix. When there is no delegated prefix, = >>> that route entry should be updated. >>> >>> The tunnel could stay up but only for the Smartphone. Or it could=20 >>> stay up for both the Smartphone _and_ the Hosts in the smartphone's=20 >>> LAN. These are two different things. >>> >>> Alex >>> >>> >>>> >>>>> Alex >>>> >>>> Ales >>>> >>>> >>> >>> >>> _______________________________________________ v6ops mailing list=20 >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ v6ops mailing list=20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From phdgang@gmail.com Sun Nov 3 16:41: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 5516B21F9DCE for ; Sun, 3 Nov 2013 16:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlqWgeiTKhZI for ; Sun, 3 Nov 2013 16:41:41 -0800 (PST) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 984F121F9E9C for ; Sun, 3 Nov 2013 16:41:40 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id d4so3736545qej.21 for ; Sun, 03 Nov 2013 16:41:40 -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=G7BJfXHh5cNdr/e6zNHSdXHqCKwIim/AcabMTQXu140=; b=iabfICmWhSUICLMAe1IApaSrZzRssx8E9NBK/CyseW79oXUEiFnifgodY/qoXhNedd 7lnE/iAk4MLQ3URTTrdG/GTM5Q7VyyhrJqagR3ncVRlZmMlWE4St2VHPp/LvB/pxcAYW RGNRQwJVaRDau94J4kXrlwPmYzLwBjDqwB7iXLvXMpcOgqr0Omlk0WJLlGJFUWQWHNxV zV7lhKzrGfPJ59zHpHvsOeIbPFLEU0mQ2cOju9gGamQpmHMYalvMB04NXdcflSL1zc9U +dAU+O2xWza4Y1NP1w8U5ORTKSfA7TvQaFWzdty/CKKxLjS4VigtyLQW08SKFxb7VooB zdYw== MIME-Version: 1.0 X-Received: by 10.224.37.72 with SMTP id w8mr18966314qad.33.1383525700019; Sun, 03 Nov 2013 16:41:40 -0800 (PST) Received: by 10.224.204.4 with HTTP; Sun, 3 Nov 2013 16:41:39 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Nov 2013 08:41:39 +0800 Message-ID: From: GangChen To: Lee Howard Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] comments on draft-ietf-v6ops-nat64-experience 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, 04 Nov 2013 00:41:42 -0000 Hi Lee, 2013/11/1, Lee Howard : > Please define the acronym NAT64-FE. "Front End"? "Functional > Equivalent"? "Fire Engine"? FE stands for "Front End". It has been defined in the abstract session. I will add the definition in the main body. > Clarify this sentence: Some failure cases may be occurred once NAT64 > serves > a IPv6 gateway while is configured only with IPv4 on WAN links. > What is an "IPv6 gateway"? Is that "IPv4 on WAN links" on the gateway, or > on the NAT64 server? > I can't quite picture the topology being described in this example. IPv6 gateway is the next hop for ::/0 When NAT64 is configured as the IPv6 gateway(that is the case in a mobile network), all the traffic heading to a dual-stack server will be transmitted only on IPv6 path and forwarded on NAT64. The topology looks like: +----+ +------+ +-----------------+ |IPv6|-----------|NAT64 |-+-------|dual-stack Server| +----+ +------+ | +-----------------+ | +-----------------+ +-------|IPv4 Server | +-----------------+ If the interface on the left side of NAT64 only configured with IPv4, the traffic going to the dual-stack server is likely failed. > I'm not sure you've made this point: > It's desirable to find the solutions that will > allow introducing IPv6/IPv4 translation service to IPv6-only hosts > while keeping dual-stack hosts unaffected and IPv4 service unchanged. > I think what you want to say is that it's preferable to have at least one > address family accessible via native service, when possible. If you want > to say that IPv4 service should remain unchanged, and that IPv6 hosts > should use NAT64, I would not agree with that. I don't think that's > consistent with the rest of the draft, either. Since this section is > about the coexistence of NAT44 and NAT64, and the previous sentence is how > hard it is to troubleshoot, maybe you want to say more about how to find > the solutions that will facilitate the best network. That might mean > having both, but upgrading hosts aggressively to support IPv6-only, and > making sure native IPv6 was available. The NAT64 is only for the case where there is an IPv6-only host intending to connect with an IPv4-only server. If the destination is IPv6-only server or dual-stack server, the native IPv6 is always preferred. In order to make this point, I will make following changes: ==OLD=== It's also difficult for operators to debug the issue and make optimal resource usages on both NAT44 and NAT64. It's desirable to find the solutions that will allow introducing IPv6/IPv4 translation service to IPv6-only hosts while keeping dual-stack hosts unaffected and IPv4 service unchanged. ==NEW=== It's also difficult for operators to find a solution to make a stable network with optimal resource utilization. In general, it's desirable to figure out the solution that will introduce IPv6/IPv4 translation service to IPv6-only hosts connecting to IPv4 servers while making sure dual-stack hosts to have at least one address family accessible via native service if it's possible. With the end-to-end native IPv6 environment is available, hosts should be upgraded aggressively to migrate to IPv6-only. > I'm not sure where you want to put it, but another NAT64-FE consideration > is the use of x-forwarded-for header. A load balancer using an IPv4 VIP > may be used to sending an IPv4 x-forwarded-for. A front-end server used > to that has no problem, but the server, logs, or log parsing tools (rDNS > looking, whois) may be affected by seeing an IPv6 address when they're > used to seeing IPv4. This is related, but not the same, as the > geo-location issue. (*)If an operator intend to use x-forwarded-for header for accurate the geo-location, I guess it's required that parsing tools should support/recognize ipv6 because it depends on the parsing results. If the consumption is not able to achieve, we may have to pick a solution from rfc6967. > I don't like the use of IPv6 subdomains beyond the testing phase. Nobody > will ever see it; you might as well not have a AAAA if you're only going > to public ipv6.example.com. It's fine to recommend it for testing, but > when ready for production, the same name should be available over A and > AAAA, and let the client choose the address family. We will clarify that the subdomain recommendation is only for the experimental phase. > Section 4.1 is an excellent discussion of the pros and cons of each mode, > with supporting data. It would be good to have a sense of the scale of > sync data for hot standby instances. I will add concrete data for the sense of the scale of sync data. > Section 5.1 needs some paragraph breaks. this will done in the next update. > Use of XFF header for geo-location would work if the server could parse > the original address out of the XFF header. Correct. that is the consumption, please also refer to (*) . > "Geo-location based on shared IPv4 address is rather inaccurate in that > case." Depending on the geographic range of the NAT64. A NAT64-CGN > covering a university or apartment complex, or even a small one covering a > neighborhood, may provide as much detail as in the old days. > > I think the detail in Section 6.1 is pretty light. I would expect that > the same things documented as problems in rfc7021 are also problematic in > NAT64-CGN. good suggestion. We could add more testing data into this section. > These sentences: > Operators may consider to add > additional site-specific rows to the default table to steer traffic > flows going through NAT64-CGN. However, it involves significant > costs to change terminal's behavior. > > I think you mean that operators might consider making changes to host > (client) behavior, but I wasn't clear on the first couple of readings > whether we were talking about host address selection or routing somehow. we are indicating the additional row in the default policy table for host address selection. For example, configure a high Precedence value for a ULA prefix compared to ::ffff:0:0/96 > Based on the above, I think this document needs another rewrite, but is > good. Thank you for the detailed review. We will make another update according to above comments. BRs Gang > Lee > > > > > > > > From phdgang@gmail.com Mon Nov 4 09:50: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 7BE0C21E8097 for ; Mon, 4 Nov 2013 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBG9kDIMvtnV for ; Mon, 4 Nov 2013 09:50:30 -0800 (PST) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9494E21E821F for ; Mon, 4 Nov 2013 09:50:25 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 1so4309200qee.37 for ; Mon, 04 Nov 2013 09:50:23 -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=gJv9IgbugWcVgcv+syY3Htwwlftz0DJvVX7mN76jpgo=; b=RoFuGeXg3LPIPo3llI4I7x+8p8JpVTpQVOs36lFdOruKxjOwG3eQ2WSHxAvMaOgaRB 9fwXXCpTKRXwxRG2WplAUfWkBG5zyPlsNeOVWbN9L1ozfMrZm1ErQarnRD7teAcjGjfq LT7fB/HddTzrWfKLMJqPzPM9galFMUp+necwgDS9Cwj8KlsnhVch0QaFMWHoTPswuwEc GZpKk3i+rAVLXDfdw5SdsNXDtHG5bqJgnXJBGRlj/OtLvIjw6ZHNIP6o4bX3MBgGbsm4 NYvgd+YkZT2wc8Tyf8n5zFiDdcBosbDslF1t3KZwHh3xpyJ9kfsQ+FEu5UvhPBXeJiyL kOKA== MIME-Version: 1.0 X-Received: by 10.224.120.6 with SMTP id b6mr24271425qar.11.1383587423482; Mon, 04 Nov 2013 09:50:23 -0800 (PST) Received: by 10.224.204.4 with HTTP; Mon, 4 Nov 2013 09:50:23 -0800 (PST) In-Reply-To: <20131104174259.10097.28929.idtracker@ietfa.amsl.com> References: <20131104174259.10097.28929.idtracker@ietfa.amsl.com> Date: Tue, 5 Nov 2013 01:50:23 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-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: Mon, 04 Nov 2013 17:50:31 -0000 Wg, We submit the new draft of IPv6 roaming. Please kindly check. Your comments are appreciated BRs Gang 2013/11/5, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Roaming Behavior Analysis > Author(s) : Gang Chen > Hui Deng > Dave Michaud > Jouni Korhonen > Mohamed Boucadair > Vizdal Ales > Cameron Byrne > Filename : draft-chen-v6ops-ipv6-roaming-analysis-02.txt > Pages : 12 > Date : 2013-11-04 > > Abstract: > This document intends to enumerate failure cases when a IPv6 > subscriber roams into visited network areas. The investigations on > those failed cases reveal the causes in order to notice improper > configurations, equipment's incomplete functions or inconsistent IPv6 > strategy. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-roaming-analysis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-chen-v6ops-ipv6-roaming-analysis-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 fernando@gont.com.ar Mon Nov 4 15:01: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 3081B21E821F; Mon, 4 Nov 2013 15:01:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKNzIXOdxYE2; Mon, 4 Nov 2013 15:01:53 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A8C9021E80E2; Mon, 4 Nov 2013 15:01:52 -0800 (PST) Received: from [2001:5c0:1000:a:8000:0:1f85:a0d1] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VdT9b-0007tg-QV; Tue, 05 Nov 2013 00:01:52 +0100 Message-ID: <5278275C.50206@gont.com.ar> Date: Mon, 04 Nov 2013 15:01:48 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 04 Nov 2013 23:01:54 -0000 Folks, I did a presentation on the topic at the IEPG meeting earlier this week. It provides some concrete data regarding IPv6 fragmentation and Extension Header filtering on the Internet. The slideware is available at: Certainly there's *much* more work to be done in this area, but I thought that this could be good food sfor some of the discussions that we were having on the topic. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From tjc@ecs.soton.ac.uk Mon Nov 4 15:27: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 D5DB921E8180; Mon, 4 Nov 2013 15:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpgQjMXmkhEr; Mon, 4 Nov 2013 15:27:51 -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 C217B11E8216; Mon, 4 Nov 2013 15:27:50 -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 rA4NRiaR024399; Mon, 4 Nov 2013 23:27:44 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA4NRiaR024399 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383607664; bh=8SGFyTGc7sX1kEevSEEsTL/Yvl8=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Du2HrzdYg9aJ9hYeWImQxdAnmDcdBq1DJLD3SoSZGKUNk6TTlhU2fklRJQTq6pc4d Q4IctaJyLTfofCcEACzx+eLIu4BLblNYq1ls6dftwGWi30WV4jyO0CSCNWGtkqAdSa vxVLUXfEzNCVjmqWisWiIlkKvyCJ7J8Fjy5hcgGM= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pA3NRi0959634445PQ ret-id none; Mon, 04 Nov 2013 23:27:44 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:b9a1:2be0:ee20:2896] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA4NREDQ022044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 23:27:16 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: <5278275C.50206@gont.com.ar> Date: Mon, 4 Nov 2013 23:27:12 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5278275C.50206@gont.com.ar> To: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA3NRi095963444500; tid=pA3NRi0959634445PQ; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA4NRiaR024399 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 04 Nov 2013 23:27:52 -0000 Hi, Also as per the IEPG discussion, the results I had in conjunction with a = summer MSc project student can be summarised as follows.=20 The headline is that he saw a 37.7% failure rate for the Fragmentation = Header (alone), a bit better than Fernando=92s results, but still not = good. He tested the top 1,000 IPv6-enabled Alexa sites. He used the scapy toolkit which supports the four main extension header = types (routing, fragmentation, destination and hop-by-hop) He tested a) valid combinations of those 4 extension headers as per RFC 2460 b) other non-valid combinations c) duplicated extension headers d) fragmentation header Primarily TCP tests, doing HTTP GET requests. For single extension headers, acceptance was Routing header 63.9% Frag header 62.3% Hop by hop header 60% Destination option header 15.8%=20 When using no extension headers, success rate was 100% When using multiple headers, the rates fall markedly, not dissimilar = with Fernando=92s numbers for longer headers. About 120 sites accept all four types of extension headers.=20 A small number of sites accepted illegal combinations/ordering of = extension headers. A more detailed set of results is being pushed to a conference paper. I now have another student taking this further, and validating the above = results, so feel free to contact me off-list if you=92re interested. Tim On 4 Nov 2013, at 23:01, Fernando Gont wrote: > Folks, >=20 > I did a presentation on the topic at the IEPG meeting earlier this = week. > It provides some concrete data regarding IPv6 fragmentation and > Extension Header filtering on the Internet. >=20 > The slideware is available at: > = >=20 > Certainly there's *much* more work to be done in this area, but I > thought that this could be good food sfor some of the discussions that > we were having on the topic. >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From swmike@swm.pp.se Mon Nov 4 15:32: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 F147111E82C7; Mon, 4 Nov 2013 15:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRiLmRSBgOL6; Mon, 4 Nov 2013 15:32:02 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 63DAC21E8180; Mon, 4 Nov 2013 15:32:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 922099C; Tue, 5 Nov 2013 00:32:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8AD419A; Tue, 5 Nov 2013 00:32:00 +0100 (CET) Date: Tue, 5 Nov 2013 00:32:00 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <5278275C.50206@gont.com.ar> Message-ID: References: <5278275C.50206@gont.com.ar> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 04 Nov 2013 23:32:08 -0000 On Mon, 4 Nov 2013, Fernando Gont wrote: > Folks, > > I did a presentation on the topic at the IEPG meeting earlier this week. > It provides some concrete data regarding IPv6 fragmentation and > Extension Header filtering on the Internet. > > The slideware is available at: > > > Certainly there's *much* more work to be done in this area, but I > thought that this could be good food sfor some of the discussions that > we were having on the topic. "Operators are known to filter IPv6 fragments". This kind of writing implies intent, right? Most of the "filtering" I would say is due to default device behavior, where no intent exists on the operator. So I'd rather see this changes to "IPv6 fragment header packets are having a severely degraded network experience" or something like that. Otherwise, great work. I would like to see traceroute or alike done with these kinds of packets headers also, to see where packets are dropped. -- Mikael Abrahamsson email: swmike@swm.pp.se From fgont@si6networks.com Mon Nov 4 16:01: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 A211C21E80FB; Mon, 4 Nov 2013 16:01:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLn1ndTk1cxb; Mon, 4 Nov 2013 16:01:27 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2F22621E82E1; Mon, 4 Nov 2013 16:01:01 -0800 (PST) Received: from [2001:5c0:1000:a:8000:0:1f85:a0d1] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VdU4p-000255-0i; Tue, 05 Nov 2013 01:00:59 +0100 Message-ID: <52783535.9030200@si6networks.com> Date: Mon, 04 Nov 2013 16:00:53 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Fernando Gont References: <5278275C.50206@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 00:01:27 -0000 On 11/04/2013 03:32 PM, Mikael Abrahamsson wrote: >> >> Certainly there's *much* more work to be done in this area, but I >> thought that this could be good food sfor some of the discussions that >> we were having on the topic. > > "Operators are known to filter IPv6 fragments". This kind of writing Isn't there a v6ops I-D with similar wording? > implies intent, right? mm... as far as discussion on a number of forums went, apparently there's intent to do so. > Most of the "filtering" I would say is due to > default device behavior, where no intent exists on the operator. Data? References? > So I'd > rather see this changes to "IPv6 fragment header packets are having a > severely degraded network experience" or something like that. Well, the preso is out there, already. :-( > Otherwise, great work. I would like to see traceroute or alike done with > these kinds of packets headers also, to see where packets are dropped. Yep. This is in my TODO list. Hopefully we will cooperate with Tim (Chown) et al to take these measurements further. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From swmike@swm.pp.se Mon Nov 4 16:08: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 C443821E81F9; Mon, 4 Nov 2013 16:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjvKdAHFak4q; Mon, 4 Nov 2013 16:08:21 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 424D511E82D1; Mon, 4 Nov 2013 16:08:19 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E51C9C; Tue, 5 Nov 2013 01:08:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 55E6C9A; Tue, 5 Nov 2013 01:08:18 +0100 (CET) Date: Tue, 5 Nov 2013 01:08:18 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <52783535.9030200@si6networks.com> Message-ID: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 00:08:26 -0000 On Mon, 4 Nov 2013, Fernando Gont wrote: > Isn't there a v6ops I-D with similar wording? I opposed to this wording in there as well. If one deploys a 6500/7600/SUP720 and configures IPv6 on it today, it'll slow-path every IPv6 packet with a fragmentation header. Default behaviour. I have no idea how much of the behaviour your're seeing is caused by this default behaviour, but I'd venture to guess a lot. > mm... as far as discussion on a number of forums went, apparently > there's intent to do so. Oki, I haven't seen these. > Data? References? http://seclists.org/nanog/2011/Sep/1076 -- Mikael Abrahamsson email: swmike@swm.pp.se From marka@isc.org Mon Nov 4 16:13: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 F368311E82F9; Mon, 4 Nov 2013 16:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-qA885+65gl; Mon, 4 Nov 2013 16:13:21 -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 C251211E8305; Mon, 4 Nov 2013 16:12:59 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 10A0BC9450; Tue, 5 Nov 2013 00:12:46 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1383610379; bh=nFwqHMhxrWjM9Zy9HH4FW+/cRCA91xJPBxNN+taOv2w=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=iDvv5HXjTr6yRCh+QO4cZKfjxoOQT01OkajDdGDyEvdHvHWGm+m1p+P/3GVV1cT9d ePr5UejmoK+vwtO8m3zd+ekY+hU4Ul4UQOa+7FwpALJxe9+XMO2PSkp67N3Vmsm+4N 6XT8OULKPtrGFPNIMvjdyvL2pWnpphx5JSuAk71M= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 5 Nov 2013 00:12:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 656D31603E9; Tue, 5 Nov 2013 00:18:26 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 75DCB160363; Tue, 5 Nov 2013 00:18:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 53E28985D0D; Tue, 5 Nov 2013 11:12:43 +1100 (EST) To: Fernando Gont From: Mark Andrews References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> In-reply-to: Your message of "Mon, 04 Nov 2013 16:00:53 -0800." <52783535.9030200@si6networks.com> Date: Tue, 05 Nov 2013 11:12:43 +1100 Message-Id: <20131105001243.53E28985D0D@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 00:13:26 -0000 In message <52783535.9030200@si6networks.com>, Fernando Gont writes: > On 11/04/2013 03:32 PM, Mikael Abrahamsson wrote: > >> > >> Certainly there's *much* more work to be done in this area, but I > >> thought that this could be good food sfor some of the discussions that > >> we were having on the topic. > > > > "Operators are known to filter IPv6 fragments". This kind of writing > > Isn't there a v6ops I-D with similar wording? > > > > implies intent, right? > > mm... as far as discussion on a number of forums went, apparently > there's intent to do so. There is also often no intent. The defaults drop fragmented packets any you have to explicitly pass them. > > Most of the "filtering" I would say is due to > > default device behavior, where no intent exists on the operator. > > Data? References? *BSD firewall drop by default. For all flavours of firewall supported. e.g. ipfw, ipf. > > So I'd > > rather see this changes to "IPv6 fragment header packets are having a > > severely degraded network experience" or something like that. > > Well, the preso is out there, already. :-( > > > > > Otherwise, great work. I would like to see traceroute or alike done with > > these kinds of packets headers also, to see where packets are dropped. > > Yep. This is in my TODO list. Hopefully we will cooperate with Tim > (Chown) et al to take these measurements further. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From simon.perreault@viagenie.ca Mon Nov 4 16:20: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 6FA8B21E80C9 for ; Mon, 4 Nov 2013 16:20: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-4DQDdE2FjN for ; Mon, 4 Nov 2013 16:20:29 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1407A21E8305 for ; Mon, 4 Nov 2013 16:20:27 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C8972401E8 for ; Mon, 4 Nov 2013 19:20:22 -0500 (EST) Message-ID: <527839C6.3000805@viagenie.ca> Date: Mon, 04 Nov 2013 16:20:22 -0800 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> In-Reply-To: <20131105001243.53E28985D0D@rock.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 00:20:30 -0000 Le 2013-11-04 16:12, Mark Andrews a écrit : >>> Most of the "filtering" I would say is due to >>> default device behavior, where no intent exists on the operator. >> >> Data? References? > > *BSD firewall drop by default. For all flavours of firewall supported. > e.g. ipfw, ipf. pf reassembles IPv6 fragments by default. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Fred.L.Templin@boeing.com Mon Nov 4 16:31: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 30BF311E82D8 for ; Mon, 4 Nov 2013 16:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6hpRqs5BFSh for ; Mon, 4 Nov 2013 16:31:52 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9091611E8257 for ; Mon, 4 Nov 2013 16:31:52 -0800 (PST) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id rA50VpI9030454 for ; Mon, 4 Nov 2013 18:31:51 -0600 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rA50VpeU030450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 4 Nov 2013 18:31:51 -0600 Received: from XCH-EXCO-103.nw.nos.boeing.com (130.247.25.37) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 4 Nov 2013 16:31:51 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-EXCO-103.nw.nos.boeing.com ([169.254.4.124]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 16:31:50 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet Thread-Index: AQHO2bzgq70DdkmKlkSk33AAKL/ErpoVyOPA Date: Tue, 5 Nov 2013 00:31:50 +0000 Message-ID: <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> In-Reply-To: <527839C6.3000805@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 00:31:59 -0000 Hi, if the network is dropping fragments we are just going to have to fix it. Tunnels are an example of a packetization layer that requires fragmentation. Thanks - Fred fred.l.templin@boeing.com From touch@isi.edu Mon Nov 4 16:40: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 3DC6121E818C for ; Mon, 4 Nov 2013 16:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.06 X-Spam-Level: X-Spam-Status: No, score=-103.06 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j-Gk1G-EAi0 for ; Mon, 4 Nov 2013 16:40:36 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5E921E8253 for ; Mon, 4 Nov 2013 16:40:31 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA50e39K024904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Nov 2013 16:40:03 -0800 (PST) Message-ID: <52783ED4.4060205@isi.edu> Date: Mon, 04 Nov 2013 16:41:56 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Templin, Fred L" , "v6ops@ietf.org" References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 00:40:41 -0000 +1 The same measurement with IPv6 used to say "IPv6 packets won't get through most of the time". If you see a bug, fix and/or report it ;-) Joe On 11/4/2013 4:31 PM, Templin, Fred L wrote: > Hi, if the network is dropping fragments we are just going to have > to fix it. Tunnels are an example of a packetization layer that > requires fragmentation. > > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From otroan@employees.org Mon Nov 4 17:25: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 96A8D11E8256 for ; Mon, 4 Nov 2013 17:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVsP-CdSQ5Tl for ; Mon, 4 Nov 2013 17:25:35 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28A11E8343 for ; Mon, 4 Nov 2013 17:25:33 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAJNHeFKQ/khN/2dsb2JhbABZgwfARIEnFnSCJQEBBAF5BQsLNRFXBogOBr5Lj1gHgyCBDgOQLpllgyc7 X-IronPort-AV: E=Sophos;i="4.93,636,1378857600"; d="asc'?scan'208";a="19251625" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 05 Nov 2013 01:25:32 +0000 Received: from dhcp-10-61-107-176.cisco.com (dhcp-10-61-107-176.cisco.com [10.61.107.176]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA51PSYe019817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 01:25:29 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_EFAC8295-01D8-4912-A245-818039954AEE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 5 Nov 2013 02:25:28 +0100 Message-Id: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1816) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 01:25:41 -0000 --Apple-Mail=_EFAC8295-01D8-4912-A245-818039954AEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Hi, if the network is dropping fragments we are just going to have > to fix it. Tunnels are an example of a packetization layer that > requires fragmentation. does the above results show the _network_ dropping fragments, or the end = host or a system closely associated with the end host dropping extension = headers? cheers, Ole --Apple-Mail=_EFAC8295-01D8-4912-A245-818039954AEE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeEkIAAoJEFuJXizso86gBN8IALtUoaFOeKYAj1/qW7YBVlXu Nl1hPKyeaS7S4w6RCMbdMCTR+gF0lThtOi0R+wfkyiR1MsPjzp2tbfJWMw2dRq4X Wr3NddnOfkazdKIPydzR9h7+640cEe7qBGcBFCmRigs1TCjTHYZIJT1xus/VPF/p im73sDI1QybrFoDPG89C0htyPVCWGYEeIau5letc645yK1WzQpsY8ZoyE5nvVbGr jfSbqsrL8ZhXRBAhcVl7WZ1q0P9LeZvedOPdr7EZ/6CWQJL3jfp4qxumc+BDdi9Q b41l2WNXxlIqE9wT8aNcsDwEAQLw9kilWPqPhOWCSk9Ih8SRRU1AcuHzWn2nxwo= =7fXs -----END PGP SIGNATURE----- --Apple-Mail=_EFAC8295-01D8-4912-A245-818039954AEE-- From tjc@ecs.soton.ac.uk Mon Nov 4 17:31: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 47BC011E81CB for ; Mon, 4 Nov 2013 17:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqrzwdihgWWJ for ; Mon, 4 Nov 2013 17:31:39 -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 53C6121E80DA for ; Mon, 4 Nov 2013 17:31:38 -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 rA51VQE1014391; Tue, 5 Nov 2013 01:31:26 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA51VQE1014391 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383615086; bh=Kv6l1scyQNKeNJjjk8pWrBCbh78=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=g9E632xR+FkUtOHmmSkKwk3DpbNWEjyE+KxFSYxD9xImA2/cQrJFptsIVZ360vK5D SHHy5JgFAzQOCOToBADo2qiJTvvJDzyADO6MqPctM+URDX89AyAF433ZNkcxaQN09Q b+ADYt0TieksXEQ2ANnmgjvATI69nefK3zZ99GE4= 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 pA41VQ0959634927JK ret-id none; Tue, 05 Nov 2013 01:31:26 +0000 Received: from dhcp-a3da.meeting.ietf.org (dhcp-a3da.meeting.ietf.org [31.133.163.218]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA51UG69017885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 01:31:01 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Tue, 5 Nov 2013 01:31:00 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <001F10BA-F1D4-4AFA-BC0B-E574739782FA@ecs.soton.ac.uk> To: Ole Troan X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA41VQ095963492700; tid=pA41VQ0959634927JK; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA51VQE1014391 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 01:31:40 -0000 On 5 Nov 2013, at 01:25, Ole Troan wrote: >> Hi, if the network is dropping fragments we are just going to have >> to fix it. Tunnels are an example of a packetization layer that >> requires fragmentation. >=20 > does the above results show the _network_ dropping fragments, or the = end host or a system closely associated with the end host dropping = extension headers? For mine, the test was simply whether the HTTP request solicited a = response. I=92ll check on the ICMPv6. Tim= From furry13@gmail.com Mon Nov 4 18:12: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 3686511E820E for ; Mon, 4 Nov 2013 18:12:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujaQwlDhigSJ for ; Mon, 4 Nov 2013 18:12:18 -0800 (PST) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C6AB921E80B6 for ; Mon, 4 Nov 2013 18:12:15 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 1so4583949qee.23 for ; Mon, 04 Nov 2013 18:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I/3k6E/6j5VAbk+ePvV0Gye4Th3Xxt9cbitk6938wng=; b=s2GiG+rsGa+24itUBkDG8LozLCZoUMbFHPnNLrXgiLPMWoPvZyPdjGTqvRlOVGi5nJ ceTTWFwb9tr17iP+8neAdJ3gU0eKj6KKX12hTtHImAoI1S6Hcw7Amk0cn/9hx9DLZQHB oO6x3kHVkutLBvEGe6dpsNYZRemX0RmT+849taFnMY0fjPSLcsB+Pb1yEDPZhYTcPnup EwuBIVIXcfFTuyRy/BBCvPAoZRMR3wPfepZcrhEZ+JpL+6v6HCfeuOSjbmDQUwLm5mlY 0/8DmJ7EaS0mzi6jx/vRPgaZgqATQDwDa33yPNrI+4ccoVqr4Otf3Ss9QP/vP5v93783 MjSg== X-Received: by 10.224.14.20 with SMTP id e20mr15488139qaa.16.1383617535111; Mon, 04 Nov 2013 18:12:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Mon, 4 Nov 2013 18:11:54 -0800 (PST) In-Reply-To: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <001F10BA-F1D4-4AFA-BC0B-E574739782FA@ecs.soton.ac.uk> From: Jen Linkova Date: Tue, 5 Nov 2013 03:11:54 +0100 Message-ID: To: Tim Chown Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:12:19 -0000 On Tue, Nov 5, 2013 at 2:31 AM, Tim Chown wrote: >> does the above results show the _network_ dropping fragments, or the end host or a system closely associated with the end host dropping extension headers? > > For mine, the test was simply whether the HTTP request solicited a response. It could be verified by checking the hop limit from the your machine to the server you are testing and then vary the hop limits of probe packets - so you can see when you stop receiving 'time exceeded'. -- SY, Jen Linkova aka Furry From fernando@gont.com.ar Mon Nov 4 18:16: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 A698621E809D for ; Mon, 4 Nov 2013 18:16:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18khjmKuN-ZZ for ; Mon, 4 Nov 2013 18:16:58 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CEBEF11E8269 for ; Mon, 4 Nov 2013 18:16:57 -0800 (PST) Received: from [2001:67c:370:160:517b:6f2e:1bc7:1d4a] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VdWCN-0005Um-5y; Tue, 05 Nov 2013 03:16:55 +0100 Message-ID: <52784E34.7040707@gont.com.ar> Date: Mon, 04 Nov 2013 17:47:32 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Templin, Fred L" , "v6ops@ietf.org" References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:16:58 -0000 On 11/04/2013 04:31 PM, Templin, Fred L wrote: > Hi, if the network is dropping fragments we are just going to have > to fix it. I guess we didn't have a good success rate with ICMP{v4,v6} filtering for PMTUD to be reliable? Not that I like it, but... it's not that easy to fix something that is not under your control. That said, I have a few ideas to provide some help in that direction. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Mon Nov 4 18:17: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 D6C7321E82E2 for ; Mon, 4 Nov 2013 18:17:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKI81Oe4OinL for ; Mon, 4 Nov 2013 18:17:04 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D20B321E82AC for ; Mon, 4 Nov 2013 18:17:00 -0800 (PST) Received: from [2001:67c:370:160:517b:6f2e:1bc7:1d4a] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VdWCH-0005Ui-IO; Tue, 05 Nov 2013 03:16:49 +0100 Message-ID: <52784DD1.7020106@gont.com.ar> Date: Mon, 04 Nov 2013 17:45:53 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan , "Templin, Fred L" References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:17:05 -0000 Hi, Ole, On 11/04/2013 05:25 PM, Ole Troan wrote: >> Hi, if the network is dropping fragments we are just going to >> have to fix it. Tunnels are an example of a packetization layer >> that requires fragmentation. > > does the above results show the _network_ dropping fragments, or > the end host or a system closely associated with the end host > dropping extension headers? So far, I have not measured that, but will do. In any case, the interesting (and unfortunate) data if the chances of success when you use extension headers or fragmentation are in the scale of "unlikely". :-( Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From swmike@swm.pp.se Mon Nov 4 18:21:20 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 1B11521E8341 for ; Mon, 4 Nov 2013 18:21:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKDiTJy+4OPY for ; Mon, 4 Nov 2013 18:21:19 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7D511E8267 for ; Mon, 4 Nov 2013 18:20:56 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 69A139C; Tue, 5 Nov 2013 03:20:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 600559A; Tue, 5 Nov 2013 03:20:54 +0100 (CET) Date: Tue, 5 Nov 2013 03:20:54 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <52784E34.7040707@gont.com.ar> Message-ID: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784E34.7040707@gont.com.ar> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:21:20 -0000 On Mon, 4 Nov 2013, Fernando Gont wrote: > I guess we didn't have a good success rate with ICMP{v4,v6} filtering > for PMTUD to be reliable? I have to oppose to this one as well. Filtering means intent (right?). Lots of PMTUD problems are not intentional, they are caused by other reasons, like L2 MTU mismatch on links so packets are dropped silently without the operator noticing. Some are also caused by misconfigured load balancers etc (the ICMP message is lost due to bad implementation, not due to active decision to filter). -- Mikael Abrahamsson email: swmike@swm.pp.se From tjc@ecs.soton.ac.uk Mon Nov 4 18:23: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 0C49F21E818C for ; Mon, 4 Nov 2013 18:23:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KuUXen+vMcR for ; Mon, 4 Nov 2013 18:22:59 -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 2F74421E82ED for ; Mon, 4 Nov 2013 18:22:55 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52Mks1023048; Tue, 5 Nov 2013 02:22:46 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA52Mks1023048 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383618167; bh=shZLN0JiPR/JL+C9NzuYkAH8oCM=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=eZhcV7CpMtBkczstEtajTTLFcgZRltkkWk47wWJDmWhHm1BtINwNIKXBHPVmagXbi fH3a74cPyyWBHYBRrETGQxOmRXHBkaZBKgl12lXI8ZvvCpqQRdr1SrwSdfomidry0l /MZSSa3R83q/nTTn9SDbm04c/EU//agja2uOP37E= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pA42Mk0959635093bR ret-id none; Tue, 05 Nov 2013 02:22:46 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:6865:dd3f:9c57:76dd] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52LQJg028359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 02:21:28 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Tue, 5 Nov 2013 02:21:25 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <001F10BA-F1D4-4AFA-BC0B-E574739782FA@ecs.soton.ac.uk> <9DC9AFAD-CB63-46BC-B8E1-229F5EA64E6E@ecs.soton.ac.uk> To: Jen Linkova X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA42Mk095963509300; tid=pA42Mk0959635093bR; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA52Mks1023048 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:23:00 -0000 On 5 Nov 2013, at 02:11, Jen Linkova wrote: > On Tue, Nov 5, 2013 at 2:31 AM, Tim Chown wrote: >>> does the above results show the _network_ dropping fragments, or the = end host or a system closely associated with the end host dropping = extension headers? >>=20 >> For mine, the test was simply whether the HTTP request solicited a = response. >=20 > It could be verified by checking the hop limit from the your machine > to the server you are testing and then vary the hop limits of probe > packets - so you can see when you stop receiving 'time exceeded=92. Modifying traceroute itself to slip in some extension headers might be = useful? Much as you can check DSCP rewrites, for example. Tim From otroan@employees.org Mon Nov 4 18:23: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 5495B21E838E for ; Mon, 4 Nov 2013 18:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjO8N1vWWyr0 for ; Mon, 4 Nov 2013 18:23:07 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6121E82ED for ; Mon, 4 Nov 2013 18:23:07 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFANdVeFKQ/khR/2dsb2JhbABZgwfARoEoFnSCJQEBBAFlFBALNRFXBogOBr4/jgGBSgeDIIEOA5AumWWDJzs X-IronPort-AV: E=Sophos;i="4.93,637,1378857600"; d="asc'?scan'208";a="87901493" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 05 Nov 2013 02:23:06 +0000 Received: from dhcp-10-61-107-176.cisco.com (dhcp-10-61-107-176.cisco.com [10.61.107.176]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA52N200014245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 02:23:02 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_2C0B7F3E-280A-4050-AD92-55EA5A290939"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <52784DD1.7020106@gont.com.ar> Date: Tue, 5 Nov 2013 03:23:01 +0100 Message-Id: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1816) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:23:18 -0000 --Apple-Mail=_2C0B7F3E-280A-4050-AD92-55EA5A290939 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, >>> Hi, if the network is dropping fragments we are just going to >>> have to fix it. Tunnels are an example of a packetization layer >>> that requires fragmentation. >>=20 >> does the above results show the _network_ dropping fragments, or >> the end host or a system closely associated with the end host >> dropping extension headers? >=20 > So far, I have not measured that, but will do. >=20 > In any case, the interesting (and unfortunate) data if the chances of > success when you use extension headers or fragmentation are in the > scale of "unlikely". :-( I'm not sure you can draw that conclusion without knowing where the = fragments are dropped. e.g. you are not saying that fragmented packets will be dropped anywhere = on the link between your home and mine, are you? I'm for example not concerned about a web server or load balancer that = sets TCP MSS to 1220 and then drop fragments. cheers, Ole --Apple-Mail=_2C0B7F3E-280A-4050-AD92-55EA5A290939 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeFaFAAoJEFuJXizso86gFBkH+wezdGnypGxmKSHhNNdKmBj0 z5h7bDYfXehX3UwDT1n4Ui9B5m2BwZSGWb/2Dzo9HHiySnvgms6hu9UzIdwM9JVU LpodpwM19Xld1fDEyV8CgcicGJhmOMNrs9MScH0X+oQ02LEWlESg1NmAO2NPGXqJ BKbaEeQv/yJyE2G2KiFo5Rfeqeilrsw83T0Hzz/BZ6DHK95EPN6z1duMFlxey1/9 cDauEDBaCCswEnPuRdeFermWPMfIj4zG7vsqhOiemKV4e3YLCs2OPrkXWayBhz/j lAWZ7s31RRA1DOcH1cpY2oKpQS302ffYcL8AtHsr5lb3H2uOL2bZUrCwy9KkQFI= =4eTs -----END PGP SIGNATURE----- --Apple-Mail=_2C0B7F3E-280A-4050-AD92-55EA5A290939-- From Fred.L.Templin@boeing.com Mon Nov 4 18:24: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 BECF111E8269 for ; Mon, 4 Nov 2013 18:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51v1cAFCQpw9 for ; Mon, 4 Nov 2013 18:24:34 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1068411E8267 for ; Mon, 4 Nov 2013 18:24:34 -0800 (PST) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id rA52OXr0023157 for ; Mon, 4 Nov 2013 20:24:33 -0600 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rA52OUV4023108 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Nov 2013 20:24:32 -0600 Received: from XCH-BLV-401.nw.nos.boeing.com (130.247.25.18) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 4 Nov 2013 18:24:31 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.67]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 18:24:31 -0800 From: "Templin, Fred L" To: Fernando Gont , "v6ops@ietf.org" Thread-Topic: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet Thread-Index: AQHO2cj+q70DdkmKlkSk33AAKL/ErpoV6DiQ Date: Tue, 5 Nov 2013 02:24:30 +0000 Message-ID: <2134F8430051B64F815C691A62D983181483E6@XCH-BLV-504.nw.nos.boeing.com> References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784E34.7040707@gont.com.ar> In-Reply-To: <52784E34.7040707@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:24:41 -0000 Hi Fernando, > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar] > Sent: Monday, November 04, 2013 5:48 PM > To: Templin, Fred L; v6ops@ietf.org > Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the= Internet >=20 > On 11/04/2013 04:31 PM, Templin, Fred L wrote: > > Hi, if the network is dropping fragments we are just going to have > > to fix it. >=20 > I guess we didn't have a good success rate with ICMP{v4,v6} filtering > for PMTUD to be reliable? Unfortunately, that seems to be the case. > Not that I like it, but... it's not that easy to fix something that is > not under your control. >=20 > That said, I have a few ideas to provide some help in that direction. Any ideas would be helpful! Thanks - Fred fred.l.templin@boeing.com > Thanks! >=20 > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 From evyncke@cisco.com Mon Nov 4 18:27: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 1E0DD21E818C for ; Mon, 4 Nov 2013 18:27:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ruk+zPwDBHqf for ; Mon, 4 Nov 2013 18:27:34 -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 DA1ED11E8269 for ; Mon, 4 Nov 2013 18:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2250; q=dns/txt; s=iport; t=1383618452; x=1384828052; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0l+vRDZnpRuKVTi2dsPrrF8KF8V3xK0kBLuYn3tgaOk=; b=IzPPa1lZsiJyejW1zn0GOnQIH8j9SOgTmNLYJeUrRa5NIHOZ3T8jLtVO c03/0aUBwnu/Yiz9lpYci6kgYfbx+h5Rsh3C/rPj9xVP1kPaQmVa5EBIq ZlbRIh7rxLCV0sUY35/r9+KGahos+SP9xrlPS0d7vIfWdcXruEg7ooTJ8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcGAEVXeFKtJXG//2dsb2JhbABZgwc4TQa/O4EoFm0HgiUBAQEEAQEBZAcXBAIBCBEEAQELHQcnCxQJCAIEEwgBh3gIBb4zjxo4BoMagQ4DiQiQMZBagyaCKg X-IronPort-AV: E=Sophos;i="4.93,637,1378857600"; d="scan'208";a="280656532" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2013 02:27:32 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA52RW6Y007972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Nov 2013 02:27:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:27:31 -0600 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: AQHOyHBxK2tyuJV06kS+8KMLL/FcoZoWC5xA Date: Tue, 5 Nov 2013 02:27:30 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> In-Reply-To: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 05 Nov 2013 02:27:39 -0000 I have hard time to understand the case described in section 3.1.4 "co-exis= tence of NAT44 and NAT64". Why would a provider use both at the same time? = Using NAT44 + native IPv6 is sensible, using IPv6-only + NAT64 is also valu= able but I cannot imagine why NAT44 and NAT64 could be use together for the= same subscribers. Thanks for shedding some light for me :-) -=E9ric > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: dimanche 13 octobre 2013 16:00 > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. >=20 > Title : NAT64 Operational Experiences > Author(s) : Gang Chen > Zhen Cao > Chongfeng Xie > David Binet > Filename : draft-ietf-v6ops-nat64-experience-04.txt > Pages : 20 > Date : 2013-10-13 >=20 > Abstract: > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and > NAT64 server Front End (NAT64-FE) are considered in this document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Mon Nov 4 18:30: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 223FA11E82CF for ; Mon, 4 Nov 2013 18:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKser8EkuqZL for ; Mon, 4 Nov 2013 18:30:31 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 57CCB21F9FB3 for ; Mon, 4 Nov 2013 18:30:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 86ED39C; Tue, 5 Nov 2013 03:30:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 82A519A; Tue, 5 Nov 2013 03:30:30 +0100 (CET) Date: Tue, 5 Nov 2013 03:30:30 +0100 (CET) From: Mikael Abrahamsson To: "Eric Vyncke (evyncke)" In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> Message-ID: References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 05 Nov 2013 02:30:38 -0000 On Tue, 5 Nov 2013, Eric Vyncke (evyncke) wrote: > I have hard time to understand the case described in section 3.1.4 > "co-existence of NAT44 and NAT64". Why would a provider use both at the > same time? Using NAT44 + native IPv6 is sensible, using IPv6-only + > NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 could be > use together for the same subscribers. Mobile. It's up to the terminal to initiate a connection in the APN, and you don't know if it'll be IPv4 only, IPv6 only or dual stack. -- Mikael Abrahamsson email: swmike@swm.pp.se From victor@jvknet.com Mon Nov 4 18:40: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 20E1A21E833F for ; Mon, 4 Nov 2013 18:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbJ+6JR7yz4V for ; Mon, 4 Nov 2013 18:39:55 -0800 (PST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEC321E80F1 for ; Mon, 4 Nov 2013 18:39:53 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id v4so3346973bkz.9 for ; Mon, 04 Nov 2013 18:39:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ELIyAq+CWJiTlnKswraxVEEUvnDHlbHa529mRtwcsyU=; b=O0y2M+z8aVo3MzwOlij0dq/NLefHApqXw1Sm8iNHUNsWnyQogpBv+tSP6f+4Pa8n70 SqAiNbC+FSkrwWqyPQqPIzyRWIEOqrQy20TcmPVA2AC/pY5iZI6W0ODHEJje5I1xY6wa NbDcs0uCMQ1+qFM3wt3IpqrY3x5MTWEI99BgSa5VkNEwXEI/cvB153GzRIwGdvqunhkk BJ8N8r+lQznyuZnUYNvrS9quizXG9fQXMuETvmvLFHeAmdJpH9pSfa9uTa7/4AQ/Jjoq FSm1AFgFC0q2vEQSctv9RVO51bariQYwvvk7/P3a6AGObHjSuWFsh5hKYr0kY+YxrZET UtrQ== X-Gm-Message-State: ALoCoQnZNJF420a2+X7Gg2BqhuZVx2hAYa2GhJG1a/YKc2niaTPESft62lxWiiN89iqOsxXmVQXC X-Received: by 10.204.226.135 with SMTP id iw7mr11861110bkb.4.1383619192760; Mon, 04 Nov 2013 18:39:52 -0800 (PST) Received: from [31.133.162.206] (dhcp-a2ce.meeting.ietf.org. [31.133.162.206]) by mx.google.com with ESMTPSA id ny10sm17451130bkb.17.2013.11.04.18.39.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Nov 2013 18:39:52 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 04 Nov 2013 18:39:47 -0800 From: Victor Kuarsingh To: "Eric Vyncke (evyncke)" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 05 Nov 2013 02:40:00 -0000 Eric, On 2013-11-04 6:27 PM, "Eric Vyncke (evyncke)" wrote: >I have hard time to understand the case described in section 3.1.4 >"co-existence of NAT44 and NAT64". Why would a provider use both at the >same time? Using NAT44 + native IPv6 is sensible, using IPv6-only + NAT64 >is also valuable but I cannot imagine why NAT44 and NAT64 could be use >together for the same subscribers. > >Thanks for shedding some light for me :-) That's a good question. I cannot comment on the original intent of this section, but one use case I can think of is a APN (with associated routing contexts etc) which may land both IPv4-only, Dual Stack, or IPv6-only PDP contexts (depending on what the device asks for and/or what is allowed by network). In such a case, if using private IPv6 addresses for the UE, it's possible that you can have this happen. Perhaps, as long as it does not break anything, it's ok? Regards, Victor K > >-=E9ric > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>Of >> internet-drafts@ietf.org >> Sent: dimanche 13 octobre 2013 16:00 >> To: i-d-announce@ietf.org >> Cc: v6ops@ietf.org >> Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >>=20 >> Title : NAT64 Operational Experiences >> Author(s) : Gang Chen >> Zhen Cao >> Chongfeng Xie >> David Binet >> Filename : draft-ietf-v6ops-nat64-experience-04.txt >> Pages : 20 >> Date : 2013-10-13 >>=20 >> Abstract: >> This document summarizes NAT64 function deployment scenarios and >> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and >> NAT64 server Front End (NAT64-FE) are considered in this document. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 tjc@ecs.soton.ac.uk Mon Nov 4 18:44: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 863C821E818C for ; Mon, 4 Nov 2013 18:44: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.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WZKX2gxAxZE for ; Mon, 4 Nov 2013 18:44:32 -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 03E6F21E82F0 for ; Mon, 4 Nov 2013 18:44:30 -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 rA52iPqv027006 for ; Tue, 5 Nov 2013 02:44:25 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA52iPqv027006 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383619465; bh=xaekYtay8Jm+zDAbZXrTtjlvM5A=; h=From:Subject:Date:To:Mime-Version:References; b=FD4aVZ/mUXgvaAtltQPXsgJ7+UePiMytk764eCsGkdWsIC7LMlis0vAvj1uOwBqea RCsZ+T8iaiQ7qID6SrKZNMqXtFoEQG0TZgPkUZSGxHQT7QSCEJaAQcExnV2DYCN31m WroCZe/bDCUecM4D5IqTgJ97wkiShNhiuCDzxBdc= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pA42iP0959635190XE ret-id none; Tue, 05 Nov 2013 02:44:25 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:6865:dd3f:9c57:76dd] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52h5Mj000411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Nov 2013 02:43:07 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_596E92DB-D2D3-40D0-8393-CDB27E1D8960" Message-ID: Date: Tue, 5 Nov 2013 02:43:03 +0000 To: IPv6 Operations Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA42iP095963519000; tid=pA42iP0959635190XE; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA52iPqv027006 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [v6ops] Comment on draft-ietf-v6ops-ula-usage-recommendations-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: Tue, 05 Nov 2013 02:44:33 -0000 --Apple-Mail=_596E92DB-D2D3-40D0-8393-CDB27E1D8960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Bing, In section 1 you say: =93 The use of ULA addresses in various types of networks has been confusing to network operators. Some network operators believe ULAs are not useful at all while other network operators have run ULAs beneficially in their networks." This implies you know operators who are using ULAs beneficially. It = would be nice if those operators are reading this and can comment. Or = failing that for you to make it clear where possible in the text which = parts you are writing based on those operators=92 comments, and which = parts are more theoretical. There are some parts of the text which are written almost in note form. = It would be nice to tidt those parts up a little. Tim --Apple-Mail=_596E92DB-D2D3-40D0-8393-CDB27E1D8960 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Bing,

In section 1 you = say:

=93 The = use of ULA addresses in various types of networks has = been
 confusing to network operators. Some network =
operators believe ULAs
 are not useful at all while other network operators have run ULAs
 beneficially in their networks."

This = implies you know operators who are using ULAs beneficially. It would be = nice if those operators are reading this and can comment.  Or = failing that for you to make it clear where possible in the text which = parts you are writing based on those operators=92 comments, and which = parts are more theoretical.

There are some = parts of the text which are written almost in note form.  It would = be nice to tidt those parts up a = little.

Tim


= --Apple-Mail=_596E92DB-D2D3-40D0-8393-CDB27E1D8960-- From fgont@si6networks.com Mon Nov 4 18:45: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 8903621E82F0; Mon, 4 Nov 2013 18:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iN4Cee8PJU2; Mon, 4 Nov 2013 18:45:46 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D64DD21E839F; Mon, 4 Nov 2013 18:45:41 -0800 (PST) Received: from [2001:67c:370:160:517b:6f2e:1bc7:1d4a] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VdWe7-00075W-9p; Tue, 05 Nov 2013 03:45:35 +0100 Message-ID: <52785BC9.3040705@si6networks.com> Date: Mon, 04 Nov 2013 18:45:29 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Pedro Torres , Tim Chown References: <5278275C.50206@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:45:46 -0000 Hi, Pedro, On 11/04/2013 05:53 PM, Pedro Torres wrote: > Tim/Fernando, > > Wow! I'm scared of these results! > (If that was the intention, it worked!) The intention certainly wasn't to scare anyone -- for instance, I didn't expect these results ot be that bad. The goal of this measurements was to get some data regarding on where we're standing with respect to IPv6 fragmentation and extension headers. This is just data that is useful and should keep in mind when developing protocols and/or extensions. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From evyncke@cisco.com Mon Nov 4 18:47: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 6C82B21E83A8 for ; Mon, 4 Nov 2013 18:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxRUo3JgbbOu for ; Mon, 4 Nov 2013 18:46:56 -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 2408021E83A9 for ; Mon, 4 Nov 2013 18:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1007; q=dns/txt; s=iport; t=1383619609; x=1384829209; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Pou6MGKIdI6HaKyeG6KUD0GDKk7Zqz0icoEenZFJCdg=; b=H02gZErv2Tq6H6SyN8h7mNtmvzvbWX8ofeZnMoRC85bTpiT4DTgK8MLX HQ5PU/lJ8f+8xv3Fj4lkOoLHNNCZLTtceUUnRuvYvDI0bMZSq/ScCaalz Zj9Ue9jId4wJ8qntO6uW8qGyXjeckC79xU/IQGDg02at9EKOqq8lRtLLh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFALZbeFKtJV2a/2dsb2JhbABZgweBC787gSgWdIIlAQEBBHkMBAIBCA4DBAEBAQodBzIUCQgCBA4FCId5vkGOAoEYMQcGgxqBDgOJCKELgyaBcTk X-IronPort-AV: E=Sophos;i="4.93,637,1378857600"; d="scan'208";a="280673191" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 05 Nov 2013 02:46:48 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA52klMn007659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 02:46:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:46:47 -0600 From: "Eric Vyncke (evyncke)" To: Mikael Abrahamsson Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: AQHOyHBxK2tyuJV06kS+8KMLL/FcoZoWC5xAgABmFQD//5/CkA== Date: Tue, 5 Nov 2013 02:46:47 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 05 Nov 2013 02:47:02 -0000 OK, understood, thanks :-) Your (and Victor's one) should be added to the d= ocument to make it clearer IMHO -=E9ric > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: lundi 4 novembre 2013 18:31 > To: Eric Vyncke (evyncke) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt >=20 > On Tue, 5 Nov 2013, Eric Vyncke (evyncke) wrote: >=20 > > I have hard time to understand the case described in section 3.1.4 > > "co-existence of NAT44 and NAT64". Why would a provider use both at > > the same time? Using NAT44 + native IPv6 is sensible, using IPv6-only > > + > > NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 could > > be use together for the same subscribers. >=20 > Mobile. >=20 > It's up to the terminal to initiate a connection in the APN, and you don'= t > know if it'll be IPv4 only, IPv6 only or dual stack. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From Christopher.Palmer@microsoft.com Mon Nov 4 18:50: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 3C24921E80B0 for ; Mon, 4 Nov 2013 18:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na+yiiaFxj7a for ; Mon, 4 Nov 2013 18:50:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id E3BF121E80AC for ; Mon, 4 Nov 2013 18:50:29 -0800 (PST) Received: from BN1PR03MB171.namprd03.prod.outlook.com (10.255.200.150) by BN1PR03MB171.namprd03.prod.outlook.com (10.255.200.150) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 5 Nov 2013 02:50:27 +0000 Received: from BN1PR03MB171.namprd03.prod.outlook.com ([169.254.11.115]) by BN1PR03MB171.namprd03.prod.outlook.com ([169.254.11.44]) with mapi id 15.00.0785.001; Tue, 5 Nov 2013 02:50:27 +0000 From: Christopher Palmer To: "v6ops@ietf.org" Thread-Topic: ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis Thread-Index: Ac7Z0GgDwAaANnZ8RHGaVb7M0I7XYw== Date: Tue, 5 Nov 2013 02:50:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:7cd1:2b3:3a66:1b31] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(76786001)(76796001)(76576001)(77096001)(56816003)(4396001)(47736001)(47976001)(54356001)(81342001)(15202345003)(49866001)(50986001)(87266001)(74316001)(51856001)(69226001)(53806001)(76176001)(46102001)(33646001)(83072001)(19300405004)(74876001)(31966008)(79102001)(59766001)(47446002)(77982001)(74662001)(74502001)(65816001)(85306002)(83322001)(15975445006)(81686001)(81816001)(19580395003)(81542001)(76482001)(80976001)(74706001)(74366001)(56776001)(16236675002)(80022001)(63696002)(54316002)(2656002)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB171; H:BN1PR03MB171.namprd03.prod.outlook.com; CLIP:2001:67c:370:160:7cd1:2b3:3a66:1b31; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a2dc12c28a1d4eb28e7da36c959e2e9bBN1PR03MB171namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 02:50:38 -0000 --_000_a2dc12c28a1d4eb28e7da36c959e2e9bBN1PR03MB171namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.3 of the draft: " As described in section 2.2.2 of [RFC5220], when an enterprise has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, then the enterprise chose ULA for site-local IPv6 connectivity. Each employee host will have both an IPv4 global or private address and a ULA. Here, when this host tries to connect to an outside node that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and the ULA for the source address according to the IPv6 preference of the default address selection policy [RFC3484]. This will clearly result in a connection failure." This is only true if the ULA is configured on a host that also has a defaul= t route The enterprise can avoid any issues by simply configuring a scoped = route on hosts (say, only for the ULA prefix). If a network does not provid= e connectivity to the IPv6 Internet, it should not advertise ::/0. I think it's useful to discuss that configuration route, which is possible = today with a vast majority of hosts and just works. Modifying the prefix policy table is not suitable at scale. And the DNS pre= ference logic alluded to in section 3.3 is highly ambiguous. --_000_a2dc12c28a1d4eb28e7da36c959e2e9bBN1PR03MB171namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.3 of = the draft:

 

“  As described in section 2.2.2 of [RFC52=
20], when an enterprise has
   IPv4 Internet connectivity but =
does not yet have IPv6 Internet
   connectivity, then the enterpri=
se chose ULA for site-local IPv6
   connectivity. Each employee hos=
t will have both an IPv4 global or
   private address and a ULA. Here=
, when this host tries to connect to
   an outside node that has regist=
ered both A and AAAA records in the
 
   DNS, the host will choose AAAA =
as the destination address and the ULA
   for the source address accordin=
g to the IPv6 preference of the
   default address selection polic=
y [RFC3484]. This will c=
learly result

&nb= sp;  in a connection failure.”

 

This is only tr= ue if the ULA is configured on a host that also has a default route The ent= erprise can avoid any issues by simply configuring a scoped route on hosts = (say, only for the ULA prefix). If a network does not provide connectivity to the IPv6 Internet, it should not = advertise ::/0.

 

I think it̵= 7;s useful to discuss that configuration route, which is possible today wit= h a vast majority of hosts and just works.

 

Modifying the p= refix policy table is not suitable at scale. And the DNS preference logic a= lluded to in section 3.3 is highly ambiguous.

--_000_a2dc12c28a1d4eb28e7da36c959e2e9bBN1PR03MB171namprd03pro_-- From tjc@ecs.soton.ac.uk Mon Nov 4 18:52: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 63C7111E8272; Mon, 4 Nov 2013 18:52:12 -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.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZurhGXMwkjTH; Mon, 4 Nov 2013 18:52:11 -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 B80DF11E827F; Mon, 4 Nov 2013 18:52:06 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52q3SV028524; Tue, 5 Nov 2013 02:52:03 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA52q3SV028524 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383619923; bh=fBbDbhJZ8FTXy6wHFLxpI8fStRo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=2/XtgNHWsIxPYfeTYOc7rsGTJyujcqRxBlKjQclADKr1G0HfdzbbQ7p3tYg7B7CbF 7f2mAY5d4Td+mL5rkZwILLK2zM8AyzeOZF+dgxZhoGFArVslf7MbF+O2cFTtXAgIPt S8LnZndd1TaV16toDyn0xtpPnvHRNlnoyJkyhzfE= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pA42q30959635222SQ ret-id none; Tue, 05 Nov 2013 02:52:03 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:6865:dd3f:9c57:76dd] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52ofSY002200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 02:50:43 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: <52785BC9.3040705@si6networks.com> Date: Tue, 5 Nov 2013 02:50:41 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5278275C.50206@gont.com.ar> <52785BC9.3040705@si6networks.com> <2E537845-6042-4572-B00E-A9197EFD9DF8@ecs.soton.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA42q3095963522200; tid=pA42q30959635222SQ; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA52q3SV028524 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Pedro Torres Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:52:12 -0000 On 5 Nov 2013, at 02:45, Fernando Gont wrote: > Hi, Pedro, >=20 > On 11/04/2013 05:53 PM, Pedro Torres wrote: >> Tim/Fernando, >>=20 >> Wow! I'm scared of these results! >> (If that was the intention, it worked!) >=20 > The intention certainly wasn't to scare anyone -- for instance, I = didn't > expect these results ot be that bad. >=20 > The goal of this measurements was to get some data regarding on where > we're standing with respect to IPv6 fragmentation and extension = headers. And to encourage further measurements, which I think Fernando will do = via his scripts (which I think are part of his wider set of IPv6 tools) = and which a student here will do via use of and/or extending scapy. We can then get some idea of where the problems exist, and whether, for = example, there are ICMPv6 messages returned or the packets are simply = being dropped. > This is just data that is useful and should keep in mind when = developing > protocols and/or extensions. Indeed, or when writing docs like the one Ron is authoring on extension = header handling. Tim= From Fred.L.Templin@boeing.com Mon Nov 4 18:57: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 B752921E83B6; Mon, 4 Nov 2013 18:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82FkOKjCPSu6; Mon, 4 Nov 2013 18:57:37 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id DE8E021E80F1; Mon, 4 Nov 2013 18:57:36 -0800 (PST) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id rA52va3F032405; Mon, 4 Nov 2013 18:57:36 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rA52vZeA032402 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Nov 2013 18:57:35 -0800 Received: from XCH-BLV-401.nw.nos.boeing.com (130.247.25.18) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 4 Nov 2013 18:57:35 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.67]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 18:57:34 -0800 From: "Templin, Fred L" To: Tim Chown , Fernando Gont Thread-Topic: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet Thread-Index: AQHO2dIRumLVu/JCNU+q9AN/9oGPZJoV8OYw Date: Tue, 5 Nov 2013 02:57:34 +0000 Message-ID: <2134F8430051B64F815C691A62D98318148482@XCH-BLV-504.nw.nos.boeing.com> References: <5278275C.50206@gont.com.ar> <52785BC9.3040705@si6networks.com> <2E537845-6042-4572-B00E-A9197EFD9DF8@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Pedro Torres Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 02:57:45 -0000 Hi Tim and Fernando, > > This is just data that is useful and should keep in mind when developin= g > > protocols and/or extensions. We already have at least one protocol that requires IPv6 fragmentation (RFC2473) and I'm sure there are others. > Indeed, or when writing docs like the one Ron is authoring on extension h= eader handling. Or SEAL also. But, SEAL simply takes the existing precedent set by RFC2473. Thanks - Fred fred.l.templin@boeing.com > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From victor@jvknet.com Mon Nov 4 18:58: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 7F95521E83C2 for ; Mon, 4 Nov 2013 18:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLQsP8soSGmY for ; Mon, 4 Nov 2013 18:57:58 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5A28221E839F for ; Mon, 4 Nov 2013 18:57:55 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id my12so1351100bkb.24 for ; Mon, 04 Nov 2013 18:57:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=vzu2i1rDPQpmi8Qis1Bitz16SVcSPUiLiM9L+0gn/LU=; b=BcrgMdOsgK4uZAVqAs5dTNH2rTG1SGeNm+ByyiocBFmin89iMa+Kq2eUqmb7kMLuDv u1SW8V1LJBB63Z0sPi9t+lSUFTrSt7WITx/bASb1o1234lYbjbyPKuCd2mGLFkXYvW1n bACmax0m3Yp5cfHC10y/MKiNQS3NujRJX7yAkZZ8cPtWxS+IYoxb0ot9HDBgBlxyyoJU I795fplfyXj4caN8LMixwUHR+kGRtLdhaV47ngZxUI0P/u0S9D+uO1swfK5cejNbNH5g pPvfm/O+HZAWXymMDTOpKeprZFir0Tw1qpENXOKwN3mJ5StUtKCthndoQu/BQOADe5c1 lL9g== X-Gm-Message-State: ALoCoQkVgZzxQFR5AqHHM6AwdsTN9slpGOKfgtYGdIuWeaD+2n0buE8IYylYGxinZIOWjwRss4yp X-Received: by 10.205.3.7 with SMTP id nw7mr6540656bkb.26.1383620274350; Mon, 04 Nov 2013 18:57:54 -0800 (PST) Received: from [31.133.162.206] (dhcp-a2ce.meeting.ietf.org. [31.133.162.206]) by mx.google.com with ESMTPSA id pk7sm17389924bkb.2.2013.11.04.18.57.52 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Nov 2013 18:57:54 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 04 Nov 2013 18:57:48 -0800 From: Victor Kuarsingh To: "Eric Vyncke (evyncke)" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 05 Nov 2013 02:58:07 -0000 All, Ooops.. > > >In such a case, if using private IPv6 addresses for the UE, it's possible Typo - s/private IPv6 addresses/private IPv4 addresses/g Victor K >that you can have this happen. Perhaps, as long as it does not break >anything, it's ok? > >Regards, > >Victor K > > >> >>-=E9ric >> >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>>Of >>> internet-drafts@ietf.org >>> Sent: dimanche 13 octobre 2013 16:00 >>> To: i-d-announce@ietf.org >>> Cc: v6ops@ietf.org >>> Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IPv6 Operations Working Group of the >>> IETF. >>>=20 >>> Title : NAT64 Operational Experiences >>> Author(s) : Gang Chen >>> Zhen Cao >>> Chongfeng Xie >>> David Binet >>> Filename : draft-ietf-v6ops-nat64-experience-04.txt >>> Pages : 20 >>> Date : 2013-10-13 >>>=20 >>> Abstract: >>> This document summarizes NAT64 function deployment scenarios and >>> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) >>>and >>> NAT64 server Front End (NAT64-FE) are considered in this document. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-04 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> 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 tjc@ecs.soton.ac.uk Mon Nov 4 18:59:06 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 21CBF21E80F1 for ; Mon, 4 Nov 2013 18:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y+NtLxhxvuV for ; Mon, 4 Nov 2013 18:59:05 -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 8F1B221E83B9 for ; Mon, 4 Nov 2013 18:59:01 -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 rA52wx9B029561 for ; Tue, 5 Nov 2013 02:58:59 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA52wx9B029561 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383620339; bh=C2Ql9YNSCbjp6iBouOIeBm3Oo6k=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=VOacLp21v2spr1RyY2ub2MZ/vmWuJ7yERk6XxE/o3zOt5tcgeWwLT5BTVzUWEVeK6 AkHGbSnAwhBTOlsmwbea4K+Yrz+wziQjAOndKMsOOMYCX+cFMDcLkpioR/8AV4wZ2F syet0CCYaGWteG0uOfpKA/BNpKFq8h9zsUJ8VaHQ= 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 pA42wx0959635252jn ret-id none; Tue, 05 Nov 2013 02:58:59 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:6865:dd3f:9c57:76dd] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52woUZ003922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Nov 2013 02:58:52 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_F549B443-736E-4706-A4BD-C08A09EDE32E" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Date: Tue, 5 Nov 2013 02:58:50 +0000 References: To: "v6ops@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA42wx095963525200; tid=pA42wx0959635252jn; 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: rA52wx9B029561 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 02:59:06 -0000 --Apple-Mail=_F549B443-736E-4706-A4BD-C08A09EDE32E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The 3484=92s in that chunk of text should be 6724=92s. Tim On 5 Nov 2013, at 02:50, Christopher Palmer = wrote: > Section 3.3 of the draft: > =20 > =93 As described in section 2.2.2 of [RFC5220], when an enterprise = has > IPv4 Internet connectivity but does not yet have IPv6 Internet > connectivity, then the enterprise chose ULA for site-local IPv6 > connectivity. Each employee host will have both an IPv4 global or > private address and a ULA. Here, when this host tries to connect to > an outside node that has registered both A and AAAA records in the > =20 > DNS, the host will choose AAAA as the destination address and the = ULA > for the source address according to the IPv6 preference of the > default address selection policy [RFC3484]. This will clearly = result > in a connection failure.=94 > =20 > This is only true if the ULA is configured on a host that also has a = default route The enterprise can avoid any issues by simply configuring = a scoped route on hosts (say, only for the ULA prefix). If a network = does not provide connectivity to the IPv6 Internet, it should not = advertise ::/0. > =20 > I think it=92s useful to discuss that configuration route, which is = possible today with a vast majority of hosts and just works. > =20 > Modifying the prefix policy table is not suitable at scale. And the = DNS preference logic alluded to in section 3.3 is highly ambiguous. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_F549B443-736E-4706-A4BD-C08A09EDE32E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = 3484=92s in that chunk of text should be = 6724=92s.

Tim

On 5 Nov 2013, = at 02:50, Christopher Palmer <Christopher.Palmer@micros= oft.com> wrote:

Section 3.3 of the = draft:

 

=93  As described =
in section 2.2=
.2 of [RFC5220], when an enterprise has
   IPv4 =
Internet connectivity but does not yet have IPv6 =
Internet
   =
connectivity, then the enterprise chose ULA for site-local =
IPv6
   =
connectivity. Each employee host will have both an IPv4 global =
or
   private =
address and a ULA. Here, when this host tries to connect =
to
   an outside =
node that has registered both A and AAAA records in the
 
   DNS, the =
host will choose AAAA as the destination address and the =
ULA
   for the =
source address according to the IPv6 preference of =
the
   default =
address selection policy [RFC3484]. This will =
clearly result

   in a connection = failure.=94

 

This is only = true if the ULA is configured on a host that also has a default route = The enterprise can avoid any issues by simply configuring a scoped route = on hosts (say, only for the ULA prefix). If a network does not provide connectivity to the IPv6 Internet, it should = not advertise ::/0.

 

I think it=92s = useful to discuss that configuration route, which is possible today with = a vast majority of hosts and just works.

 

Modifying the = prefix policy table is not suitable at scale. And the DNS preference = logic alluded to in section 3.3 is highly ambiguous.

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

= --Apple-Mail=_F549B443-736E-4706-A4BD-C08A09EDE32E-- From fgont@si6networks.com Mon Nov 4 19:00: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 32E7311E80F5 for ; Mon, 4 Nov 2013 19:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT703WM0CYiQ for ; Mon, 4 Nov 2013 19:00:37 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1119E21E82F9 for ; Mon, 4 Nov 2013 19:00:26 -0800 (PST) Received: from [2001:67c:370:160:517b:6f2e:1bc7:1d4a] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VdWsD-0007NV-6b; Tue, 05 Nov 2013 04:00:09 +0100 Message-ID: <52785F34.6020606@si6networks.com> Date: Mon, 04 Nov 2013 19:00:04 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan , Fernando Gont References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 03:00:38 -0000 On 11/04/2013 06:23 PM, Ole Troan wrote: >> >> In any case, the interesting (and unfortunate) data if the >> chances of success when you use extension headers or >> fragmentation are in the scale of "unlikely". :-( > > I'm not sure you can draw that conclusion without knowing where > the fragments are dropped. > > e.g. you are not saying that fragmented packets will be dropped > anywhere on the link between your home and mine, are you? I'm certainly not. All tests were against web servers. > I'm for example not concerned about a web server or load balancer > that sets TCP MSS to 1220 and then drop fragments. Certainly, there's much more testing to be done (this is even stated in the slideware :-) ). That said, you might still be concerned about the case you meantion -- at least in theory, that case might arise in a NAT64 (?) case. Also, one of the main points of this slideware is that its not just fragments that are dropped, but extension headers in general. In any case, my goal of sharing the results is to trigger discussion and encourage further testing, rather than coming up with scary or bold statements. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Nov 4 19:05: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 D891F11E8232 for ; Mon, 4 Nov 2013 19:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziHEiHqmfG7E for ; Mon, 4 Nov 2013 19:05:57 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 317EB21E80DB for ; Mon, 4 Nov 2013 19:05:57 -0800 (PST) Received: from [2001:67c:370:160:517b:6f2e:1bc7:1d4a] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VdWxn-0007a0-CB; Tue, 05 Nov 2013 04:05:55 +0100 Message-ID: <52785CA4.1060600@si6networks.com> Date: Mon, 04 Nov 2013 18:49:08 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tim Chown , Jen Linkova References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <001F10BA-F1D4-4AFA-BC0B-E574739782FA@ecs.soton.ac.uk> <9DC9AFAD-CB63-46BC-B8E1-229F5EA64E6E@ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 03:05:58 -0000 On 11/04/2013 06:21 PM, Tim Chown wrote: > >> On Tue, Nov 5, 2013 at 2:31 AM, Tim Chown wrote: >>>> does the above results show the _network_ dropping fragments, or the end host or a system closely associated with the end host dropping extension headers? >>> >>> For mine, the test was simply whether the HTTP request solicited a response. >> >> It could be verified by checking the hop limit from the your machine >> to the server you are testing and then vary the hop limits of probe >> packets - so you can see when you stop receiving 'time exceeded’. > > Modifying traceroute itself to slip in some extension headers might be useful? Much as you can check DSCP rewrites, for example. FWIW, I'm in the process of updating the toolkit to support this sort of thing.. Should have something along these lines shortly. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Christopher.Palmer@microsoft.com Mon Nov 4 19:10: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 C401921E809F for ; Mon, 4 Nov 2013 19:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDewZ25RYAva for ; Mon, 4 Nov 2013 19:10:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0158.outbound.protection.outlook.com [207.46.163.158]) by ietfa.amsl.com (Postfix) with ESMTP id C55FB11E80F8 for ; Mon, 4 Nov 2013 19:10:47 -0800 (PST) Received: from BN1PR03MB171.namprd03.prod.outlook.com (10.255.200.150) by BN1PR03MB171.namprd03.prod.outlook.com (10.255.200.150) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 5 Nov 2013 03:10:46 +0000 Received: from BN1PR03MB171.namprd03.prod.outlook.com ([169.254.11.115]) by BN1PR03MB171.namprd03.prod.outlook.com ([169.254.11.44]) with mapi id 15.00.0785.001; Tue, 5 Nov 2013 03:10:46 +0000 From: Christopher Palmer To: Tim Chown , "v6ops@ietf.org" Thread-Topic: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis Thread-Index: Ac7Z0GgDwAaANnZ8RHGaVb7M0I7XYwAAov4AAAAfT7A= Date: Tue, 5 Nov 2013 03:10:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:7cd1:2b3:3a66:1b31] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(24454002)(76786001)(76796001)(76576001)(77096001)(56816003)(4396001)(47736001)(47976001)(54356001)(81342001)(15202345003)(49866001)(50986001)(87266001)(74316001)(51856001)(69226001)(53806001)(46102001)(33646001)(83072001)(19300405004)(74876001)(31966008)(79102001)(59766001)(47446002)(77982001)(74662001)(74502001)(65816001)(85306002)(83322001)(15975445006)(81686001)(19580405001)(81816001)(19580395003)(81542001)(76482001)(80976001)(74706001)(74366001)(56776001)(16236675002)(80022001)(63696002)(54316002)(2656002)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB171; H:BN1PR03MB171.namprd03.prod.outlook.com; CLIP:2001:67c:370:160:7cd1:2b3:3a66:1b31; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_fbfd317f606e47fb8666f45cfe8ce7dfBN1PR03MB171namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 03:10:56 -0000 --_000_fbfd317f606e47fb8666f45cfe8ce7dfBN1PR03MB171namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The majority of in-the-wild hosts are running 3484, so as an operational do= cument I think it's reasonable to discuss the issue as it exists with those= machines. Even with 6724 - hosts configured as described in 3.3 may still attempt a U= LA -> Native IPv6 connection. That connection will just not be preferred ov= er IPv4 -> IPv4. I'd argue that's still non-ideal. If the enterprise hosts in question do no= t have access to the IPv6 Internet, they should not be configured with a de= fault route - thus they would *never* attempt connectivity. Overprovisioning effective IPv6 connectivity is a painful topic. From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= im Chown Sent: Monday, November 4, 2013 6:59 PM To: v6ops@ietf.org Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis The 3484's in that chunk of text should be 6724's. Tim On 5 Nov 2013, at 02:50, Christopher Palmer > wrote: Section 3.3 of the draft: " As described in section 2.2.2 of [RFC5220], when an enterprise has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, then the enterprise chose ULA for site-local IPv6 connectivity. Each employee host will have both an IPv4 global or private address and a ULA. Here, when this host tries to connect to an outside node that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and the ULA for the source address according to the IPv6 preference of the default address selection policy [RFC3484]. This will clearly result in a connection failure." This is only true if the ULA is configured on a host that also has a defaul= t route The enterprise can avoid any issues by simply configuring a scoped = route on hosts (say, only for the ULA prefix). If a network does not provid= e connectivity to the IPv6 Internet, it should not advertise ::/0. I think it's useful to discuss that configuration route, which is possible = today with a vast majority of hosts and just works. Modifying the prefix policy table is not suitable at scale. And the DNS pre= ference logic alluded to in section 3.3 is highly ambiguous. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_fbfd317f606e47fb8666f45cfe8ce7dfBN1PR03MB171namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The majority of in-the= -wild hosts are running 3484, so as an operational document I think it̵= 7;s reasonable to discuss the issue as it exists with those machines.

 

Even with 6724 –= hosts configured as described in 3.3 may still attempt a ULA -> Native = IPv6 connection. That connection will just not be preferred over IPv4 ->= IPv4.

 

I’d argue that&#= 8217;s still non-ideal. If the enterprise hosts in question do not have acc= ess to the IPv6 Internet, they should not be configured with a default rout= e – thus they would *never* attempt connectivity.

 

Overprovisioning effec= tive IPv6 connectivity is a painful topic.=

From: v6ops-bounces@ietf.org [mailto:v6ops-bo= unces@ietf.org] On Behalf Of Tim Chown
Sent: Monday, November 4, 2013 6:59 PM
To: v6ops@ietf.org
Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analys= is

 

The 3484’s in that chunk of text should be 672= 4’s.

 

Tim

 

On 5 Nov 2013, at 02:50, Christopher Palmer <Christopher.Palmer@microsof= t.com> wrote:



Section 3.3 of = the draft:

 

“  As described in section 2.2.2 of [RFC52=
20], when an enterprise has
   IPv4 Internet connectivity but =
does not yet have IPv6 Internet
   connectivity, then the enterpri=
se chose ULA for site-local IPv6
   connectivity. Each employee hos=
t will have both an IPv4 global or
   private address and a ULA. Here=
, when this host tries to connect to
   an outside node that has regist=
ered both A and AAAA records in the
 
   DNS, the host will choose AAAA =
as the destination address and the ULA
   for the source address accordin=
g to the IPv6 preference of the
   default address selection polic=
y [RFC3484]. This will c=
learly result

&nb= sp;  in a connection failure.”

 

This is only tr= ue if the ULA is configured on a host that also has a default route The ent= erprise can avoid any issues by simply configuring a scoped route on hosts = (say, only for the ULA prefix). If a network does not provide connectivity to the IPv6 Internet, it should not = advertise ::/0.

 

I think it̵= 7;s useful to discuss that configuration route, which is possible today wit= h a vast majority of hosts and just works.

 

Modifying the p= refix policy table is not suitable at scale. And the DNS preference logic a= lluded to in section 3.3 is highly ambiguous.

____________________________________= ___________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.or= g/mailman/listinfo/v6ops

 

--_000_fbfd317f606e47fb8666f45cfe8ce7dfBN1PR03MB171namprd03pro_-- From prvs=014a613ed=Dave.Michaud@rci.rogers.com Mon Nov 4 19:13: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 0102221E80CF for ; Mon, 4 Nov 2013 19:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnwJExVU5ITH for ; Mon, 4 Nov 2013 19:13:30 -0800 (PST) Received: from mail.mail.rss.rogers.com (mail.mail.rss.rogers.com [142.146.31.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5065921E8056 for ; Mon, 4 Nov 2013 19:13:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEBAFtheFKOkg6Cl2dsb2JhbABZw02BKBYOAQEBAQEIFgc8gicBBBIeIwsBLAEVFQYYB1cBBBsah1+ceINCngyPGk6DCoEOA4kIOIVaj1SOaR4 X-IronPort-AV: E=Sophos;i="4.93,637,1378872000"; d="scan'208";a="217969843" Received: from unknown (HELO rsoesnexigwa.rci.rogers.ca) ([142.146.14.130]) by mail.mail.rss.rogers.com with ESMTP; 04 Nov 2013 22:13:26 -0500 Received: from RSOESNGTABHA.rci.rogers.ca ([10.3.37.22]) by rsoesnexigwa.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Nov 2013 22:13:27 -0500 Received: from CL08MBE.rci.rogers.ca ([10.3.45.56]) by RSOESNGTABHA.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Nov 2013 22:13:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Nov 2013 22:08:37 -0500 Message-ID: <29AE8DB910E7704CA043795E00DCBE7803417A05@CL08MBE.rci.rogers.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: draft-byrne-v6ops-clatip-00 thread-index: Ac7Z1FIgWdjhF87yQc60vkaLrXcsQg== From: "Dave Michaud" To: X-OriginalArrivalTime: 05 Nov 2013 03:13:26.0418 (UTC) FILETIME=[FE5DD720:01CED9D4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: [v6ops] draft-byrne-v6ops-clatip-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: Tue, 05 Nov 2013 03:13:36 -0000 VGhlIGRpc2N1c3Npb24vY29udHJvdmVyc3kgZm9yIHRoaXMgZG9jdW1lbnQgc2VlbWVkIHRvIGJl IGFyb3VuZCB0aGUgY29uY2VwdCBvZiByZXNlcnZpbmcgYW4gYWRkcmVzcyBmb3IgNDY0WExBVCB1 c2UuCgpJIHRoaW5rIGhvd2V2ZXIsIGFuZCB0aGlzIGlzIG15IGludGVycHJldGF0aW9uIHdoZW4g SSByZWFkIHRoZSBJLUQsIHRoYXQgdGhlIGN1cnJlbnQgaW50ZW50aW9uIGlzIG9ubHkgdG8gZ2Vu ZXJhbGl6ZSBhIGJsb2NrIGFscmVhZHkgYXNzaWduZWQgZm9yIERTLWxpdGUgc28gdGhhdCBpdCBj YW4gYmUgcmUtdXNlZCBmb3Igb3RoZXIgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMuIFRoZSBpZGVh IGhlcmUgaXMgdG8gcHJvdmlkZSBhbiBvcHRpb24gZm9yIGRlcGxveWluZyA0NjRYTEFULiAKCk1h bmRhdGluZyB0aGUgdXNlIG9mIHRoaXMgcmFuZ2UgbWF5IGJlIGluYXBwcm9wcmlhdGUgYXQgdGhp cyBwb2ludCBidXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBk cmFmdCBkb2VzIGFueXdheS4KCgpEYXZlIE1pY2hhdWQKCgpUaGlzIGUtbWFpbCAoYW5kIGF0dGFj aG1lbnQocykpIGlzIGNvbmZpZGVudGlhbCwgcHJvcHJpZXRhcnksIG1heSBiZSBzdWJqZWN0IHRv IGNvcHlyaWdodCBhbmQgbGVnYWwgcHJpdmlsZWdlIGFuZCBubyByZWxhdGVkIHJpZ2h0cyBhcmUg d2FpdmVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9yIGl0cyBhZ2Vu dCwgYW55IHJldmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2Yg dGhpcyBlLW1haWwgb3IgYW55IG9mIGl0cyBjb250ZW50IGlzIHN0cmljdGx5IHByb2hpYml0ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4gQWxsIG1lc3NhZ2VzIG1heSBiZSBtb25pdG9yZWQgYXMgcGVy bWl0dGVkIGJ5IGFwcGxpY2FibGUgbGF3IGFuZCByZWd1bGF0aW9ucyBhbmQgb3VyIHBvbGljaWVz IHRvIHByb3RlY3Qgb3VyIGJ1c2luZXNzLiBFLW1haWxzIGFyZSBub3Qgc2VjdXJlIGFuZCB5b3Ug YXJlIGRlZW1lZCB0byBoYXZlIGFjY2VwdGVkIGFueSByaXNrIGlmIHlvdSBjb21tdW5pY2F0ZSB3 aXRoIHVzIGJ5IGUtbWFpbC4gSWYgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMg aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBm cm9tIGFueSBjb21wdXRlciBvciBhbnkgc3RvcmFnZSBtZWRpdW0gd2l0aG91dCBwcmludGluZyBh IGNvcHkuCgpDZSBjb3VycmllbCAoYWluc2kgcXVlIHNlcyBwacOoY2VzIGpvaW50ZXMpIGVzdCBj b25maWRlbnRpZWwsIGV4Y2x1c2lmLCBldCBwZXV0IGZhaXJlIGzigJlvYmpldCBkZSBkcm9pdCBk 4oCZYXV0ZXVyIGV0IGRlIHByaXZpbMOoZ2UganVyaWRpcXVlOyBhdWN1biBkcm9pdCBjb25uZXhl IG7igJllc3QgZXhjbHUuIFNpIHZvdXMgbuKAmcOqdGVzIHBhcyBsZSBkZXN0aW5hdGFpcmUgdmlz w6kgb3Ugc29uIHJlcHLDqXNlbnRhbnQsIHRvdXRlIMOpdHVkZSwgZGlmZnVzaW9uLCB0cmFuc21p c3Npb24gb3UgY29waWUgZGUgY2UgY291cnJpZWwgZW4gdG91dCBvdSBlbiBwYXJ0aWUsIGVzdCBz dHJpY3RlbWVudCBpbnRlcmRpdGUgZXQgcGV1dCDDqnRyZSBpbGzDqWdhbGUuIFRvdXMgbGVzIG1l c3NhZ2VzIHBldXZlbnQgw6p0cmUgc3VydmVpbGzDqXMsIHNlbG9uIGxlcyBsb2lzIGV0IHLDqGds ZW1lbnRzIGFwcGxpY2FibGVzIGV0IGxlcyBwb2xpdGlxdWVzIGRlIHByb3RlY3Rpb24gZGUgbm90 cmUgZW50cmVwcmlzZS4gTGVzIGNvdXJyaWVscyBuZSBzb250IHBhcyBzw6ljdXJpc8OpcyBldCB2 b3VzIMOqdGVzIHLDqXB1dMOpcyBhdm9pciBhY2NlcHTDqSB0b3VzIGxlcyByaXNxdWVzIHF1aSB5 IHNvbnQgbGnDqXMgc2kgdm91cyBjaG9pc2lzc2V6IGRlIGNvbW11bmlxdWVyIGF2ZWMgbm91cyBw YXIgY2UgbW95ZW4uIFNpIHZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IG5vdXMgZW4gYXZpc2VyIGltbcOpZGlhdGVtZW50IGV0IHN1cHByaW1lciBjZSBjb3Vy cmllbCAoYWluc2kgcXVlIHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVzKSBkZSB0b3V0IG9yZGlu YXRldXIgb3Ugc3VwcG9ydCBkZSBkb25uw6llcyBzYW5zIGVuIGltcHJpbWVyIHVuZSBjb3BpZS4g Cg== From phdgang@gmail.com Mon Nov 4 19:15: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 1DB9611E821F for ; Mon, 4 Nov 2013 19:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA7immZDqpLv for ; Mon, 4 Nov 2013 19:15:01 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 81F0111E81F7 for ; Mon, 4 Nov 2013 19:15:01 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id s19so4422180qcw.21 for ; Mon, 04 Nov 2013 19:15:01 -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:content-transfer-encoding; bh=L2PAbUv7WHOdouXLIzugSxZ95jcX0FqGtYrcfGnByJc=; b=c0eiO1qMJJC301+K9fKHHiaBKpTcJ5dJfDWvVXB6elWqvcTOOg0rASMQC5Mc+3ssvo +FadtiZgLkW+F8H2TH3fAiy7BN9JwVwY+pK7I/UrFAmHZNixcV4J7JZUL8e2YrYkIGF7 qPBvWEb+7tIzXLOAmlY7bODbsS2Qeek/eAH594LB2PRpbYwGZOwKjuDNtk6vTfH3igi9 iZ15xGOEHkzcTP5V8E4pJZL1h1/vpmf0l7FmrcBzrsprBJa5jkNbOHNuXz1GHhEJBzaS udgpcNXtBZHuODu3YfnBgGCtlPoWEkY4TpZm34evMAPtHzmW1egx4OXlJQoxP2h6WhCZ O5Rw== MIME-Version: 1.0 X-Received: by 10.224.54.129 with SMTP id q1mr26287543qag.19.1383621301066; Mon, 04 Nov 2013 19:15:01 -0800 (PST) Received: by 10.224.204.4 with HTTP; Mon, 4 Nov 2013 19:15:01 -0800 (PST) In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> Date: Tue, 5 Nov 2013 11:15:01 +0800 Message-ID: From: GangChen To: "Eric Vyncke (evyncke)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 05 Nov 2013 03:15:02 -0000 2013/11/5, Eric Vyncke (evyncke) : > OK, understood, thanks :-) Your (and Victor's one) should be added to the > document to make it clearer IMHO Yes. In the draft, we have following description: The coexistence has already appeared in mobile networks, in which dual stack mobile phones normally initiate some dual-stack PDN/PDP Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated addresses are very often private ones. -Gang > > -=E9ric > >> -----Original Message----- >> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >> Sent: lundi 4 novembre 2013 18:31 >> To: Eric Vyncke (evyncke) >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.tx= t >> >> On Tue, 5 Nov 2013, Eric Vyncke (evyncke) wrote: >> >> > I have hard time to understand the case described in section 3.1.4 >> > "co-existence of NAT44 and NAT64". Why would a provider use both at >> > the same time? Using NAT44 + native IPv6 is sensible, using IPv6-only >> > + >> > NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 could >> > be use together for the same subscribers. >> >> Mobile. >> >> It's up to the terminal to initiate a connection in the APN, and you >> don't >> know if it'll be IPv4 only, IPv6 only or dual stack. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From furry13@gmail.com Mon Nov 4 19:23: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 ADCF411E8155 for ; Mon, 4 Nov 2013 19:23:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ysFvW43AECV for ; Mon, 4 Nov 2013 19:23:27 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2735711E821F for ; Mon, 4 Nov 2013 19:23:23 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id n9so4495561qcw.15 for ; Mon, 04 Nov 2013 19:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=6v2GzwsHG+wc2j5BnfsKC+kxjtufkwjVUkyBcv2dnI8=; b=iSGXNaTxfxVlDpJaAOZpoi5vAvkGJ6Cu3t5YVFNvnM74rFK0ilYL96yxAiOKIKBHgv j92QlsS9AdPixFKM62KD//HO5TRk8jW39eMmM8qh7LeOH7wKpyh24XItSvylIIX+A1Iw sQB0DqKANfZlJOFS5P/wTM9b2yIds15FjUl2Jvx4gDflpuJay1buhJXonej2ZP02k6fD gjKRU3lCYb9AEaPp+uzZpIokQ6thUFZAXAlZJxy099an24Qy/06AnaqnYM1H1Tpc3rHc +YQgaEUOUj3LMMIMjYsJcN4lzfLtUCYnC0FIzgGAmiYp4St5Mhzcs6F0xnlXUTOhZW2a Z7vw== X-Received: by 10.49.71.207 with SMTP id x15mr26926309qeu.49.1383621802660; Mon, 04 Nov 2013 19:23:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Mon, 4 Nov 2013 19:23:02 -0800 (PST) In-Reply-To: <52785CA4.1060600@si6networks.com> References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <001F10BA-F1D4-4AFA-BC0B-E574739782FA@ecs.soton.ac.uk> <9DC9AFAD-CB63-46BC-B8E1-229F5EA64E6E@ecs.soton.ac.uk> <52785CA4.1060600@si6networks.com> From: Jen Linkova Date: Tue, 5 Nov 2013 04:23:02 +0100 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 03:23:27 -0000 -v6ops@ to minimize the noise On Tue, Nov 5, 2013 at 3:49 AM, Fernando Gont wrote= : >>> It could be verified by checking the hop limit from the your machine >>> to the server you are testing and then vary the hop limits of probe >>> packets - so you can see when you stop receiving 'time exceeded=92. >> >> Modifying traceroute itself to slip in some extension headers might be u= seful? Much as you can check DSCP rewrites, for example. > > FWIW, I'm in the process of updating the toolkit to support this sort of > thing.. Should have something along these lines shortly. It would be interesting to do such measurements using Atlas but AFAIR it does not have an option to send packets with extension headers.. Just curious - have you contacted RIPE Atlas guys? I could ask them if you think it makes sense. --=20 SY, Jen Linkova aka Furry From swmike@swm.pp.se Mon Nov 4 19:30: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 90C7711E8232 for ; Mon, 4 Nov 2013 19:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+n00A5OJqrr for ; Mon, 4 Nov 2013 19:30:39 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5A25D21E811A for ; Mon, 4 Nov 2013 19:30:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 93E27A1; Tue, 5 Nov 2013 04:30:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DA039A; Tue, 5 Nov 2013 04:30:12 +0100 (CET) Date: Tue, 5 Nov 2013 04:30:12 +0100 (CET) From: Mikael Abrahamsson To: fred@cisco.com In-Reply-To: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 03:30:44 -0000 On Mon, 21 Oct 2013, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment. My comment just now at the mic: I would like to see if any implementation actually deprecates the /64 onlink prefix when A goes from 1 to 0, or ignores the on-link prefix when A=0. Ie the on-link prefix should be used by installing a /64 route towards the interface, then the A-flag determines if the host is allowed to create addresses within this /64 itself, or not. But when one reads RFC4862 and (from my interpration) is just in the context of creating addresses, not what to do with the on-link prefix. 5.5.3. Router Advertisement Processing For each Prefix-Information option in the Router Advertisement: a) If the Autonomous flag is not set, silently ignore the Prefix Information option. This doesn't say anything regarding the /64 route towards the interface, it only talks about creating addresses within this /64. I can imagine implementators getting this wrong? -- Mikael Abrahamsson email: swmike@swm.pp.se From tjc@ecs.soton.ac.uk Mon Nov 4 19:39: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 4674921E8102 for ; Mon, 4 Nov 2013 19:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo-anGPaaLUx for ; Mon, 4 Nov 2013 19:39:53 -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 CCCBD21E80E0 for ; Mon, 4 Nov 2013 19:39:52 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA53dl1T004254 for ; Tue, 5 Nov 2013 03:39:47 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA53dl1T004254 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383622787; bh=bu76HeCQjRjxM0WEOtPz/B9gBkw=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=E8+6vW4H1N9s3G75fWMI1EvOlD8rcjDNO4CLPK4HiLXyi65tM9YZuPFGoC2GFMvyr OuAX8+8zv2cYAfNY0TgPWhhF9iQm5u/+vj1uoyWUU9nJ3Ml5fZPqUVVU1HQi9PQUei oxknww+upX629KHVU0+FvP+Pqh6a5DekpZxRakA4= 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 pA43dl09596353831P ret-id none; Tue, 05 Nov 2013 03:39:47 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:6865:dd3f:9c57:76dd] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA53cQat012974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Nov 2013 03:38:28 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Tue, 5 Nov 2013 03:38:26 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <001F10BA-F1D4-4AFA-BC0B-E574739782FA@ecs.soton.ac.uk> <9DC9AFAD-CB63-46BC-B8E1-229F5EA64E6E@ecs.soton.ac.uk> <52785CA4.1060600@si6networks.com> <1AD8D4F7-0756-43C0-A4CF-94DA406C20A7@ecs.soton.ac.uk> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA43dl095963538300; tid=pA43dl09596353831P; 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: rA53dl1T004254 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 03:39:54 -0000 On 5 Nov 2013, at 03:23, Jen Linkova wrote: > -v6ops@ to minimize the noise >=20 > On Tue, Nov 5, 2013 at 3:49 AM, Fernando Gont = wrote: >>>> It could be verified by checking the hop limit from the your = machine >>>> to the server you are testing and then vary the hop limits of probe >>>> packets - so you can see when you stop receiving 'time exceeded=92. >>>=20 >>> Modifying traceroute itself to slip in some extension headers might = be useful? Much as you can check DSCP rewrites, for example. >>=20 >> FWIW, I'm in the process of updating the toolkit to support this sort = of >> thing.. Should have something along these lines shortly. >=20 > It would be interesting to do such measurements using Atlas but AFAIR > it does not have an option to send packets with extension headers.. > Just curious - have you contacted RIPE Atlas guys? I could ask them if > you think it makes sense. While I love the idea of the Atlas project, and have a probe myself, I = tried asking them whether I could do just basic HTTP monitoring with my = probe, and that wasn=92t possible, so I=92m not optimistic that a = general probe user could just add such tests.=20 I suspect it would need some significant code updates from the = developers. But measuring probe to probe would certainly be useful, so = it would be nice to see at some point=85 some of the Atlas people are = here, so we might get some idea of a timeline if it is possible=85 :) Tim= From jinmei.tatuya@gmail.com Tue Nov 5 00:02: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 E9C2411E822C for ; Tue, 5 Nov 2013 00:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSd69hyVWidv for ; Tue, 5 Nov 2013 00:02:17 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 377C711E8238 for ; Tue, 5 Nov 2013 00:02:16 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id ez12so1666586wid.15 for ; Tue, 05 Nov 2013 00:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yIPjYBT5wsjS2lXRGSaY1X0ssiRqL2ZYtZfqVwJsGpw=; b=KBst16YOqrDCn5pQ8QOhyDmOlDnEytGACUloI92Xv4mdXoUM0daGWPgKMKx4YP8GxY kXbyML6CfP1rZJkCDYlcUz4zzxqfI5+XVVvifBNSXfzc10L+14Vg/hTQzRQyOgCE6TTh v5apc1SIT9+O2HFKbNhJTr85fSw44SuBVk7VzKwUkVmpptprFIe7Lxs62MUnrsIGmu3e 98KRXDCQu47kTWG0Iyoirge4SXr40pdfoun1Qq9yQz79usq5iQFeBmKVSfPlKO5e7DlJ LuFvtUnfFhId4jgT3VKJIDzNccx1JqlqPPtGEBm9M6CxiziFnywN+s082QVKVywWPsDA 6xgQ== MIME-Version: 1.0 X-Received: by 10.194.77.167 with SMTP id t7mr16431316wjw.27.1383638530652; Tue, 05 Nov 2013 00:02:10 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Tue, 5 Nov 2013 00:02:10 -0800 (PST) In-Reply-To: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> Date: Tue, 5 Nov 2013 00:02:10 -0800 X-Google-Sender-Auth: cUWL5py2LO4tu3h2aXt0gM4iuns Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 08:02:18 -0000 At Tue, 5 Nov 2013 04:30:12 +0100 (CET), Mikael Abrahamsson wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment. > > My comment just now at the mic: > > I would like to see if any implementation actually deprecates the /64 > onlink prefix when A goes from 1 to 0, or ignores the on-link prefix when > A=0. What do you mean by "deprecate the /64 onlink prefix"? Are you referring to this part of draft-liu-bonica-v6ops-dhcpv6-slaac-problem? [...] But when SLAAC-configured, and A changed from 1 to 0, the behaviors varied, some deprecated SLAAC while some ignored the RA messages. On re-reading it now, the draft text (specifically "deprecated SLAAC") is not very clear either, but at least it's clear to me that this is about address configuration, not about on/off link. -- JINMEI, Tatuya From otroan@employees.org Tue Nov 5 02:12: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 26C5511E8196 for ; Tue, 5 Nov 2013 02:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuKFkICPI39q for ; Tue, 5 Nov 2013 02:12:17 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CA7DB11E8267 for ; Tue, 5 Nov 2013 02:12:13 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEnDeFKQ/khM/2dsb2JhbABaw0yBJxZ0giYBBWUUEAsOOFcGiBS+I44PgUoHgyCBDwOqE4MnOw X-IronPort-AV: E=Sophos;i="4.93,638,1378857600"; d="asc'?scan'208";a="161402588" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2013 09:59:56 +0000 Received: from dhcp-lys02-vla252-10-147-116-88.cisco.com (dhcp-lys02-vla252-10-147-116-88.cisco.com [10.147.116.88]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA59xpSu004298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 09:59:52 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_F4D4C562-3F9E-4554-B396-2341BD09F8D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <52785F34.6020606@si6networks.com> Date: Tue, 5 Nov 2013 10:59:51 +0100 Message-Id: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1816) Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 10:12:23 -0000 --Apple-Mail=_F4D4C562-3F9E-4554-B396-2341BD09F8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Fernando, >>> In any case, the interesting (and unfortunate) data if the >>> chances of success when you use extension headers or >>> fragmentation are in the scale of "unlikely". :-( >>=20 >> I'm not sure you can draw that conclusion without knowing where >> the fragments are dropped. >>=20 >> e.g. you are not saying that fragmented packets will be dropped=20 >> anywhere on the link between your home and mine, are you? >=20 > I'm certainly not. All tests were against web servers. >=20 >=20 >> I'm for example not concerned about a web server or load balancer=20 >> that sets TCP MSS to 1220 and then drop fragments. >=20 > Certainly, there's much more testing to be done (this is even stated = in > the slideware :-) ). That said, you might still be concerned about the > case you meantion -- at least in theory, that case might arise in a > NAT64 (?) case. >=20 > Also, one of the main points of this slideware is that its not just > fragments that are dropped, but extension headers in general. >=20 > In any case, my goal of sharing the results is to trigger discussion > and encourage further testing, rather than coming up with scary or > bold statements. splendid. it would be very interesting to know where filtering is done. my assumption is that it isn't done in what I call the Internet = infrastructure, but close to the hosts (edge), or in the hosts themselves. pretty tricky to measure that from afar though. cheers, Ole --Apple-Mail=_F4D4C562-3F9E-4554-B396-2341BD09F8D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeMGXAAoJEFuJXizso86gjyIIAKav4LnqOoaPu9XEMIUbEpjR D0UI0odP3NwF7LYqavBbOQY+vLFa83hQj1bxW1yP32aDa/CRFAQvy01YZe+XwS/2 uk4E/YRp1UdMHHGdWvTwL3khy2bwG6L3h1CPung1Rz6NAshTo50lhgtZzyZFYt2W HVGanZL9l5kxjauFqto5pq4e3CPoNT9HeHv6NBG7j3PheN3p09ByBu+0QUxIoy7P c6+kUN27hErv/zlVWDW9yNS49f+f7Hpl7fvMlkuMOzI/wRUTgc+qZhKxXxiXbhRy otRE9MtmSI6WcXvQwZNzi94cUhGwghFgOIpszg2cYkHm/caKOaJveE37gPUuAKA= =aVHe -----END PGP SIGNATURE----- --Apple-Mail=_F4D4C562-3F9E-4554-B396-2341BD09F8D0-- From gert@space.net Tue Nov 5 02:50: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 66E9321E820C for ; Tue, 5 Nov 2013 02:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeGNGjtFEUlK for ; Tue, 5 Nov 2013 02:50:30 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id C9D8321E8161 for ; Tue, 5 Nov 2013 02:50:28 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4663A608C7 for ; Tue, 5 Nov 2013 11:50:21 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 294BD60310 for ; Tue, 5 Nov 2013 11:50:21 +0100 (CET) Received: (qmail 86629 invoked by uid 1007); 5 Nov 2013 11:50:21 +0100 Date: Tue, 5 Nov 2013 11:50:21 +0100 From: Gert Doering To: Simon Perreault Message-ID: <20131105105021.GI81676@Space.Net> References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527839C6.3000805@viagenie.ca> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 10:50:30 -0000 Hi, On Mon, Nov 04, 2013 at 04:20:22PM -0800, Simon Perreault wrote: > pf reassembles IPv6 fragments by default. Not on FreeBSD, as far as I'm aware. They have not yet imported these bits from OpenBSD :-( (and the state of pf(4) in FreeBSD 9.x isn't so good anyway, with rdr being broken for IPv6, too...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From BECHA@ripe.net Tue Nov 5 02:53: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 EBAB311E8196 for ; Tue, 5 Nov 2013 02:53: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q3imxhIGPP7 for ; Tue, 5 Nov 2013 02:53:51 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 8791711E8128 for ; Tue, 5 Nov 2013 02:53:43 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VdeGT-0002Ja-GZ; Tue, 05 Nov 2013 11:53:41 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=air-becha.fritz.box) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VdeGT-0004X9-Ao; Tue, 05 Nov 2013 11:53:41 +0100 Message-ID: <5278CE37.80305@ripe.net> Date: Tue, 05 Nov 2013 11:53:43 +0100 From: Vesna Manojlovic User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tim Chown References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <001F10BA-F1D4-4AFA-BC0B-E574739782FA@ecs.soton.ac.uk> <9DC9AFAD-CB63-46BC-B8E1-229F5EA64E6E@ecs.soton.ac.uk> <52785CA4.1060600@si6networks.com> <1AD8D4F7-0756-43C0-A4CF-94DA406C20A7@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20131105 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 63c376d8fe7b052a5a65f88a9765b61a57fdfbfbcf813adf8c7b071f9de69d97 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] (RIPE Atlas) Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 10:53:56 -0000 Hi Tim, all, On 05-nov.-13 04:38, Tim Chown wrote: > While I love the idea of the Atlas project, and have a probe myself, > I tried asking them whether I could do just basic HTTP monitoring > with my probe, > and that wasn’t possible, so I’m not optimistic that a general probe > user could just add such tests. Currently, indeed, we do not support HTTP measurements for regular users -- while it is technically possible, and some researchers have done measurements project with very controlled parameters -- the policy of "allowed" targets is still under discussion. > I suspect it would need some significant code updates from the > developers. But measuring probe to probe would certainly be useful, While not all the probes might be good targets, we have introduced RIPE Atlas anchors specifically with this in mind -- willing targets, that also can take more measurements with regards to bandwidth. Please see the list of features here: https://atlas.ripe.net/about/anchors/ & here: https://atlas.ripe.net/doc/anchors > so it would be nice to see at some point… some of the Atlas people > are here, so we might get some idea of a timeline if it is possible… > :) We have few of the requests related to IPv6 & HTTP already on the roadmap, and we are waiting for more community input to help us prioritize them. http://roadmap.ripe.net/ripe-atlas/ From this discussion, I have noted +1 for HTTP measurements +1 for IPv6 extension headers "probe to probe" measurements Please send your detailed suggestions to "MAT-WG" mailing list -- Measurements, Analysis & Tools: http://www.ripe.net/mailman/listinfo/mat-wg/ Thank you, Vesna From swmike@swm.pp.se Tue Nov 5 03:53: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 EAFDD11E8272 for ; Tue, 5 Nov 2013 03:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMR3YmONhHmZ for ; Tue, 5 Nov 2013 03:53:37 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id AF2C211E80DE for ; Tue, 5 Nov 2013 03:53:37 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E66949C; Tue, 5 Nov 2013 12:53:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E1D189A; Tue, 5 Nov 2013 12:53:35 +0100 (CET) Date: Tue, 5 Nov 2013 12:53:35 +0100 (CET) From: Mikael Abrahamsson To: =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= In-Reply-To: Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1230133297-1383652415=:26054" Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 11:53:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1230133297-1383652415=:26054 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed On Tue, 5 Nov 2013, $B?@L@C#:H(J wrote: > At Tue, 5 Nov 2013 04:30:12 +0100 (CET), > Mikael Abrahamsson wrote: > >>> A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment. >> >> My comment just now at the mic: >> >> I would like to see if any implementation actually deprecates the /64 >> onlink prefix when A goes from 1 to 0, or ignores the on-link prefix when >> A=0. > > What do you mean by "deprecate the /64 onlink prefix"? > > Are you referring to this part of > draft-liu-bonica-v6ops-dhcpv6-slaac-problem? > > [...] But when > SLAAC-configured, and A changed from 1 to 0, the behaviors varied, > some deprecated SLAAC while some ignored the RA messages. > > On re-reading it now, the draft text (specifically "deprecated SLAAC") > is not very clear either, but at least it's clear to me that this is > about address configuration, not about on/off link. Yes, I know this is about address configuration. I am still curious if all OSes keep the /64 interface route when A changes to 0 (or is 0 to begin with). If you feel this is out of scope that's fine, then my curiosity will stay unanswered. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1230133297-1383652415=:26054-- From otroan@employees.org Tue Nov 5 04:22: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 3348B11E8277 for ; Tue, 5 Nov 2013 04:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOGBwriQjW-W for ; Tue, 5 Nov 2013 04:22:12 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id F342811E828D for ; Tue, 5 Nov 2013 04:22:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAMnieFKQ/khN/2dsb2JhbABagwc4wA2BKRZ0giYBBTo/EAsOOFcGiBQNviaPJjMHgyCBDwOZOZBagyc7 X-IronPort-AV: E=Sophos;i="4.93,639,1378857600"; d="scan'208";a="18796803" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 05 Nov 2013 12:22:09 +0000 Received: from dhcp-lys02-vla252-10-147-116-88.cisco.com (dhcp-lys02-vla252-10-147-116-88.cisco.com [10.147.116.88]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA5CL9s3001427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 12:22:06 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: Date: Tue, 5 Nov 2013 13:22:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57C59B32-C65F-4B52-AC7E-AFD33194D486@employees.org> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1816) Cc: "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 12:22:17 -0000 Mikael, >>>> A new draft has been posted, at = http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. = Please take a look at it and comment. >>>=20 >>> My comment just now at the mic: >>>=20 >>> I would like to see if any implementation actually deprecates the = /64 >>> onlink prefix when A goes from 1 to 0, or ignores the on-link prefix = when >>> A=3D0. >>=20 >> What do you mean by "deprecate the /64 onlink prefix"? >>=20 >> Are you referring to this part of >> draft-liu-bonica-v6ops-dhcpv6-slaac-problem? >>=20 >> [...] But when >> SLAAC-configured, and A changed from 1 to 0, the behaviors varied, >> some deprecated SLAAC while some ignored the RA messages. >>=20 >> On re-reading it now, the draft text (specifically "deprecated = SLAAC") >> is not very clear either, but at least it's clear to me that this is >> about address configuration, not about on/off link. >=20 > Yes, I know this is about address configuration. I am still curious if = all OSes keep the /64 interface route when A changes to 0 (or is 0 to = begin with). If you feel this is out of scope that's fine, then my = curiosity will stay unanswered. in the nit-picking department, wouldn't that really be the L flag? cheers, Ole From nick@inex.ie Tue Nov 5 04:37: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 DEE6211E828D for ; Tue, 5 Nov 2013 04:37:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdtz0ir53KRI for ; Tue, 5 Nov 2013 04:36:56 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C473D11E8277 for ; Tue, 5 Nov 2013 04:36:50 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rA5CaAX6092929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 12:36:10 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <5278E639.3040606@inex.ie> Date: Tue, 05 Nov 2013 12:36:09 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan , Fernando Gont References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.6 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" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 12:37:10 -0000 On 05/11/2013 09:59, Ole Troan wrote: > it would be very interesting to know where filtering is done. > my assumption is that it isn't done in what I call the Internet infrastructure, > but close to the hosts (edge), or in the hosts themselves. > > pretty tricky to measure that from afar though. as Mike Abrahamsson said, if you have cisco sup720 (or anything with a PFC3) in the path, then you have serious problems with frags. As an operator you need to make a decision between dropping all frags in hardware (chassis-wide), passing all frags in hardware (chassis-wide, noting that this removes control plane protection for v6 frags), or slow-pathing the frags via the RP (thereby opening up the RP to being trashed). From an operational point of view there is really only one option. You could say that this is an operator problem and they get what they deserve for running equipment of this era, but realistically these devices will be running on the internet until the heat death of the universe. Nick From otroan@employees.org Tue Nov 5 04: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 8000611E82A8 for ; Tue, 5 Nov 2013 04:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV9Rv8Jl4pBP for ; Tue, 5 Nov 2013 04:47:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CA42F11E82A7 for ; Tue, 5 Nov 2013 04:47:13 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAOzneFKQ/khM/2dsb2JhbABZgwfARYEpFnSCJQEBBAF5EAtGVwaIDga+Lo9ZB4MggQ8DkC6ZZYMnOw X-IronPort-AV: E=Sophos;i="4.93,639,1378857600"; d="asc'?scan'208";a="161411609" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2013 12:47:12 +0000 Received: from dhcp-lys02-vla252-10-147-116-88.cisco.com (dhcp-lys02-vla252-10-147-116-88.cisco.com [10.147.116.88]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5Cl8pP000399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 12:47:09 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_61B923E4-B73D-49B1-B76A-D78980DB6F31"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <5278E639.3040606@inex.ie> Date: Tue, 5 Nov 2013 13:47:08 +0100 Message-Id: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1816) Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 12:47:26 -0000 --Apple-Mail=_61B923E4-B73D-49B1-B76A-D78980DB6F31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nick, >> it would be very interesting to know where filtering is done. >> my assumption is that it isn't done in what I call the Internet = infrastructure, >> but close to the hosts (edge), or in the hosts themselves. >>=20 >> pretty tricky to measure that from afar though. >=20 > as Mike Abrahamsson said, if you have cisco sup720 (or anything with a > PFC3) in the path, then you have serious problems with frags. As an > operator you need to make a decision between dropping all frags in = hardware > (chassis-wide), passing all frags in hardware (chassis-wide, noting = that > this removes control plane protection for v6 frags), or slow-pathing = the > frags via the RP (thereby opening up the RP to being trashed). =46rom = an > operational point of view there is really only one option. >=20 > You could say that this is an operator problem and they get what they > deserve for running equipment of this era, but realistically these = devices > will be running on the internet until the heat death of the universe. yes, I should have included something about "barring software bugs". if you use one of these in the Internet core I cannot see any other = choice than to allow forwarding of fragments.=20 cheers, Ole --Apple-Mail=_61B923E4-B73D-49B1-B76A-D78980DB6F31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeOjMAAoJEFuJXizso86gOsoIAL1Xk9CTwTvlDM9mVLjV4roc +HOUpfSuBpgel6AYMl/QPvJsu21GMAYXrGQsY8tzCuYa66j6/L6tT9Ut/4FwRpf/ X1oUdIEvBMioA9VuISzmAoVB2jdEPTDLysYCcdY+6zzDdlRq5DbNl06IxQBp755r Vf5bIopjXHDwnlAlSUHa2tGANLJGx/szITizYoqNHTIxyLptbC2EkyjI0hte06Gj JRJb7xvMcVnq9FlmvYw6jICwdj1dKxbPtfy8h/SdBcu+XT3A/1QpsRvG87bArVTM 0jivwRMhns+LX1v969fASy4tC9AeNkjQj1hEvxSDF0ywhUxKJ8bbinkYwlOeAZw= =pucR -----END PGP SIGNATURE----- --Apple-Mail=_61B923E4-B73D-49B1-B76A-D78980DB6F31-- From nick@inex.ie Tue Nov 5 04:50: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 5023E21E8135 for ; Tue, 5 Nov 2013 04:50: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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4x139F+2+U6 for ; Tue, 5 Nov 2013 04:50:42 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB7F11E82A5 for ; Tue, 5 Nov 2013 04:50:30 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rA5CoEot093046 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 12:50:14 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <5278E986.9050409@inex.ie> Date: Tue, 05 Nov 2013 12:50:14 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> In-Reply-To: X-Enigmail-Version: 1.6 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: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 12:50:43 -0000 On 05/11/2013 12:47, Ole Troan wrote: > if you use one of these in the Internet core I cannot see any other choice than to > allow forwarding of fragments. no, drop! Because otherwise your infrastructure is wide open to control plane attacks with ipv6 frags, with no means of defence! If that happens, then your entire network falls over. Nick From otroan@employees.org Tue Nov 5 04:54: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 18BC611E82A5 for ; Tue, 5 Nov 2013 04:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.527 X-Spam-Level: X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-Ze6rUsY9nF for ; Tue, 5 Nov 2013 04:54:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9F21F9F2B for ; Tue, 5 Nov 2013 04:54:34 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADrqeFKQ/khM/2dsb2JhbABZgwfARYEpFnSCJQEBBAF5EAtGVwaIDga+MI9ZB4MggQ8DkC6ZZYMnOw X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="asc'?scan'208";a="161412032" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2013 12:54:12 +0000 Received: from dhcp-lys02-vla252-10-147-116-88.cisco.com (dhcp-lys02-vla252-10-147-116-88.cisco.com [10.147.116.88]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5Cs8Ih001938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 12:54:09 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_3476B8CE-527B-4FD0-B567-034818E251F0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <5278E986.9050409@inex.ie> Date: Tue, 5 Nov 2013 13:54:08 +0100 Message-Id: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1816) Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 12:54:41 -0000 --Apple-Mail=_3476B8CE-527B-4FD0-B567-034818E251F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nick, >> if you use one of these in the Internet core I cannot see any other = choice than to >> allow forwarding of fragments.=20 >=20 > no, drop! Because otherwise your infrastructure is wide open to = control > plane attacks with ipv6 frags, with no means of defence! If that = happens, > then your entire network falls over. why don't you filter out packets on the edge destined to your router's = addresses? instead of what's effectively breaking IPv6 service across the network. cheers, Ole --Apple-Mail=_3476B8CE-527B-4FD0-B567-034818E251F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeOpwAAoJEFuJXizso86gmZ0IAI5dzli/CXZ8ypGrRRmKePt+ 4367ZlS7VHv5EjuLZhm1xyi4+OuZC4kQmigH0eJp3xXuBb+Cwy8tQvhbSEAvN2pN 8MoHDU//u+R06C/Yhv9S5hf7X24hMHXn8/pOd3aqlOt4X1kCkcBuJprxTsVp0zIC Aa0v1a8Xk8qT/QGzZTB8a2BZaonOLDV+Ag192hL4uUkSLommWcODgPTiXShCJGB+ WyLn1OaZnompY4U6QShKxWzXU66YwQmAkYmzdDShTlahdONe1Nj5qO4bW5jVKY7g kxtARPtCF1HvQqhQj1yG7WWP8Ige7F3nrZC/teb6iFTqCp3nVxONK0ymVqxqBqg= =BsnA -----END PGP SIGNATURE----- --Apple-Mail=_3476B8CE-527B-4FD0-B567-034818E251F0-- From nick@inex.ie Tue Nov 5 05:08: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 92A0211E8168 for ; Tue, 5 Nov 2013 05:08:19 -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_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxpgPm7saFw6 for ; Tue, 5 Nov 2013 05:08:19 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E248E11E8193 for ; Tue, 5 Nov 2013 05:08:05 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rA5D7t6w093154 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 13:07:56 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie Message-ID: <5278EDAB.5030601@inex.ie> Date: Tue, 05 Nov 2013 13:07:55 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> In-Reply-To: X-Enigmail-Version: 1.6 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: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 13:08:19 -0000 On 05/11/2013 12:54, Ole Troan wrote: > why don't you filter out packets on the edge destined to your router's addresses? > instead of what's effectively breaking IPv6 service across the network. you can use infrastructure acls if they are handled carefully and don't depend on implicit "deny any any" (which has special handling for the "platform ipv6 acl fragment hardware"). But in order to implement this you need to protect every single link network connected to your PFC3s. If your addressing plan is designed with this in mind, it's feasible. If you have a very large network or if you've not handled your link address assignments very carefully, it's often not practical because it means dynamically maintaining huge access lists on every single device on the network. Nick From swmike@swm.pp.se Tue Nov 5 06:21: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 2610011E80E6 for ; Tue, 5 Nov 2013 06:21:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruIg+kWOG+IZ for ; Tue, 5 Nov 2013 06:21:52 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F411E8141 for ; Tue, 5 Nov 2013 06:21:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7E465A1; Tue, 5 Nov 2013 15:21:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 74D229C; Tue, 5 Nov 2013 15:21:48 +0100 (CET) Date: Tue, 5 Nov 2013 15:21:48 +0100 (CET) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: <15A60E31-DAD1-4E72-8E27-52868FAF9203@cisco.com> Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <15A60E31-DAD1-4E72-8E27-52868FAF9203@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 14:21:53 -0000 On Tue, 5 Nov 2013, Ole Troan wrote: >> Yes, I know this is about address configuration. I am still curious if all OSes keep the /64 interface route when A changes to 0 (or is 0 to begin with). If you feel this is out of scope that's fine, then my curiosity will stay unanswered. > > in the nit-picking department, wouldn't that really be the L flag? Well, my question was for L=1, A=1, A=1 -> A=0, and A=0 cases. In case the implementor got the addressing generation mixed up with the route stuff. Are there test suites for all this stuff that implementors can use? What should come out of this eventually is a document where all states/transitions should be tested and the document should say exactly what is the expected behaviour. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Tue Nov 5 07:21: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 84B1511E818D for ; Tue, 5 Nov 2013 07:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEcXGcIp5ujY for ; Tue, 5 Nov 2013 07:21:15 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 486A011E81D5 for ; Tue, 5 Nov 2013 07:21:13 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id tp5so14780139ieb.2 for ; Tue, 05 Nov 2013 07:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wSTdfIVrVg2e2htQ56qwKuu9q76LTWHOvifueKXaDMQ=; b=OsXEj1hAyDLKPxI/2tEyhVWuAubGDezceXXkPMCrawspbfU5YsLC3o/l9jAaKsVmmq JArcSryjVqqYg7vXd/hzg5dBZf/foEjEU0EowexCqb/sTXJ/uatSNc7Lgz+VLhGrtHrP d2Me43QKxBIuvyv4hFEMALfYf4fHVFARsp9EOtQrEui5qrepI5fT3bad3x164y++L5td FYbSwCK01W827FLXibPjK+nCaAHhuziMGDnvyeSuWt1oMSA8p+KA1lm1RtcgbM9WeaCJ O3C7nKNIxtEUHZjg8mys5Kw+KdxTOdjQoHnOH8/LTdsfiCm2qQ+WgUxsh+tSfNPl81Z8 afAA== X-Received: by 10.42.60.18 with SMTP id o18mr241312ich.83.1383664872760; Tue, 05 Nov 2013 07:21:12 -0800 (PST) Received: from [31.133.148.174] (dhcp-94ae.meeting.ietf.org. [31.133.148.174]) by mx.google.com with ESMTPSA id cl4sm22089871igc.1.2013.11.05.07.21.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 07:21:12 -0800 (PST) Message-ID: <52790CE7.6010506@gmail.com> Date: Wed, 06 Nov 2013 04:21:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> In-Reply-To: <5278EDAB.5030601@inex.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 15:21:15 -0000 On 06/11/2013 02:07, Nick Hilliard wrote: > On 05/11/2013 12:54, Ole Troan wrote: >> why don't you filter out packets on the edge destined to your router's addresses? >> instead of what's effectively breaking IPv6 service across the network. > > you can use infrastructure acls if they are handled carefully and don't > depend on implicit "deny any any" (which has special handling for the > "platform ipv6 acl fragment hardware"). But in order to implement this you > need to protect every single link network connected to your PFC3s. If your > addressing plan is designed with this in mind, it's feasible. If you have > a very large network or if you've not handled your link address assignments > very carefully, it's often not practical because it means dynamically > maintaining huge access lists on every single device on the network. I think Homer Simpson has a word for this situation. We *really* aren't going to deprecate fragmentation because of one model of broken kit, are we? Brian From jared@puck.nether.net Tue Nov 5 07:30: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 F264311E80E6 for ; Tue, 5 Nov 2013 07:30:56 -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_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaLXnA3YNEE0 for ; Tue, 5 Nov 2013 07:30:56 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A3A0311E80EC for ; Tue, 5 Nov 2013 07:30:49 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id rA5FUhUn028251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 10:30:44 -0500 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <52790CE7.6010506@gmail.com> Date: Tue, 5 Nov 2013 10:31:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.1 (puck.nether.net [204.42.254.5]); Tue, 05 Nov 2013 10:30:44 -0500 (EST) Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 15:30:57 -0000 On Nov 5, 2013, at 10:21 AM, Brian E Carpenter = wrote: > On 06/11/2013 02:07, Nick Hilliard wrote: >> On 05/11/2013 12:54, Ole Troan wrote: >>> why don't you filter out packets on the edge destined to your = router's addresses? >>> instead of what's effectively breaking IPv6 service across the = network. >>=20 >> you can use infrastructure acls if they are handled carefully and = don't >> depend on implicit "deny any any" (which has special handling for the >> "platform ipv6 acl fragment hardware"). But in order to implement = this you >> need to protect every single link network connected to your PFC3s. = If your >> addressing plan is designed with this in mind, it's feasible. If you = have >> a very large network or if you've not handled your link address = assignments >> very carefully, it's often not practical because it means dynamically >> maintaining huge access lists on every single device on the network. >=20 > I think Homer Simpson has a word for this situation. >=20 > We *really* aren't going to deprecate fragmentation because of one > model of broken kit, are we? I think the challenge here is that Cisco doesn't care to fix the problem inherent in their software/hardware integration issue here. There is no structural correction of the defects in the software and nobody there = takes ownership to correct it. I've sadly seen this play out time and time again without anyone fixing = basic infrastructure items that need correction. They're unable to as it = impacts too many sub-platforms/internal consumers of the code that don't see the = value as it's not adding revenue. Many of these headers (eg: hop-by-hop) are comparable to IPv4 features = that are ignored or dropped by firewalls and routers (Eg: source-route, ecn, = etc). Without an explicit standard that says things MUST be supported that we = can cite in RFP/RFI and broad coalition of purchasers it's difficult or = impossible to change things. Places like Cisco are too big to steer and correct = the bad behavior. I would love to be proven wrong, but years of experience = tell me it's not going to get better. - Jared= From joelja@bogus.com Tue Nov 5 07:31: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 0122D11E80E6 for ; Tue, 5 Nov 2013 07:31:26 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zobs5YrxxTL5 for ; Tue, 5 Nov 2013 07:31:25 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B9CDD11E81A3 for ; Tue, 5 Nov 2013 07:31:16 -0800 (PST) Received: from dhcp-bc20.meeting.ietf.org (dhcp-bc20.meeting.ietf.org [31.133.188.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id rA5FV4cX007791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Nov 2013 15:31:05 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_FAB9C83A-C300-494D-8D64-519F7098E42F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: joel jaeggli In-Reply-To: <52790CE7.6010506@gmail.com> Date: Tue, 5 Nov 2013 07:31:03 -0800 Message-Id: <49A0D108-95E4-4AB2-8C98-6B87DE706D98@bogus.com> References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 05 Nov 2013 15:31:07 +0000 (UTC) Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 15:31:26 -0000 --Apple-Mail=_FAB9C83A-C300-494D-8D64-519F7098E42F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 5, 2013, at 7:21 AM, Brian E Carpenter = wrote: > On 06/11/2013 02:07, Nick Hilliard wrote: >> On 05/11/2013 12:54, Ole Troan wrote: >>> why don't you filter out packets on the edge destined to your = router's addresses? >>> instead of what's effectively breaking IPv6 service across the = network. >>=20 >> you can use infrastructure acls if they are handled carefully and = don't >> depend on implicit "deny any any" (which has special handling for the >> "platform ipv6 acl fragment hardware"). But in order to implement = this you >> need to protect every single link network connected to your PFC3s. = If your >> addressing plan is designed with this in mind, it's feasible. If you = have >> a very large network or if you've not handled your link address = assignments >> very carefully, it's often not practical because it means dynamically >> maintaining huge access lists on every single device on the network. >=20 > I think Homer Simpson has a word for this situation. >=20 > We *really* aren't going to deprecate fragmentation because of one > model of broken kit, are we? Do you think there=92s one model of broken kit? > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_FAB9C83A-C300-494D-8D64-519F7098E42F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJ5DzcACgkQ8AA1q7Z/VrI8BwCfWScQQjRnDiFWmvm/FzMNKT5k yFIAn2Uq1NQAvdf/eVs3ZDsKaE5+XZuM =sp47 -----END PGP SIGNATURE----- --Apple-Mail=_FAB9C83A-C300-494D-8D64-519F7098E42F-- From brian.e.carpenter@gmail.com Tue Nov 5 07:35: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 A9A5721F9E36 for ; Tue, 5 Nov 2013 07:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzEsxY8jKDws for ; Tue, 5 Nov 2013 07:35:00 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3D521F9DA8 for ; Tue, 5 Nov 2013 07:34:59 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so15067166ieb.5 for ; Tue, 05 Nov 2013 07:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JpMBguGA6didX3hqYKflIBwgf+eORwmZ7aWDllr7X+0=; b=qU+lFw0vjONzCit7bqwONy7nAA6FwR/J172ftAYeuSKGcTrGufgrLGsIunVoQIz/n0 P4y/67VXA6WsN0AHFfs1+ipegxIFiPyZDbF3iQIX/iCzOz72p15X8yIaJUWekuAu0fsX HGdNlpOUg5ll3YAu81kc4EUP2gCCAO6hTRE03LQbIg5Ac5PSPATiSBZyxjDCYJcMXOvV LImT8ItZGFnmHCsg4+iPoOFB02orBeWWyMvKOnU2Cd0UFV9F/FqieAdMGr0kaFO5DUnI UY2SPVoc5TLfA5WQpbZE9LJo1h37gyWZ5xJKZPtJNzGGoZV/pHaDK8vZqMrX8d6y+Rj4 J5PA== X-Received: by 10.50.16.68 with SMTP id e4mr16261231igd.12.1383665698886; Tue, 05 Nov 2013 07:34:58 -0800 (PST) Received: from [31.133.148.174] (dhcp-94ae.meeting.ietf.org. [31.133.148.174]) by mx.google.com with ESMTPSA id v2sm2600406igz.3.2013.11.05.07.34.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 07:34:58 -0800 (PST) Message-ID: <52791025.6070601@gmail.com> Date: Wed, 06 Nov 2013 04:35:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <15A60E31-DAD1-4E72-8E27-52868FAF9203@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ole Troan , "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 15:35:00 -0000 On 06/11/2013 03:21, Mikael Abrahamsson wrote: > On Tue, 5 Nov 2013, Ole Troan wrote: > >>> Yes, I know this is about address configuration. I am still curious >>> if all OSes keep the /64 interface route when A changes to 0 (or is 0 >>> to begin with). If you feel this is out of scope that's fine, then my >>> curiosity will stay unanswered. >> >> in the nit-picking department, wouldn't that really be the L flag? > > Well, my question was for L=1, A=1, A=1 -> A=0, and A=0 cases. In case > the implementor got the addressing generation mixed up with the route > stuff. > > Are there test suites for all this stuff that implementors can use? What > should come out of this eventually is a document where all > states/transitions should be tested and the document should say exactly > what is the expected behaviour. >From yesterday's discussion, the outcomes seem a little more complicated than that. 1. I think the problem statement as it stands (with the English cleaned up) is a very useful document with two audiences: a) the IETF, including 6man, because it points to ambiguity in our specs; b) the operator community, because it warns of some very specific operational (mis)behaviours with currently deployed code. Because of b) I think it needs to become an RFC quite soon. 2. Then (probably as a separate document) we need an analysis of which problems are a result of a) implementation errors, which the IETF can document but not fix; b) differing interpretations of MAYs and SHOULDs (Fred's point), where the IETF could consider BCP guidance to implementors; c) errors or ambiguities in the standards, which 6man should fix. Brian From nick@inex.ie Tue Nov 5 07:38: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 9350121E8094 for ; Tue, 5 Nov 2013 07:38:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7OFExLO4cQ7 for ; Tue, 5 Nov 2013 07:38:03 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0C421F9DA0 for ; Tue, 5 Nov 2013 07:38:02 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rA5Fb3UA094288 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 15:37:03 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <5279109F.80306@inex.ie> Date: Tue, 05 Nov 2013 15:37:03 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Brian E Carpenter References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> In-Reply-To: <52790CE7.6010506@gmail.com> X-Enigmail-Version: 1.6 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=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 15:38:10 -0000 On 05/11/2013 15:21, Brian E Carpenter wrote: > I think Homer Simpson has a word for this situation. "grim reality"? > We *really* aren't going to deprecate fragmentation because of one > model of broken kit, are we? flicking the question around, how much will it cost operators to upgrade these boxes, and are they prepared to make this investment in order to fix a problem which for the most part has a minimal impact on their networks because 50% of web sites don't accept fragments anyway. These devices are ubiquitous on the internet. The IETF should ignore them at their peril. As Joel says, they're not the only box with problems, but they are one of the problem contributors in the core. Nick From brian.e.carpenter@gmail.com Tue Nov 5 07:45: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 4208D11E8105 for ; Tue, 5 Nov 2013 07:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMlwO0IJ3qt2 for ; Tue, 5 Nov 2013 07:45:30 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1973F11E81C9 for ; Tue, 5 Nov 2013 07:45:30 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so14835878iec.20 for ; Tue, 05 Nov 2013 07:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=syzYdPtYULy7YxnjaOseS1yoHhfWEKF7pLDlNa1Kpv4=; b=vZHgsZSphot11WMS6GI/0OZX9bwbWNr4p9p1WaNeJTP8BiXkhV0Ns9YNKVsVW14/UU atAlA46pySa7qABU7i8aen5/Hj/TuUmYJwP0TXVvGwn0ehaTB0ZcQvp/BoWvVNegpQPT 9mYvB4qcBqrdjmgFolJ4IIS5ouBTajDTKcKWXLMkx7CNclkp/sKW9LmcCE9d7Mp0wbjj S3PhDzLcPwdXiU6aLQ4rB9jXuOde7sy8WFyf1n27bxzEz/tp4wYv03SUy8uFq9VEG/2q 9O8LkNdtHCXTWESakdRpeCL0Q936rKgWVZc34W5hIoaIAa6yqCLhPDkFFWSHzWCvbW7x XjJg== X-Received: by 10.50.12.71 with SMTP id w7mr12056534igb.32.1383666329449; Tue, 05 Nov 2013 07:45:29 -0800 (PST) Received: from [31.133.148.174] (dhcp-94ae.meeting.ietf.org. [31.133.148.174]) by mx.google.com with ESMTPSA id w4sm8978480igb.5.2013.11.05.07.45.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 07:45:28 -0800 (PST) Message-ID: <52791299.9050301@gmail.com> Date: Wed, 06 Nov 2013 04:45:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jared Mauch References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 15:45:32 -0000 X-List-Received-Date: Tue, 05 Nov 2013 15:45:32 -0000 > On Nov 5, 2013, at 10:21 AM, Brian E Carpenter wrote: >=20 >> On 06/11/2013 02:07, Nick Hilliard wrote: >>> On 05/11/2013 12:54, Ole Troan wrote: >>>> why don't you filter out packets on the edge destined to your router= 's addresses? >>>> instead of what's effectively breaking IPv6 service across the netwo= rk. >>> you can use infrastructure acls if they are handled carefully and don= 't >>> depend on implicit "deny any any" (which has special handling for the= >>> "platform ipv6 acl fragment hardware"). But in order to implement th= is you >>> need to protect every single link network connected to your PFC3s. I= f your >>> addressing plan is designed with this in mind, it's feasible. If you= have >>> a very large network or if you've not handled your link address assig= nments >>> very carefully, it's often not practical because it means dynamically= >>> maintaining huge access lists on every single device on the network. >> I think Homer Simpson has a word for this situation. >> >> We *really* aren't going to deprecate fragmentation because of one >> model of broken kit, are we? On 06/11/2013 04:31, joel jaeggli wrote: > Do you think there=E2=80=99s one model of broken kit? Only one has been reported here. Of course I doubt if it's the only one but it is very widely deployed. On 06/11/2013 04:31, Jared Mauch wrote: > I think the challenge here is that Cisco doesn't care to fix the proble= m > inherent in their software/hardware integration issue here. There is n= o > structural correction of the defects in the software and nobody there t= akes > ownership to correct it. >=20 > I've sadly seen this play out time and time again without anyone fixing= basic > infrastructure items that need correction. They're unable to as it imp= acts > too many sub-platforms/internal consumers of the code that don't see th= e value > as it's not adding revenue. >=20 > Many of these headers (eg: hop-by-hop) are comparable to IPv4 features = that > are ignored or dropped by firewalls and routers (Eg: source-route, ecn,= etc). >=20 > Without an explicit standard that says things MUST be supported that we= can > cite in RFP/RFI and broad coalition of purchasers it's difficult or imp= ossible > to change things. Places like Cisco are too big to steer and correct t= he > bad behavior. I would love to be proven wrong, but years of experience= tell > me it's not going to get better. I don't think there's any doubt whatever that fragmentation is a mandator= y part of the IPv6 standard. For the rest of the extension headers, the requirement is in the RFC Editor queue and the new IANA registry is already in place at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ext= ension-header Brian From sthaug@nethelp.no Tue Nov 5 07:57: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 3C65811E8231 for ; Tue, 5 Nov 2013 07:57:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfAqNm8iEawz for ; Tue, 5 Nov 2013 07:57:34 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 755C921E80CE for ; Tue, 5 Nov 2013 07:57:20 -0800 (PST) Received: (qmail 21699 invoked from network); 5 Nov 2013 15:57:17 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Nov 2013 15:57:17 -0000 Date: Tue, 05 Nov 2013 16:57:17 +0100 (CET) Message-Id: <20131105.165717.74734321.sthaug@nethelp.no> To: nick@inex.ie From: sthaug@nethelp.no In-Reply-To: <5279109F.80306@inex.ie> References: <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> <5279109F.80306@inex.ie> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: fgont@si6networks.com, v6ops@ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 15:57:41 -0000 > > We *really* aren't going to deprecate fragmentation because of one > > model of broken kit, are we? > > flicking the question around, how much will it cost operators to upgrade > these boxes, and are they prepared to make this investment in order to fix > a problem which for the most part has a minimal impact on their networks > because 50% of web sites don't accept fragments anyway. Speaking only for myself and the network I know best: I have some boxes that cannot inspect "sufficiently far" into the IPv6 packet. These boxes will eventually be replaced as part of normal network buildout/renewal. There's no way I'm going to ask management for funding to replace these boxes *just* because they are suboptimal for IPv6. > These devices are ubiquitous on the internet. The IETF should ignore them > at their peril. As Joel says, they're not the only box with problems, but > they are one of the problem contributors in the core. Agreed. Steinar Haug, AS 2116 From Fred.L.Templin@boeing.com Tue Nov 5 08:30: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 0985411E81CD for ; Tue, 5 Nov 2013 08:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EsKndnPHWm3 for ; Tue, 5 Nov 2013 08:30:09 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF1F11E8118 for ; Tue, 5 Nov 2013 08:30:08 -0800 (PST) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id rA5GU7FE016636 for ; Tue, 5 Nov 2013 10:30:07 -0600 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rA5GU5Fe016611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 Nov 2013 10:30:06 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-PHX-511.sw.nos.boeing.com ([169.254.11.86]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 08:30:05 -0800 From: "Templin, Fred L" To: "sthaug@nethelp.no" , "nick@inex.ie" Thread-Topic: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet Thread-Index: AQHO2iguq70DdkmKlkSk33AAKL/ErpoXRxyAgAAEb4CAAAWngP//gsow Date: Tue, 5 Nov 2013 16:30:04 +0000 Message-ID: <2134F8430051B64F815C691A62D98318148A86@XCH-BLV-504.nw.nos.boeing.com> References: <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> <5279109F.80306@inex.ie> <20131105.165717.74734321.sthaug@nethelp.no> In-Reply-To: <20131105.165717.74734321.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "fgont@si6networks.com" , "v6ops@ietf.org" , "fernando@gont.com.ar" Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 16:30:43 -0000 Hi, we can't deprecate IPv6 fragmentation; tunnels need it. Thanks - Fred From simon.perreault@viagenie.ca Tue Nov 5 09:15:06 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 2284421E811C for ; Tue, 5 Nov 2013 09:15:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwYeuxB8L+qa for ; Tue, 5 Nov 2013 09:15:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 42F4421E816A for ; Tue, 5 Nov 2013 09:14:50 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2B91640402 for ; Tue, 5 Nov 2013 12:14:49 -0500 (EST) Message-ID: <52792788.3070907@viagenie.ca> Date: Tue, 05 Nov 2013 09:14:48 -0800 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> <5279109F.80306@inex.ie> In-Reply-To: <5279109F.80306@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 17:15:06 -0000 Le 2013-11-05 07:37, Nick Hilliard a écrit : >> We *really* aren't going to deprecate fragmentation because of one >> model of broken kit, are we? > > flicking the question around, how much will it cost operators to upgrade > these boxes, and are they prepared to make this investment in order to fix > a problem which for the most part has a minimal impact on their networks > because 50% of web sites don't accept fragments anyway. > > These devices are ubiquitous on the internet. The IETF should ignore them > at their peril. As Joel says, they're not the only box with problems, but > they are one of the problem contributors in the core. Won't they just disappear gradually, being replaced by newer boxes in the normal course of events? Looks like a problem that will fix itself in time. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From swmike@swm.pp.se Tue Nov 5 09:27: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 B90AC11E81C7 for ; Tue, 5 Nov 2013 09:27: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxfL6E6RPm99 for ; Tue, 5 Nov 2013 09:27:16 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CE0DC11E817A for ; Tue, 5 Nov 2013 09:27:12 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D9A619C; Tue, 5 Nov 2013 18:27:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D12339A; Tue, 5 Nov 2013 18:27:10 +0100 (CET) Date: Tue, 5 Nov 2013 18:27:10 +0100 (CET) From: Mikael Abrahamsson To: Simon Perreault In-Reply-To: <52792788.3070907@viagenie.ca> Message-ID: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> <5279109F.80306@inex.ie> <52792788.3070907@viagenie.ca> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 17:27:20 -0000 On Tue, 5 Nov 2013, Simon Perreault wrote: > Won't they just disappear gradually, being replaced by newer boxes in > the normal course of events? > > Looks like a problem that will fix itself in time. I agree. I think it's good that there is documentation on current behaviour seen in the wild, but also would be interesting to hear about testing with current generation devices and how they perform. Perhaps time for a rfc6204 style document for certain aspects? :P -- Mikael Abrahamsson email: swmike@swm.pp.se From leo.liubing@huawei.com Tue Nov 5 09:41: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 74DBD21E8135 for ; Tue, 5 Nov 2013 09:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.525 X-Spam-Level: X-Spam-Status: No, score=-5.525 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj-IOp2R4HXz for ; Tue, 5 Nov 2013 09:40:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4E221F9FC3 for ; Tue, 5 Nov 2013 09:40:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO58944; Tue, 05 Nov 2013 17:40:05 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 17:39:26 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 17:40:03 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 01:39:57 +0800 From: "Liubing (Leo)" To: Mikael Abrahamsson , =?gb2312?B?yfHD999f1NU=?= Thread-Topic: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: AQHOzltsXXG/hvZHw0OAdgyFq+29zZoVi9gAgABL/ACAAECpgIAA5VkL Date: Tue, 5 Nov 2013 17:39:55 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F07F3@nkgeml506-mbx.china.huawei.com> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.36] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 17:41:53 -0000 SGksIE1pa2FlbA0KDQo+IFllcywgSSBrbm93IHRoaXMgaXMgYWJvdXQgYWRkcmVzcyBjb25maWd1 cmF0aW9uLiBJIGFtIHN0aWxsIGN1cmlvdXMgaWYgYWxsDQo+IE9TZXMga2VlcCB0aGUgLzY0IGlu dGVyZmFjZSByb3V0ZSB3aGVuIEEgY2hhbmdlcyB0byAwIChvciBpcyAwIHRvIGJlZ2luDQo+IHdp dGgpLiBJZiB5b3UgZmVlbCB0aGlzIGlzIG91dCBvZiBzY29wZSB0aGF0J3MgZmluZSwgdGhlbiBt eSBjdXJpb3NpdHkNCj4gd2lsbCBzdGF5IHVuYW5zd2VyZWQuDQoNCldlIGRpZCBub3QgcGF5IGF0 dGVudGlvbiB0byB0aGUgLzY0IGRlcHJlY2F0ZWQgb3Igbm90IGluIHRoZSByb3V0ZXMuIE1heWJl IHdlJ2xsIGRvIGl0IGluIGZ1cnRoZXIgdGVzdHMuDQoNClJlZ2FyZHMsDQpCaW5n From jhw@conjury.org Tue Nov 5 09:49: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 71E2521E8137 for ; Tue, 5 Nov 2013 09:49:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiQR-Kpxj1xe for ; Tue, 5 Nov 2013 09:48:55 -0800 (PST) Received: from prime.conjury.org (prime.conjury.org [174.136.98.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5478C11E81BD for ; Tue, 5 Nov 2013 09:48:45 -0800 (PST) Received: from dhcp-bc5e.meeting.ietf.org (dhcp-bc5e.meeting.ietf.org [31.133.188.94]) by prime.conjury.org (Postfix) with ESMTPSA id ED7FEB22CF for ; Tue, 5 Nov 2013 09:52:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: james woodyatt In-Reply-To: <29AE8DB910E7704CA043795E00DCBE7803417A05@CL08MBE.rci.rogers.ca> Date: Tue, 5 Nov 2013 09:48:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29AE8DB910E7704CA043795E00DCBE7803417A05@CL08MBE.rci.rogers.ca> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [v6ops] draft-byrne-v6ops-clatip-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: Tue, 05 Nov 2013 17:49:01 -0000 On 2013-11-04, at 19:08 , Dave Michaud = wrote: >=20 > I think however, and this is my interpretation when I read the I-D, = that the current intention is only to generalize a block already = assigned for DS-lite so that it can be re-used for other transition = technologies. The idea here is to provide an option for deploying = 464XLAT.=20 >=20 > Mandating the use of this range may be inappropriate at this point but = that is not what the current version of the draft does anyway. I finally figured out why this draft made me say "huh?" when it was = presented. When I was working on the IPv4 dial-tone features a certain home gateway = implementation, I ran into a very similar problem. I needed some IPv4 = addresses to number the PPP interface when it was in its = "connect-on-demand" state. These addresses would never appear on the = wire, because they were only used for triggering the PPPoE Discovery = protocol in response to "outbound" DNS query packets. The way I dealt with this problem was to use the old 0.0.0.0/8 = "unspecified" prefix from the old days before CIDR. These numbers have = never been either global scope or routable. They're pretty much useless = on the wire. I don't see why you'd need an RFC to use them for 464XLAT = purposes. --james woodyatt From furry13@gmail.com Tue Nov 5 09:53:06 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 C3C8321F9E91 for ; Tue, 5 Nov 2013 09:53:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drLsley2F8E8 for ; Tue, 5 Nov 2013 09:53:05 -0800 (PST) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D9E3621F9D19 for ; Tue, 5 Nov 2013 09:50:53 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id x12so5046343qcv.28 for ; Tue, 05 Nov 2013 09:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=67C5OCEzVMes86iHkWZ3j7Q4aj6jD8ld/q6xvNjq+r4=; b=QSq5bOCEFWVylErmBGzX1YxFLJbPlzL3QvOL5SSTjvtv1e3t9u5u2maNInImYMc+D0 hUg2dZJ2MVtoHG7yPCU7h+CvPU04kPmUzg5oSzTKwmrPztrMq3EtYU+iSK4euwwER8eR oo28zsrTlGpbnJwp8AqSBXaHSUEXTipjBaHldtSskT8qNEOewayDDz3Dlx7+WdtYsLZY 3FdPYjs1BgxWx9E8mLcHGGXgJcurwhM9nJc9tb80Eg54BVVRS4Hw/4w77ydJkA54IhWb w5E+E66aJuTb4PGLjxy4EUlSq4K6tg6B4NmNQhMU564Mx1J68HJwuqakp3Ib4jjfUfCc E+Zg== X-Received: by 10.224.129.74 with SMTP id n10mr30887120qas.92.1383673852637; Tue, 05 Nov 2013 09:50:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Tue, 5 Nov 2013 09:50:32 -0800 (PST) From: Jen Linkova Date: Tue, 5 Nov 2013 18:50:32 +0100 Message-ID: To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 17:53:06 -0000 Section 4.2. says that " So when using ULAs in a network, the administrators should clearly set the scope of the ULAs and configure ACLs on relevant border routers to block them out of the scope. And if internal DNS are enabled, the administrators might also need to use internal-only DNS names for ULAs. " I believe it should that that the administrator MUST configure egress ACLs on borders routers and MUST ensure that their DNS servers do not include ULAs in any responses to external clients. -- SY, Jen Linkova aka Furry From arturo.servin@gmail.com Tue Nov 5 10:17: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 B193611E8118 for ; Tue, 5 Nov 2013 10:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFnA++XEVyvM for ; Tue, 5 Nov 2013 10:17:14 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E80E011E8119 for ; Tue, 5 Nov 2013 10:17:03 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id q58so3903903wes.14 for ; Tue, 05 Nov 2013 10:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Sia+Dphe3XawRSLr8kA41potCRjrkPT3MegK/AlWmhc=; b=fo7wpQvxW5g5ivekBzypLWPejNcu3B2FhepxfF89DArQOaejbZ8rjQKmk9IKZkIXvi qASsR9Q7r0CKHJcHf0nN/w6vcACq6kCCPzbkFCEUg8EBtyG10rPGoKq9vbMk3xAq0jDH ASZncbvoiW65QQS5HIWCj23L7pBx76FJu+0RNQgEP+VLuzwQdmiXIGKRTVnJuZalvOnl VoCGnLbr3cyyuL/nnjsIEPke94cLtNAg3FCnPl/ESmzZarWS4+f9VQ0iwryJf+bXArlc 0of2Hf+bGHLZQnL3s4wNt153zA23jx8NUVN7KYfBNW66NM0uydxA5pXROtRVUkNMIBe6 tIlg== X-Received: by 10.180.78.165 with SMTP id c5mr18118618wix.3.1383675422566; Tue, 05 Nov 2013 10:17:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.42.4 with HTTP; Tue, 5 Nov 2013 10:16:42 -0800 (PST) In-Reply-To: References: From: Arturo Servin Date: Tue, 5 Nov 2013 16:16:42 -0200 Message-ID: To: Jen Linkova Content-Type: multipart/alternative; boundary=f46d04388e670bf32304ea720ab3 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 18:17:14 -0000 --f46d04388e670bf32304ea720ab3 Content-Type: text/plain; charset=ISO-8859-1 Blocking according to DNS content would be something like Deep Packet Inspection, isn't it? Do we want to go there? /as On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova wrote: > Section 4.2. says that > " > > So when using ULAs in a network, the administrators should clearly > set the scope of the ULAs and configure ACLs on relevant border > routers to block them out of the scope. And if internal DNS are > enabled, the administrators might also need to use internal-only DNS > names for ULAs. > " > I believe it should that that the administrator MUST configure egress > ACLs on borders routers and MUST ensure that their DNS servers do not > include ULAs in any responses to external clients. > > > > > -- > SY, Jen Linkova aka Furry > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04388e670bf32304ea720ab3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Blocking according to DNS content would be someth= ing like Deep Packet Inspection, isn't it?

Do = we want to go there?

/as


On Tue, Nov 5, 2013 at 3:50 PM, Jen Link= ova <furry13@gmail.com> wrote:
Section 4.2. says that
"

So when using ULAs in a network, the administrators should clearly
=A0 =A0set the scope of the ULAs and configure ACLs on relevant border
=A0 =A0routers to block them out of the scope. And if internal DNS are
=A0 =A0enabled, the administrators might also need to use internal-only DNS=
=A0 =A0names for ULAs.
"
I believe it should that that the administrator MUST configure egress
ACLs on borders routers and MUST ensure that their DNS servers do not
include ULAs in any responses to external clients.




--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d04388e670bf32304ea720ab3-- From brian.e.carpenter@gmail.com Tue Nov 5 10:25: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 14B2A11E80DE for ; Tue, 5 Nov 2013 10:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxfDBdJqiAeL for ; Tue, 5 Nov 2013 10:25:41 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2DF21F8C65 for ; Tue, 5 Nov 2013 10:25:41 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so15599801ieb.33 for ; Tue, 05 Nov 2013 10:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pQJ9C4DlfNjaPFinqSQ6HrOPVXShmDs+etA6yc8NL88=; b=fXWBdzvmVqwwZMWBfq7TQiIVaGx7BlACFnFI0KAkWKF5sPL4FTzqKsogVMNZ8VCqc7 a9batKDTMYmz0V0E04wCpJ2o3qLYfumRK9O5jy6NNMc5K2KXQS9q1dXRFBXC77i2sfoD YwNpC1niWdmGLSAczSQt0aAOoFvbuqh7IqfgZXoeX3oQF1jmb1m9x0tHRWKgq8yBwCcG yKo4rClENt6w6d3yGplIdD9D9U1URI9VR14yIOmsb0EIDNnjn2sqM6t8/sTB1Q+Ly9Gy pKIIwIFPPf4hJHEkyDmfGpv7ZyHSWA270UNGJZdhwJvjOQO18XxRFVVtZAzdVBSM26dF q4bg== X-Received: by 10.50.111.16 with SMTP id ie16mr16531737igb.52.1383675940141; Tue, 05 Nov 2013 10:25:40 -0800 (PST) Received: from [31.133.165.38] (dhcp-a526.meeting.ietf.org. [31.133.165.38]) by mx.google.com with ESMTPSA id ka1sm9649151igb.7.2013.11.05.10.25.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:25:39 -0800 (PST) Message-ID: <52793827.2040708@gmail.com> Date: Wed, 06 Nov 2013 07:25:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arturo Servin References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 18:25:42 -0000 On 06/11/2013 07:16, Arturo Servin wrote: > Blocking according to DNS content would be something like Deep Packet > Inspection, isn't it? > > Do we want to go there? No, but that's not what he means. He means split DNS, where the internal DNS server includes records that are not present in the external DNS server. That, like it or not, is standard practice today in many enterprise networks. Brian > > /as > > > On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova wrote: > >> Section 4.2. says that >> " >> >> So when using ULAs in a network, the administrators should clearly >> set the scope of the ULAs and configure ACLs on relevant border >> routers to block them out of the scope. And if internal DNS are >> enabled, the administrators might also need to use internal-only DNS >> names for ULAs. >> " >> I believe it should that that the administrator MUST configure egress >> ACLs on borders routers and MUST ensure that their DNS servers do not >> include ULAs in any responses to external clients. >> >> >> >> >> -- >> SY, Jen Linkova aka Furry >> _______________________________________________ >> 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 leo.liubing@huawei.com Tue Nov 5 10:26: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 9ACB221F8C65 for ; Tue, 5 Nov 2013 10:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.326 X-Spam-Level: X-Spam-Status: No, score=-5.326 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTEh3UZ0LSs0 for ; Tue, 5 Nov 2013 10:26:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4621E809E for ; Tue, 5 Nov 2013 10:26:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO61449; Tue, 05 Nov 2013 18:26:48 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 18:26:10 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 18:26:47 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 02:26:41 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Mikael Abrahamsson Thread-Topic: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: AQHOzltsXXG/hvZHw0OAdgyFq+29zZoVi9gAgABL/ACAAECpgIAAB7OAgAAhtgCAABR1gIAAqRLL Date: Tue, 5 Nov 2013 18:26:40 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F083A@nkgeml506-mbx.china.huawei.com> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <15A60E31-DAD1-4E72-8E27-52868FAF9203@cisco.com> , <52791025.6070601@gmail.com> In-Reply-To: <52791025.6070601@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.36] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ole Troan , "v6ops@ietf.org" , =?gb2312?B?yfHD999f1NU=?= Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 05 Nov 2013 18:26:54 -0000 PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0K DQo+IEZyb20geWVzdGVyZGF5J3MgZGlzY3Vzc2lvbiwgdGhlIG91dGNvbWVzIHNlZW0gYSBsaXR0 bGUgbW9yZSBjb21wbGljYXRlZA0KPiB0aGFuIHRoYXQuDQpbQmluZ10gSSBoYXZlIHRoZSBzYW1l IGZlZWxpbmcsIGVzcGVjaWFsbHkgYWZ0ZXIgb2ZmLWxpbmUgdGFsa2luZyB3aXRoIEVyaWMsIEkg YmVnYW4gdG8gbm90aWNlIHRoYXQgaXQgbWlnaHQgaW52b2x2ZSBzb21lIG5ldHdvcmstbWFuYWdl bWVudC1waGlsb3NvcGh5IGRpZmZlcmVuY2UuIFRoYXQgbWlnaHQgYmUgb25lIG9mIHRoZSByZXNv bnMgd2h5IHRoZSBzcGVjaWZpY2F0aW9uIGhhcyBhbWJpZ3VpdHkuIEl0IHdhcyBhbmQgd2lsbCBi ZSBkaWZmaWN1bHQgdG8gZ2V0IGNvbnNlbnN1cyBvbiB3aGF0IGlzIGV4YWN0bHkgdGhlICJyaWdo dCIgYmVoYXZpb3IuDQoNCj4gMS4gSSB0aGluayB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYXMgaXQg c3RhbmRzICh3aXRoIHRoZSBFbmdsaXNoIGNsZWFuZWQNCj4gdXApIGlzIGEgdmVyeSB1c2VmdWwg ZG9jdW1lbnQgd2l0aCB0d28gYXVkaWVuY2VzOg0KDQogPiBhKSB0aGUgSUVURiwgaW5jbHVkaW5n IDZtYW4sIGJlY2F1c2UgaXQgcG9pbnRzIHRvIGFtYmlndWl0eSBpbiBvdXIgc3BlY3M7DQogPiBi KSB0aGUgb3BlcmF0b3IgY29tbXVuaXR5LCBiZWNhdXNlIGl0IHdhcm5zIG9mIHNvbWUgdmVyeSBz cGVjaWZpYw0KID4gb3BlcmF0aW9uYWwgKG1pcyliZWhhdmlvdXJzIHdpdGggY3VycmVudGx5IGRl cGxveWVkIGNvZGUuDQpbQmluZ10gWWVzLCB0aGF0IGlzIHdoeSB3ZSBwdXQgdGhlIGRvY3VtZW50 IGluIHY2b3BzLiBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgNm1hbiB3b3VsZCBjbGVhciB0aGUgYW1i aWd1aXR5IG9yIG5vdCwgdGhlIG9wZXJhdGlvbmFsIHByb2JsZW1zIG5lZWQgdG8gYmUgZG9jdW1l bnRlZCwgdGhhdCBpcyB0aGUgYmFzaWMgZ29hbCBvZiB0aGlzIGRyYWZ0Lg0KDQo+IEJlY2F1c2Ug b2YgYikgSSB0aGluayBpdCBuZWVkcyB0byBiZWNvbWUgYW4gUkZDIHF1aXRlIHNvb24uDQpbQmlu Z10gSSBob3BlIHNvLg0KDQo+IDIuIFRoZW4gKHByb2JhYmx5IGFzIGEgc2VwYXJhdGUgZG9jdW1l bnQpIHdlIG5lZWQgYW4gYW5hbHlzaXMgb2YNCj4gd2hpY2ggcHJvYmxlbXMgYXJlIGEgcmVzdWx0 IG9mDQoNCj4gICBhKSBpbXBsZW1lbnRhdGlvbiBlcnJvcnMsIHdoaWNoIHRoZSBJRVRGIGNhbiBk b2N1bWVudCBidXQgbm90IGZpeDsNCj4gICBiKSBkaWZmZXJpbmcgaW50ZXJwcmV0YXRpb25zIG9m IE1BWXMgYW5kIFNIT1VMRHMgKEZyZWQncyBwb2ludCksDQo+ICAgICAgd2hlcmUgdGhlIElFVEYg Y291bGQgY29uc2lkZXIgQkNQIGd1aWRhbmNlIHRvIGltcGxlbWVudG9yczsNCj4gICBjKSBlcnJv cnMgb3IgYW1iaWd1aXRpZXMgaW4gdGhlIHN0YW5kYXJkcywgd2hpY2ggNm1hbiBzaG91bGQgZml4 Lg0KW0JpbmddIEEgc2VwYXJhdGVkIGRvY3VtZW50IHdvdWxkIG1ha2Ugc2Vuc2UuIEFuZCBpdCBt aWdodCBpbnZvbHZlIG11Y2ggbW9yZSBkaXNjdXNzaW9uL2FyZ3VtZW50cyB0aGFuIHRoZSBwcm9i bGVtIHN0YXRlbWVudC4NCg0KUmVnYXJkcywNCkJpbmc= From touch@isi.edu Tue Nov 5 10:28: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 67C1D21E809E for ; Tue, 5 Nov 2013 10:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.331 X-Spam-Level: X-Spam-Status: No, score=-103.331 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGECR03pAiWB for ; Tue, 5 Nov 2013 10:28:08 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6464821E812E for ; Tue, 5 Nov 2013 10:28:03 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA5IRWox007841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Nov 2013 10:27:32 -0800 (PST) Message-ID: <52793908.2090202@isi.edu> Date: Tue, 05 Nov 2013 10:29:28 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Jared Mauch , Brian E Carpenter References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <5278EDAB.5030601@inex.ie> <52790CE7.6010506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 18:28:14 -0000 On 11/5/2013 7:31 AM, Jared Mauch wrote: > Without an explicit standard that says things MUST be supported that we can > cite in RFP/RFI and broad coalition of purchasers it's difficult or impossible > to change things. RFC2460 Sec 4. Joe From leo.liubing@huawei.com Tue Nov 5 10:47: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 73DCB11E8210 for ; Tue, 5 Nov 2013 10:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkCm15Sf6ghP for ; Tue, 5 Nov 2013 10:46:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4979011E8215 for ; Tue, 5 Nov 2013 10:46:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZX56832; Tue, 05 Nov 2013 18:45:48 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 18:45:07 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 18:45:48 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 02:45:43 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Arturo Servin Thread-Topic: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHO2k/wLQNmfJ8fNUS0872S7bWPwZoWa54AgAAChYCAAItPAw== Date: Tue, 5 Nov 2013 18:45:42 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F086C@nkgeml506-mbx.china.huawei.com> References: , <52793827.2040708@gmail.com> In-Reply-To: <52793827.2040708@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 18:47:09 -0000 Hi, Brian Thanks for your explanation, that is what the draft means. It might needs re-wording to make it clearer. Regards, Bing ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Brian E = Carpenter [brian.e.carpenter@gmail.com] Sent: Tuesday, November 05, 2013 10:25 To: Arturo Servin Cc: v6ops@ietf.org Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis On 06/11/2013 07:16, Arturo Servin wrote: > Blocking according to DNS content would be something like Deep Packet > Inspection, isn't it? > > Do we want to go there? No, but that's not what he means. He means split DNS, where the internal DNS server includes records that are not present in the external DNS server. That, like it or not, is standard practice today in many enterprise networks. Brian > > /as > > > On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova wrote: > >> Section 4.2. says that >> " >> >> So when using ULAs in a network, the administrators should clearly >> set the scope of the ULAs and configure ACLs on relevant border >> routers to block them out of the scope. And if internal DNS are >> enabled, the administrators might also need to use internal-only DNS >> names for ULAs. >> " >> I believe it should that that the administrator MUST configure egress >> ACLs on borders routers and MUST ensure that their DNS servers do not >> include ULAs in any responses to external clients. >> >> >> >> >> -- >> SY, Jen Linkova aka Furry >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops= From arturo.servin@gmail.com Tue Nov 5 10:48: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 C9C6D21F9FA7 for ; Tue, 5 Nov 2013 10:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO1Wyt7HM8PG for ; Tue, 5 Nov 2013 10:47:59 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C511E81D2 for ; Tue, 5 Nov 2013 10:47:16 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t60so3938406wes.12 for ; Tue, 05 Nov 2013 10:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4cv0xY6BlXugT4DQxSocLfH87BIeNcGjmVKAdv4GMVs=; b=xpc0qc9gVu4w78r8H/k1UNp+eU2/lJcZug2bPhuDudG8ue7Flr59lrPQ5TfSJzIBZc ywEhl1KPlvo5tCdu70GzBFP+074nHp73VIsSpEhB07FxgAqePA699yufMnCe5p3YdKMZ 3s2b9nEidDbY+qfy9EaQsC6xNozbV1K3wnu+8YwJkWCWsn6OOkcmDEW9ElN6I40G4xPg 9g+fwKGTAKteJkTzFxX7cldW6MreUEFZ0nbjTCAzkf/lyz1BaP6DJi+JzHjYDAH3XnxQ wDD0qJQSNQkSniySLsld98NqAXUQILbjJPCOBnS7UtTlidj3xquIm1vuczlvhiqQsdM1 +5Xw== X-Received: by 10.194.8.137 with SMTP id r9mr188120wja.78.1383677233701; Tue, 05 Nov 2013 10:47:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.42.4 with HTTP; Tue, 5 Nov 2013 10:46:52 -0800 (PST) In-Reply-To: <52793827.2040708@gmail.com> References: <52793827.2040708@gmail.com> From: Arturo Servin Date: Tue, 5 Nov 2013 16:46:52 -0200 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b5d2532ffa90d04ea72756c Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 18:48:02 -0000 --047d7b5d2532ffa90d04ea72756c Content-Type: text/plain; charset=ISO-8859-1 Then we need more text because that is not clear enough. Also, talking about DNS, another advise would be to to have reverse delegations on internal DNS to avoid leaking queries. .as On Tue, Nov 5, 2013 at 4:25 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 06/11/2013 07:16, Arturo Servin wrote: > > Blocking according to DNS content would be something like Deep Packet > > Inspection, isn't it? > > > > Do we want to go there? > > No, but that's not what he means. He means split DNS, where > the internal DNS server includes records that are not present > in the external DNS server. That, like it or not, is standard > practice today in many enterprise networks. > > Brian > > > > > /as > > > > > > On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova wrote: > > > >> Section 4.2. says that > >> " > >> > >> So when using ULAs in a network, the administrators should clearly > >> set the scope of the ULAs and configure ACLs on relevant border > >> routers to block them out of the scope. And if internal DNS are > >> enabled, the administrators might also need to use internal-only DNS > >> names for ULAs. > >> " > >> I believe it should that that the administrator MUST configure egress > >> ACLs on borders routers and MUST ensure that their DNS servers do not > >> include ULAs in any responses to external clients. > >> > >> > >> > >> > >> -- > >> SY, Jen Linkova aka Furry > >> _______________________________________________ > >> 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 > --047d7b5d2532ffa90d04ea72756c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Then we need more text because that is not clear = enough.

Also, talking about DNS, another advise wo= uld be to to have reverse delegations on internal DNS to avoid leaking quer= ies.

.as


On Tue, Nov 5, 2013 at 4:25 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 06/11/2013 07:16, Artur= o Servin wrote:
> Blocking according to DNS content would be something like Deep Packet<= br> > Inspection, isn't it?
>
> Do we want to go there?

No, but that's not what he means. He means split DNS, where
the internal DNS server includes records that are not present
in the external DNS server. That, like it or not, is standard
practice today in many enterprise networks.

=A0 =A0Brian

>
> /as
>
>
> On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova <furry13@gmail.com> wrote:
>
>> Section 4.2. says that
>> "
>>
>> So when using ULAs in a network, the administrators should clearly=
>> =A0 =A0set the scope of the ULAs and configure ACLs on relevant bo= rder
>> =A0 =A0routers to block them out of the scope. And if internal DNS= are
>> =A0 =A0enabled, the administrators might also need to use internal= -only DNS
>> =A0 =A0names for ULAs.
>> "
>> I believe it should that that the administrator MUST configure egr= ess
>> ACLs on borders routers and MUST ensure that their DNS servers do = not
>> include ULAs in any responses to external clients.
>>
>>
>>
>>
>> --
>> SY, Jen Linkova aka Furry
>> _______________________________________________
>> 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

--047d7b5d2532ffa90d04ea72756c-- From furry13@gmail.com Tue Nov 5 10:59: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 CF30321E8135 for ; Tue, 5 Nov 2013 10:59:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFznZS0nke-M for ; Tue, 5 Nov 2013 10:59:48 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8D521F9F86 for ; Tue, 5 Nov 2013 10:59:42 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id f11so1312781qae.10 for ; Tue, 05 Nov 2013 10:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bXZMvQqf9kLW6Qu1LqL1PDGUEU/urGPswuNGRtVVxIo=; b=rm3ZW3pMFX/lN4l98e4VtbPOlXq2KxiI62IY2s3ruLuCUIpwoJUYrJEPQXqpNvqebp oTZxOuJzfqJigDF2t94BKEmHGkI1MjawRrd9ET2kgA0So/31aiHA9bFzXWs1MlQd/gBD CLSMM4Ax5hPyDWXHAHErMHJUk/CDdG5WIoqNury2jtnXlMqetML2qq+pHLr3hJByCWtm fzphUvTPbM4V1KAeJEiueFHT7wblhkGXopzxzyWyj9XlQlg0H1FPYB9W2nBFmcVyk46y SPw5xdc726wETrSTHo1If2bfrmGmhxZcIZTA9rVOmE4jj2kc/JljzN/iraS1kQ/PL4Ok G1vQ== X-Received: by 10.224.57.68 with SMTP id b4mr32106956qah.63.1383677981945; Tue, 05 Nov 2013 10:59:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Tue, 5 Nov 2013 10:59:21 -0800 (PST) In-Reply-To: References: From: Jen Linkova Date: Tue, 5 Nov 2013 19:59:21 +0100 Message-ID: To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 18:59:49 -0000 On Tue, Nov 5, 2013 at 7:16 PM, Arturo Servin wrote: > Blocking according to DNS content would be something like Deep Packet > Inspection, isn't it? > > Do we want to go there? There are various ways to achieve it but I think the standard way is to use split DNS. Anyway I don't think that the document in question must dictate how to prevent DNS leakage (although having some recommendation would be nice). > On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova wrote: >> >> Section 4.2. says that >> " >> >> So when using ULAs in a network, the administrators should clearly >> set the scope of the ULAs and configure ACLs on relevant border >> routers to block them out of the scope. And if internal DNS are >> enabled, the administrators might also need to use internal-only DNS >> names for ULAs. >> " >> I believe it should that that the administrator MUST configure egress >> ACLs on borders routers and MUST ensure that their DNS servers do not >> include ULAs in any responses to external clients. >> >> >> >> >> -- >> SY, Jen Linkova aka Furry >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > -- SY, Jen Linkova aka Furry From cb.list6@gmail.com Tue Nov 5 11:19: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 3C6BC11E8110 for ; Tue, 5 Nov 2013 11:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OBRvWBRhvhU for ; Tue, 5 Nov 2013 11:19:47 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 08E3911E8117 for ; Tue, 5 Nov 2013 11:19:45 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t60so3813734wes.26 for ; Tue, 05 Nov 2013 11:19:45 -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=V+HtDBylNKGi7uVdFmXNdsRRH4sdDW1a1zT8kuGvHNs=; b=Sed4kM0Yqsg9W6Bh8+MI/ibOfwoMUUr+kXaH6WLfwogNph5nAl9Ie1ojzvwM4Px1R3 /WlbT4sjiR5rh6eEZ7iXcj5ulF/Cu8zAwmotH0cVf32i3HkLvZutM7dJmXmE3yodJxFv bxD80VaLQ98/r0sfFfB0FVKhsKKA0qZtU5PqWCJaL8DiIE+y9fukOl68suPQbDukMuvB xYq2p19xedzfDxZN+Tw9PyhsLRLTzsgb9ZMj6jMvRsDAyVk4mq1YNNpKOViESxao/RRn fta38gN+qNtWuOESL4sI8OipEwCLeoVwzgHZyZaO+ruLH+nG3KQbs7yFR7d696kxUcjz WycQ== MIME-Version: 1.0 X-Received: by 10.180.37.227 with SMTP id b3mr17904211wik.24.1383679185093; Tue, 05 Nov 2013 11:19:45 -0800 (PST) Received: by 10.216.99.68 with HTTP; Tue, 5 Nov 2013 11:19:45 -0800 (PST) In-Reply-To: References: <20131104174259.10097.28929.idtracker@ietfa.amsl.com> Date: Tue, 5 Nov 2013 11:19:45 -0800 Message-ID: From: "cb.list6" To: GangChen Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , "" Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-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: Tue, 05 Nov 2013 19:19:48 -0000 Folks, As a listed author, i am sorry for not having reviewed this document prior to publication. I probably should not be on the author list for this reason :) Nonetheless, this is a VERY important topic. First, regarding the draft. Failure case #5 does not exist since a home routed PDP terminates on the home network GGSN so the visited network does not need to deploy NAT64/DNS64. The roaming user is only exposed to the home NAT64/DNS64 and all IP packets are GTP tunneled to the home. Second, i do not recommend anyone attempt dual-stack (v4v6) 3GPP roaming. I am convinced that it is so broken that it may take more than 5 years to fix. Essentially, we need to wait of broken gear run by disinterested networks to simply cycle out. In fact, the 3GPP roaming and home serving architectures are so entwined, that i cannot deploy dual-stack in a 3GPP home network because this will result in all subscribers to fail for all access attempts in these flawed roaming partner networks. This is not acceptable to the business. It is truly a terrible situation where a roaming partner's flawed deployment inhibits my ability to do dual-stack in my own network. That said, there is only one path that i know of to thread this needle. If a mobile network operator wants to deploy IPv6 and NOT break roaming, the mobile network operator MUST deploy an IPv6-only solution in the home network (such as RFC6877 / 464XLAT) AND require the phone / UE to request _IPv6-only while at home_ AND _IPv4-only while roaming_. The fundamental issue is that widely deployed gear fails to handle v4v6 permissions correctly, and the mere presence of this permission causes the user to fail to access anything at all. I know 464XLAT at 3GPP home and IPv4-only while roaming works, because i have deployed this. I know that i can NOT deploy v4v6 because i deployed that too, and had to roll it back when customers started failing. CB On Mon, Nov 4, 2013 at 9:50 AM, GangChen wrote: > Wg, > > We submit the new draft of IPv6 roaming. Please kindly check. > Your comments are appreciated > > BRs > > Gang > > 2013/11/5, internet-drafts@ietf.org : >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : IPv6 Roaming Behavior Analysis >> Author(s) : Gang Chen >> Hui Deng >> Dave Michaud >> Jouni Korhonen >> Mohamed Boucadair >> Vizdal Ales >> Cameron Byrne >> Filename : draft-chen-v6ops-ipv6-roaming-analysis-02.txt >> Pages : 12 >> Date : 2013-11-04 >> >> Abstract: >> This document intends to enumerate failure cases when a IPv6 >> subscriber roams into visited network areas. The investigations on >> those failed cases reveal the causes in order to notice improper >> configurations, equipment's incomplete functions or inconsistent IPv6 >> strategy. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-roaming-analysis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-chen-v6ops-ipv6-roaming-analysis-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 leo.liubing@huawei.com Tue Nov 5 11:28: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 0849511E81BB for ; Tue, 5 Nov 2013 11:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+FxJi9hXNiH for ; Tue, 5 Nov 2013 11:28:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5908311E8142 for ; Tue, 5 Nov 2013 11:28:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZX58829; Tue, 05 Nov 2013 19:28:41 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 19:27:59 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 19:28:40 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 03:28:33 +0800 From: "Liubing (Leo)" To: Jen Linkova , "v6ops@ietf.org" Thread-Topic: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHO2k/wLQNmfJ8fNUS0872S7bWPwZoW/DTD Date: Tue, 5 Nov 2013 19:28:32 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F090A@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 19:28:49 -0000 Hi, Jen I got your comments. I'll consider to revise accordingly. Many thanks Regards, Bing ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Jen Link= ova [furry13@gmail.com] Sent: Tuesday, November 05, 2013 09:50 To: v6ops@ietf.org Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis Section 4.2. says that " So when using ULAs in a network, the administrators should clearly set the scope of the ULAs and configure ACLs on relevant border routers to block them out of the scope. And if internal DNS are enabled, the administrators might also need to use internal-only DNS names for ULAs. " I believe it should that that the administrator MUST configure egress ACLs on borders routers and MUST ensure that their DNS servers do not include ULAs in any responses to external clients. -- SY, Jen Linkova aka Furry _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops= From ggm@algebras.org Tue Nov 5 11:29: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 E7B1E11E80E2 for ; Tue, 5 Nov 2013 11:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eary-5nbdFrk for ; Tue, 5 Nov 2013 11:29:44 -0800 (PST) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id ABC8E21E808A for ; Tue, 5 Nov 2013 11:29:44 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id q10so9031612pdj.14 for ; Tue, 05 Nov 2013 11:29:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xoefcv3N6HcLKNvi+FRLOpWwtUM3gOFtBsh/BmmzAl4=; b=HsnZaj14IrT8HSsW6NZOb8LcKvAoENSRlWnL4SpVtTXuDJ15BLUfsbaM6pqM7kFpFV siW+ZHPvM4w1fzGmVmcXT49xK47Baw5utOcijmSWc0PlxuN6G0uRH/AlkJTuFhkm4hFx UvjDjAOcs0CgsfLLJaZVZ27rHVKt0Y0J7vw/I9Btx1AiR+rGbpjLt6rZrYn/kWyUaz/G uM/KLq8LcRRJlLxL5SHipd2WBvHraa+lwM4fSO5kHrNPvfPd1oxokLVOXMMUnbGJtrMW 9a/33HZvMxivn1wI+8qVsJL4FYiA0r/OnMTiuaz081ykJ2b7j847yriIUNSmH/5fENBA MIOA== X-Gm-Message-State: ALoCoQn8czZXbSgtwV0QgTv01DI9OS9x7sv8RVI4jNv7d77500UjPUgdskiEV99eWqf77yL5/R4n MIME-Version: 1.0 X-Received: by 10.68.233.135 with SMTP id tw7mr24481600pbc.112.1383679784050; Tue, 05 Nov 2013 11:29:44 -0800 (PST) Received: by 10.70.19.98 with HTTP; Tue, 5 Nov 2013 11:29:43 -0800 (PST) X-Originating-IP: [2001:67c:370:168:9d3:37fe:7fa3:5363] In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F090A@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F090A@nkgeml506-mbx.china.huawei.com> Date: Tue, 5 Nov 2013 11:29:43 -0800 Message-ID: From: George Michaelson To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=047d7b33da0a02fb4e04ea730e22 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 19:29:49 -0000 --047d7b33da0a02fb4e04ea730e22 Content-Type: text/plain; charset=ISO-8859-1 I tend to SHOULD. you can do what you like, but the consequence of not doing a local delegation is information leakage. There is no compelling MUST On Tue, Nov 5, 2013 at 11:28 AM, Liubing (Leo) wrote: > Hi, Jen > > I got your comments. I'll consider to revise accordingly. Many thanks > > Regards, > Bing > > ________________________________________ > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Jen > Linkova [furry13@gmail.com] > Sent: Tuesday, November 05, 2013 09:50 > To: v6ops@ietf.org > Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis > > Section 4.2. says that > " > > So when using ULAs in a network, the administrators should clearly > set the scope of the ULAs and configure ACLs on relevant border > routers to block them out of the scope. And if internal DNS are > enabled, the administrators might also need to use internal-only DNS > names for ULAs. > " > I believe it should that that the administrator MUST configure egress > ACLs on borders routers and MUST ensure that their DNS servers do not > include ULAs in any responses to external clients. > > > > > -- > SY, Jen Linkova aka Furry > _______________________________________________ > 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 > --047d7b33da0a02fb4e04ea730e22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I tend to SHOULD. you can do what you like, but the conseq= uence of not doing a local delegation is information leakage. There is no c= ompelling MUST


On Tue, Nov 5, 2013 at 11:28 AM, Liubing (Leo) <leo.liubing@huawei.co= m> wrote:
Hi, Jen

I got your comments. I'll consider to revise accordingly. Many thanks
Regards,
Bing

________________________________________
From: v6ops-bounces@ietf.org = [v6ops-bounces@ietf.org] on b= ehalf of Jen Linkova [furry13@gmail.co= m]
Sent: Tuesday, November 05, 2013 09:50
To: v6ops@ietf.org
Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis

Section 4.2. says that
"

So when using ULAs in a network, the administrators should clearly
=A0 =A0set the scope of the ULAs and configure ACLs on relevant border
=A0 =A0routers to block them out of the scope. And if internal DNS are
=A0 =A0enabled, the administrators might also need to use internal-only DNS=
=A0 =A0names for ULAs.
"
I believe it should that that the administrator MUST configure egress
ACLs on borders routers and MUST ensure that their DNS servers do not
include ULAs in any responses to external clients.




--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b33da0a02fb4e04ea730e22-- From markzzzsmith@yahoo.com.au Tue Nov 5 11:33: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 6E8D721F9E54 for ; Tue, 5 Nov 2013 11:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvupePpU+Kbz for ; Tue, 5 Nov 2013 11:33:06 -0800 (PST) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with ESMTP id E8DE311E8196 for ; Tue, 5 Nov 2013 11:33:02 -0800 (PST) Received: from [98.139.212.151] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 19:32:59 -0000 Received: from [98.139.212.211] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 19:32:59 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 19:32:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 270212.96721.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 91479 invoked by uid 60001); 5 Nov 2013 19:32:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383679978; bh=dVW5FyeN+5h008dRdV/hRhGEnJbG1z9aV2OElYDcsl4=; 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=nTkJFOHs0sJZ3g+/Vxm+BeyXgqK18IY37idyOTOATNG4dnfdiZSJpBMC5dicFrevCnWi7fywUct/AUkeS2O/s20MiJRsJ52ZF623Vxv+AxFaMnEALVbPeQvbaGOdV4Mxc+pHrR5UXWZQPRf6q3jE39P4ml81sz8McFUUZcCVu5g= 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=sGkQ1+TxJkLAGutiHs7kg4POiO2xX2q7SxMglkHsVTRfxDJFkqGlPeVkYz9lCDxAMomEU1AOB5G/oQwX2wy2jMk1tAtvI/7eEUgnV0Bkc3K5qVkaZ8z3znYc05Go4FoS2i7y61vDHHs8VNyPOkmh+FR4yuCQot7LhTyKky8ArPk=; X-YMail-OSG: A595SRcVM1mIvlbx_XBZqnOVm90B5OmVcm3rxf.pgZy.r.h pg_eBlNLK.IsHKKgKIbgvrMpHL4aj0bUqYmdlAgvMAWjAZ2WqkB_oaocG1sX 2Sw8c8lzsVR9g9piCKs6jMtWWE6j6fcWh9mdzcNtwXSJcjKJdzKbbls8Bwih K3eGetilLhY9oBdVm0tFDrs5umcL.RolCY20RrjSPuU4332r8eHBYTi1KuEl Eyc4KO4JLCm0wVs.pLPHDsFfr8y0rhGfdRhaLTVc13bGPlRcVpbGgy9cmi5x F32k.tvpKFftmidj8tiDPUJGkqME3xgQdoWklTe0hNSUcoctGPF5dAaaDc2F iPoDGGJGC.1YReSuiJI1g84Ixt873xspsArZ8QH_nr.PQWv55o6xbWzmsNnB rHWORNVw_iTbpiY9I.lrGPWF_O7V0B5Jj_6pPqAxfsuOspG9rsIIFlNnrkiC kmU1Q4L1vpeHVymYPHZuKD5zidh0.50rX.tjoKrmcvb0kmwZrtesTxfcKXvj z07EENBi2qeW0bkSEc.jlZ8HoKwYwk.NlfK.gI6MhaXYGzLrzHcv9zVfQgBM IwW5snkKReoBBF.7zgcY2i1JR8tskJhKF7VY4chLTixSgoWI- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 05 Nov 2013 11:32:58 PST X-Rocket-MIMEInfo: 002.001, Cgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBDaHJpc3RvcGhlciBQYWxtZXIgPENocmlzdG9waGVyLlBhbG1lckBtaWNyb3NvZnQuY29tPgo.VG86IFRpbSBDaG93biA8dGpjQGVjcy5zb3Rvbi5hYy51az47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFR1ZXNkYXksIDUgTm92ZW1iZXIgMjAxMyAyOjEwIFBNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBVTEEgYW5kIElQdjQgLSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzCj4gCj4KPgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.161.596 References: Message-ID: <1383679978.91401.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 5 Nov 2013 11:32:58 -0800 (PST) From: Mark ZZZ Smith To: Christopher Palmer , Tim Chown , "v6ops@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:33:11 -0000 =0A=0A>________________________________=0A> From: Christopher Palmer =0A>To: Tim Chown ; "v6ops= @ietf.org" =0A>Sent: Tuesday, 5 November 2013 2:10 PM=0A>S= ubject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis=0A> = =0A>=0A>=0A>The majority of in-the-wild hosts are running 3484, so as an op= erational document I think it=E2=80=99s reasonable to discuss the issue as = it exists with those machines. =0A>=C2=A0=0A>Even with 6724 =E2=80=93 hosts= configured as described in 3.3 may still attempt a ULA -> Native IPv6 conn= ection. That connection will just not be preferred over IPv4 -> IPv4. =0A>= =C2=A0=0A>I=E2=80=99d argue that=E2=80=99s still non-ideal. If the enterpri= se hosts in question do not have access to the IPv6 Internet, they should n= ot be configured with a default route =E2=80=93 thus they would *never* att= empt connectivity.=0A>=C2=A0=0A=0AEven if the hosts do have a default route= , the network shouldn't (or at some point shouldn't). At that point, the ro= uter should generate an ICMPv6 Destination Unreachable, which will cause th= e host to switch to IPv4.=0A=0AI tested this a few years ago and the switch= over was both sub-second and not noticeable (under Linux with Firefox and/= or Chrome).=0A=0AI think where people might be thinking this is a bigger is= sue an it is is because there was one particular IPv6 CPE that didn't gener= ate ICMP Destination Unreachables when it didn't have IPv6 Internet connect= ivity. This showed up around the time of RFC6204 being finalised, and I thi= nk people didn't completely realise it was an implementation issue, rather = than a flaw in IPv6 operation.=0A=0A=0AOne thing that could influence this = switch over performance is ICMPv6 Destination Unreachable rate limiting on = the originating router. Assuming for the moment that ICMPv6 behaviour is th= e same as ICMPv4s in this regard, it might be worth either advising to rais= e the rate specifically for ICMPv6 Destination Unreachables, and perhaps re= vising the ICMPv6 RFCs to have a higher rate specifically for ICMPv6 Destin= ation Unreachables.=0A=0AICMPv6 Destination Unreachables are fundamentally = unreliable though, which is why I think the happy-eyeballs approach is much= better, and should be used in more applications. I really agree with Fred = Baker's draft:=0A=0A=0AHappier Eyeballs=0Ahttp://tools.ietf.org/html/draft-= baker-happier-eyeballs-00.html=0A=0A=0A=0ARegards,=0AMark.=0A=0A=0A>Overpro= visioning effective IPv6 connectivity is a painful topic.=0A>From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tim Chown=0A>Se= nt: Monday, November 4, 2013 6:59 PM=0A>To: v6ops@ietf.org=0A>Subject: Re: = [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis=0A>=C2=A0=0A>The = 3484=E2=80=99s in that chunk of text should be 6724=E2=80=99s.=0A>=C2=A0=0A= >Tim=0A>=C2=A0=0A>On 5 Nov 2013, at 02:50, Christopher Palmer wrote:=0A>=0A>=0A>=0A>Section 3.3 of the draft:=0A>>= =C2=A0=0A>>=E2=80=9C=C2=A0 As described in section=C2=A02.2.2 of [RFC5220],= when an enterprise has=0A>>=C2=A0=C2=A0 IPv4 Internet connectivity but doe= s not yet have IPv6 Internet=0A>>=C2=A0=C2=A0 connectivity, then the enterp= rise chose ULA for site-local IPv6=0A>>=C2=A0=C2=A0 connectivity. Each empl= oyee host will have both an IPv4 global or=0A>>=C2=A0=C2=A0 private address= and a ULA. Here, when this host tries to connect to=0A>>=C2=A0=C2=A0 an ou= tside node that has registered both A and AAAA records in the=0A>>=C2=A0=0A= >>=C2=A0=C2=A0 DNS, the host will choose AAAA as the destination address an= d the ULA=0A>>=C2=A0=C2=A0 for the source address according to the IPv6 pre= ference of the=0A>>=C2=A0=C2=A0 default address selection policy [RFC3484].= This will clearly result=0A>>=C2=A0=C2=A0 in a connection failure.=E2=80= =9D=0A>>=C2=A0=0A>>This is only true if the ULA is configured on a host tha= t also has a default route The enterprise can avoid any issues by simply co= nfiguring a scoped route on hosts (say, only for the ULA prefix). If a netw= ork does not provide connectivity to the IPv6 Internet, it should not adver= tise ::/0.=0A>>=C2=A0=0A>>I think it=E2=80=99s useful to discuss that confi= guration route, which is possible today with a vast majority of hosts and j= ust works. =0A>>=C2=A0=0A>>Modifying the prefix policy table is not suitabl= e at scale. And the DNS preference logic alluded to in section 3.3 is highl= y ambiguous. =0A>>_______________________________________________=0A>>v6ops= mailing list=0A>>v6ops@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/= v6ops=0A>=C2=A0=0A>=0A>_______________________________________________=0A>v= 6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listinf= o/v6ops=0A>=0A>=0A> From leo.liubing@huawei.com Tue Nov 5 11:34: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 5674311E813B for ; Tue, 5 Nov 2013 11:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyAST7e-1LUh for ; Tue, 5 Nov 2013 11:33:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A317311E8159 for ; Tue, 5 Nov 2013 11:33:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZX59050; Tue, 05 Nov 2013 19:33:54 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 19:33:17 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 19:33:53 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 03:33:45 +0800 From: "Liubing (Leo)" To: Tim Chown , IPv6 Operations Thread-Topic: [v6ops] Comment on draft-ietf-v6ops-ula-usage-recommendations-01 Thread-Index: AQHO2dEFjLLTF7PKn0+84GG5Ze7x7ZoXB2YD Date: Tue, 5 Nov 2013 19:33:44 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F0935@nkgeml506-mbx.china.huawei.com> References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.36] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7F0935nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] Comment on draft-ietf-v6ops-ula-usage-recommendations-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: Tue, 05 Nov 2013 19:34:01 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7F0935nkgeml506mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tim, Thanks for you comment. Please see inline. ________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Tim Chow= n [tjc@ecs.soton.ac.uk] Sent: Monday, November 04, 2013 18:43 To: IPv6 Operations Subject: [v6ops] Comment on draft-ietf-v6ops-ula-usage-recommendations-01 Hi Bing, In section 1 you say: =93 The use of ULA addresses in various types of networks has been confusing to network operators. Some network operators believe ULAs are not useful at all while other network operators have run ULAs beneficially in their networks." This implies you know operators who are using ULAs beneficially. It would b= e nice if those operators are reading this and can comment. Or failing tha= t for you to make it clear where possible in the text which parts you are w= riting based on those operators=92 comments, and which parts are more theor= etical. [Bing] The reason why we wrote this was because our co-author who is from a= n ISP was actually using ULA in their networks. But I agree with you the wording need to be tidted. There are some parts of the text which are written almost in note form. It= would be nice to tidt those parts up a little. Tim --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7F0935nkgeml506mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Tim,

 

Thanks for you comment. Please see inline.

From: v6ops-bounces@ietf.org [v6ops-bounce= s@ietf.org] on behalf of Tim Chown [tjc@ecs.soton.ac.uk]
Sent: Monday, November 04, 2013 18:43
To: IPv6 Operations
Subject: [v6ops] Comment on draft-ietf-v6ops-ula-usage-recommendatio= ns-01

Hi Bing,

In section 1 you say:

=93 The use of ULA addresses in various= types of networks has been
 confusing to=
 network operators. Some network operators believe ULAs
 are not useful at all while other network operators have run ULAs
 beneficially in their networks."

This implies you know operators who are using ULAs beneficially. It wo= uld be nice if those operators are reading this and can comment.  Or f= ailing that for you to make it clear where possible in the text which parts= you are writing based on those operators=92 comments, and which parts are more theoretical.
 
[Bing] The reason why we wrote this was because our co-author who is f= rom an ISP was actually using ULA in their networks.
But I agree with you the wording need to be tidted.

There are some parts of the text which are written almost in note form= .  It would be nice to tidt those parts up a little.

Tim


--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7F0935nkgeml506mbxchi_-- From lorenzo@google.com Tue Nov 5 11:37: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 6602711E8162 for ; Tue, 5 Nov 2013 11:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWY2YqRy3Gy4 for ; Tue, 5 Nov 2013 11:37:45 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91311E8119 for ; Tue, 5 Nov 2013 11:37:45 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id x13so15560863ief.23 for ; Tue, 05 Nov 2013 11:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j7w90P/Wx4RQndsvsUTm9x5ajWbDkFx1dkLftf88ZPo=; b=LIVlu+IEt8e7ZewBYfe1TnOs9Yy2huKE0Z97l73qZvIZWnR6X2gUQSUHbbFyPyUDTI ahCQ5nyrKuxD4mmTzfheEmdvoleEzQbK6t4Cwd4EmRpZ5wlXteSvw12+W9BvCvong8V2 XSYlCBsHw9+0lS4pvz1xilsFRVL5KLqg7Re7BhHjt/H6biTwlh4y3ni0K1i4r//UQvSz j9tn5JjbGmsJB4eVzdzuJKGsNi06Y+/E/bSWjDw4BuS+pU0llXlSXnrufVfBkRqgOCkl mJMfjPVFi6oiYh+VAQgbMkYhNl6ZYkIlEVDZQQN3PUx0C6blYhOZhciPeFxNWGWFIAWp 0TIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=j7w90P/Wx4RQndsvsUTm9x5ajWbDkFx1dkLftf88ZPo=; b=eSHewMVvmuHReAKtJwFIqocfWzJrjHmAxAuq3IlGH9p5HttqAN1k3VFJlkbGanQQG2 saiDs9978p+1suNc4YTDoYqJ547ikVGQardRyAR4lsMy+alawKFv8ERpT85JPXVBhqrp 39XnYaleW0RuhvRuK28K5fHXnHnPFH/lfWm0K8XeEVBRLBKJxjeYWuw8V9nbPIXbr+Tx jkc3yRoWtG33KAaPXK86GMlXKbMxuA6QH4mDwLVHyWVeA3At+B6/z4OcakiogFE9tloF ZvQyGGGMawSqD82jODVDB20aYdWKxTMbeIG1vw02JdE4swJB78gjnFyt3/dnCdGvoXQP nTaA== X-Gm-Message-State: ALoCoQnpWIpgS2rT4dHuuicAreJhmC/ZPhIrHltBwQeTgxermmQJmnDVzxKhsWE/F/OD7ODa+M9DtjvClVXdjz9y7nRYzHht18dS6jYJoz2cW+byUWrOJDV5m8o+PwG05v0drnbrpI+zPGcN85mRyWe+ZaN+CQsi5wxBfjYiIz1g6PUHm+SAIo0RQKoL+t5U4CGcPE9RxVEx X-Received: by 10.42.149.7 with SMTP id t7mr1465637icv.60.1383680264281; Tue, 05 Nov 2013 11:37:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Tue, 5 Nov 2013 11:37:21 -0800 (PST) In-Reply-To: <1383679978.91401.YahooMailNeo@web142501.mail.bf1.yahoo.com> References: <1383679978.91401.YahooMailNeo@web142501.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Wed, 6 Nov 2013 04:37:21 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=90e6ba212171a312ab04ea732a6c Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 19:37:46 -0000 --90e6ba212171a312ab04ea732a6c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 4:32 AM, Mark ZZZ Smith wrote: > Happier Eyeballs > http://tools.ietf.org/html/draft-baker-happier-eyeballs-00.html Great. We can't be bothered to get things right in the network, so we just tell hosts to try everything all the time in the hope that something will work. It's very easy to say "we should just have smarter algorithms", especially if we expect that someone other than ourselves will be writing those algorithms, but I have yet to see a proposal that's sanely implementable, high performance, and low load (even considering the fact that you'd have to completely overhaul the socket API and app the apps using it before you could deploy it). --90e6ba212171a312ab04ea732a6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 4:32 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:
Happier Eyeballs
http://tools.ietf.org/html/draft-baker-happier-eyeballs-= 00.html

Great. We can't be bothered= to get things right in the network, so we just tell hosts to try everythin= g all the time in the hope that something will work.

It's very easy to say "we should just have sma= rter algorithms", especially if we expect that someone other than ours= elves will be writing those algorithms, but I have yet to see a proposal th= at's sanely implementable, high performance, and low load (even conside= ring the fact that you'd have to completely overhaul the socket API and= app the apps using it before you could deploy it).
--90e6ba212171a312ab04ea732a6c-- From owen@delong.com Tue Nov 5 11:50: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 0799821E8089 for ; Tue, 5 Nov 2013 11:50:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYQMwxRZepGO for ; Tue, 5 Nov 2013 11:50:23 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7D11E8110 for ; Tue, 5 Nov 2013 11:49:36 -0800 (PST) Received: from [172.20.0.201] (63-235-172-3.dia.static.qwest.net [63.235.172.3]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rA5JivSN007244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Nov 2013 11:44:59 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rA5JivSN007244 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1383680699; bh=xUuejDyhu7bwV+jWMyYNyTka5KY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=4nNis/2ta9L54TNKohRdhRds8S+PYvGKtBnPNitioZJAatkYpt/srIaLg4ZCHwU/A UXvAQDrkBdNiWKp/iPtHkB6e4z2g9F3IsV2LWp3lCKe3LQnf12chvyNcxtqcJCJud6 L5IPogCOWOv+KpoGeb+5KqY8VxyhCkPZ61Jo/S/M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Owen DeLong In-Reply-To: Date: Tue, 5 Nov 2013 11:44:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <87D04C8B-9413-4F1A-B8F5-07E2275717AE@delong.com> References: <29AE8DB910E7704CA043795E00DCBE7803417A05@CL08MBE.rci.rogers.ca> To: james woodyatt X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 05 Nov 2013 11:44:59 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-byrne-v6ops-clatip-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: Tue, 05 Nov 2013 19:50:27 -0000 Is there a reason the 100.64.0.0/10 prefix reserved for transitional = technology implementations would be inadequate or inappropriate to this = task? Owen On Nov 5, 2013, at 9:48 AM, james woodyatt wrote: > On 2013-11-04, at 19:08 , Dave Michaud = wrote: >>=20 >> I think however, and this is my interpretation when I read the I-D, = that the current intention is only to generalize a block already = assigned for DS-lite so that it can be re-used for other transition = technologies. The idea here is to provide an option for deploying = 464XLAT.=20 >>=20 >> Mandating the use of this range may be inappropriate at this point = but that is not what the current version of the draft does anyway. >=20 > I finally figured out why this draft made me say "huh?" when it was = presented. >=20 > When I was working on the IPv4 dial-tone features a certain home = gateway implementation, I ran into a very similar problem. I needed = some IPv4 addresses to number the PPP interface when it was in its = "connect-on-demand" state. These addresses would never appear on the = wire, because they were only used for triggering the PPPoE Discovery = protocol in response to "outbound" DNS query packets. >=20 > The way I dealt with this problem was to use the old 0.0.0.0/8 = "unspecified" prefix from the old days before CIDR. These numbers have = never been either global scope or routable. They're pretty much useless = on the wire. I don't see why you'd need an RFC to use them for 464XLAT = purposes. >=20 > --james woodyatt >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Tue Nov 5 11:58: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 35D2921F9BA4 for ; Tue, 5 Nov 2013 11:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.824 X-Spam-Level: X-Spam-Status: No, score=-6.824 tagged_above=-999 required=5 tests=[AWL=3.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwL6yrehBOqG for ; Tue, 5 Nov 2013 11:58:40 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7A421E8097 for ; Tue, 5 Nov 2013 11:58:37 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 664AA2383D9; Tue, 5 Nov 2013 19:58:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CC41D160485; Tue, 5 Nov 2013 20:04:05 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 71201160484; Tue, 5 Nov 2013 20:04:05 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 957B0992B25; Wed, 6 Nov 2013 06:58:18 +1100 (EST) To: George Michaelson From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F090A@nkgeml506-mbx.china.huawei.com> In-reply-to: Your message of "Tue, 05 Nov 2013 11:29:43 -0800." Date: Wed, 06 Nov 2013 06:58:18 +1100 Message-Id: <20131105195818.957B0992B25@rock.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 19:58:45 -0000 In message , George Michaelson writes: > > I tend to SHOULD. you can do what you like, but the consequence of not > doing a local delegation is information leakage. There is no compelling MUST And if you have random address selection you along with random prefix selection you have a 2^114 birthday paradox space. I'll assume the subnet are not random. You have a 2^40 birthday paradox space of a getting sub optimal address selection order. i.e. you will try the ULA before GUA. > On Tue, Nov 5, 2013 at 11:28 AM, Liubing (Leo) wrote: > > > Hi, Jen > > > > I got your comments. I'll consider to revise accordingly. Many thanks > > > > Regards, > > Bing > > > > ________________________________________ > > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Jen > > Linkova [furry13@gmail.com] > > Sent: Tuesday, November 05, 2013 09:50 > > To: v6ops@ietf.org > > Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis > > > > Section 4.2. says that > > " > > > > So when using ULAs in a network, the administrators should clearly > > set the scope of the ULAs and configure ACLs on relevant border > > routers to block them out of the scope. And if internal DNS are > > enabled, the administrators might also need to use internal-only DNS > > names for ULAs. > > " > > I believe it should that that the administrator MUST configure egress > > ACLs on borders routers and MUST ensure that their DNS servers do not > > include ULAs in any responses to external clients. > > > > > > > > > > -- > > SY, Jen Linkova aka Furry > > _______________________________________________ > > 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 > > > > --047d7b33da0a02fb4e04ea730e22 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > >
I tend to SHOULD. you can do what you like, but the conseq= > uence of not doing a local delegation is information leakage. There is no c= > ompelling MUST


quote"> > On Tue, Nov 5, 2013 at 11:28 AM, Liubing (Leo) < f=3D"mailto:leo.liubing@huawei.com" target=3D"_blank">leo.liubing@huawei.co= > m> wrote:
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Hi, Jen
>
> I got your comments. I'll consider to revise accordingly. Many thanks r> >
> Regards,
> Bing
>
> ________________________________________
> From: v6ops-bounces@ietf.org = > [v6ops-bounces@ietf.org] on b= > ehalf of Jen Linkova [furry13@gmail.co= > m]
> > Sent: Tuesday, November 05, 2013 09:50
> To: v6ops@ietf.org
> Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis
>

> Section 4.2. says that
> "
>
> So when using ULAs in a network, the administrators should clearly
> =A0 =A0set the scope of the ULAs and configure ACLs on relevant border
> =A0 =A0routers to block them out of the scope. And if internal DNS are
> =A0 =A0enabled, the administrators might also need to use internal-only DNS= >
> =A0 =A0names for ULAs.
> "
> I believe it should that that the administrator MUST configure egress
> ACLs on borders routers and MUST ensure that their DNS servers do not
> include ULAs in any responses to external clients.
>
>
>
>
> --
> SY, Jen Linkova aka Furry
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> h= > ttps://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> h= > ttps://www.ietf.org/mailman/listinfo/v6ops
>

> > --047d7b33da0a02fb4e04ea730e22-- > > --===============5663455589702191862== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --===============5663455589702191862==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Tue Nov 5 12:12: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 3FFD611E8159 for ; Tue, 5 Nov 2013 12:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLKJq3V9YTZ1 for ; Tue, 5 Nov 2013 12:12:03 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id BFFB411E8190 for ; Tue, 5 Nov 2013 12:12:00 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id e14so15862491iej.36 for ; Tue, 05 Nov 2013 12:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6kifxrQTyUcJpBkcOF0NxaO5JrnTe4253pJqV3weWjE=; b=ec92nlQlk+l0TBHq1Vh/6nhGIwHj1p5KA5l7DjuuSYZL7xqPH48T4ucZ7faA9brRKG keC/hNPbTKD2Gaw6Pd2UyaylslG8ZhR2+U09Oxdv3pRcbxE8+QsrQ3C1/a/H81oVDoin AaB5JsExq18TLYDbhTZHkl/5a5WC6d5m8wbKScPJmG1lhTqPh4adHzqXqqamfWqW0GA4 a8+qeJwS46csLrtDoZ7YyhV9PBItX6SDHRnnAr4wllw7KZ2mlZ+dxpewQhpGTHZ5HdX/ WH0lw+gCYcHW37FzNkYjtfOsXt8tOtAew4NCEnkfuo6ovT8waXAWb8svCdEpGn5OMqra kEOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6kifxrQTyUcJpBkcOF0NxaO5JrnTe4253pJqV3weWjE=; b=dyqgn8lD/+fMUlkAHcO4XBsXFW+KjgP7GlvpUDJpN37GQnri/5OTxwEaIav3q2jbat jrpnQy2kMGoj0H7bjSt9BbpVcvQ9i37dZMxOKdJtKLXBTAKiim+Wiun/c1RwbEp308QA 8mJllYGMfpwvATjR4x/RgANg1RtDqxObghT5ibdIBlslVxd5e7oQjMGy27j4/vD2OKhf 5pDnIRd8USJl7l1d49eiPuDhPu/1JQ9eYtG4zevm7wKXB7aS/eEUpiTOr2VAagHtuYZ5 87Iwp6KJ0FcNkgGQq6xhyxamuIIbxQE+iJfHpUUcUDFfp+4q4CltLhzOfZeUZTQk7LN0 /Esg== X-Gm-Message-State: ALoCoQkfgFEqAISBeR3v1xHaHgM1tKNBGQvd69XawYohc0FSD+q7MHdXUSkt/xlu5OPqCOHhcyMg//excoO0had+lwms68xhZjE1QHFJcorkEqECxvOKa4zoezFAhFGlkyGp7sAZ0TabvJxcx1zoE567S0+vUa0VgM01g5kVHwjrex/7q+V6gre5PYitcXg16R1NaVGajT6L X-Received: by 10.43.178.135 with SMTP id ow7mr2267537icc.43.1383682319743; Tue, 05 Nov 2013 12:11:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Tue, 5 Nov 2013 12:11:39 -0800 (PST) In-Reply-To: References: <29AE8DB910E7704CA043795E00DCBE7803417A05@CL08MBE.rci.rogers.ca> From: Lorenzo Colitti Date: Wed, 6 Nov 2013 05:11:39 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=001a11c30bec27043404ea73a587 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-byrne-v6ops-clatip-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: Tue, 05 Nov 2013 20:12:04 -0000 --001a11c30bec27043404ea73a587 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 2:48 AM, james woodyatt wrote: > The way I dealt with this problem was to use the old 0.0.0.0/8"unspecified" prefix from the old days before CIDR. These numbers have > never been either global scope or routable. They're pretty much useless on > the wire. I don't see why you'd need an RFC to use them for 464XLAT > purposes. > It appears that (at least some) IP stacks don't like 0.0.0.0/8. For example, Linux returns EINVAL if I try to sendto() it (but I can bind to it). So unless you modified the stacks in question, you wouldn't be able to support apps that sent packets to themselves. I know this sounds silly, but unfortunately apps sometimes do silly things, and when you're a compatibility mechanism trying to support legacy apps, you don't really get to refuse to support apps just because they're silly. (For example: Skype wouldn't work if it didn't have a default gateway IP address; if it had a perfectly working point-to-point default route with no default gateway, it decided that it didn't have connectivity. We ended up giving it a default gateway of itself.) --001a11c30bec27043404ea73a587 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 2:48 AM, james woodyatt <jhw@conju= ry.org> wrote:
The= way I dealt with this problem was to use the old 0.0.0.0/8 "unspecified" prefix from the old days before CIDR. These num= bers have never been either global scope or routable. They're pretty mu= ch useless on the wire. I don't see why you'd need an RFC to use th= em for 464XLAT purposes.

It appears that (at least some) IP stacks = don't like 0.0.0.0/8= . For example, Linux returns EINVAL if I try to sendto() it (but I can bind= to it).

So unless you modified the stacks in question, you woul= dn't be able to support apps that sent packets to themselves. I know th= is sounds silly, but unfortunately apps sometimes do silly things, and when= you're a compatibility mechanism trying to support legacy apps, you do= n't really get to refuse to support apps just because they're silly= .

(For example: Skype wouldn't work if it didn't = have a default gateway IP address; if it had a perfectly working point-to-p= oint default route with no default gateway, it decided that it didn't h= ave connectivity. We ended up giving it a default gateway of itself.)
--001a11c30bec27043404ea73a587-- From marka@isc.org Tue Nov 5 12:26: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 5256E11E8196 for ; Tue, 5 Nov 2013 12:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP80zs-BbPph for ; Tue, 5 Nov 2013 12:26:10 -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 0875011E813A for ; Tue, 5 Nov 2013 12:26:01 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7AE4BC948E; Tue, 5 Nov 2013 20:25:46 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1383683159; bh=SxXL31POFNJLqQ8Xe0y+DDWrOiclXmaJB1AekYLkOjQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=AYTIMOWqySTmgkWLaIi+pckycGpOxKi5/QMkbMKaB3u/wgIvZPUCPJCF89vbE0Gbx UOW23j7IWKJ2r2OiD95sOY5lv+p70+sbBvflwoLgNloTA6Mx96tm8gN9PyWbOEl4Zi 9sUpDCNJShUNW0WzV0ec2mObMotIxTpZrFkXNeBI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 5 Nov 2013 20:25:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8669A1603E9; Tue, 5 Nov 2013 20:31:30 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 51A01160363; Tue, 5 Nov 2013 20:31:30 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 03603992E6A; Wed, 6 Nov 2013 07:25:43 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <1383679978.91401.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-reply-to: Your message of "Wed, 06 Nov 2013 04:37:21 +0900." Date: Wed, 06 Nov 2013 07:25:43 +1100 Message-Id: <20131105202544.03603992E6A@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis 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, 05 Nov 2013 20:26:18 -0000 In message , Lorenzo Colitti writes: > On Wed, Nov 6, 2013 at 4:32 AM, Mark ZZZ Smith wro > te: > > > Happier Eyeballs > > http://tools.ietf.org/html/draft-baker-happier-eyeballs-00.html > > > Great. We can't be bothered to get things right in the network, so we just > tell hosts to try everything all the time in the hope that something will > work. While devices should return unreachables we all know that there are error conditions where that does not happen even when they are configured to do so. If you have multihomed servers then the clients should be failing over faster than they tradionally have. We spend BILLIONS dealing with clients that do not fall over fast enough. > It's very easy to say "we should just have smarter algorithms", especially > if we expect that someone other than ourselves will be writing those > algorithms, but I have yet to see a proposal that's sanely implementable, > high performance, and low load (even considering the fact that you'd have > to completely overhaul the socket API and app the apps using it before you > could deploy it). You can have fast failover using the current socket APIs. For TCP is is relatively trivial, just use a non-blocking connect call. For UDP it is a little harder but not impossible. DNS servers have been dealing with multihomed services for decades. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From markzzzsmith@yahoo.com.au Tue Nov 5 12:27: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 A15DF11E813A for ; Tue, 5 Nov 2013 12:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZLm69LTZrSP for ; Tue, 5 Nov 2013 12:26:52 -0800 (PST) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id B428F11E81C3 for ; Tue, 5 Nov 2013 12:26:48 -0800 (PST) Received: from [66.196.81.173] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 20:26:47 -0000 Received: from [98.139.212.210] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 20:26:47 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 20:26:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 392454.3927.bm@omp1019.mail.bf1.yahoo.com Received: (qmail 49612 invoked by uid 60001); 5 Nov 2013 20:26:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383683207; bh=+cuoI5WwI+lvF4wakq0YjLew90nRwDixPqcz/CxhyTY=; 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=6vnu2ZGUuIJS2+fRenCR8mH6hqoc3Bgo733oVMQRku+zgY9jEC0zNxV5vdeZcViBC46ZK53bB0neiUq8bL4iycTfKHmfN5c0urPPxT1CrUd8dHDfpRZWwhZP1qgvz1gQsVnASPklDMZ9k8RpNSA0ZgdwfSQGq3HAueum+H6myec= 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=NT+g5CXLHl14kD+ONu7yXnIDDtNc3DGkm8K/dNXxEhUsQIkqh6pTQiT6FozQKo87taFcQuH8S0rHMaRAFCPc8zgHJqKZJiGxeqcg2XTSMJ+B0XHF6uQ0ujCG+YRdIXCiqtXIGfU8IMkSj8LTv/zFjHXm5x8sbrrV19ozGwfQbaE=; X-YMail-OSG: 0gpv5QsVM1mvSVJXiw_odNHtWMDu41S6HbTApTZMMcDVLIE RuosFRNyONWAOqKJUOgxhgdt1WELLliSesM6JuvCuEtphwvqvCTI34jB97RQ 24m5T0LeTvNguB.8EWu385xrOeDM5e09M8mDVjLQl7dnUd467LkktUCgRwuu ZqSydvWGtltfcepBVMyKThK8eBnv0MbxIdX4lrWOwJhL2WOgu4nIvehBs2ZF xqzEeKhvKTxIEqkSKLEJhCDXlf_s0s_9cyZmfULIUKaq.Q6nu9LONoQujbTO 1iTbqxpL26nekoaWB.e4m0TJoybQyvP_NXigLN6VzCyXlZt.vEl0h5.eWght jbPzJYuE9HCSdcGwi8NuePF2n5CMiPhy8hIo.qUCABJtgy8h8X3a1pqqWnEc 8L1MxXxhr86Fmh7aY13o_NF0XGn.6XP7POZSwrwMwJCCi3T6gVNNUZ5MCg2u UIt8yar3.A9J8OGKBs.7LHVgSvaxMk84S3X54rf9siqpO7XG9DHdXVsAigGw VyfPqut8XBUHwA4hNhMSssv0GFIR.dNnzTTFg86.QawY4QjUrYpNC0hpw.Rv psuyULThm91.qoxA_.nr9ETBIYvLshtqfSvh9SomcjKEVjg-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 05 Nov 2013 12:26:47 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4gCj5DYzogQ2hyaXN0b3BoZXIgUGFsbWVyIDxDaHJpc3RvcGhlci5QYWxtZXJAbWljcm9zb2Z0LmNvbT47IFRpbSBDaG93biA8dGpjQGVjcy5zb3Rvbi5hYy51az47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFdlZG5lc2RheSwgNiBOb3ZlbWJlciABMAEBAQE- X-Mailer: YahooMailWebService/0.8.161.596 References: <1383679978.91401.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1383683207.49081.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 5 Nov 2013 12:26:47 -0800 (PST) From: Mark ZZZ Smith To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:27:00 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Mark ZZZ Smith =0A>= Cc: Christopher Palmer ; Tim Chown ; "v6ops@ietf.org" =0A>Sent: Wednesday, 6 N= ovember 2013 6:37 AM=0A>Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops= -ula-usage-analysis=0A> =0A>=0A>=0A>On Wed, Nov 6, 2013 at 4:32 AM, Mark ZZ= Z Smith wrote:=0A>=0A>Happier Eyeballs=0A>>http= ://tools.ietf.org/html/draft-baker-happier-eyeballs-00.html=0A>=0A>=0A>Grea= t. We can't be bothered to get things right in the network, so we just tell= hosts to try everything all the time in the hope that something will work.= =0A>=0A=0ANetworks can lose packets, regardless of whether they're IPv4 or = IPv6.=0A=0AI don't think the problem happy eyeballs is solving isn't really= any different to the problem where multiple IPv4 A records are returned an= d a client has to walk through them until it succeeds. Fortunately that see= ms to be reliable enough that end users don't have to wait for connection t= imeouts as the returned list of A records is walked through. But if they we= re (are?) waiting, then happy-eyeballs for only IPv4 would also be benefici= al.=0A=0AThe happy eyeballs technique could be considered to be another for= m of retransmission to recover from packet loss. A host has to recover from= packet loss whether it is within a single protocol, or across multiple one= s used by and for the same application.=0A=0A>=0A>It's very easy to say "we= should just have smarter algorithms", especially if we expect that someone= other than ourselves will be writing those algorithms, but I have yet to s= ee a proposal that's sanely implementable, high performance, and low load (= even considering the fact that you'd have to completely overhaul the socket= API and app the apps using it before you could deploy it).=0A>=0A=0AI thin= k Multipath TCP fills that gap, as it is transparent to applications, unles= s they start directly dealing with IPv4/IPv6 addresses. I think the combina= tion of Multipath TCP and happy-eyeballs at initial MPTCP connection establ= ishment (to bring up multiple subflows concurrently) would be even better.= =0A=0ARegards,=0AMark.=0A From fred@cisco.com Tue Nov 5 13:56: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 5DE0E21E80D1 for ; Tue, 5 Nov 2013 13:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.424 X-Spam-Level: X-Spam-Status: No, score=-109.424 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSCpenm24mcK for ; Tue, 5 Nov 2013 13:56:15 -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 7922511E80E3 for ; Tue, 5 Nov 2013 13:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=774; q=dns/txt; s=iport; t=1383688575; x=1384898175; h=from:to:cc:subject:date:message-id:mime-version; bh=8Ri5qhBMCseFtludzuEthyjmY9KPICJn9yNuJd40H+s=; b=fPU6a0giec6pyjzDNz2UtQf7HTzUWcUffak1zvVxKks8vFAesNAAaagE ttOgIDMwe+Hd5AsBAfuQ/i/2/JeNVCySvRwD5hDsJmYTshykeRUYV2UXF nmgn8lOvm87krW0EJvcqonNNwSKhameR8hoIl3ajVEpeg90d0oayyIHhg 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuNgAE9oeVKtJXG9/2dsb2JhbABZgwc4U69xhBOLQ4EsFnAEgix5EgGBACcEDhOHcw2+eI9ZgyeBDwOQLoEwhiySCYMmgio X-IronPort-AV: E=Sophos;i="4.93,641,1378857600"; d="asc'?scan'208";a="281090880" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2013 21:56:15 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA5LuDfZ012873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 21:56:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 15:56:13 -0600 From: "Fred Baker (fred)" To: Cameron Byrne Thread-Topic: Congratulations! Thread-Index: AQHO2nHXcTHseWpNUkWfQHuV5SxZPQ== Date: Tue, 5 Nov 2013 21:56:12 +0000 Message-ID: <6F1F01DE-165D-4414-AD2D-D85055BE8EC2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.25] Content-Type: multipart/signed; boundary="Apple-Mail=_6EFF9F2B-2248-4C58-BDB4-ED92D00044CD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: [v6ops] Congratulations! 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, 05 Nov 2013 21:56:25 -0000 --Apple-Mail=_6EFF9F2B-2248-4C58-BDB4-ED92D00044CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttp://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Dev= ices-126506 --Apple-Mail=_6EFF9F2B-2248-4C58-BDB4-ED92D00044CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSeWl7bjEdbHIsm0MRAolgAJ4yXyc2/5KUF7ubxQx1cIorGEEYrwCg5/KW XGzCRDXXFdkv+sxT8omdLo8= =zq3q -----END PGP SIGNATURE----- --Apple-Mail=_6EFF9F2B-2248-4C58-BDB4-ED92D00044CD-- From phdgang@gmail.com Tue Nov 5 14:41: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 E330A11E8123 for ; Tue, 5 Nov 2013 14:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIjx39mAv-zP for ; Tue, 5 Nov 2013 14:41:27 -0800 (PST) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id E0B9F21F9D35 for ; Tue, 5 Nov 2013 14:41:26 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id 1so5565232qec.27 for ; Tue, 05 Nov 2013 14:41:26 -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=HKkcSRgnOCsTM9ijAqxEyFO5srQ17bfCon1gC3zrBiY=; b=cqwP/s+5qhlczJYMxYynGfM/t5uIbgXCC2bd9iWmqDjCBYpNzo9dpkEg87zSzpI+yz Wj/HcsMa5z9V5m7VwemZpauFbiGpSm8ROBrDpeacypwSDooG6T77FkSYHYbzRftWmocz Z0v92DUa1XELwOJtH8hbVO2tzVz85WufzAXamLF2cX83KFNNTT1FaphvTpXUAAtCtSGW mXt5/G0yFK2ciEK1OFvfNkT/4sjr/qVpS2fVnv8kb93K3lCGK0+pqdKo1THE9S/nV+dt 0VINKLGi/K1FfZ0vSXc0EvUCLGjm/dv1BJbnPZGJRnNfIYCf+U1DWC+mDX5QrgSvgKes 2cbw== MIME-Version: 1.0 X-Received: by 10.224.57.142 with SMTP id c14mr1299407qah.120.1383691286372; Tue, 05 Nov 2013 14:41:26 -0800 (PST) Received: by 10.224.172.135 with HTTP; Tue, 5 Nov 2013 14:41:26 -0800 (PST) In-Reply-To: References: <20131104174259.10097.28929.idtracker@ietfa.amsl.com> Date: Wed, 6 Nov 2013 06:41:26 +0800 Message-ID: From: GangChen To: "cb.list6" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , "" Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-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: Tue, 05 Nov 2013 22:41:28 -0000 Hi Cameron, 2013/11/6, cb.list6 : > Folks, > > As a listed author, i am sorry for not having reviewed this document > prior to publication. I probably should not be on the author list for > this reason :) > > Nonetheless, this is a VERY important topic. > > First, regarding the draft. Failure case #5 does not exist since a > home routed PDP terminates on the home network GGSN so the visited > network does not need to deploy NAT64/DNS64. The roaming user is only > exposed to the home NAT64/DNS64 and all IP packets are GTP tunneled to > the home. The case#5 is mainly for intra-PLMN mobility. It's not the international case. That is also the case in our network when deploy 464xlat. We set APN-OI-Replacement flag, so the visited network would direct traffic to local GW. The intra-PLMN mobility case is described in the draft. I will highlight this condition both in the draft and slides. > Second, i do not recommend anyone attempt dual-stack (v4v6) 3GPP > roaming. I am convinced that it is so broken that it may take more > than 5 years to fix. Essentially, we need to wait of broken gear run > by disinterested networks to simply cycle out. In fact, the 3GPP > roaming and home serving architectures are so entwined, that i cannot > deploy dual-stack in a 3GPP home network because this will result in > all subscribers to fail for all access attempts in these flawed > roaming partner networks. This is not acceptable to the business. > It is truly a terrible situation where a roaming partner's flawed > deployment inhibits my ability to do dual-stack in my own network. That is covered in case#1. Best Regards Gang > That said, there is only one path that i know of to thread this > needle. If a mobile network operator wants to deploy IPv6 and NOT > break roaming, the mobile network operator MUST deploy an IPv6-only > solution in the home network (such as RFC6877 / 464XLAT) AND require > the phone / UE to request _IPv6-only while at home_ AND _IPv4-only > while roaming_. The fundamental issue is that widely deployed gear > fails to handle v4v6 permissions correctly, and the mere presence of > this permission causes the user to fail to access anything at all. > > I know 464XLAT at 3GPP home and IPv4-only while roaming works, because > i have deployed this. I know that i can NOT deploy v4v6 because i > deployed that too, and had to roll it back when customers started > failing. > > CB > > On Mon, Nov 4, 2013 at 9:50 AM, GangChen wrote: >> Wg, >> >> We submit the new draft of IPv6 roaming. Please kindly check. >> Your comments are appreciated >> >> BRs >> >> Gang >> >> 2013/11/5, internet-drafts@ietf.org : >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : IPv6 Roaming Behavior Analysis >>> Author(s) : Gang Chen >>> Hui Deng >>> Dave Michaud >>> Jouni Korhonen >>> Mohamed Boucadair >>> Vizdal Ales >>> Cameron Byrne >>> Filename : draft-chen-v6ops-ipv6-roaming-analysis-02.txt >>> Pages : 12 >>> Date : 2013-11-04 >>> >>> Abstract: >>> This document intends to enumerate failure cases when a IPv6 >>> subscriber roams into visited network areas. The investigations on >>> those failed cases reveal the causes in order to notice improper >>> configurations, equipment's incomplete functions or inconsistent IPv6 >>> strategy. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-roaming-analysis >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-chen-v6ops-ipv6-roaming-analysis-02 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 cb.list6@gmail.com Tue Nov 5 14: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 C876E21F9C53 for ; Tue, 5 Nov 2013 14:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB2Ez+HIhU1G for ; Tue, 5 Nov 2013 14:47:25 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6484421E80D5 for ; Tue, 5 Nov 2013 14:45:09 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id b13so3613497wgh.0 for ; Tue, 05 Nov 2013 14:44:09 -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=TGNHlPcwbMyK90Ix5OTLV8/yLdrM5SvCq0u3MU1kEt4=; b=Swr6jo4ytl2GPqMwhZ7OOhKR3COiyiz25NmF9+GEuuw3F9yxevbX30v2k2AsTjeE9c pT7oWMorLhPSJSZ2b+VjImkyuG4H8h9nWXTCfuXWawZcCDyYX33Wrn4h4iQf4xehImri TNOPxzGxX8a/9VdE+MPkfh3vFYhztJi239VO8RFSxDqhbkzz9SnROGPVQ+Ju5nKwIbIY KQuO68FznOGqON6I/MQjOTofgWAtRKbHQn8Qt+Lcmy1fa18z5hrNdNwQoSCMvgGZWt2h /yk80SQKa+u7P8L5wSWtQvEMI1KdOmdmlXxhjLCU03dql4p7kubPXAocN4rIl5lPUUEf dz8g== MIME-Version: 1.0 X-Received: by 10.194.175.66 with SMTP id by2mr105987wjc.59.1383691449447; Tue, 05 Nov 2013 14:44:09 -0800 (PST) Received: by 10.216.99.68 with HTTP; Tue, 5 Nov 2013 14:44:09 -0800 (PST) Received: by 10.216.99.68 with HTTP; Tue, 5 Nov 2013 14:44:09 -0800 (PST) In-Reply-To: <6F1F01DE-165D-4414-AD2D-D85055BE8EC2@cisco.com> References: <6F1F01DE-165D-4414-AD2D-D85055BE8EC2@cisco.com> Date: Tue, 5 Nov 2013 14:44:09 -0800 Message-ID: From: "cb.list6" To: Fred Baker Content-Type: multipart/alternative; boundary=089e013d19f852bc0904ea75c51a Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Congratulations! 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, 05 Nov 2013 22:47:26 -0000 --089e013d19f852bc0904ea75c51a Content-Type: text/plain; charset=ISO-8859-1 On Nov 5, 2013 1:56 PM, "Fred Baker (fred)" wrote: > > http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506 > > Congrats indeed to the v6ops WG. RFC6877 is your work product and it is shipping. I feel very fortunate to be able to work with an open and global standards body that helps me get my work done in my network while also sharing and learning with such a talented and driven group of engineers. The link talks about android 4.4, the untold story is that we shipped RFC6877 as default a month back on the Samsung Galaxy Note 3 with Android 4.3. So far, it just works. Several more new models of Android phones will also ship as 464XLAT default this year. My hope is that other mobile operating systems will see this model as a good path forward. Cameron Byrne T-Mobile US > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e013d19f852bc0904ea75c51a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 5, 2013 1:56 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
>
> http://www.dslreports.com/shownews/TMobile-Goe= s-IPv6-Only-on-Android-44-Devices-126506
>
>

Congrats indeed to the v6ops WG.=A0 RFC6877 is your work pro= duct and it is shipping.=A0

I feel very fortunate to be able to work with an open and gl= obal standards body that helps me get my work done in my network while also= sharing and learning with such a talented and driven group of engineers.

The link talks about android 4.4, the untold story is that w= e shipped RFC6877 as default a=A0month back on the Samsung Galaxy Note 3 wi= th Android 4.3.=A0 So far, it just works.=A0 Several more new models of And= roid phones will also ship as 464XLAT default this year.

My hope is that other mobile operating systems will see this= model as a good path forward.=A0

Cameron Byrne
T-Mobile US

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

--089e013d19f852bc0904ea75c51a-- From wwwrun@rfc-editor.org Tue Nov 5 17:34: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 DA20021E81AF; Tue, 5 Nov 2013 17:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiBI-k3eBnbA; Tue, 5 Nov 2013 17:34:02 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C825E21E81C3; Tue, 5 Nov 2013 17:33:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 263D775E001; Tue, 5 Nov 2013 17:24:27 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131106012427.263D775E001@rfc-editor.org> Date: Tue, 5 Nov 2013 17:24:27 -0800 (PST) Cc: drafts-update-ref@iana.org, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7066 on IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts 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, 06 Nov 2013 01:34:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7066 Title: IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts Author: J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan Status: Informational Stream: IETF Date: November 2013 Mailbox: jouni.nospam@gmail.com, jari.arkko@piuha.net, teemu.savolainen@nokia.com, suresh.krishnan@ericsson.com Pages: 20 Characters: 44253 Obsoletes: RFC3316 I-D Tag: draft-ietf-v6ops-rfc3316bis-06.txt URL: http://www.rfc-editor.org/rfc/rfc7066.txt As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From furry13@gmail.com Tue Nov 5 17:55: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 CCE9B21E815D for ; Tue, 5 Nov 2013 17:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h52ZMX7syt-1 for ; Tue, 5 Nov 2013 17:55:54 -0800 (PST) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D69E521E8113 for ; Tue, 5 Nov 2013 17:55:47 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id s14so5566349qeb.5 for ; Tue, 05 Nov 2013 17:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0NU6xeQc2SF5peRY+jdRKrJOUmPy60QX9f5ZE7a0xRk=; b=uLMol/5SvUkFgQxAXUZxFvU1Gaehv9nhmgzBCRmoxUVBazKfguBjBpL3yUdm9vX4sp G0/MtRyls5taGqWND6zO9QnyR4oHcpdr5bQoqvspdViq10PSwy21RI/5BpKrHkYCDBPF mExBru/10Yxhc9/t6vaGPVBDywoFj0KuX11VQA9sj3csWPZPOYlmEgAbjmhiefsIGe/d IuIuvQtQE1HUGZ1yHi3fYkt/aRsAGrIp6Es1YxVYRBjcKFUOVotcJTJuo07TEdFcmX7k e8MhFYg+3IVACLGDpno20WVCQbZDG5IhErwfhNvJG/XR9C8JEfJmRnCe5LcFlSWhYiu7 7YPA== X-Received: by 10.224.14.79 with SMTP id f15mr2234010qaa.113.1383702947354; Tue, 05 Nov 2013 17:55:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Tue, 5 Nov 2013 17:55:27 -0800 (PST) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F090A@nkgeml506-mbx.china.huawei.com> From: Jen Linkova Date: Wed, 6 Nov 2013 02:55:27 +0100 Message-ID: To: George Michaelson Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 06 Nov 2013 01:55:56 -0000 On Tue, Nov 5, 2013 at 8:29 PM, George Michaelson wrote: > I tend to SHOULD. you can do what you like, but the consequence of not doing > a local delegation is information leakage. There is no compelling MUST Thanks for your comment, George! After thinking about it for a while and checking RFC4193 I stand corrected: it should be 'SHOULD' in both cases. > > > On Tue, Nov 5, 2013 at 11:28 AM, Liubing (Leo) > wrote: >> >> Hi, Jen >> >> I got your comments. I'll consider to revise accordingly. Many thanks >> >> Regards, >> Bing >> >> ________________________________________ >> From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Jen >> Linkova [furry13@gmail.com] >> Sent: Tuesday, November 05, 2013 09:50 >> To: v6ops@ietf.org >> Subject: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis >> >> Section 4.2. says that >> " >> >> So when using ULAs in a network, the administrators should clearly >> set the scope of the ULAs and configure ACLs on relevant border >> routers to block them out of the scope. And if internal DNS are >> enabled, the administrators might also need to use internal-only DNS >> names for ULAs. >> " >> I believe it should that that the administrator MUST configure egress >> ACLs on borders routers and MUST ensure that their DNS servers do not >> include ULAs in any responses to external clients. >> >> >> >> >> -- >> SY, Jen Linkova aka Furry >> _______________________________________________ >> 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 > > -- SY, Jen Linkova aka Furry From furry13@gmail.com Tue Nov 5 18:17: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 BD70A11E81D3 for ; Tue, 5 Nov 2013 18:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zJPNCxl5iXn for ; Tue, 5 Nov 2013 18:17:13 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 578EC11E81C6 for ; Tue, 5 Nov 2013 18:17:10 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id ii20so1116329qab.8 for ; Tue, 05 Nov 2013 18:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=r/4ZJcw0GRGaNQm3vkXyj+iTZL2O2IBgQI5w/anxEd4=; b=KcXmxJqR3QbsmRWmeXx+/0JxKa7utYO2ttXYiEre7hU2GXJTkEINYkyQVVKWH1i0IM OTGUD6lOpTWZYG/CTo3DqXV/L32GiEFnBxFxpSAHPIS+xTGE7wNIEEQkoDWFCE/vhYL0 v7tS5MvQikHUQBrh2jvhJx8a8nOYeorkEPYa/IA1tWUqGYqAnSpsT4AB57q07ZhNu9XC jM4SZJPLNeS2koQvv9HN9Z8c0WgLnt81xwuSC+p9PIt/JrrUfGrm+IKO1y7poDgGZH4i EN9UKILuNGfgGRfAn8v17kkGrhgPeC1Xg8j7KTT2m2TjawuLdngwwIpDDbTninkfZblQ bNcw== X-Received: by 10.224.14.79 with SMTP id f15mr2356542qaa.113.1383704227882; Tue, 05 Nov 2013 18:17:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Tue, 5 Nov 2013 18:16:47 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F090A@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F090A@nkgeml506-mbx.china.huawei.com> From: Jen Linkova Date: Wed, 6 Nov 2013 03:16:47 +0100 Message-ID: To: "Liubing (Leo)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 06 Nov 2013 02:17:13 -0000 On Tue, Nov 5, 2013 at 8:28 PM, Liubing (Leo) wrote: > I got your comments. I'll consider to revise accordingly. Many thanks Few more comments if you don't mind: 1) Section 3.1. Isolated network " - Prefix generation: Randomly generated according to the algorithms defined in [RFC4193] or literally assigned by human. Normally, it is recommended to following the standard way to automatically generate the prefixes; if there are some specific reasons that need to be assigned by human, the administrators must carefully plan the prefixes to avoid collision." As Erik pointed out this Monday, "recommended" violates RFC4193. In addition, I'm not sure why you are mentioning prefix generation in "Isolated network' section only while it is applicable for all scenarios. Maybe it should be moved to the section 4 "General Guidelines" 2) 3.3. IPv4 Co-existence consideration Looks like it is being discussed in another thread already - I think you might mention 'sending ICMPv6 message back' and 'not having default route' as options to prevent the issue. 3) 4. General Guidelines of using ULA It would be great to emphasize the importance of randomness and of having L bit set so fd00 prefix will be used, not fc00:: Probably (as you mentioning DNS and ACL) it might make sense to refer to Section 4 of RFC4193 which contains some guidelines as well. Question: you do not mention VPN usage at all. Such use case is described in RFC4193 but do you think it might be useful to mention it at least? === One typo: "2.3. Independent address space ULA provides an internal address independence capability in IPv6ULA can be used for internal communications without having any permanent or only intermittent Internet connectivity." s/IPv6ULA/IPv6. ULA/ From tore@fud.no Wed Nov 6 00:08: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 B7EE211E8176 for ; Wed, 6 Nov 2013 00:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGocxdrFvd+o for ; Wed, 6 Nov 2013 00:08:37 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id E56B611E8171 for ; Wed, 6 Nov 2013 00:08:29 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=43570 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VdyA6-0008M4-SG; Wed, 06 Nov 2013 09:08:26 +0100 Message-ID: <5279F8FA.5050206@fud.no> Date: Wed, 06 Nov 2013 09:08:26 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "cb.list6" , GangChen References: <20131104174259.10097.28929.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: v6ops , "" Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-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, 06 Nov 2013 08:08:37 -0000 * cb.list6 > First, regarding the draft. Failure case #5 does not exist since a > home routed PDP terminates on the home network GGSN so the visited > network does not need to deploy NAT64/DNS64. The roaming user is only > exposed to the home NAT64/DNS64 and all IP packets are GTP tunneled to > the home. My experience agrees. This also applies to failure case 4, which says «Roaming to IPv4-only networks with IPv6 PDP/PDN request would fail to get addresses.» > Second, i do not recommend anyone attempt dual-stack (v4v6) 3GPP > roaming. I am convinced that it is so broken that it may take more > than 5 years to fix. [...] > > That said, there is only one path that i know of to thread this > needle. If a mobile network operator wants to deploy IPv6 and NOT > break roaming, the mobile network operator MUST deploy an IPv6-only > solution in the home network (such as RFC6877 / 464XLAT) AND require > the phone / UE to request _IPv6-only while at home_ AND _IPv4-only > while roaming_. The fundamental issue is that widely deployed gear > fails to handle v4v6 permissions correctly, and the mere presence of > this permission causes the user to fail to access anything at all. I feel that there is is a gap in this analysis. You say IPv4v6 roaming is broken - ok, I'll accept that as fact. However, you do not explain how this leads to a requirement for the UE to request IPv4-only while roaming (as opposed to simply doing IPv6-only + RFC6877 exactly like when in the home network). Indeed, the draft calls out IPv6-only roaming as a working approach: In Table 1, all variants of IPv6-only UE request (with or without 464xlat) are noted as "OK" in the home routed case, regardless of visited network capability. > I know 464XLAT at 3GPP home and IPv4-only while roaming works, because > i have deployed this. I know that i can NOT deploy v4v6 because i > deployed that too, and had to roll it back when customers started > failing. I know IPv6-only roaming works too, since I've been doing just that for a couple of years already and, well, in my experience it Just Works, regardless of the visited network's IPv6 capabilities (which are usually non-existent). If the draft ends up recommending against the UE requesting IPv6-only (with or without 464xlat) while roaming, I believe it needs to discuss why in much more detail. (For what it's worth, doing IPv4-only while roaming would significantly reduce my exposure to IPv6 connectivity, as I frequently roam onto the incumbent's PLMN because my own home PLMN doesn't have nation-wide coverage. The incumbent doesn't support IPv6 for their own subscribers, but it works just fine for me when roaming, thanks to the GTP magic.) Tore From nick.heatley@ee.co.uk Wed Nov 6 05:38: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 8C08811E81DE for ; Wed, 6 Nov 2013 05:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74HWIJr9dkQt for ; Wed, 6 Nov 2013 05:38:53 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6250211E81A9 for ; Wed, 6 Nov 2013 05:38:51 -0800 (PST) Received: from [85.158.136.3:4264] by server-6.bemta-5.messagelabs.com id E7/D3-04949-A664A725; Wed, 06 Nov 2013 13:38:50 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-16.tower-123.messagelabs.com!1383745128!35950450!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17712 invoked from network); 6 Nov 2013 13:38:48 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-16.tower-123.messagelabs.com with SMTP; 6 Nov 2013 13:38:48 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Wed, 06 Nov 2013 13:44:08 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.02.0318.004; Wed, 6 Nov 2013 13:38:47 +0000 From: "Heatley, Nick" To: GangChen , v6ops Thread-Topic: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-02.txt Thread-Index: AQHO2YZ77aGIDBHpI0aKReOiW5MEqJoWaY9A Date: Wed, 6 Nov 2013 13:38:47 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303A1250C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20131104174259.10097.28929.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-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, 06 Nov 2013 13:38:59 -0000 Hi there Gang, A useful draft thank you. Some comments that, from my perspective, would make the content clearer. = By all means take them or leave them :-)) Section 3 -Defining "failure" in this draft - in general I infer fallback is a succ= ess -so you could adapt the middle sentences: >There may be a mismatch between the subscriber request and network capab= ility. In 3GPP networks a mismatch between the UE request and the bearer = network could result in bearer negotiation and a fallback to a common bea= rer type. The failures here can be a result of no common bearer type exis= ting and the UE is left disconnected. Or in the case of local breakout a = failure could result from network functionality that is assumed by the UE= =20configuration being absent in the visited network. The following table= =20lists the potential failure cases. Section3 - Table1 - I would prefer to say that the UEs request IPv4v6, rather than dual sta= ck. That is also what you have defined at the start of section 3. - I would prefer to see two tables in this section, one covering Home rou= ting and one covering local breakout, because of the following specific c= omments - Do you need to define what you mean by Dual Stack for the "Visited Netw= ork Capability"? I am wondering, in the case of Home routing, if "Visited= =20Network Capability" is better expressed as "PDN/PDP IP Type permitted"= ? Then "dual stack" could become "all PDN/PDP IP types"? What do you thin= k?=20 Either way "dual stack" may leave some ambiguity to some readers not fami= liar with 3GPP networks here (especially as the terms appears in section = 4.2. in association with separate single-IP-type PDP). - The failure cases are potential failure cases - for the home routing ta= ble, I would like to see a middle column which describes "success" whethe= r request is granted or a suitable fallback, as would be expected when vi= sited networks are ready e.g. In an IPv4-only capable visited network, th= e terminal can request IPv4v6 and be downgraded to IPv4 PDP. I'd like to = see all possible cases listed then, for example adding IPv4v6 request to = "Dual Stack" visited network. If adding such a column is undesirable, the= n at least stressing that there is a *risk* of these failure cases, they = are not an architectural certainty. - So the current columns capturing failures could be labelled "potential = failure cases (Home Routing)" -Where there are no possible failure cases identified then "None" could r= eplace "OK" -To be clear I'd change"IPv6-only with 464xlat" to "IPv6-only (where UE i= s 464xlat enabled)" or similar. As this case is only highlighted for loca= l breakout, then I'd not list it in the Home Routing table. Section 4 - Would it make sense to keep section 4 as the "problem definition" text = and split out the "mitigations" text? I am thinking some of the mitigatio= ns will mitigate more than one failure case? Section4.2 -I am not clear whether failure case 2 is a failure or just a warning of = knock-on effects? What is recommended at the home network or the visited = network? Would the approach of roaming profiles in HSS of section 4.1. also help h= ere? Etc. Section4.3. >Since IMS roaming architecture will offload all traffic in the visited n= etwork -Is this mandatory in all cases? I would suggest: >In the IMS roaming architecture when traffic is offloaded in the visited= =20network.... The next sections I must admit I found difficult - it may be my lack of u= nderstanding so apologies if so! I assume you are trying to cover local breakout for both Data and IMS Voi= ce use cases. Section4.4. -I am confused why this failure is not also applied to Home routing i.e. = if visited network permits only IPv4 PDP? Now I am wondering whether I understood the authors' intentions for "Visi= ted Network Capability" column, if this is not a potential failure for Ho= me Routing? For local breakout do you mean specifically that the local breakout path = at and beyond the GGSN /PGW is "IPv4-only" though the SGSN/SGW may allow = all PDP/PDN types? I would split out local breakout case into a table2, so the appropriate c= olumns can be created and labelled. Section 4.5 - So this is a local breakout issue where local DNS/NAT functionality is = to be used? -However, looking back at the table, a 464xlat capable UE could start by = requesting IPv4v6, receive an IPv6 PDP, and try to invoke the CLAT functi= onality, could it not?=20 So then it can go on to have the problems of case5. The bearer requested = by the UE seems less relevant. Perhaps there are extra parameters assumed= =20in the Local Breakout scenarios that I am missing e.g. the local break= out APN settings?; something more relevant to the case than what "UE requ= ests"? I am not so familiar with all the local break out scenarios, but I= =20would again suggest a separate table 2 for local breakout so that we c= an link the scenarios appropriately. - Is the AAA server a solution for local breakout? I thought this was des= cribed by Dave as a Home Routing solution? The text is reasonable, just n= ot sure why it appears specifically in this section? I hope this is useful. Best Regards, Nick Heatley -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= =20GangChen Sent: 04 November 2013 17:50 To: v6ops Cc: Subject: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-02.tx= t Wg, We submit the new draft of IPv6 roaming. Please kindly check. Your comments are appreciated BRs Gang 2013/11/5, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > > Title : IPv6 Roaming Behavior Analysis > Author(s) : Gang Chen > Hui Deng > Dave Michaud > Jouni Korhonen > Mohamed Boucadair > Vizdal Ales > Cameron Byrne > Filename : draft-chen-v6ops-ipv6-roaming-analysis-02.txt > Pages : 12 > Date : 2013-11-04 > > Abstract: > This document intends to enumerate failure cases when a IPv6 > subscriber roams into visited network areas. The investigations on > those failed cases reveal the causes in order to notice improper > configurations, equipment's incomplete functions or inconsistent IPv= 6 > strategy. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-roaming-analysi > s > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-v6ops-ipv6-roaming-analys= i > s-02 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW From Lee@asgard.org Wed Nov 6 07:42: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 C453A21F9DC9 for ; Wed, 6 Nov 2013 07:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j+bHM2UA6yX for ; Wed, 6 Nov 2013 07:42:38 -0800 (PST) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.57]) by ietfa.amsl.com (Postfix) with ESMTP id 121B821E8127 for ; Wed, 6 Nov 2013 07:42:35 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id rA6FgZmb018462 for ; Wed, 6 Nov 2013 10:42:35 -0500 Received: (qmail 20740 invoked by uid 0); 6 Nov 2013 15:42:35 -0000 X-TCPREMOTEIP: 208.181.207.235 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?208.181.207.235?) (lee@asgard.org@208.181.207.235) by 0 with ESMTPA; 6 Nov 2013 15:42:34 -0000 User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 05 Nov 2013 18:38:57 +0200 From: Lee Howard To: "'IPv6 Operations'" Message-ID: Thread-Topic: review of draft-ietf-v6ops-ula-usage-recommendations-01 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [v6ops] review of draft-ietf-v6ops-ula-usage-recommendations-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: Wed, 06 Nov 2013 15:42:43 -0000 I confess, I skipped to Section 3, "Enumeration of Scenarios Using ULAs" I'd like some qualification on this sentence:"And since ULA support multiple subnets, it is scalable." ULA scales to /48, which is admittedly pretty good, but isn't what I think of when I describe something as "scalable." Unless you mean multiple ULA prefixes, but I don't think that's what you're describing here; more on routing in a minute. "The global uniqueness of prefixes is not guaranteed, however, the probability is extremely low" Actually, the probability (of uniqueness) is extremely high. The probability of collision is low. The "Prefix Announcement" section is a problem. You want to say that ULAs can be freely routed between networks, but that has significant technical issues: * As you point out, you could extend RAs. Unless that's done, this is actually a drawback to ULAs. * Scaling is limited, again, to however many route entries devices can handle. * And all the problems of an ad hoc, non-hierarchical networks. Home network: I understand the use case described, though it's worth repeating that ULA fits between LLA and GUA; in other words, only provides a benefit for a multiple-segment home network. There may be other issues in the home network, still being discovered by Homenet, like source selection for service advertsiements, and naming. I like the use of ULA for an enterprise's management network. There's also the consideration (raised in the NAT64-experience draft) that a dual-stack node with IPv4, GUA and ULA may get confused about source address selection. Especially in the renumbering case; IPv6 connectivity works, but IPv4 will be used in preference to ULA. . . There's another consideration in 3.2.2, ULA+GUA: if you run forward DNS, you may need a split DNS, where depending on where the query comes from (inside or outside) you return a ULA or GUA. You might just use GUAs for everything that is externally available, or you might have different policies depending on whether you use the GUA or ULA (for instance, internal vs external firewall policy). You do mention this later in 4.2. There are several places where the address selection problem is mentioned, and there's a suggestion to configure policy to force the desired behavior. This may be possible in an enterprise (using a group policy object, or maybe other configuration mechanisms) but I don't think it's realistic in a home network, and I think you should say so. The first paragraph of 4.1 says "on the other hand," but I think the point is consistent with the previous point. Don't say "on the other hand" here. :-) Please clarify the case of using ULA as the internal prefix for NAT64. If you do that with no GUA, you are giving IPv6-only hosts IPv4-only access; there's no native IPv6 (because of ULA) and all IPv4 will use the NAT64. It's the worst of both worlds. THe point made in 5.3.3 is a good one. So good that more words may be needed. A GUA would be a good identifier in the same way, except that a GUA prefix may change. Security considerations probably needs more. There are several places in the document describing NAT and (enterprise) security considerations. These should at least be referenced. It also improves security for hosts/nodes that are not intended to be globally reachable; instead of applying a filter, there is simply no route from outside the network. I do agree that this document is striking the right balance in its considerations. Lee From jinmei.tatuya@gmail.com Wed Nov 6 11:24: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 6AF5E21E817B for ; Wed, 6 Nov 2013 11:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7YuKFtp5yzw for ; Wed, 6 Nov 2013 11:24:07 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5421E80C3 for ; Wed, 6 Nov 2013 11:24:06 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id n12so5423921wgh.35 for ; Wed, 06 Nov 2013 11:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3qbJLDOdeOwj6Zc7eiWYdsmRhEWx0aLCBkzwXhs8C4A=; b=A2hByxEDvgN7ExVTB41crTz61CtbhLRj/6/RZgeaT4SifaJdSOJhhDWCInTsEkOn2u C9jjfEzzuioUAl6d5J6wIqidWstEgw48w235UUQHWrmOhumbBsOy0q0OHYn2UXx0Lpbq QydodpFuA8fHbPx1aeKZzQJ2/16PkwVQIOnfJ7feafzEQxeghIvbrcKGnY8f4CiBTXW6 u3+GtOxiS+EAzzqn92mM3KgjVM9QU6pAz0vZhgKSSSABrHwOPBr9+cSoMVVjgBua+Vsq NrtvjJpPUZsFGSnZkjld6u2NYkXcYc83cCfODHKI5LGKtT1j4b/0m195SoanSvLUTdwr i30Q== MIME-Version: 1.0 X-Received: by 10.180.83.40 with SMTP id n8mr22466923wiy.0.1383765846030; Wed, 06 Nov 2013 11:24:06 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Wed, 6 Nov 2013 11:24:05 -0800 (PST) In-Reply-To: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <15A60E31-DAD1-4E72-8E27-52868FAF9203@cisco.com> Date: Wed, 6 Nov 2013 11:24:05 -0800 X-Google-Sender-Auth: PCA0IPuBaIH1xj_wi-QwLy17lfs Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: Ole Troan , "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem 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, 06 Nov 2013 19:24:09 -0000 At Tue, 5 Nov 2013 15:21:48 +0100 (CET), Mikael Abrahamsson wrote: > >> Yes, I know this is about address configuration. I am still curious if all OSes keep the /64 interface route when A changes to 0 (or is 0 to begin with). If you feel this is out of scope that's fine, then my curiosity will stay unanswered. > > > > in the nit-picking department, wouldn't that really be the L flag? > > Well, my question was for L=1, A=1, A=1 -> A=0, and A=0 cases. In case the > implementor got the addressing generation mixed up with the route stuff. I don't understand exactly what this means: "L=1, A=1, A=1 -> A=0, and A=0". If you mean something like this 1. a host first receives a prefix information option for a /64 prefix with L=1 and A=1 2. the host then receives a prefix information option of the same /64 prefix with L=1 and A=0 I believe almost all implementations create a direct route for the /64 as well as an address or more using the prefix at step 1. According to the draft, Windows 7 "deprecate"s (its precise meaning is not really clear but doesn't matter much here) the address. All other implementations listed in the draft do nothing for the address. I don't know Windows 7 or other implementations do for the /64 direct route at step 2, but I believe nothing happens on at least all others than Windows 7. Perhaps an interesting question is what happens to the direct route if we keep receiving the L=1 and A=0 prefix information option and the corresponding address eventually expires. Unless it has changed recently, BSD variants should still keep the /64 route. I don't know about Linux; I don't know if iOS works as other BSD variants on this regard either. > Are there test suites for all this stuff that implementors can use? What I think some of such scenarios are covered in TAHI test suites (http://www.tahi.org/). -- JINMEI, Tatuya From phdgang@gmail.com Wed Nov 6 18:33: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 C315911E820A for ; Wed, 6 Nov 2013 18:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=-2.075, BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgpNsUAENnXx for ; Wed, 6 Nov 2013 18:33:49 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5412721E818F for ; Wed, 6 Nov 2013 18:33:48 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id s19so370271qcw.35 for ; Wed, 06 Nov 2013 18:33:47 -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=ND7x+HZiYKf8qWl2/wFJGexUWazFZdBKMItYIWGNiWc=; b=SCft9dn42gzHJ6f1OMO3BETAnR6OU4oEcMJ02TXtl2sp+1e0z/Gu0b+P6fFuSV6ig7 gpYzrr0qBjiWq8vgsVGOjXlV/tTEO60OHmK0O9+Uhgfn7hvsSMcvt7nTRUVTuL0J07Fe a8CpR2hXpMqpIaj9UFjl5tzKr6FgvBBDuH8f1/SM8BQYiwH3TO6Qz2JrNnYKqTkZ5plQ 91Md0nh6OTBGNmfKeCXlYykud+SpSDr2UChV+KiqOKHwaSSZXcwZk7SZ+ILyp+foyuiS nIXDirNXwAYGaauZvj+z8fFo6XeCUljT4aD+c7Kr9i+vQzIPd4CuWxzQVWGO2GSEyIad BPQw== MIME-Version: 1.0 X-Received: by 10.49.27.226 with SMTP id w2mr9014124qeg.32.1383791627715; Wed, 06 Nov 2013 18:33:47 -0800 (PST) Received: by 10.224.172.135 with HTTP; Wed, 6 Nov 2013 18:33:47 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303A1250C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20131104174259.10097.28929.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303A1250C@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Thu, 7 Nov 2013 10:33:47 +0800 Message-ID: From: GangChen To: "Heatley, Nick" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , "" Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-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, 07 Nov 2013 02:33:50 -0000 Hi Nick, 2013/11/6, Heatley, Nick : > Hi there Gang, > A useful draft thank you. thank you for the interest > Some comments that, from my perspective, would make the content clearer. By > all means take them or leave them :-)) > > Section 3 > -Defining "failure" in this draft - in general I infer fallback is a success > -so you could adapt the middle sentences: >>There may be a mismatch between the subscriber request and network >> capability. In 3GPP networks a mismatch between the UE request and the >> bearer network could result in bearer negotiation and a fallback to a >> common bearer type. The failures here can be a result of no common bearer >> type existing and the UE is left disconnected. Or in the case of local >> breakout a failure could result from network functionality that is assumed >> by the UE configuration being absent in the visited network. The following >> table lists the potential failure cases. The failure maybe not only about fallback. The cases can be categorized as three types: 1) legacy can't parse the IPv4v6 (they even can't get chance to fallback) 2) Can't find a common bearer to fallback(I guess that is what you mentioned) 3) after the fallback, they found there is a mismatch with mobile device expectation 1) is about home routed cases. 2) and 3) is about local-breakout > Section3 - Table1 > - I would prefer to say that the UEs request IPv4v6, rather than dual stack. > That is also what you have defined at the start of section 3. Yes. It should be changed to PDP/PDN type IPv4v6 > - I would prefer to see two tables in this section, one covering Home > routing and one covering local breakout, because of the following specific > comments > - Do you need to define what you mean by Dual Stack for the "Visited Network > Capability"? I am wondering, in the case of Home routing, if "Visited > Network Capability" is better expressed as "PDN/PDP IP Type permitted"? Then > "dual stack" could become "all PDN/PDP IP types"? What do you think? > Either way "dual stack" may leave some ambiguity to some readers not > familiar with 3GPP networks here (especially as the terms appears in section > 4.2. in association with separate single-IP-type PDP). Your understanding is correct. We will take your comments into consideration when we update the table. If the expression of "PDN/PDP IP Type permitted" is adopted, the rows in the home routed mode may only has two options: "all PDN/PDP IP types" and "PDP/PDN type IPv4v6 is not allowed". for the local breakout mode, they may have different capabilities, i.e. "all PDN/PDP IP types", "PDN/PDP type IPv4", , "PDN/PDP type IPv6" and "PDN/PDP type IPv4 & PDN/PDP type IPv6", > - The failure cases are potential failure cases - for the home routing > table, I would like to see a middle column which describes "success" whether > request is granted or a suitable fallback, as would be expected when visited > networks are ready e.g. In an IPv4-only capable visited network, the > terminal can request IPv4v6 and be downgraded to IPv4 PDP. I'd like to see > all possible cases listed then, for example adding IPv4v6 request to "Dual > Stack" visited network. If adding such a column is undesirable, then at > least stressing that there is a *risk* of these failure cases, they are not > an architectural certainty. > - So the current columns capturing failures could be labelled "potential > failure cases (Home Routing)" In the home routed case, the failure is mainly about extended-PDP-type AVP over Gr interface. The success can be achieved only if HLR/HSS does send this AVP to vSGSN(it can be done by deleting or send different profiles to vPLMN). Is this description you want to see? > -Where there are no possible failure cases identified then "None" could > replace "OK" > -To be clear I'd change"IPv6-only with 464xlat" to "IPv6-only (where UE is > 464xlat enabled)" or similar. As this case is only highlighted for local > breakout, then I'd not list it in the Home Routing table. > > Section 4 > - Would it make sense to keep section 4 as the "problem definition" text and > split out the "mitigations" text? I am thinking some of the mitigations will > mitigate more than one failure case? That could be a way. But, I would like to wait for more comments on the document structure. > Section4.2 > -I am not clear whether failure case 2 is a failure or just a warning of > knock-on effects? What is recommended at the home network or the visited > network? Splitting PDP type IPv4v6 into parallel two is a standard behavior in 3GPP. It may creates the failure when mobile devices have some limitations to request IPv6. Local-break out option could be disable in this case or mobile device could be configured to request IPv4 in vPLMN > Would the approach of roaming profiles in HSS of section 4.1. also help > here? Etc. HSS can only help to pass the attach process. But it can't address the whole issue > Section4.3. >>Since IMS roaming architecture will offload all traffic in the visited >> network > -Is this mandatory in all cases? I would suggest: Yes. It's the GSMA recommendation >>In the IMS roaming architecture when traffic is offloaded in the visited >> network.... > > The next sections I must admit I found difficult - it may be my lack of > understanding so apologies if so! > I assume you are trying to cover local breakout for both Data and IMS Voice > use cases. > > Section4.4. > -I am confused why this failure is not also applied to Home routing i.e. if > visited network permits only IPv4 PDP? > Now I am wondering whether I understood the authors' intentions for "Visited > Network Capability" column, if this is not a potential failure for Home > Routing? this failure is only for local breakout > For local breakout do you mean specifically that the local breakout path at > and beyond the GGSN /PGW is "IPv4-only" though the SGSN/SGW may allow all > PDP/PDN types? there is the case SGSN could understand all PDP/PDN types but GGSN only assign IPv4 address > I would split out local breakout case into a table2, so the appropriate > columns can be created and labelled. > > Section 4.5 > - So this is a local breakout issue where local DNS/NAT functionality is to > be used? yes > -However, looking back at the table, a 464xlat capable UE could start by > requesting IPv4v6, receive an IPv6 PDP, and try to invoke the CLAT > functionality, could it not? AFAIK, it's proper to only request PDP type IPv6-only for a 464xlat capable UE. If you check with table, there only is IPv6-only with 464xlat. > So then it can go on to have the problems of case5. The bearer requested by > the UE seems less relevant. Perhaps there are extra parameters assumed in > the Local Breakout scenarios that I am missing e.g. the local breakout APN > settings?; something more relevant to the case than what "UE requests"? I am > not so familiar with all the local break out scenarios, but I would again > suggest a separate table 2 for local breakout so that we can link the > scenarios appropriately. > - Is the AAA server a solution for local breakout? I thought this was > described by Dave as a Home Routing solution? The text is reasonable, just I would like to point out the case 5 is mainly about intra-PLMN mobility. therefore, AAA server here is deployed in the same operator. I guess it aligns with Dave description. > not sure why it appears specifically in this section? We would move the AAA server description into an independent section. > > I hope this is useful. thank you for the effort Best Regards Gang > Best Regards, > Nick Heatley > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > GangChen > Sent: 04 November 2013 17:50 > To: v6ops > Cc: > Subject: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-02.txt > > Wg, > > We submit the new draft of IPv6 roaming. Please kindly check. > Your comments are appreciated > > BRs > > Gang > > 2013/11/5, internet-drafts@ietf.org : >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : IPv6 Roaming Behavior Analysis >> Author(s) : Gang Chen >> Hui Deng >> Dave Michaud >> Jouni Korhonen >> Mohamed Boucadair >> Vizdal Ales >> Cameron Byrne >> Filename : draft-chen-v6ops-ipv6-roaming-analysis-02.txt >> Pages : 12 >> Date : 2013-11-04 >> >> Abstract: >> This document intends to enumerate failure cases when a IPv6 >> subscriber roams into visited network areas. The investigations on >> those failed cases reveal the causes in order to notice improper >> configurations, equipment's incomplete functions or inconsistent IPv6 >> strategy. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-roaming-analysi >> s >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-chen-v6ops-ipv6-roaming-analysi >> s-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or use > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachments > are free from any virus, but it remains your responsibility to ensure that > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > From fernando@gont.com.ar Wed Nov 6 20:32: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 D8FEF11E81B0; Wed, 6 Nov 2013 20:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SebOCook113m; Wed, 6 Nov 2013 20:32:45 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 88A9A11E8158; Wed, 6 Nov 2013 20:32:45 -0800 (PST) Received: from dhcp-a038.meeting.ietf.org ([31.133.160.56]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VeHGp-0006GJ-Mo; Thu, 07 Nov 2013 05:32:39 +0100 Message-ID: <527B0098.6080800@gont.com.ar> Date: Wed, 06 Nov 2013 18:53:12 -0800 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Fernando Gont References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 07 Nov 2013 04:32:55 -0000 Hi, Michael, On 11/04/2013 04:08 PM, Mikael Abrahamsson wrote: > On Mon, 4 Nov 2013, Fernando Gont wrote: > >> Isn't there a v6ops I-D with similar wording? > > I opposed to this wording in there as well. Then I apologize -- I kind of assumed some sort of intention based on that I-D. So.. point taken. That said, the meat is in stats. :-) > If one deploys a 6500/7600/SUP720 and configures IPv6 on it today, it'll > slow-path every IPv6 packet with a fragmentation header. Default behaviour. But slow path != drop. > I have no idea how much of the behaviour your're seeing is caused by > this default behaviour, but I'd venture to guess a lot. > >> mm... as far as discussion on a number of forums went, apparently >> there's intent to do so. > > Oki, I haven't seen these. > >> Data? References? > > http://seclists.org/nanog/2011/Sep/1076 Quickly skimming through the discussion it looks like a decision is made to drop -- albeit for reasonable reasons. Am I missing something? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From swmike@swm.pp.se Thu Nov 7 06:05: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 8830111E8269; Thu, 7 Nov 2013 06:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+Qs5yzRNMK8; Thu, 7 Nov 2013 06:05:02 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 52BBC11E8265; Thu, 7 Nov 2013 06:05:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 907929C; Thu, 7 Nov 2013 15:05:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 89F4A9A; Thu, 7 Nov 2013 15:05:00 +0100 (CET) Date: Thu, 7 Nov 2013 15:05:00 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <527B0098.6080800@gont.com.ar> Message-ID: References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <527B0098.6080800@gont.com.ar> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 07 Nov 2013 14:05:07 -0000 On Wed, 6 Nov 2013, Fernando Gont wrote: >> If one deploys a 6500/7600/SUP720 and configures IPv6 on it today, it'll >> slow-path every IPv6 packet with a fragmentation header. Default behaviour. > > But slow path != drop. Since this platform does few megabits/s in slowpath, it's pretty close. Most reasonable people will deploy CoPP here and set low policer limits for this kind of traffic. > Quickly skimming through the discussion it looks like a decision is made > to drop -- albeit for reasonable reasons. Am I missing something? I'm sure there are some who set it to drop, and some set it to forward (both for good reasons), and some don't know and leave the default. -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Thu Nov 7 08: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 0F74321E81D7; Thu, 7 Nov 2013 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.406 X-Spam-Level: X-Spam-Status: No, score=-110.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfIFJp75IRmf; Thu, 7 Nov 2013 08:45:48 -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 08ED321E81DA; Thu, 7 Nov 2013 08:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1383842711; x=1385052311; h=from:to:cc:subject:date:message-id:mime-version; bh=0fCRmUo2kyj0YZUSKGrF6CVkYbrAGNuWML0DY2sRDyQ=; b=NfOUmwcP+/OhaC1tiiXG7SAX/bZa2oYIGWvnzHLzSUHqi4oVzm5/hQJN ZksHptKQxuktbOuK02gTPuxSOr1Jiwz0auFmuG2zUCEx09t1RsS17nutl ncrr+pzDlTKdJ6UKALOTbmU1PN1uq0W+RRV1VppbJ8YPz0F9nEisWwPL/ 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKXCe1KtJXG9/2dsb2JhbABagwc4U78OgSUWdIIseRIBgQAnBAENE4dzDbx0jg+BSoMngRADkC6BMIYugS+QW4Mmgio X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="asc'?scan'208";a="282091699" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2013 16:45:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7Gj8uB006053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 16:45:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 10:45:07 -0600 From: "Fred Baker (fred)" To: Routing WG , "ospf@ietf.org" , "isis-wg@ietf.org" Thread-Topic: Tsinghua work on source/destination routing Thread-Index: AQHO29i28SykYfa5/UyGL9QietHsLg== Date: Thu, 7 Nov 2013 16:45:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.25] Content-Type: multipart/signed; boundary="Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , "v6ops@ietf.org WG" Subject: [v6ops] Tsinghua work on source/destination routing 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, 07 Nov 2013 16:46:31 -0000 --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd like to draw your attention to a talk that will be given this = morning in homenet. The context is: = http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-case= s http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases "Requirements and Use Cases for Source/Destination Routing", Fred = Baker, 2013-08-13 http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class http://tools.ietf.org/html/draft-xu-homenet-traffic-class "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu = Yang, Jianping Wu, Fred Baker, 2013-10-21 http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, = Shu Yang, Jianping Wu, Dan Wang, 2013-08-22 http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28 http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, = Fred Baker, 2013-10-15 I had breakfast this morning with Shu Yang, who has been writing Quagga = code for several years in the course of his PHd. He first implemented a = source/destination model, reported on in = draft-xu-homenet-twod-ip-routing, which was an MTR scheme. He tells me = he found that very complex. He also listened to my talk in homenet = around draft-baker-fun-routing-class, and has now implemented (if I = understand him correctly) draft-ietf-ospf-ospfv3-lsa-extend and = draft-baker-ipv6-ospf-dst-src-routing. The FIB implementation has a = limitation: the source prefixes must be disjoint. However, given that, = he has two FIB implementations, one of which has separate FIBs for each = source prefix in play including ::/0 (so if there are M prefixes in the = network, M+1 FIBs), and one of which is a single hierarchical M-Trie = that looks up the destination and then the source. He has tested the = code in simulation; the next step is testing in live networks. Examples of use cases are generally around multi-prefix campus networks. = There is a security use case that could be of value; at IETF 87, George = Michaelson of APNIC reported on ULAs seen in his darknet. The short = report is that he sees a fair bit of traffic with a ULA source address = on the backbone. An interesting potential use of source/destination = routing would counter that, and perhaps mitigate the need for ISP BCP 38 = if generally deployed; in a case where a network is using a ULA and a = global prefix (e.g., is not multihomed but has two prefixes, one of = which is intended to only be used within its network), the default route = to the network egress would use the global prefix as a source, and as a = result traffic sent outside the network with a ULA source prefix would = in effect have no route. The network could literally only emit traffic = from its correct prefix. I think this is relevant to the discussion of=20 draft-baker-rtgwg-src-dst-routing-use-cases draft-ietf-ospf-ospfv3-lsa-extend draft-baker-ipv6-ospf-dst-src-routing draft-baker-ipv6-isis-dst-src-routing --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSe8OSbjEdbHIsm0MRAo4JAKD1Gu32KozZNW+5Y1ee5sH14VA5XACg/9jZ h0LqlvvqSnEfhdffbQ568wA= =ofmZ -----END PGP SIGNATURE----- --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2-- From furry13@gmail.com Thu Nov 7 08:59: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 0CFB811E81CF; Thu, 7 Nov 2013 08:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFD7hSJxATaM; Thu, 7 Nov 2013 08:59:22 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id F31DA11E819E; Thu, 7 Nov 2013 08:59:21 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id cm18so657195qab.8 for ; Thu, 07 Nov 2013 08:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=E6In2s4X0lJ4eSm+mhds+DubXv78BpYk2pyjpkrwmyo=; b=ctMeitCKZ8TbbL+9oJw1SmmbvTKcBI0lkcSORji2Hj8k1OMf0VY67d78WAMLm++LCN kT0sk/I7uw8MNp84l/u3Y/4e6ByYN8rIuwjSPL+3FubT8BuW4ohw+E9TMQhVkVxvXERW PRIkYADMSg1DSsJvL3GyxH4NWeP5f/oHwx7vCm4rm+/+ReuuyWWbBLMV4JschQq0K3XF 6NyXGEdogSeme+Qyun5s0bOzZda+JZnZ9JeWRQvwcIfQGnK5RHf6yYILkDukvCUzBa+3 umWRojvwrx//W4pElx60A5yy673ScRcj6o4QVQ1QVCWOSHvMEaPEWL5tG6IZfkenn2vp AScw== X-Received: by 10.224.121.198 with SMTP id i6mr16184619qar.52.1383843556903; Thu, 07 Nov 2013 08:59:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Thu, 7 Nov 2013 08:58:56 -0800 (PST) In-Reply-To: References: From: Jen Linkova Date: Thu, 7 Nov 2013 17:58:56 +0100 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 16:59:23 -0000 On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) wrote: > Examples of use cases are generally around multi-prefix campus networks. = There is a security use case that could be of value; at IETF 87, George Mic= haelson of APNIC reported on ULAs seen in his darknet. The short report is = that he sees a fair bit of traffic with a ULA source address on the backbon= e. An interesting potential use of source/destination routing would counter= that, and perhaps mitigate the need for ISP BCP 38 if generally deployed; = in a case where a network is using a ULA and a global prefix (e.g., is not = multihomed but has two prefixes, one of which is intended to only be used w= ithin its network), the default route to the network egress would use the g= lobal prefix as a source, and as a result traffic sent outside the network = with a ULA source prefix would in effect have no route. The network could l= iterally only emit traffic from its correct prefix. Looks like we (finally) have a chance to enforce the requirement from RFC4007, Section9: "If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded. " I'm seeing plenty of packets from link-local sources to global destinations which means that: 1) there are hosts with broken default address selection AND 2) routers on the Internet do forward such packets (violating the rule mentioned above). Fixing #2 actually requires making forwarding decision based on src and dst (which is not happening now). More data (sorry, shameless plug :)) https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf --=20 SY, Jen Linkova aka Furry From Fred.L.Templin@boeing.com Thu Nov 7 09:08: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 7C4D321E81D8; Thu, 7 Nov 2013 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U-OQ+jAgEBU; Thu, 7 Nov 2013 09:08:02 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3C11E8188; Thu, 7 Nov 2013 09:07:38 -0800 (PST) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id rA7H7bgd012939; Thu, 7 Nov 2013 09:07:37 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rA7H7aMq012929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 7 Nov 2013 09:07:37 -0800 Received: from XCH-BLV-406.nw.nos.boeing.com (130.247.25.162) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 7 Nov 2013 09:07:36 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.190]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 09:07:34 -0800 From: "Templin, Fred L" To: "Fred Baker (fred)" , Routing WG , "ospf@ietf.org" , "isis-wg@ietf.org" Thread-Topic: Tsinghua work on source/destination routing Thread-Index: AQHO29i28SykYfa5/UyGL9QietHsLpoZ/WGA Date: Thu, 7 Nov 2013 17:07:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831814AE3D@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "homenet@ietf.org Group" , "v6ops@ietf.org WG" Subject: Re: [v6ops] Tsinghua work on source/destination routing 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, 07 Nov 2013 17:08:24 -0000 Hi Fred, It is good to see this discussion, but an alternative approach that should also be considered is tunneling. In the IRON approach at least, the end user network gets a stable IPv6 prefix that is independent of the access network IP addresses it gets from its ISPs. So, there is no need for source address-based forwarding to ensure that packets sent via ISP A will not have a source address from ISP B. The use cases for tunneling are very broad, and probably overlap with the ones you are considering in this approach. The relevant documents are here: http://tools.ietf.org/html/draft-templin-ironbis http://tools.ietf.org/html/draft-templin-intarea-vet http://tools.ietf.org/html/draft-templin-intarea-seal =20 Thanks - 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: Thursday, November 07, 2013 8:45 AM > To: Routing WG; ospf@ietf.org; isis-wg@ietf.org > Cc: homenet@ietf.org Group; v6ops@ietf.org WG > Subject: [v6ops] Tsinghua work on source/destination routing >=20 > I'd like to draw your attention to a talk that will be given this morning= in homenet. The context is: >=20 > http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cas= es > http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases > "Requirements and Use Cases for Source/Destination Routing", Fred Baker= , > 2013-08-13 >=20 > http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class > http://tools.ietf.org/html/draft-xu-homenet-traffic-class > "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang= , > Jianping Wu, Fred Baker, 2013-10-21 >=20 > http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing > http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing > "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu > Yang, Jianping Wu, Dan Wang, 2013-08-22 >=20 > http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing > http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing > "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28 >=20 > http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend > http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend > "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fre= d > Baker, 2013-10-15 >=20 > I had breakfast this morning with Shu Yang, who has been writing Quagga c= ode for several years in the > course of his PHd. He first implemented a source/destination model, repor= ted on in draft-xu-homenet- > twod-ip-routing, which was an MTR scheme. He tells me he found that very = complex. He also listened to > my talk in homenet around draft-baker-fun-routing-class, and has now impl= emented (if I understand him > correctly) draft-ietf-ospf-ospfv3-lsa-extend and draft-baker-ipv6-ospf-ds= t-src-routing. The FIB > implementation has a limitation: the source prefixes must be disjoint. Ho= wever, given that, he has two > FIB implementations, one of which has separate FIBs for each source prefi= x in play including ::/0 (so > if there are M prefixes in the network, M+1 FIBs), and one of which is a = single hierarchical M-Trie > that looks up the destination and then the source. He has tested the code= in simulation; the next step > is testing in live networks. >=20 > Examples of use cases are generally around multi-prefix campus networks. = There is a security use case > that could be of value; at IETF 87, George Michaelson of APNIC reported o= n ULAs seen in his darknet. > The short report is that he sees a fair bit of traffic with a ULA source = address on the backbone. An > interesting potential use of source/destination routing would counter tha= t, and perhaps mitigate the > need for ISP BCP 38 if generally deployed; in a case where a network is u= sing a ULA and a global > prefix (e.g., is not multihomed but has two prefixes, one of which is int= ended to only be used within > its network), the default route to the network egress would use the globa= l prefix as a source, and as > a result traffic sent outside the network with a ULA source prefix would = in effect have no route. The > network could literally only emit traffic from its correct prefix. >=20 > I think this is relevant to the discussion of > draft-baker-rtgwg-src-dst-routing-use-cases > draft-ietf-ospf-ospfv3-lsa-extend > draft-baker-ipv6-ospf-dst-src-routing > draft-baker-ipv6-isis-dst-src-routing From hermin.anggawijaya@gmail.com Thu Nov 7 10:41: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 BD6AC21E8216; Thu, 7 Nov 2013 10:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucC9URx8BT4c; Thu, 7 Nov 2013 10:41:04 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 96C1421E8118; Thu, 7 Nov 2013 10:40:40 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db12so709930veb.37 for ; Thu, 07 Nov 2013 10:40:08 -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=u2qlO4+/ho6hSd/jP4oKgCqCmXp49G5B3sLVqWRrR9Q=; b=BoRsuq3ZPJf+11hd3ALQkVoGKOTYWzwcTccKFC8pRi+9OxP1/WFDyRvYbriT7AIdre WaaT5A/nXgT5gY3oUhFl4//lQL5kNkeyXZDWgnc5MZrqpxMzT8eQovMwSuqpPHY0DaDs m6nF4v/QWVx1Y7FmcDcWJWSdy9AksysRARtyw0WoZourOAoGIflSLMUdRzQllGFXgXNH wDXSBvZe7HOP0cD7SGS2d0cAdkzG42Q78MKAQWh7wgZEHMjvvsvbdqD2Tt8JvOMJtVVs yNIOHcxqXQLeYCLsGhEaEht0CU/J6Sf7TXo+4XYjR/kjsgX0EHyMmoOjl0SjOkGtNdix n9bQ== MIME-Version: 1.0 X-Received: by 10.220.47.10 with SMTP id l10mr1814747vcf.32.1383849608424; Thu, 07 Nov 2013 10:40:08 -0800 (PST) Received: by 10.58.188.72 with HTTP; Thu, 7 Nov 2013 10:40:08 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 10:40:08 -0800 Message-ID: From: Hermin Anggawijaya To: Jen Linkova Content-Type: multipart/alternative; boundary=001a11c2a58c55340d04ea9a9896 Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 18:41:13 -0000 --001a11c2a58c55340d04ea9a9896 Content-Type: text/plain; charset=ISO-8859-1 > I'm seeing plenty of packets from link-local sources to global destinations > ..... > 2) routers on the Internet do forward such packets (violating the rule mentioned above). > Fixing #2 actually requires making forwarding decision based on src > and dst (which is not happening now). To fix the above issue, wouldn't address scope checking be enough, rather than the [src,dst] based routing discussed ? On Thu, Nov 7, 2013 at 8:58 AM, Jen Linkova wrote: > On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) wrote: > > Examples of use cases are generally around multi-prefix campus networks. > There is a security use case that could be of value; at IETF 87, George > Michaelson of APNIC reported on ULAs seen in his darknet. The short report > is that he sees a fair bit of traffic with a ULA source address on the > backbone. An interesting potential use of source/destination routing would > counter that, and perhaps mitigate the need for ISP BCP 38 if generally > deployed; in a case where a network is using a ULA and a global prefix > (e.g., is not multihomed but has two prefixes, one of which is intended to > only be used within its network), the default route to the network egress > would use the global prefix as a source, and as a result traffic sent > outside the network with a ULA source prefix would in effect have no route. > The network could literally only emit traffic from its correct prefix. > > Looks like we (finally) have a chance to enforce the requirement from > RFC4007, Section9: > > "If transmitting the packet on the chosen next-hop interface > would cause the packet to leave the zone of the source > address, i.e., > cross a zone boundary of the scope of the > source address, then the packet is discarded. " > > I'm seeing plenty of packets from link-local sources to global > destinations which means that: > 1) there are hosts with broken default address selection > AND > 2) routers on the Internet do forward such packets (violating the rule > mentioned above). > Fixing #2 actually requires making forwarding decision based on src > and dst (which is not happening now). > > More data (sorry, shameless plug :)) > https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf > > -- > SY, Jen Linkova aka Furry > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c2a58c55340d04ea9a9896 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> I'm seeing plenty of packets f= rom link-local sources to global destinations
> .....
> 2) routers on the Internet do forward su= ch packets (violating the rule=A0 mentioned above).
> Fixing #2 actually requires making forwarding decision based on src > and dst (which is not happening now).

To fix the above is= sue, wouldn't address scope checking be enough, rather than the [src,ds= t] based routing
discussed ?



On Thu, Nov 7, 2013 at 8:58 AM, Jen Link= ova <furry13@gmail.com> wrote:
On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> Examples of use cases are generally around multi-prefix campus network= s. There is a security use case that could be of value; at IETF 87, George = Michaelson of APNIC reported on ULAs seen in his darknet. The short report = is that he sees a fair bit of traffic with a ULA source address on the back= bone. An interesting potential use of source/destination routing would coun= ter that, and perhaps mitigate the need for ISP BCP 38 if generally deploye= d; in a case where a network is using a ULA and a global prefix (e.g., is n= ot multihomed but has two prefixes, one of which is intended to only be use= d within its network), the default route to the network egress would use th= e global prefix as a source, and as a result traffic sent outside the netwo= rk with a ULA source prefix would in effect have no route. The network coul= d literally only emit traffic from its correct prefix.

Looks like we (finally) have a chance to enforce the requirement from=
RFC4007, Section9:

"If transmitting the packet on the chosen next-hop interface
would cause the packet to leave the zone of the source
address, i.e.,
cross a zone boundary of the scope of the
source address, then the packet is discarded. "

I'm seeing plenty of packets from link-local sources to global
destinations which means that:
1) there are hosts with broken default address selection
AND
2) routers on the Internet do forward such packets (violating the rule
mentioned above).
Fixing #2 actually requires making forwarding decision based on src
and dst (which is not happening now).

More data (sorry, shameless plug :))
https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf
--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--001a11c2a58c55340d04ea9a9896-- From jinmei.tatuya@gmail.com Thu Nov 7 10:43: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 AAF5C21E80FE; Thu, 7 Nov 2013 10:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okINNPS-ZsSB; Thu, 7 Nov 2013 10:43:51 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id ACF5721E8200; Thu, 7 Nov 2013 10:42:56 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so940992wes.37 for ; Thu, 07 Nov 2013 10:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qSpNWGJWc8rjvH5McFCgIlaLQdmSEewymyCi3yoAyv4=; b=EZRzPTnTbvgBw8XkN5Hb9OGWNoHcngut+YyyUiS6shC4hX3TStvkZ/gDZZcIsiOFNe PjpD3WhoTBXPeyv7sE3txP7nmBlwG6y7cLsEmCdcdZpPamOuMEpLPdCMsxanZV7FjTIY 1/HAN5T4IuSU4PrpCSAnUiAAwQLb//0mA1WOYqSwdNkV6Tysw/kZ+Ked384RXUqeTxiA Fe32h/5sipfcnUK6W0DWKF5AAEFQUXXRPkC/YPSQxkDEALjFjFFojdDk0MQQbeZRkOTr GTUF8NBIwomzeKh/3SNvpTaGeAIZBPzMesX6GXQvMfMQXaR1jt56+2QmYeW8+UzXPW5u s3tQ== MIME-Version: 1.0 X-Received: by 10.180.37.134 with SMTP id y6mr3867788wij.48.1383849772295; Thu, 07 Nov 2013 10:42:52 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Thu, 7 Nov 2013 10:42:52 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 10:42:52 -0800 X-Google-Sender-Auth: dO1-WPbSBrhdlegMd1UcgfRY9tY Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jen Linkova Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 18:43:51 -0000 At Thu, 7 Nov 2013 17:58:56 +0100, Jen Linkova wrote: > Looks like we (finally) have a chance to enforce the requirement from > RFC4007, Section9: > > "If transmitting the packet on the chosen next-hop interface > would cause the packet to leave the zone of the source > address, i.e., > cross a zone boundary of the scope of the > source address, then the packet is discarded. " > > I'm seeing plenty of packets from link-local sources to global > destinations which means that: > 1) there are hosts with broken default address selection > AND (Probably an off-topic in this context but) this is not necessarily accurate. If a host only has a link-local address but somehow knows the interface to send packets to a global destination, it would be able to send packets with source being link-local and destination being global, and validly (not breaking RFC 6724) so. I believe it's more likely to be a broken network configuration than a broken host implementation. -- JINMEI, Tatuya From fred@cisco.com Thu Nov 7 10:56: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 B87CF21E8219; Thu, 7 Nov 2013 10:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.314 X-Spam-Level: X-Spam-Status: No, score=-110.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thhb18A-2jfu; Thu, 7 Nov 2013 10:56:36 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 44FE221E814E; Thu, 7 Nov 2013 10:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2305; q=dns/txt; s=iport; t=1383850583; x=1385060183; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u94GyZUlvbj5d0RSc0jv9e9KFnokK1ampB+pehGsEe8=; b=WqFDHY2vr00esHogK1xhmoSghfdH2wWEnPh/NHdosE3U5u2QZY0pdtVn FsxjokHGScV9QHU3ygHrm3pUPEklOCA8vctnvlrG0uzB0xIqLqjNj0NHM Jt+VKHg0bURKi/5B/8D5piM80YMbbqYWln0sfXZ4+He7fu6iQqcIET+Mb w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFACfhe1KtJXG8/2dsb2JhbABagweBC4J0vBuBJRZ0giUBAQEDASNWBQsCAQYCGCoCAiERJQIEDgUOh2EDCQaOOJteiFkNiWuMZ4E0gT4Hgms1gRADkC6BMIRDgWuMUoU4gyaBaUE X-IronPort-AV: E=Sophos;i="4.93,653,1378857600"; d="asc'?scan'208";a="282096191" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2013 18:56:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA7IuDm0024565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 18:56:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 12:56:13 -0600 From: "Fred Baker (fred)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] [homenet] Tsinghua work on source/destination routing Thread-Index: AQHO2+sHHvd0L93ku0KOjrOyzNpCaA== Date: Thu, 7 Nov 2013 18:56:12 +0000 Message-ID: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.80] Content-Type: multipart/signed; boundary="Apple-Mail=_80C57558-2DEF-458E-9CFE-A2F1F43DB003"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 18:56:48 -0000 --Apple-Mail=_80C57558-2DEF-458E-9CFE-A2F1F43DB003 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 7, 2013, at 10:42 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > At Thu, 7 Nov 2013 17:58:56 +0100, > Jen Linkova wrote: >=20 >> Looks like we (finally) have a chance to enforce the requirement from >> RFC4007, Section9: >>=20 >> "If transmitting the packet on the chosen next-hop interface >> would cause the packet to leave the zone of the source >> address, i.e., >> cross a zone boundary of the scope of the >> source address, then the packet is discarded. " >>=20 >> I'm seeing plenty of packets from link-local sources to global >> destinations which means that: >> 1) there are hosts with broken default address selection >> AND >=20 > (Probably an off-topic in this context but) this is not necessarily > accurate. If a host only has a link-local address but somehow knows > the interface to send packets to a global destination, it would be > able to send packets with source being link-local and destination > being global, and validly (not breaking RFC 6724) so. I believe it's > more likely to be a broken network configuration than a broken host > implementation. I suspect it's some of each. The host should, I should think, set the = hop limit to one on any packet that is to a link-local address, to = ensure that the packet is not repeated by a broken router (apart from = protocols that ask to have it set to 255 and have the receiving host = check for that value). Also, upstream network's BCP 38 implementation = sounds suspect, and I'm with Jen in wondering why a router forwarded the = packet in the first place. --Apple-Mail=_80C57558-2DEF-458E-9CFE-A2F1F43DB003 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSe+JKbjEdbHIsm0MRAqkbAJ0ZTLdAY6APMRY3oOWLS72wLTuVrwCcDl04 LiKakgQCjPuHp+Um7AUSCPs= =cwKF -----END PGP SIGNATURE----- --Apple-Mail=_80C57558-2DEF-458E-9CFE-A2F1F43DB003-- From joelja@bogus.com Thu Nov 7 11:06: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 191CE11E81FF for ; Thu, 7 Nov 2013 11:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi7PFKiCq6q8 for ; Thu, 7 Nov 2013 11:06:04 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9659911E8118 for ; Thu, 7 Nov 2013 11:06:04 -0800 (PST) Received: from wireless-a-1x-v6.meeting.ietf.org (wireless-a-1x-v6.meeting.ietf.org [IPv6:2001:67c:370:184:419e:c485:c804:a314] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id rA7J5wx1045920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Nov 2013 19:05:58 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_9B848F55-8F16-445E-B2D0-1ED2A2291723"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: joel jaeggli In-Reply-To: Date: Thu, 7 Nov 2013 11:05:58 -0800 Message-Id: <1CC52A18-ADA1-4987-9AB4-2D6C75379AA8@bogus.com> References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> To: Ole Troan X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Thu, 07 Nov 2013 19:06:00 +0000 (UTC) Cc: Fernando Gont , "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 07 Nov 2013 19:06:05 -0000 --Apple-Mail=_9B848F55-8F16-445E-B2D0-1ED2A2291723 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2013, at 4:54 AM, Ole Troan wrote: > Nick, >=20 >>> if you use one of these in the Internet core I cannot see any other = choice than to >>> allow forwarding of fragments.=20 >>=20 >> no, drop! Because otherwise your infrastructure is wide open to = control >> plane attacks with ipv6 frags, with no means of defence! If that = happens, >> then your entire network falls over. >=20 > why don't you filter out packets on the edge destined to your router's = addresses? > instead of what's effectively breaking IPv6 service across the = network. my routers actually do process unsolicited packets from from the = internet (icmp echo for example, packets of any variety with a ttl of 1) = and do need the control plane acl that reflects that. >=20 > cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_9B848F55-8F16-445E-B2D0-1ED2A2291723 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJ75JYACgkQ8AA1q7Z/VrIHGgCfZPAUvLeob+V20EKfUK/Tix3S 20IAnR5mZ/wGNRMj3rHwNtLZqcKbSy1d =pZ1N -----END PGP SIGNATURE----- --Apple-Mail=_9B848F55-8F16-445E-B2D0-1ED2A2291723-- From simon.perreault@viagenie.ca Thu Nov 7 11:15: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 F2EE111E822F for ; Thu, 7 Nov 2013 11:15:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMglWRnINubB for ; Thu, 7 Nov 2013 11:15:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9769F21E80DF for ; Thu, 7 Nov 2013 11:15:49 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 97BB8403DB for ; Thu, 7 Nov 2013 14:15:42 -0500 (EST) Message-ID: <527BE6DD.7070609@viagenie.ca> Date: Thu, 07 Nov 2013 11:15:41 -0800 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5278275C.50206@gont.com.ar> <52783535.9030200@si6networks.com> <20131105001243.53E28985D0D@rock.dv.isc.org> <527839C6.3000805@viagenie.ca> <2134F8430051B64F815C691A62D98318148100@XCH-BLV-504.nw.nos.boeing.com> <52784DD1.7020106@gont.com.ar> <52785F34.6020606@si6networks.com> <5278E639.3040606@inex.ie> <5278E986.9050409@inex.ie> <1CC52A18-ADA1-4987-9AB4-2D6C75379AA8@bogus.com> In-Reply-To: <1CC52A18-ADA1-4987-9AB4-2D6C75379AA8@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 07 Nov 2013 19:15:55 -0000 Le 2013-11-07 11:05, joel jaeggli a écrit : >>>> if you use one of these in the Internet core I cannot see any other choice than to >>>> allow forwarding of fragments. >>> >>> no, drop! Because otherwise your infrastructure is wide open to control >>> plane attacks with ipv6 frags, with no means of defence! If that happens, >>> then your entire network falls over. >> >> why don't you filter out packets on the edge destined to your router's addresses? >> instead of what's effectively breaking IPv6 service across the network. > > my routers actually do process unsolicited packets from from the internet (icmp echo for example, packets of any variety with a ttl of 1) and do need the control plane acl that reflects that. Why is passing ICMP echos to the CP acceptable, and passing fragments to the CP is not acceptable? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From brian.e.carpenter@gmail.com Thu Nov 7 11:21: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 7B73E11E828C; Thu, 7 Nov 2013 11:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ1Tixzmnvsa; Thu, 7 Nov 2013 11:21:44 -0800 (PST) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DDACA11E828D; Thu, 7 Nov 2013 11:21:43 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id mz13so413479bkb.30 for ; Thu, 07 Nov 2013 11:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bIabsIcHA6ZJfIhoiBbd8a0Et6dQt3lhQ/KaVsKekEo=; b=dL+dvjy21rbKNtySs8I4Ll7h2kZboPvNqZps7RDwYDKHeT2RBNL5X/exrJkQS0eYVL Pve9umjIctiRj9X+OiyAslgumzmlgQQbJ+Lsegj3DWVNMWbAG2v3TLAayhVuasTaMxdQ lrvN2etWMUlx4gCr5gwrGAX8bkGM+yE78ItqQpxGrbPUhkydcz4yJOgcyquDS0MpdZlg jrnhM60F210Pt1RK1+9qvxv31kxGcWBjNDIvYMTwLg4RIJinNwOjkII/UTBC4S3+YFR6 8JJMwyrpHPiiEg1enk1kdWOkE2oXqK9aPxY5pU5P12LkWLNnykUOW20a2mfMhmF2KdVg Vq8Q== X-Received: by 10.204.171.142 with SMTP id h14mr7568747bkz.30.1383852102969; Thu, 07 Nov 2013 11:21:42 -0800 (PST) Received: from [31.133.165.38] (dhcp-a526.meeting.ietf.org. [31.133.165.38]) by mx.google.com with ESMTPSA id no2sm3317936bkb.15.2013.11.07.11.21.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 11:21:42 -0800 (PST) Message-ID: <527BE84E.2000205@gmail.com> Date: Fri, 08 Nov 2013 08:21:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> In-Reply-To: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , =?UTF-8?B?56We5piO6YGU5ZOJ?= , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 19:21:45 -0000 On 08/11/2013 07:56, Fred Baker (fred) wrote: > On Nov 7, 2013, at 10:42 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > wrote: >=20 >> At Thu, 7 Nov 2013 17:58:56 +0100, >> Jen Linkova wrote: >> >>> Looks like we (finally) have a chance to enforce the requirement from= >>> RFC4007, Section9: >>> >>> "If transmitting the packet on the chosen next-hop interface >>> would cause the packet to leave the zone of the source >>> address, i.e., >>> cross a zone boundary of the scope of the >>> source address, then the packet is discarded. " >>> >>> I'm seeing plenty of packets from link-local sources to global >>> destinations which means that: >>> 1) there are hosts with broken default address selection >>> AND >> (Probably an off-topic in this context but) this is not necessarily >> accurate. If a host only has a link-local address but somehow knows >> the interface to send packets to a global destination, it would be >> able to send packets with source being link-local and destination >> being global, and validly (not breaking RFC 6724) so. I believe it's >> more likely to be a broken network configuration than a broken host >> implementation. >=20 > I suspect it's some of each. The host should, I should think, set the h= op limit to one on any packet that is to a link-local address, to ensure = that the packet is not repeated by a broken router (apart from protocols = that ask to have it set to 255 and have the receiving host check for that= value). Also, upstream network's BCP 38 implementation sounds suspect, a= nd I'm with Jen in wondering why a router forwarded the packet in the fir= st place. Are you sure these packets come from hosts? There is a known case which is a router generating ICMP reply packets that has no GUA configured since all its peers are link-local. Brian From fred@cisco.com Thu Nov 7 14:57: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 33BEE11E815B for ; Thu, 7 Nov 2013 14:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.124 X-Spam-Level: X-Spam-Status: No, score=-110.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdR6Vt9HAZjf for ; Thu, 7 Nov 2013 14:57:00 -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 A978611E8140 for ; Thu, 7 Nov 2013 14:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2013; q=dns/txt; s=iport; t=1383865020; x=1385074620; h=from:to:cc:subject:date:message-id:mime-version; bh=JWVbtwuSfP8ZbVM/ecpGirvX/rXzRtaPjZpLspXln3o=; b=hOG22wnBciial0bDgC8hoGfHBDmiBEuAshmbja+DJwQOtXiFFHwBlM9C vweTATmefBYLIXU/+AltycB5xK4+g8a1jzrU7kbGeRxAaeubuBVyTJ/vo wwaIMLR9vNqeFLN1/yGzepVDNL2KcY+9MoJKSn0Nw506kdQP4lNIABOxS k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGEZfFKtJV2a/2dsb2JhbABagweBC78OgScWdIIsZQkLEgGBABQTBA4FDodzvTSPWYMngRADkC6BMIYukgqDJoIq X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="asc'?scan'208";a="282186227" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 07 Nov 2013 22:56:59 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA7Mux2I009766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 22:56:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 16:56:59 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Checking an outcome on the list Thread-Index: AQHO3Aype5QzVdxtfEaHGp2VxesyKQ== Date: Thu, 7 Nov 2013 22:56:58 +0000 Message-ID: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.80] Content-Type: multipart/signed; boundary="Apple-Mail=_ED0FB9DD-2ACF-4A6B-B641-A13BE7EAAFDE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Checking an outcome on the list 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, 07 Nov 2013 22:57:15 -0000 --Apple-Mail=_ED0FB9DD-2ACF-4A6B-B641-A13BE7EAAFDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We say we check f2f decisions on the mailing list to ensure that = everyone had a chance to speak. Let's do that. In IETF 88, we discussed a number of drafts. Of these: - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC = on Monday morning New Zealand time. - draft-ietf-v6ops-nat64-experience appears to have reached closure. = We have one additional revision coming, and then will do a 1 week last = call, probably early December. - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to = be a real problem.=20 1) In your opinion, should = draft-liu-bonica-v6ops-dhcpv6-slaac-problem be adopted as WG draft = draft-ietf-v6ops-dhcpv6-slaac-problem and matured into a problem = statement to present to 6man? 2) In your opinion, should v6ops invite a draft (which we might = adopt as a working group draft) that gives current guidance to operators = regarding the use of DHCP and SLAAC in their networks? - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft = draft-ietf-v6ops-ipv6-roaming-analysis? I'll collect up the responses in a week and make a determination based = on that. I'm interested in your viewpoint, whether positive or negative. = If you would prefer to send it privately to v6ops-chairs@tools.ietf.org, = that works too. --Apple-Mail=_ED0FB9DD-2ACF-4A6B-B641-A13BE7EAAFDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSfBq4bjEdbHIsm0MRAjmCAKDBPJkLAhDmTvrgVWVEewA0DTn8pACbBNkz RTGRIcBRknkvZftLh9swG3w= =x/OH -----END PGP SIGNATURE----- --Apple-Mail=_ED0FB9DD-2ACF-4A6B-B641-A13BE7EAAFDE-- From furry13@gmail.com Thu Nov 7 15:27: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 C5FB311E8103; Thu, 7 Nov 2013 15:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-AXll9Qp05c; Thu, 7 Nov 2013 15:27:27 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E2DF111E8278; Thu, 7 Nov 2013 15:27:24 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id n7so1108757qcx.13 for ; Thu, 07 Nov 2013 15:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VQxqJWkh/3nQG4mmBLkm0StRghWMOeanJOFthn2unaI=; b=ObA7wKbqjnGrhn4fGDghxlX3wIDtEKJnddxAd0YQhbNUiUDMwGp30dW59QMy/GnDot WCTCYdliIjV80a4AC3UwI1qvWbm+gGBnx/cSQe3ev0bwFloNRuDiJyiMkFsskKNW2NBh 5BKDDnFJD7freyf/c3LC895SmXqTChuR4Uc4EBkDLxLddGWHdJSAAdwDyFrlWIfFAa7l 9Q8mg0BoZTQWzwvs4Z21XLl7qLRCfid9dO6iVG3pNJtUU5gNo7MEJHHrOuPJ1Nb+doiN KUnCzcwUenmitVaidupvB3XBkhLZlOBSodZxcoXUsXUu38q4jsuhYXoSuLbBzSwPEXro bUXQ== X-Received: by 10.224.73.200 with SMTP id r8mr18903610qaj.72.1383866844074; Thu, 07 Nov 2013 15:27:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Thu, 7 Nov 2013 15:27:04 -0800 (PST) In-Reply-To: References: From: Jen Linkova Date: Fri, 8 Nov 2013 00:27:04 +0100 Message-ID: To: Hermin Anggawijaya Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 23:27:32 -0000 On Thu, Nov 7, 2013 at 7:40 PM, Hermin Anggawijaya wrote: >> I'm seeing plenty of packets from link-local sources to global >> destinations >> ..... > >> 2) routers on the Internet do forward such packets (violating the rule >> mentioned above). >> Fixing #2 actually requires making forwarding decision based on src >> and dst (which is not happening now). > > To fix the above issue, wouldn't address scope checking be enough, rather > than the [src,dst] based routing > discussed ? My point is that to do verify the scope, the router need to check *source* address while making forwarding decision. It looks like it is not happening now but it might get changed by [src, dst] based routing. > On Thu, Nov 7, 2013 at 8:58 AM, Jen Linkova wrote: >> >> On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) wrote: >> > Examples of use cases are generally around multi-prefix campus networks. >> > There is a security use case that could be of value; at IETF 87, George >> > Michaelson of APNIC reported on ULAs seen in his darknet. The short report >> > is that he sees a fair bit of traffic with a ULA source address on the >> > backbone. An interesting potential use of source/destination routing would >> > counter that, and perhaps mitigate the need for ISP BCP 38 if generally >> > deployed; in a case where a network is using a ULA and a global prefix >> > (e.g., is not multihomed but has two prefixes, one of which is intended to >> > only be used within its network), the default route to the network egress >> > would use the global prefix as a source, and as a result traffic sent >> > outside the network with a ULA source prefix would in effect have no route. >> > The network could literally only emit traffic from its correct prefix. >> >> Looks like we (finally) have a chance to enforce the requirement from >> RFC4007, Section9: >> >> "If transmitting the packet on the chosen next-hop interface >> would cause the packet to leave the zone of the source >> address, i.e., >> cross a zone boundary of the scope of the >> source address, then the packet is discarded. " >> >> I'm seeing plenty of packets from link-local sources to global >> destinations which means that: >> 1) there are hosts with broken default address selection >> AND >> 2) routers on the Internet do forward such packets (violating the rule >> mentioned above). >> Fixing #2 actually requires making forwarding decision based on src >> and dst (which is not happening now). >> >> More data (sorry, shameless plug :)) >> https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf >> >> -- >> SY, Jen Linkova aka Furry >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > -- SY, Jen Linkova aka Furry From furry13@gmail.com Thu Nov 7 15:34: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 63EA321E80E6; Thu, 7 Nov 2013 15:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+EBk6XBGArb; Thu, 7 Nov 2013 15:34:07 -0800 (PST) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 38A7021E80DB; Thu, 7 Nov 2013 15:34:03 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 1so1268699qee.9 for ; Thu, 07 Nov 2013 15:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=7O5+0IPZlfYycRXZ63fTXsoFEt1xEUP2gAkfLHf8VPY=; b=Y6hzgmkGthS0k7kFOnKk8ajQR+nlB6wdYgohljjOQBHSzYoWAkjeJKc6XUCKEVW0PL DeASkE/F9uKgqnDQ/Pol3VWfr0R7et5s6ORCD/2slckuIhGGphLbJF39HnX+9UODuFLI WpCI+oRzgXxv/RgMks6SuSm2LExaeRqP/evbF6zMT3N2zQMyLC1WDo7wW9qvFPYXWSTQ h7q82BzPzPhfBpbpUqOGqO8Kc7ra0yeiM7Od19u1WSNTmDeMbPriTu8CMP6uCtNp8sea F8bW0rk6y9xXKAw0STkrn8sf3SbHM1V1zmIniMgYlfggFaFFHUYNrX8TFq7AfWeLD3DQ HNPw== X-Received: by 10.224.162.211 with SMTP id w19mr18623220qax.59.1383867240454; Thu, 07 Nov 2013 15:34:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Thu, 7 Nov 2013 15:33:40 -0800 (PST) In-Reply-To: <527BE84E.2000205@gmail.com> References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> <527BE84E.2000205@gmail.com> From: Jen Linkova Date: Fri, 8 Nov 2013 00:33:40 +0100 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , Routing WG , =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 23:34:08 -0000 On Thu, Nov 7, 2013 at 8:21 PM, Brian E Carpenter wrote: >> I suspect it's some of each. The host should, I should think, set the ho= p limit to one on any packet that is to a link-local address, to ensure tha= t the packet is not repeated by a broken router (apart from protocols that = ask to have it set to 255 and have the receiving host check for that value)= . Also, upstream network's BCP 38 implementation sounds suspect, and I'm wi= th Jen in wondering why a router forwarded the packet in the first place. > > Are you sure these packets come from hosts? There is a known case > which is a router generating ICMP reply packets that has no GUA > configured since all its peers are link-local. I saw packets with link-local source/GUA destination coming from hosts and from routers (I analyzed EUI-64-based IIDs) back in 2011. Now majority of such traffic is TCP to our services and, again, IID checks shows that these packets are from hosts. --=20 SY, Jen Linkova aka Furry From brian.e.carpenter@gmail.com Thu Nov 7 15:39: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 D765521E8194 for ; Thu, 7 Nov 2013 15:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OMR+VZnharU for ; Thu, 7 Nov 2013 15:39:50 -0800 (PST) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2C81611E817A for ; Thu, 7 Nov 2013 15:39:18 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id na10so602269bkb.0 for ; Thu, 07 Nov 2013 15:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1WUp19CUHRmJ4bm5+PW1Xcn2R/QSY+K2vKdc/R6zS8g=; b=OiBrRAz4LYUgqQ4y03unh0OUtH17xNC/VIXo4FWT2zlWZi8k4FYDPMwz0W+YhXHFuc kXaaEbFSbiRAnShLLdByI6uYQE9eeJtoM90Kswg4bJ12b573H9Uk40/br2UHqZGOCDFF 7iULm4vRqIRebVXzbJ0kNyfJcUbC8uxilaBzsC1mdTweu7nOqbmyo4m9KBAZCszzTjGg uf2ekC+vaxKQIxwFxYoN0joZXpWQYwS4wtju/6Mbv1FZgA/5N3mmUOBmbScc2gPTXq3r 1ZaM0r/GR7lo7qwf+WnjnJmjbrvOp195C2gXA0nO33+hT9Sxc1VGkyz7S85uNZDuHN2B 7keA== X-Received: by 10.205.10.200 with SMTP id pb8mr8613400bkb.16.1383867548160; Thu, 07 Nov 2013 15:39:08 -0800 (PST) Received: from [31.133.165.38] (dhcp-a526.meeting.ietf.org. [31.133.165.38]) by mx.google.com with ESMTPSA id pu8sm3852278bkb.9.2013.11.07.15.39.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 15:39:07 -0800 (PST) Message-ID: <527C24A3.40505@gmail.com> Date: Fri, 08 Nov 2013 12:39:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> In-Reply-To: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Checking an outcome on the list 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, 07 Nov 2013 23:39:51 -0000 On 08/11/2013 11:56, Fred Baker (fred) wrote: > We say we check f2f decisions on the mailing list to ensure that everyone had a chance to speak. Let's do that. > > In IETF 88, we discussed a number of drafts. Of these: > - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC on Monday morning New Zealand time. Good choice (of time zone) > - draft-ietf-v6ops-nat64-experience appears to have reached closure. We have one additional revision coming, and then will do a 1 week last call, probably early December. > - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to be a real problem. > 1) In your opinion, should draft-liu-bonica-v6ops-dhcpv6-slaac-problem be adopted as WG draft draft-ietf-v6ops-dhcpv6-slaac-problem and matured into a problem statement to present to 6man? Yes > 2) In your opinion, should v6ops invite a draft (which we might adopt as a working group draft) that gives current guidance to operators regarding the use of DHCP and SLAAC in their networks? Assuming you mean "based on current specifications and implementations", yes. > - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft draft-ietf-v6ops-ipv6-roaming-analysis? No objection. Brian From tjc@ecs.soton.ac.uk Thu Nov 7 15:47: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 DF1CD21F9985; Thu, 7 Nov 2013 15:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h6j0aIBkAd5; Thu, 7 Nov 2013 15:47:47 -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 2759821F8F61; Thu, 7 Nov 2013 15:47:42 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA7NleBL014483; Thu, 7 Nov 2013 23:47:40 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA7NleBL014483 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383868060; bh=aQC6ux+DdJRqGiKUSnmuyE59k7g=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=BbsJgYUKzu9ypKwZ/p1SHAXB2ApZ26UeZWX319Wz8zZIQmqMXXJ7UubrSZ5Haqt/j 1t9aj8oIj7vzuuBsBCdxHPdPKcncGjYrHr6qZQoYXAYuA6ximPccleaFJwmdv8wfD5 uGuhyQS93uwYObgm6Pxc4FWzFOdcoTLF9vmWt3cc= 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 pA6Nle0959602001IS ret-id none; Thu, 07 Nov 2013 23:47:40 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:4cc9:61d9:dc83:b91] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA7NlUKi024624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Nov 2013 23:47:33 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Thu, 7 Nov 2013 23:47:30 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> <527BE84E.2000205@gmail.com> To: Jen Linkova X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA6Nle095960200100; tid=pA6Nle0959602001IS; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA7NleBL014483 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org WG" , =?utf-8?B?56We5piO6YGU5ZOJ?= , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 23:47:48 -0000 On 7 Nov 2013, at 23:33, Jen Linkova wrote: > On Thu, Nov 7, 2013 at 8:21 PM, Brian E Carpenter > wrote: >=20 >>> I suspect it's some of each. The host should, I should think, set = the hop limit to one on any packet that is to a link-local address, to = ensure that the packet is not repeated by a broken router (apart from = protocols that ask to have it set to 255 and have the receiving host = check for that value). Also, upstream network's BCP 38 implementation = sounds suspect, and I'm with Jen in wondering why a router forwarded the = packet in the first place. >>=20 >> Are you sure these packets come from hosts? There is a known case >> which is a router generating ICMP reply packets that has no GUA >> configured since all its peers are link-local. >=20 > I saw packets with link-local source/GUA destination coming from hosts > and from routers (I analyzed EUI-64-based IIDs) back in 2011. Now > majority of such traffic is TCP to our services and, again, IID checks > shows that these packets are from hosts. Any specifc clues by vendor? Tim= From furry13@gmail.com Thu Nov 7 15:58: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 4FFA011E8162; Thu, 7 Nov 2013 15:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnWRlTaXTLEI; Thu, 7 Nov 2013 15:58:43 -0800 (PST) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id D485011E80FA; Thu, 7 Nov 2013 15:58:42 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id w7so1279465qeb.11 for ; Thu, 07 Nov 2013 15:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KEwxCVBSWhFI/UFuCzdI+tCoaF/MKMGbRzKZZsmsJa0=; b=kbM59qpL/vtC4xbYMHivlKPXDCQj59HuNl4N6X4cjhBwFV+4xN4srdk1leJi+AgdM/ YSLVJ0mFLvA7TWA39mMlKkzod9dQPt+C4vj1+zY+bS3e38d1zffUEF8yOTqz2dD3uaWA 98kdD0Eo4gImCqkVndXjkaX14qqVTMJ/Xqt/beCMClxuINh27OwwEy4ateFBDNF2kRAQ CFSJlogeiYbjkKgXu5/zRhCa/He6pPuZ4vD+IMkQzf00esjXasXXbOe874nj+HFWtRD6 g/xeKRHvvYL/5iOy39LfuHeFq0KhQz1nvqYT0CECdhbbrOueqSR8vgBt7JBWzVmwmqu9 gJgw== X-Received: by 10.49.51.103 with SMTP id j7mr17380153qeo.29.1383868722296; Thu, 07 Nov 2013 15:58:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Thu, 7 Nov 2013 15:58:22 -0800 (PST) In-Reply-To: References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> <527BE84E.2000205@gmail.com> From: Jen Linkova Date: Fri, 8 Nov 2013 00:58:22 +0100 Message-ID: To: Tim Chown Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" , =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 07 Nov 2013 23:58:44 -0000 On Fri, Nov 8, 2013 at 12:47 AM, Tim Chown wrote: >> I saw packets with link-local source/GUA destination coming from hosts >> and from routers (I analyzed EUI-64-based IIDs) back in 2011. Now >> majority of such traffic is TCP to our services and, again, IID checks >> shows that these packets are from hosts. > > Any specifc clues by vendor? I decided not to put any names on the slides but I identified ~20 vendors (see slide #8 at https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf ) P.S. One more reason for me to like EUI-64-based IID ;-)) -- SY, Jen Linkova aka Furry From hermin.anggawijaya@gmail.com Thu Nov 7 16:14: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 5C41E21E808A; Thu, 7 Nov 2013 16:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWeyFAY4R7L1; Thu, 7 Nov 2013 16:14:10 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 63DE421E80E6; Thu, 7 Nov 2013 16:13:40 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hv10so936156vcb.29 for ; Thu, 07 Nov 2013 16:13:39 -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=c0lBn4r1XwQnCZPjY3+GvpMytpW+sYeasZHkcDgjCLA=; b=OSFUjs5d2mPjA1MIaMHTwWwyxswGlIpMyl+Yz/Jxe4aZlEAfMUhU8r4pE4joeEYcun DLZw79qyNgAqPRk5tfuC8NwUTcu4zwfJLINZlasXkjLcb+OkZI/gcB+sMXm4eO7ookvC xM9I6iDPG6bEA7paQtf5rxhmRshQIBhpGnU1/eivk7G9eaM33kjo+S+Kqerzk2JxorI2 8kAQadVEIWh3cyOxJC1gj190T6EtPR/00/WykzM3s1IUVqO4w6PhLOV+4fqylMuvx3Lm TvyM3nVn7CWMOzZ0aQNsuLin9sM/x0FTa5rEDSf2hLXa7uMJuGVeqW6G2hkXaizPM3eh rmmg== MIME-Version: 1.0 X-Received: by 10.58.210.66 with SMTP id ms2mr9091736vec.10.1383869619794; Thu, 07 Nov 2013 16:13:39 -0800 (PST) Received: by 10.58.188.72 with HTTP; Thu, 7 Nov 2013 16:13:39 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 16:13:39 -0800 Message-ID: From: Hermin Anggawijaya To: Jen Linkova Content-Type: multipart/alternative; boundary=047d7bd6ae8c1a789604ea9f4126 Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 08 Nov 2013 00:14:11 -0000 --047d7bd6ae8c1a789604ea9f4126 Content-Type: text/plain; charset=ISO-8859-1 wrote: >> I'm seeing plenty of packets from link-local sources to global >> destinations >> ..... > >> 2) routers on the Internet do forward such packets (violating the rule >> mentioned above). >> Fixing #2 actually requires making forwarding decision based on src >> and dst (which is not happening now). > > To fix the above issue, wouldn't address scope checking be enough, rather > than the [src,dst] based routing > discussed ? > My point is that to do verify the scope, the router need to check > *source* address while making forwarding decision. > It looks like it is not happening now but it might get changed by > [src, dst] based routing. scope checking does not need to look up any fib though whereas [src,dst] forwarding does. I think scope checking feature is standard even on switching silicons *today*. But I think I understand what you are trying to say, we just have different interpretation of the phrase [src,dst] forwarding. Thanks. On Thu, Nov 7, 2013 at 3:27 PM, Jen Linkova wrote: > On Thu, Nov 7, 2013 at 7:40 PM, Hermin Anggawijaya > wrote: > >> I'm seeing plenty of packets from link-local sources to global > >> destinations > >> ..... > > > >> 2) routers on the Internet do forward such packets (violating the rule > >> mentioned above). > >> Fixing #2 actually requires making forwarding decision based on src > >> and dst (which is not happening now). > > > > To fix the above issue, wouldn't address scope checking be enough, rather > > than the [src,dst] based routing > > discussed ? > > My point is that to do verify the scope, the router need to check > *source* address while making forwarding decision. > It looks like it is not happening now but it might get changed by > [src, dst] based routing. > > > On Thu, Nov 7, 2013 at 8:58 AM, Jen Linkova wrote: > >> > >> On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) > wrote: > >> > Examples of use cases are generally around multi-prefix campus > networks. > >> > There is a security use case that could be of value; at IETF 87, > George > >> > Michaelson of APNIC reported on ULAs seen in his darknet. The short > report > >> > is that he sees a fair bit of traffic with a ULA source address on the > >> > backbone. An interesting potential use of source/destination routing > would > >> > counter that, and perhaps mitigate the need for ISP BCP 38 if > generally > >> > deployed; in a case where a network is using a ULA and a global prefix > >> > (e.g., is not multihomed but has two prefixes, one of which is > intended to > >> > only be used within its network), the default route to the network > egress > >> > would use the global prefix as a source, and as a result traffic sent > >> > outside the network with a ULA source prefix would in effect have no > route. > >> > The network could literally only emit traffic from its correct prefix. > >> > >> Looks like we (finally) have a chance to enforce the requirement from > >> RFC4007, Section9: > >> > >> "If transmitting the packet on the chosen next-hop interface > >> would cause the packet to leave the zone of the source > >> address, i.e., > >> cross a zone boundary of the scope of the > >> source address, then the packet is discarded. " > >> > >> I'm seeing plenty of packets from link-local sources to global > >> destinations which means that: > >> 1) there are hosts with broken default address selection > >> AND > >> 2) routers on the Internet do forward such packets (violating the rule > >> mentioned above). > >> Fixing #2 actually requires making forwarding decision based on src > >> and dst (which is not happening now). > >> > >> More data (sorry, shameless plug :)) > >> https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf > >> > >> -- > >> SY, Jen Linkova aka Furry > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > -- > SY, Jen Linkova aka Furry > --047d7bd6ae8c1a789604ea9f4126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<h= ermin.anggawijaya@gmail.com> wrote:
>> I'm seeing plenty of packets from link-local sources to global=
>> destinations
>> .....
>
>> 2) routers on the Internet do forward such packets (violating the = rule
>> mentioned above).
>> Fixing #2 actually requires making forwarding decision based on sr= c
>> and dst (which is not happening now).
>
> To fix the above issue, wouldn't address scope checking be enough,= rather
> than the [src,dst] based routing
> discussed ?

> My point is that to do verify the scope, the router need to check
> *source* address while making forwarding decision.
> It looks like it is not happening now but it might get changed by
> [src, dst] based routing.

scope checking does not need to= look up any fib though whereas [src,dst] forwarding does. I think scope ch= ecking feature is standard even on switching silicons *today*.

But I think I understand what you are trying to say, we just have different= interpretation of the phrase [src,dst] forwarding. Thanks.




On Thu, Nov= 7, 2013 at 3:27 PM, Jen Linkova <furry13@gmail.com> wrote:<= br>
On Thu, Nov 7, 2013 at 7:4= 0 PM, Hermin Anggawijaya
<hermin.anggawijaya@gmai= l.com> wrote:
>> I'm seeing plenty of packets from link-local sources to global=
>> destinations
>> .....
>
>> 2) routers on the Internet do forward such packets (violating the = rule
>> mentioned above).
>> Fixing #2 actually requires making forwarding decision based on sr= c
>> and dst (which is not happening now).
>
> To fix the above issue, wouldn't address scope checking be enough,= rather
> than the [src,dst] based routing
> discussed ?

My point is that to do verify the scope, the router need to check
*source* address while making forwarding decision.
It looks like it is not happening now but it might get changed by
[src, dst] based routing.

> On Thu, Nov 7, 2013 at 8:58 AM, Jen Linkova <furry13@gmail.com> wrote:
>>
>> On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) <fred@cisco.com> wrote:
>> > Examples of use cases are generally around multi-prefix campu= s networks.
>> > There is a security use case that could be of value; at IETF = 87, George
>> > Michaelson of APNIC reported on ULAs seen in his darknet. The= short report
>> > is that he sees a fair bit of traffic with a ULA source addre= ss on the
>> > backbone. An interesting potential use of source/destination = routing would
>> > counter that, and perhaps mitigate the need for ISP BCP 38 if= generally
>> > deployed; in a case where a network is using a ULA and a glob= al prefix
>> > (e.g., is not multihomed but has two prefixes, one of which i= s intended to
>> > only be used within its network), the default route to the ne= twork egress
>> > would use the global prefix as a source, and as a result traf= fic sent
>> > outside the network with a ULA source prefix would in effect = have no route.
>> > The network could literally only emit traffic from its correc= t prefix.
>>
>> Looks like we (finally) have a chance to enforce the requirement f= rom
>> RFC4007, Section9:
>>
>> "If transmitting the packet on the chosen next-hop interface<= br> >> would cause the packet to leave the zone of the source
>> address, i.e.,
>> cross a zone boundary of the scope of the
>> source address, then the packet is discarded. "
>>
>> I'm seeing plenty of packets from link-local sources to global=
>> destinations which means that:
>> 1) there are hosts with broken default address selection
>> AND
>> 2) routers on the Internet do forward such packets (violating the = rule
>> mentioned above).
>> Fixing #2 actually requires making forwarding decision based on sr= c
>> and dst (which is not happening now).
>>
>> More data (sorry, shameless plug :))
>> https://ripe67.ripe.net/presentations/288-Jen_RIPE67.p= df
>>
>> --
>> SY, Jen Linkova aka Furry
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>



--
SY, Jen Linkova aka Furry

--047d7bd6ae8c1a789604ea9f4126-- From swmike@swm.pp.se Thu Nov 7 17:44: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 477AD11E815A for ; Thu, 7 Nov 2013 17:44:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU7tjUYCq-bp for ; Thu, 7 Nov 2013 17:44:33 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA5011E8288 for ; Thu, 7 Nov 2013 17:43:03 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4174B9C; Fri, 8 Nov 2013 02:43:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 324F29A; Fri, 8 Nov 2013 02:43:00 +0100 (CET) Date: Fri, 8 Nov 2013 02:43:00 +0100 (CET) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> Message-ID: References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Checking an outcome on the list 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, 08 Nov 2013 01:44:35 -0000 On Thu, 7 Nov 2013, Fred Baker (fred) wrote: > - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC on Monday morning New Zealand time. Support. > - draft-ietf-v6ops-nat64-experience appears to have reached closure. We have one additional revision coming, and then will do a 1 week last call, probably early December. Support. > - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to be a real problem. > 1) In your opinion, should draft-liu-bonica-v6ops-dhcpv6-slaac-problem be adopted as WG draft draft-ietf-v6ops-dhcpv6-slaac-problem and matured into a problem statement to present to 6man? Yes. > 2) In your opinion, should v6ops invite a draft (which we might adopt as a working group draft) that gives current guidance to operators regarding the use of DHCP and SLAAC in their networks? Yes. > - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft draft-ietf-v6ops-ipv6-roaming-analysis? Yes. -- Mikael Abrahamsson email: swmike@swm.pp.se From jinmei.tatuya@gmail.com Thu Nov 7 17:57: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 DC56321E812A; Thu, 7 Nov 2013 17:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLzrVN6gANzW; Thu, 7 Nov 2013 17:57:40 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 05ADB11E8202; Thu, 7 Nov 2013 17:57:39 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id p61so1350492wes.19 for ; Thu, 07 Nov 2013 17:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zgVjAlROUt9KGVRQGhItVS8zPr5ljZRGBTbib1QjHiM=; b=rJHer06FyrS1ewUomJvoHJQnYcn5vTvLAFBMC17BKQF6wuoE02pUY8KXTM8NBjc8jK Usf5oWwelDe+4jfqU0JBl3ZUbc8LPtOOBbfGVow9For3wPZ1P3Uq4Jj9ReJAqiXmDezU 31ZEtlUq2GAp/ngFSRjTZoJ6T7pX+eT6c2DjzI3kAENbNyLt5D+d/wbYaxC7PnBsULNU /CREWzcxRgYXlzp6MHyWDIjbd5PQApe0WRXdKnqhttmztuYMFY2q1iqAVhefQdgF04Yl NHLcmlVgbTVoFooetx1TIE+BXLLMvjtvDzfIuUV0Nr6c2r+wOCFzwGzLKAOLQHjrMuzl LEWQ== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr346685wic.64.1383875859119; Thu, 07 Nov 2013 17:57:39 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Thu, 7 Nov 2013 17:57:39 -0800 (PST) In-Reply-To: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> Date: Thu, 7 Nov 2013 17:57:39 -0800 X-Google-Sender-Auth: IRpez4kP4GKGXxyaI24a-YCdkQY Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 08 Nov 2013 01:57:41 -0000 At Thu, 7 Nov 2013 18:56:12 +0000, "Fred Baker (fred)" wrote: > >> I'm seeing plenty of packets from link-local sources to global > >> destinations which means that: > >> 1) there are hosts with broken default address selection > >> AND > > > > (Probably an off-topic in this context but) this is not necessarily > > accurate. If a host only has a link-local address but somehow knows > > the interface to send packets to a global destination, it would be > > able to send packets with source being link-local and destination > > being global, and validly (not breaking RFC 6724) so. I believe it's > > more likely to be a broken network configuration than a broken host > > implementation. > > I suspect it's some of each. The host should, I should think, set > the hop limit to one on any packet that is to a link-local address, To make it sure: this is about the case of packets "from" a link-local address. > to ensure that the packet is not repeated by a broken router (apart > from protocols that ask to have it set to 255 and have the receiving > host check for that value). Also, upstream network's BCP 38 I'd note, from purely architectural point of view, that it's totally valid a packet that has a link-local address is forwarded, as long as the packet remains in the originating link zone. That would be a very unlikely case in practice, but can still happen, e.g., when a host sends all packets to a router, expecting the router to forward it back to the same link toward the destination. RFC 4007 mentions such cases. That said, I see it should be a very rare case except for implementation or operational errors. So it may make sense to introduce something similar to the IPV6_MULTICAST_HOPS socket option defined in RFC 3493 and define its default value to be 1 for narrower scopes. > implementation sounds suspect, and I'm with Jen in wondering why a > router forwarded the packet in the first place. It's not surprising to me since the source address is not needed as long as routing decision is only made based on the destination address. I noticed one popular router vendor didn't implement this restriction of RFC 4007 correctly many years ago and even reported it to the vendor, but (assuming it's still not fixed) just being "non compliant" is probably not convincing enough for them to introduce additional overhead in their forwarding logic. -- JINMEI, Tatuya From gnocuil@gmail.com Thu Nov 7 18:15: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 E7C2721E80AF for ; Thu, 7 Nov 2013 18:15:26 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+VFgq9mg17O for ; Thu, 7 Nov 2013 18:15:26 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2311E8170 for ; Thu, 7 Nov 2013 18:15:25 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id s19so1224747qcw.21 for ; Thu, 07 Nov 2013 18:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KrXrC/7yAI3B9+KSBoqCoIBLpN2kpzxn0Hmx6BWbu5E=; b=CRfEIajskJ9mh1iCZyaIm+PaiyNVxCbpjCOE+dcm71YPQpnTCTqv/R16foWfCwefA8 CtmIv+KnnIkf6qUeagTgCtCHOfrU4laSf2krtdawijZJjfMGMlbYl74owKxxNukF9daO jHoPJpT+ZjOpJFf3XbZM7oz72vko00Com5vK1iMhNV0nChzAIygrAp7VsThz0X582Y5j H37KBWFX7F39caT5FWlEB1qSn8qQKBaYGTpYbWuE2g7z9TuG6+INAYdlin1Iqzqix3W5 y9Ky+8ktjKCkrY7KQU9w5ed0alrOB4dF77QEDJ62qJ4F6kd3pmdULvZ3zSzyBlneY5Hf JluA== X-Received: by 10.224.124.134 with SMTP id u6mr19433606qar.79.1383876925504; Thu, 07 Nov 2013 18:15:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Thu, 7 Nov 2013 18:15:05 -0800 (PST) In-Reply-To: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> From: Cong Liu Date: Thu, 7 Nov 2013 18:15:05 -0800 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11c29e9c8ec1f404eaa0f420 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Checking an outcome on the list 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, 08 Nov 2013 02:15:27 -0000 --001a11c29e9c8ec1f404eaa0f420 Content-Type: text/plain; charset=ISO-8859-1 Hi all, 2013/11/7 Fred Baker (fred) > We say we check f2f decisions on the mailing list to ensure that everyone > had a chance to speak. Let's do that. > > In IETF 88, we discussed a number of drafts. Of these: > - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC on > Monday morning New Zealand time. > I support > - draft-ietf-v6ops-nat64-experience appears to have reached closure. We > have one additional revision coming, and then will do a 1 week last call, > probably early December. > I support > - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to be > a real problem. > 1) In your opinion, should > draft-liu-bonica-v6ops-dhcpv6-slaac-problem be adopted as WG draft > draft-ietf-v6ops-dhcpv6-slaac-problem and matured into a problem statement > to present to 6man? > Yes > 2) In your opinion, should v6ops invite a draft (which we might > adopt as a working group draft) that gives current guidance to operators > regarding the use of DHCP and SLAAC in their networks? > Yes > - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft > draft-ietf-v6ops-ipv6-roaming-analysis? > Yes > > I'll collect up the responses in a week and make a determination based on > that. I'm interested in your viewpoint, whether positive or negative. If > you would prefer to send it privately to v6ops-chairs@tools.ietf.org, > that works too. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > Best Regards, Cong --001a11c29e9c8ec1f404eaa0f420 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

2013/11/7 Fred Baker (fred) <fred@cisco.com>
We say we check f2f decisions on the mailing list to ensure that everyone h= ad a chance to speak. Let's do that.

In IETF 88, we discussed a number of drafts. Of these:
=A0 - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC on= Monday morning New Zealand time.
I support
= =A0
=A0 - draft-ietf-v6ops-nat64-experience appears to have reached closure. We= have one additional revision coming, and then will do a 1 week last call, = probably early December.
I support
=A0
=A0 - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to b= e a real problem.
=A0 =A0 =A0 1) In your opinion, should draft-liu-bonica-v6ops-dhcpv6-slaac-= problem be adopted as WG draft draft-ietf-v6ops-dhcpv6-slaac-problem and ma= tured into a problem statement to present to 6man?
Yes=
=A0
=A0 =A0 =A0 2) In your opinion, should v6ops invite a draft (which we might= adopt as a working group draft) that gives current guidance to operators r= egarding the use of DHCP and SLAAC in their networks?
= Yes
=A0
=A0 - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft = draft-ietf-v6ops-ipv6-roaming-analysis?
Yes=A0

I'll collect up the responses in a week and make a determination based = on that. I'm interested in your viewpoint, whether positive or negative= . If you would prefer to send it privately to v6ops-chairs@tools.ietf.org, that works too.

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


Best Regards,
Cong
--001a11c29e9c8ec1f404eaa0f420-- From owen@delong.com Thu Nov 7 18:44: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 1D90521F9CA5; Thu, 7 Nov 2013 18:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbA25ofl3BjO; Thu, 7 Nov 2013 18:44:21 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 33AEE11E815E; Thu, 7 Nov 2013 18:44:04 -0800 (PST) Received: from [172.20.72.215] (63-235-172-7.dia.static.qwest.net [63.235.172.7]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rA82g25L013739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Nov 2013 18:42:08 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rA82g25L013739 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1383878531; bh=/hcgWLX/FyNGeFMpZeF8Wf+gEgo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=z3P5whR+oUL0EpAWKigfrNXryd64FqdSgwPD0dpLGUzMSqCNy6r1wzlG0QrMHQraZ Pq1Wp/2ApWgeHboCjup5Cr+dNlxcG6xI7jF+74HJO43fLGXzKjvSy3FSXRR3EEAmKN 5WRZNQv59sZrpVG+9oyDpdV/u52pyhQLwkqTrUXM= Content-Type: multipart/alternative; boundary="Apple-Mail=_83FE3C79-55CD-4723-AE10-8E286E15210D" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Owen DeLong In-Reply-To: Date: Thu, 7 Nov 2013 18:42:02 -0800 Message-Id: <3447189B-394A-429E-A24B-29E6791B9109@delong.com> References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 07 Nov 2013 18:42:11 -0800 (PST) Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 08 Nov 2013 02:44:28 -0000 --Apple-Mail=_83FE3C79-55CD-4723-AE10-8E286E15210D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> to ensure that the packet is not repeated by a broken router (apart >> from protocols that ask to have it set to 255 and have the receiving >> host check for that value). Also, upstream network's BCP 38 >=20 > I'd note, from purely architectural point of view, that it's totally > valid a packet that has a link-local address is forwarded, as long as > the packet remains in the originating link zone. That would be a very > unlikely case in practice, but can still happen, e.g., when a host > sends all packets to a router, expecting the router to forward it back > to the same link toward the destination. RFC 4007 mentions such > cases. That is not correct=85 RFC 4291 says: 2.5.6. Link-Local IPv6 Unicast Addresses Link-Local addresses are for use on a single link. Link-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present. Routers must not forward any packets with Link-Local source or destination addresses to other links. It is quite clear that a packet with a link-local address in either = field MUST not be forwarded. >> implementation sounds suspect, and I'm with Jen in wondering why a >> router forwarded the packet in the first place. >=20 > It's not surprising to me since the source address is not needed as > long as routing decision is only made based on the destination > address. I noticed one popular router vendor didn't implement this > restriction of RFC 4007 correctly many years ago and even reported it > to the vendor, but (assuming it's still not fixed) just being "non > compliant" is probably not convincing enough for them to introduce > additional overhead in their forwarding logic. It's surprising to me and it means that the router is, by definition, = not compliant with RFC 4291, ergo, the router is broken. Owen --Apple-Mail=_83FE3C79-55CD-4723-AE10-8E286E15210D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
to ensure = that the packet is not repeated by a broken router (apart
from = protocols that ask to have it set to 255 and have the receiving
host = check for that value). Also, upstream network's BCP = 38

I'd note, from purely architectural point of = view, that it's totally
valid a packet that has a link-local address = is forwarded, as long as
the packet remains in the originating link = zone.  That would be a very
unlikely case in practice, but can = still happen, e.g., when a host
sends all packets to a router, = expecting the router to forward it back
to the same link toward the = destination.  RFC 4007 mentions = such
cases.

That is not = correct=85

RFC 4291 = says:

2.5.6.  Link-Local IPv6 Unicast =
Addresses


   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

It is = quite clear that a packet with a link-local address in either field MUST = not be forwarded.

implementation sounds suspect, = and I'm with Jen in wondering why a
router forwarded the packet in = the first place.

It's not surprising to me since the = source address is not needed as
long as routing decision is only made = based on the destination
address.  I noticed one popular router = vendor didn't implement this
restriction of RFC 4007 correctly many = years ago and even reported it
to the vendor, but (assuming it's = still not fixed) just being "non
compliant" is probably not = convincing enough for them to introduce
additional overhead in their = forwarding logic.

It's surprising to me = and it means that the router is, by definition, not compliant with RFC = 4291, ergo, the router is = broken.

Owen

= --Apple-Mail=_83FE3C79-55CD-4723-AE10-8E286E15210D-- From owen@delong.com Thu Nov 7 18:44: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 7DF3711E81FA; Thu, 7 Nov 2013 18:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb293f3L-ynD; Thu, 7 Nov 2013 18:44:21 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11821E80F4; Thu, 7 Nov 2013 18:44:15 -0800 (PST) Received: from [172.20.72.215] (63-235-172-7.dia.static.qwest.net [63.235.172.7]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rA82ct5Z013553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Nov 2013 18:38:56 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rA82ct5Z013553 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1383878352; bh=N08vyre+erX5G3lix3bAakYdVjU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YajQ79gg0ct2CRuHOHM8s4VYhMnuZkN34g7fB0eh76TWG1yHDWPQYrmOfVbB4YMXn MrNxOzAT+G8nkqZl1N9/IL/UTULAy/cO9U9BQRt+z03WXmJ6KJt66Q9LbyTTHxS30w Y5AyIX9lr+ESMuo9d8S4Ztr/QttFtMmZvfpFTuGY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Owen DeLong In-Reply-To: Date: Thu, 7 Nov 2013 18:38:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> <527BE84E.2000205@gmail.com> To: Jen Linkova X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 07 Nov 2013 18:39:12 -0800 (PST) Cc: "v6ops@ietf.org WG" , =?utf-8?B?56We5piO6YGU5ZOJ?= , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 08 Nov 2013 02:44:31 -0000 On Nov 7, 2013, at 3:33 PM, Jen Linkova wrote: > On Thu, Nov 7, 2013 at 8:21 PM, Brian E Carpenter > wrote: >=20 >>> I suspect it's some of each. The host should, I should think, set = the hop limit to one on any packet that is to a link-local address, to = ensure that the packet is not repeated by a broken router (apart from = protocols that ask to have it set to 255 and have the receiving host = check for that value). Also, upstream network's BCP 38 implementation = sounds suspect, and I'm with Jen in wondering why a router forwarded the = packet in the first place. >>=20 >> Are you sure these packets come from hosts? There is a known case >> which is a router generating ICMP reply packets that has no GUA >> configured since all its peers are link-local. >=20 > I saw packets with link-local source/GUA destination coming from hosts > and from routers (I analyzed EUI-64-based IIDs) back in 2011. Now > majority of such traffic is TCP to our services and, again, IID checks > shows that these packets are from hosts. >=20 It is not wrong for a node {host, router} to emit a packet with a = link-local source and a destination in another scope. It is wrong for a router to forward a packet containing a link-local = scope address (source or destination). It is wrong to do so regardless = of whether the outgoing link is the same as the incoming link or not. Owen From jinmei.tatuya@gmail.com Thu Nov 7 23:17: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 DD3F811E8218; Thu, 7 Nov 2013 23:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX+L4pGE9rdE; Thu, 7 Nov 2013 23:17:38 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C3AE221E80E0; Thu, 7 Nov 2013 23:17:36 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t60so1524537wes.26 for ; Thu, 07 Nov 2013 23:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=GxIZfApjoyV+nJQNbnF4vln2jUUyesbBED7DhS9/xTU=; b=YG/a/a9ZXNxMiQY6bFIDwLtp/Bu1sDJgUs6DVX/Sy5fkxK5iqYP+BtuDvXAG/IIsBU YzlQs8j0GCs/MM98vRMMFokyeu1botPjUsBKmD/XqcUH6h5ZuDG9u0aSJeIh3l3/JmXL kgPzMDzUvmaeDmOFf8sb79Fy6A7OfSGrY2QRvaM7RB5+uKX/fLfXy+ENOGJ/UONt43+N ERa2DVL0OXMnR2m1YrVi7Xzo0V1yqHXhNUbLs9ZUHwEMN+buC0fKSOt4J87o1jf5t/kP hfcZJOIjjHYBX2ucdvON2/lRblHhFKc7+zRF5I6ocepA/y/SfI1wQLlP+re+kLFiUAVM 6w4g== MIME-Version: 1.0 X-Received: by 10.180.77.19 with SMTP id o19mr1182464wiw.34.1383895055864; Thu, 07 Nov 2013 23:17:35 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Thu, 7 Nov 2013 23:17:35 -0800 (PST) In-Reply-To: References: <27F73F5B-6095-43E1-ADBE-2E05E8071E3F@cisco.com> <527BE84E.2000205@gmail.com> Date: Thu, 7 Nov 2013 23:17:35 -0800 X-Google-Sender-Auth: rHXXLQBy-ng_y7xB_-RYYVzoPgU Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Owen DeLong Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 08 Nov 2013 07:17:39 -0000 At Thu, 7 Nov 2013 18:42:02 -0800, Owen DeLong wrote: > > I'd note, from purely architectural point of view, that it's totally > > valid a packet that has a link-local address is forwarded, as long as > > the packet remains in the originating link zone. [...] > > That is not correct=85 > > RFC 4291 says: [...] > Routers must not forward any packets with Link-Local source or > destination addresses to other links. > > It is quite clear that a packet with a link-local address in either > field MUST not be forwarded. Don't forget the "to other links" part. This make it valid, e.g., that a router forwards a packet with a link-local source address back to the receiving link. A stubborn person might still argue that "other" can include the receiving link itself, and in a sense I admit it might confuse readers. In fact, such confusion is one of the things RFC 4007 tried to clarify. At the very least, I'm 100% sure this is what Steve (Deering) intended when he co-authored the IPv6 addressing architecture spec and what he tried to clarify in RFC 4007 as a co-author of it. > >> implementation sounds suspect, and I'm with Jen in wondering why a > >> router forwarded the packet in the first place. > > > > It's not surprising to me since the source address is not needed as > > long as routing decision is only made based on the destination > > address. I noticed one popular router vendor didn't implement this > > restriction of RFC 4007 correctly many years ago and even reported it > > to the vendor, but (assuming it's still not fixed) just being "non > > compliant" is probably not convincing enough for them to introduce > > additional overhead in their forwarding logic. > > It's surprising to me and it means that the router is, by definition, not= compliant with RFC 4291, ergo, the router is broken. Of course it's broken. But the existence of broken implementations is not uncommon in general, so simply because something is broken doesn't mean (to me) it's surprising there's such a thing. And, in this particular case, I can even see the incentive of being broken, so it's not surprising to me at all. But "surprising" is a subjective concept anyway, so it's not surprising different people have different sense of it:-) -- JINMEI, Tatuya From nick.heatley@ee.co.uk Fri Nov 8 09:10: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 D96D111E80DC for ; Fri, 8 Nov 2013 09:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKCHAYpPP4hX for ; Fri, 8 Nov 2013 09:10:51 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9590111E8239 for ; Fri, 8 Nov 2013 09:10:42 -0800 (PST) Received: from [194.106.220.35:48066] by server-3.bemta-14.messagelabs.com id 2C/37-03488-11B1D725; Fri, 08 Nov 2013 17:10:41 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-7.tower-91.messagelabs.com!1383930640!9740929!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.9.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23172 invoked from network); 8 Nov 2013 17:10:40 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-7.tower-91.messagelabs.com with SMTP; 8 Nov 2013 17:10:40 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Fri, 08 Nov 2013 17:15:58 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([fe80::5093:62a6:6ee3:7198%11]) with mapi id 14.02.0318.004; Fri, 8 Nov 2013 17:10:39 +0000 From: "Heatley, Nick" To: GangChen , "Eric Vyncke (evyncke)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: AQHOyHB1/aS13ASbK0O9Jy+4NHt/ApoWDEUAgAAA1wCAAASNgIAAB+OAgAVLKMA= Date: Fri, 8 Nov 2013 17:10:39 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 08 Nov 2013 17:10:57 -0000 VGFsa2luZyBmdXJ0aGVyIGFib3V0IGNvZXhpc3RlbmNlIG9mIE5BVDY0IGFuZCBOQVQ0NC4NCklm IE5BVDY0IGlzIGdvb2QgZW5vdWdoIGZvciBJUHY2LW9ubHkgY2xpZW50cyB0aGVuIGl0J3MgZ29v ZCBlbm91Z2ggZm9yIGFsbCBOQVQtYmFzZWQgY2xpZW50cywgcmlnaHQ/DQoNCkEgdGhvdWdodCBl eHBlcmltZW50Lg0KQSBuZXR3b3JrIHJ1bnMgc3Vic2NyaWJlcnMgYmFzZWQgb246DQotIElQdjQg cHJpdmF0ZSBhZGRyZXNzaW5nIG9ubHksIHZpYSBOQVQ0NA0KLSBJUHY2IG5hdGl2ZSwgYnV0IElQ djYtb25seSBkZXZpY2VzIHBhc3MgdmlhIE5BVDY0IHRvIGFjY2VzcyB2NCBvbmx5IGNvbnRlbnQN Ci0gVGhlIE5BVDQ0IGFuZCBOQVQ2NCBpcyBwcm92aWRlZCBieSB0aGUgc2FtZSBwbGF0Zm9ybSwg dGhlIHBsYXRmb3JtIGNhcGFjaXR5IGlzIHVuY2hhbmdlZCBieSB2NCBhbmQgdjYgbWl4ZXMsIGFu ZCB0aGUgdmVuZG9yIGFpbXMgdG8gcmVhY2ggcGFyaXR5IG9uIEFMR3MgKGZvciB0aGUgc2FrZSBv ZiBhcmd1bWVudCwgbGV0J3Mgc2F5IHRoaXMgaGFzIGJlZW4gYWNoaWV2ZWQpDQoNClRoZSBkdWFs IHN0YWNrIGhvc3RzIGNvdWxkIGFsbCBwcmlvcml0aXNlIEFBQUEgYW5kIHRha2UgdGhlIHY2IHBh dGggYnkgZGVmYXVsdC4NCkhhcHB5IEV5ZWJhbGxzIGNvdWxkIG92ZXJyaWRlIHRoaXMsIGFuZCBw cmlvcml0aXNlIHRoZSB2NCBwYXRoIGluIGNhc2VzIHdoZXJlICBiYXNlZCBvbiB0aGUgY2xpZW50 Lg0KDQpJIHVuZGVyc3RhbmQgdGhlIHRyb3VibGVzaG9vdGluZyBhcmd1bWVudCBvZiBrbm93aW5n IHRvIHdoaWNoIE5BVCBwYXRoIHlvdXIgdHJhZmZpYyBnb2VzLCAoYnV0IGhleSwgdGhhdCdzIEhh cHB5IEV5ZWJhbGxzKS4NCk90aGVyIHRoYW4gdGhhdCwgd2h5IHdvdWxkIHRoaXMgbmV0d29yayBv cGVyYXRvciBjYXJlIHdoZXRoZXIgdHJhZmZpYyB0byBJUHY0IGNvbnRlbnQgZnJvbSBkdWFsIHN0 YWNrIGNsaWVudHMgZ29lcyB2aWEgTkFUNjQgb3IgTkFUNDQ/DQpJZiB0aGUgc2NvcGUgb2YgRE5T NjQgZWZmZWN0aXZlbHkgcHVzaGVzIGFsbCBkdWFsIHN0YWNrIGNsaWVudHMgdG8gZmF2b3VyIE5B VDY0LCB3aHkgbm90Pw0KDQpSZWdhcmRzLA0KTmljaw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdhbmdDaGVuDQpTZW50OiAwNSBOb3ZlbWJlciAyMDEz IDAzOjE1DQpUbzogRXJpYyBWeW5ja2UgKGV2eW5ja2UpDQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhw ZXJpZW5jZS0wNC50eHQNCg0KMjAxMy8xMS81LCBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgPGV2eW5j a2VAY2lzY28uY29tPjoNCj4gT0ssIHVuZGVyc3Rvb2QsIHRoYW5rcyA6LSkgWW91ciAoYW5kIFZp Y3RvcidzIG9uZSkgc2hvdWxkIGJlIGFkZGVkIHRvIA0KPiB0aGUgZG9jdW1lbnQgdG8gbWFrZSBp dCBjbGVhcmVyIElNSE8NCg0KWWVzLiBJbiB0aGUgZHJhZnQsIHdlIGhhdmUgZm9sbG93aW5nIGRl c2NyaXB0aW9uOg0KDQogICBUaGUNCiAgIGNvZXhpc3RlbmNlIGhhcyBhbHJlYWR5IGFwcGVhcmVk IGluIG1vYmlsZSBuZXR3b3JrcywgaW4gd2hpY2ggZHVhbA0KICAgc3RhY2sgbW9iaWxlIHBob25l cyBub3JtYWxseSBpbml0aWF0ZSBzb21lIGR1YWwtc3RhY2sgUEROL1BEUA0KICAgVHlwZVtSRkM2 NDU5XSB0byBxdWVyeSBib3RoIElQdjQvSVB2NiBhZGRyZXNzIGFuZCBJUHY0IGFsbG9jYXRlZA0K ICAgYWRkcmVzc2VzIGFyZSB2ZXJ5IG9mdGVuIHByaXZhdGUgb25lcy4NCg0KLUdhbmcNCg0KPg0K PiAtw6lyaWMNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBNaWth ZWwgQWJyYWhhbXNzb24gW21haWx0bzpzd21pa2VAc3dtLnBwLnNlXQ0KPj4gU2VudDogbHVuZGkg NCBub3ZlbWJyZSAyMDEzIDE4OjMxDQo+PiBUbzogRXJpYyBWeW5ja2UgKGV2eW5ja2UpDQo+PiBD YzogdjZvcHNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IA0K Pj4gZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlLTA0LnR4dA0KPj4NCj4+IE9uIFR1 ZSwgNSBOb3YgMjAxMywgRXJpYyBWeW5ja2UgKGV2eW5ja2UpIHdyb3RlOg0KPj4NCj4+ID4gSSBo YXZlIGhhcmQgdGltZSB0byB1bmRlcnN0YW5kIHRoZSBjYXNlIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDMuMS40IA0KPj4gPiAiY28tZXhpc3RlbmNlIG9mIE5BVDQ0IGFuZCBOQVQ2NCIuIFdoeSB3b3Vs ZCBhIHByb3ZpZGVyIHVzZSBib3RoIGF0IA0KPj4gPiB0aGUgc2FtZSB0aW1lPyBVc2luZyBOQVQ0 NCArIG5hdGl2ZSBJUHY2IGlzIHNlbnNpYmxlLCB1c2luZyANCj4+ID4gSVB2Ni1vbmx5DQo+PiA+ ICsNCj4+ID4gTkFUNjQgaXMgYWxzbyB2YWx1YWJsZSBidXQgSSBjYW5ub3QgaW1hZ2luZSB3aHkg TkFUNDQgYW5kIE5BVDY0IA0KPj4gPiBjb3VsZCBiZSB1c2UgdG9nZXRoZXIgZm9yIHRoZSBzYW1l IHN1YnNjcmliZXJzLg0KPj4NCj4+IE1vYmlsZS4NCj4+DQo+PiBJdCdzIHVwIHRvIHRoZSB0ZXJt aW5hbCB0byBpbml0aWF0ZSBhIGNvbm5lY3Rpb24gaW4gdGhlIEFQTiwgYW5kIHlvdSANCj4+IGRv bid0IGtub3cgaWYgaXQnbGwgYmUgSVB2NCBvbmx5LCBJUHY2IG9ubHkgb3IgZHVhbCBzdGFjay4N Cj4+DQo+PiAtLQ0KPj4gTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBw LnNlDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpOT1RJQ0Ug QU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBp cyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBk ZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3Ig dXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFu ZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhh dmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMg YXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxp dHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0K DQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJl Z2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJp ZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5 QlcNCg== From gert@space.net Fri Nov 8 09:27: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 6E8CE11E80EC for ; Fri, 8 Nov 2013 09:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6G-qUyMwjQf for ; Fri, 8 Nov 2013 09:27:37 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 7820D21F9E7C for ; Fri, 8 Nov 2013 09:27:35 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 623D360A0E for ; Fri, 8 Nov 2013 18:27:30 +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 37814608F4 for ; Fri, 8 Nov 2013 18:27:30 +0100 (CET) Received: (qmail 60846 invoked by uid 1007); 8 Nov 2013 18:27:30 +0100 Date: Fri, 8 Nov 2013 18:27:30 +0100 From: Gert Doering To: "Heatley, Nick" Message-ID: <20131108172730.GM81676@Space.Net> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> 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-ietf-v6ops-nat64-experience-04.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, 08 Nov 2013 17:27:38 -0000 Hi, On Fri, Nov 08, 2013 at 05:10:39PM +0000, Heatley, Nick wrote: > If the scope of DNS64 effectively pushes all dual stack clients to favour NAT64, why not? If you have NAT44 and native IPv6, I can't see why you would want to add DNS64+NAT64 to the mix. NAT64 is good when you do *not* want IPv4 at the customer edge. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From prvs=017fb8179=Dave.Michaud@rci.rogers.com Fri Nov 8 09:44: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 149DD21E81D1 for ; Fri, 8 Nov 2013 09:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.665 X-Spam-Level: X-Spam-Status: No, score=0.665 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_50=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqH0Xw3zCGDM for ; Fri, 8 Nov 2013 09:44:47 -0800 (PST) Received: from mail.mail.rss.rogers.com (mail.mail.rss.rogers.com [142.146.31.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1A89521E8189 for ; Fri, 8 Nov 2013 09:44:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPshfVKOkg56l2dsb2JhbABZwyiBRg4BAQEBAQgWBzyCJQEBAQMBEh4KGQsBBgkQBwYBCBEEAQELBhcBB0UJCgQBEggRAgeHWQafGp4PjzY+gxqBEAOJQoVankIe X-IronPort-AV: E=Sophos;i="4.93,661,1378872000"; d="scan'208";a="344432856" Received: from rssesnexigwb.rss.rogers.com (HELO rsoesnexigwb.rci.rogers.ca) ([142.146.14.122]) by mail.mail.rss.rogers.com with ESMTP; 08 Nov 2013 12:44:34 -0500 Received: from RSOESNGTABHC.rci.rogers.ca ([10.3.37.54]) by rsoesnexigwb.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 12:44:34 -0500 Received: from CL08MBE.rci.rogers.ca ([10.3.45.56]) by RSOESNGTABHC.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 12:44:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Nov 2013 12:44:31 -0500 Message-ID: <29AE8DB910E7704CA043795E00DCBE780AB193BB@CL08MBE.rci.rogers.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Checking an outcome on the list Thread-Index: AQHO3Aype5QzVdxtfEaHGp2VxesyKZobmISA From: "Dave Michaud" To: "Fred Baker (fred)" , X-OriginalArrivalTime: 08 Nov 2013 17:44:34.0599 (UTC) FILETIME=[2FDE9370:01CEDCAA] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [v6ops] Checking an outcome on the list 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, 08 Nov 2013 17:44:57 -0000 Q29tbWVudHMgYXJlIGlubGluZQoKRGF2ZSBNaWNoYXVkCgo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tCj4gRnJvbTogdjZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZgpPZgo+IEZyZWQgQmFrZXIgKGZyZWQpCj4gU2VudDogVGh1 cnNkYXksIE5vdmVtYmVyIDA3LCAyMDEzIDI6NTcgUE0KPiBUbzogdjZvcHNAaWV0Zi5vcmcgV0cK PiBTdWJqZWN0OiBbdjZvcHNdIENoZWNraW5nIGFuIG91dGNvbWUgb24gdGhlIGxpc3QKPiAKPiBX ZSBzYXkgd2UgY2hlY2sgZjJmIGRlY2lzaW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0IHRvIGVuc3Vy ZSB0aGF0CmV2ZXJ5b25lIGhhZCBhCj4gY2hhbmNlIHRvIHNwZWFrLiBMZXQncyBkbyB0aGF0Lgo+ IAo+IEluIElFVEYgODgsIHdlIGRpc2N1c3NlZCBhIG51bWJlciBvZiBkcmFmdHMuIE9mIHRoZXNl Ogo+ICAgLSBkcmFmdC1pZXRmLXY2b3BzLWJhbGFuY2VkLWlwdjYtc2VjdXJpdHkgd2lsbCBzdGFy dCBhIHR3byB3ZWVrIFdHTEMKb24KPiBNb25kYXkgbW9ybmluZyBOZXcgWmVhbGFuZCB0aW1lLgoK T2sKCj4gICAtIGRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZSBhcHBlYXJzIHRvIGhh dmUgcmVhY2hlZCBjbG9zdXJlLgpXZSBoYXZlCj4gb25lIGFkZGl0aW9uYWwgcmV2aXNpb24gY29t aW5nLCBhbmQgdGhlbiB3aWxsIGRvIGEgMSB3ZWVrIGxhc3QgY2FsbCwKcHJvYmFibHkKPiBlYXJs eSBEZWNlbWJlci4KCkkgd2lsbCByZXZpZXcgb25jZSB0aGUgZmluYWwgdmVyc2lvbiBpcyBpbi4K Cj4gICAtIGRyYWZ0LWxpdS1ib25pY2EtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0gZG9jdW1l bnRzIHdoYXQgc2VlbXMKdG8gYmUgYQo+IHJlYWwgcHJvYmxlbS4KPiAgICAgICAxKSBJbiB5b3Vy IG9waW5pb24sIHNob3VsZApkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9i bGVtIGJlCj4gYWRvcHRlZCBhcyBXRyBkcmFmdCBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFh Yy1wcm9ibGVtIGFuZCBtYXR1cmVkCmludG8gYQo+IHByb2JsZW0gc3RhdGVtZW50IHRvIHByZXNl bnQgdG8gNm1hbj8KClllcwoKPiAgICAgICAyKSBJbiB5b3VyIG9waW5pb24sIHNob3VsZCB2Nm9w cyBpbnZpdGUgYSBkcmFmdCAod2hpY2ggd2UgbWlnaHQKYWRvcHQgYXMgYQo+IHdvcmtpbmcgZ3Jv dXAgZHJhZnQpIHRoYXQgZ2l2ZXMgY3VycmVudCBndWlkYW5jZSB0byBvcGVyYXRvcnMKcmVnYXJk aW5nIHRoZQo+IHVzZSBvZiBESENQIGFuZCBTTEFBQyBpbiB0aGVpciBuZXR3b3Jrcz8KClllcwoK PiAgIC0gU2hvdWxkIGRyYWZ0LWNoZW4tdjZvcHMtaXB2Ni1yb2FtaW5nLWFuYWx5c2lzIGJlIGFk b3B0ZWQgYXMgV0cKZHJhZnQKPiBkcmFmdC1pZXRmLXY2b3BzLWlwdjYtcm9hbWluZy1hbmFseXNp cz8KCjNHUFAgc3BlY2lmaWVzIGhvdyB0aGUgY2VsbHVsYXIgbm9kZXMgU0hPVUxEIGJlaGF2ZQpH U01BIHNwZWNpZmllcyBwcm92aWRlcyBndWlkZWxpbmVzIG9uIGhvdyBvcGVyYXRvcnMgU0hPVUxE IGNvbmZpZ3VyZQpyb2FtaW5nCklFVEYgdjZvcHMgKHRocm91Z2ggdGhpcyBkcmFmdCkgcHJlc2Vu dHMgYSByZWFsIGxpZmUgdmlldyBvZiB3aGF0CmNoYWxsZW5nZXMvaXNzdWVzIG9wZXJhdG9ycyB3 aWxsIGZhY2Ugd2l0aCBJUHY2IHJvYW1pbmcgCgpJdCBpcyBpbiB0aGUgYmVzdCBpbnRlcmVzdCBm b3IgdGhlIGFkdmFuY2VtZW50IG9mIE1vYmlsZSBJUHY2IGRlcGxveW1lbnQKdG8gaGF2ZSBhcyBt dWNoIGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIG9uIHRoZSBwb3RlbnRpYWwgaW1wYWN0cyBhbmQK cG90ZW50aWFsIHNvbHV0aW9ucyB0aGF0IG9wZXJhdG9ycyB3aWxsIGZhY2Ugd2hlbiBlbmFibGlu ZyBJUHY2IHJvYW1pbmcuCkkgdGhlcmVmb3JlIHN1cHBvcnQgdGhhdCB0aGlzIGRyYWZ0IGlzIGFk b3B0ZWQgYXMgYSBXRyBkcmFmdC4KCj4gCj4gSSdsbCBjb2xsZWN0IHVwIHRoZSByZXNwb25zZXMg aW4gYSB3ZWVrIGFuZCBtYWtlIGEgZGV0ZXJtaW5hdGlvbiBiYXNlZApvbiB0aGF0Lgo+IEknbSBp bnRlcmVzdGVkIGluIHlvdXIgdmlld3BvaW50LCB3aGV0aGVyIHBvc2l0aXZlIG9yIG5lZ2F0aXZl LiBJZiB5b3UKd291bGQKPiBwcmVmZXIgdG8gc2VuZCBpdCBwcml2YXRlbHkgdG8gdjZvcHMtY2hh aXJzQHRvb2xzLmlldGYub3JnLCB0aGF0IHdvcmtzCnRvby4KClRoaXMgZS1tYWlsIChhbmQgYXR0 YWNobWVudChzKSkgaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgbWF5IGJlIHN1YmplY3Qg dG8gY29weXJpZ2h0IGFuZCBsZWdhbCBwcml2aWxlZ2UgYW5kIG5vIHJlbGF0ZWQgcmlnaHRzIGFy ZSB3YWl2ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb3IgaXRzIGFn ZW50LCBhbnkgcmV2aWV3LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBv ZiB0aGlzIGUtbWFpbCBvciBhbnkgb2YgaXRzIGNvbnRlbnQgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBBbGwgbWVzc2FnZXMgbWF5IGJlIG1vbml0b3JlZCBhcyBw ZXJtaXR0ZWQgYnkgYXBwbGljYWJsZSBsYXcgYW5kIHJlZ3VsYXRpb25zIGFuZCBvdXIgcG9saWNp ZXMgdG8gcHJvdGVjdCBvdXIgYnVzaW5lc3MuIEUtbWFpbHMgYXJlIG5vdCBzZWN1cmUgYW5kIHlv dSBhcmUgZGVlbWVkIHRvIGhhdmUgYWNjZXB0ZWQgYW55IHJpc2sgaWYgeW91IGNvbW11bmljYXRl IHdpdGggdXMgYnkgZS1tYWlsLiBJZiByZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1 cyBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMp IGZyb20gYW55IGNvbXB1dGVyIG9yIGFueSBzdG9yYWdlIG1lZGl1bSB3aXRob3V0IHByaW50aW5n IGEgY29weS4KCkNlIGNvdXJyaWVsIChhaW5zaSBxdWUgc2VzIHBpw6hjZXMgam9pbnRlcykgZXN0 IGNvbmZpZGVudGllbCwgZXhjbHVzaWYsIGV0IHBldXQgZmFpcmUgbOKAmW9iamV0IGRlIGRyb2l0 IGTigJlhdXRldXIgZXQgZGUgcHJpdmlsw6hnZSBqdXJpZGlxdWU7IGF1Y3VuIGRyb2l0IGNvbm5l eGUgbuKAmWVzdCBleGNsdS4gU2kgdm91cyBu4oCZw6p0ZXMgcGFzIGxlIGRlc3RpbmF0YWlyZSB2 aXPDqSBvdSBzb24gcmVwcsOpc2VudGFudCwgdG91dGUgw6l0dWRlLCBkaWZmdXNpb24sIHRyYW5z bWlzc2lvbiBvdSBjb3BpZSBkZSBjZSBjb3VycmllbCBlbiB0b3V0IG91IGVuIHBhcnRpZSwgZXN0 IHN0cmljdGVtZW50IGludGVyZGl0ZSBldCBwZXV0IMOqdHJlIGlsbMOpZ2FsZS4gVG91cyBsZXMg bWVzc2FnZXMgcGV1dmVudCDDqnRyZSBzdXJ2ZWlsbMOpcywgc2Vsb24gbGVzIGxvaXMgZXQgcsOo Z2xlbWVudHMgYXBwbGljYWJsZXMgZXQgbGVzIHBvbGl0aXF1ZXMgZGUgcHJvdGVjdGlvbiBkZSBu b3RyZSBlbnRyZXByaXNlLiBMZXMgY291cnJpZWxzIG5lIHNvbnQgcGFzIHPDqWN1cmlzw6lzIGV0 IHZvdXMgw6p0ZXMgcsOpcHV0w6lzIGF2b2lyIGFjY2VwdMOpIHRvdXMgbGVzIHJpc3F1ZXMgcXVp IHkgc29udCBsacOpcyBzaSB2b3VzIGNob2lzaXNzZXogZGUgY29tbXVuaXF1ZXIgYXZlYyBub3Vz IHBhciBjZSBtb3llbi4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbm91cyBlbiBhdmlzZXIgaW1tw6lkaWF0ZW1lbnQgZXQgc3VwcHJpbWVyIGNlIGNv dXJyaWVsIChhaW5zaSBxdWUgdG91dGVzIHNlcyBwacOoY2VzIGpvaW50ZXMpIGRlIHRvdXQgb3Jk aW5hdGV1ciBvdSBzdXBwb3J0IGRlIGRvbm7DqWVzIHNhbnMgZW4gaW1wcmltZXIgdW5lIGNvcGll LiAK From jiangsheng@huawei.com Fri Nov 8 09: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 D012521E81D7 for ; Fri, 8 Nov 2013 09:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvNaYBRaap29 for ; Fri, 8 Nov 2013 09:54:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90321F9A64 for ; Fri, 8 Nov 2013 09:54:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAB39371; Fri, 08 Nov 2013 17:54:53 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 17:54:08 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 17:54:52 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.74]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 01:54:47 +0800 From: Sheng Jiang To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Thread-Topic: Checking an outcome on the list Thread-Index: AQHO3Aype5QzVdxtfEaHGp2VxesyKZobnDJJ Date: Fri, 8 Nov 2013 17:54:46 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD76D42@nkgeml512-mbx.china.huawei.com> References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> In-Reply-To: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] Checking an outcome on the list 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, 08 Nov 2013 17:55:01 -0000 ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Fred Bak= er (fred) [fred@cisco.com] Sent: 08 November 2013 6:56 To: v6ops@ietf.org WG Subject: [v6ops] Checking an outcome on the list We say we check f2f decisions on the mailing list to ensure that everyone h= ad a chance to speak. Let's do that. In IETF 88, we discussed a number of drafts. Of these: - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC on M= onday morning New Zealand time. Support for advancing. - draft-ietf-v6ops-nat64-experience appears to have reached closure. We h= ave one additional revision coming, and then will do a 1 week last call, pr= obably early December. Support for advancing. I was one of volunteer reviewer from last me= eting. The current version has addressed my comments. In general, I think t= he document is mature for next stage. - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to be = a real problem. 1) In your opinion, should draft-liu-bonica-v6ops-dhcpv6-slaac-proble= m be adopted as WG draft draft-ietf-v6ops-dhcpv6-slaac-problem and matured = into a problem statement to present to 6man? Yes. The stand-alone problem document is also worth of publishing a= s a RFC. Then the guidance document below can refer to it without having to= rediscribe the issues again. 2) In your opinion, should v6ops invite a draft (which we might adopt= as a working group draft) that gives current guidance to operators regardi= ng the use of DHCP and SLAAC in their networks? Yes. - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft dr= aft-ietf-v6ops-ipv6-roaming-analysis? Yes. This document is quite helpful. Regards, Sheng I'll collect up the responses in a week and make a determination based on t= hat. I'm interested in your viewpoint, whether positive or negative. If you= would prefer to send it privately to v6ops-chairs@tools.ietf.org, that wor= ks too.= From swmike@swm.pp.se Sat Nov 9 00:28: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 D7C4521F9E3F for ; Sat, 9 Nov 2013 00:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13QeXe-APeew for ; Sat, 9 Nov 2013 00:28:20 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 85FB321F9E3A for ; Sat, 9 Nov 2013 00:28:20 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 371C99C; Sat, 9 Nov 2013 09:27:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 281509A; Sat, 9 Nov 2013 09:27:32 +0100 (CET) Date: Sat, 9 Nov 2013 09:27:32 +0100 (CET) From: Mikael Abrahamsson To: Gert Doering In-Reply-To: <20131108172730.GM81676@Space.Net> Message-ID: References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 09 Nov 2013 08:28:26 -0000 On Fri, 8 Nov 2013, Gert Doering wrote: > If you have NAT44 and native IPv6, I can't see why you would want to add > DNS64+NAT64 to the mix. > > NAT64 is good when you do *not* want IPv4 at the customer edge. Mobile. You don't know if the client is v4 only, v6 only, or dual stack. This is up to the client. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Sat Nov 9 02:50: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 D5AFC21F9F0A for ; Sat, 9 Nov 2013 02:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.955 X-Spam-Level: X-Spam-Status: No, score=-9.955 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoLwrVeUpSg5 for ; Sat, 9 Nov 2013 02:50:51 -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 2B24511E810A for ; Sat, 9 Nov 2013 02:50:51 -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 rA9AolJW007454; Sat, 9 Nov 2013 11:50:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BAA002054E1; Sat, 9 Nov 2013 11:50:54 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A5A5E201525; Sat, 9 Nov 2013 11:50:54 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.9]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rA9AojxY016952; Sat, 9 Nov 2013 11:50:46 +0100 Message-ID: <527E1385.1020506@gmail.com> Date: Sat, 09 Nov 2013 11:50:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> In-Reply-To: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Checking an outcome on the list 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, 09 Nov 2013 10:50:56 -0000 Le 07/11/2013 23:56, Fred Baker (fred) a écrit : > We say we check f2f decisions on the mailing list to ensure that > everyone had a chance to speak. Let's do that. > > In IETF 88, we discussed a number of drafts. Of these: [...] > - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG > draft draft-ietf-v6ops-ipv6-roaming-analysis? I support adoption of this draft. I just looked at it in some detail. I think it deserves enumerating a few practical use-cases where IPv6 roaming occurs, including extremes like changing operator in same place, or through same operator but crossing a national border. I also wonder about which cellular technology is involved in this roaming: 3G, 4G, or CDMA. And to expose that - just like in IPv4 - ongoing IPv6 sessions are breaking upon roaming. Alex > > I'll collect up the responses in a week and make a determination > based on that. I'm interested in your viewpoint, whether positive or > negative. If you would prefer to send it privately to > v6ops-chairs@tools.ietf.org, that works too. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From gert@space.net Sat Nov 9 05:25: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 0FE2A21E8088 for ; Sat, 9 Nov 2013 05:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLMJHWR3hhtR for ; Sat, 9 Nov 2013 05:25:55 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5AD11E80E4 for ; Sat, 9 Nov 2013 05:25:55 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3EDA9608DF for ; Sat, 9 Nov 2013 14:25:53 +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 1FE00602E5 for ; Sat, 9 Nov 2013 14:25:53 +0100 (CET) Received: (qmail 18881 invoked by uid 1007); 9 Nov 2013 14:25:53 +0100 Date: Sat, 9 Nov 2013 14:25:53 +0100 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20131109132552.GQ81676@Space.Net> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cp+VOSm8VfVBUvcG" 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-ietf-v6ops-nat64-experience-04.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, 09 Nov 2013 13:25:56 -0000 --Cp+VOSm8VfVBUvcG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Nov 09, 2013 at 09:27:32AM +0100, Mikael Abrahamsson wrote: > On Fri, 8 Nov 2013, Gert Doering wrote: >=20 > > If you have NAT44 and native IPv6, I can't see why you would want to ad= d=20 > > DNS64+NAT64 to the mix. > > > > NAT64 is good when you do *not* want IPv4 at the customer edge. >=20 > Mobile. You don't know if the client is v4 only, v6 only, or dual stack.= =20 > This is up to the client. Understood, and I see your issue here - you would want to announce a=20 "normal" DNS server to a dual-stack client, not a DNS64 server, and=20 you can't do that because you don't know whether he's v6 only or=20 dual-stack. This is somewhat easier in other types of large-scale customer deployments,= =20 where you can control what the client can get - which will mostly be=20 something like "NAT44+IPv6" for many subscribers for the time to come, so adding DNS64/NAT64 really does not have much benefit here. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Cp+VOSm8VfVBUvcG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUn434N9WwGXkzn/FAQJjmg/9Fgn0hGW3Y5tTb8uwMR/SbyhfLdfYl4wy 1QDbp3vnJbd9fEs4jJ4jmBr8jysw6pZosoVeOw1S57Ir/LaJRqC/uNGcVcccGF8w jxZ6P5rn317phIol55xTAfiko9cDZL59BX6zAe0irnWFZvhKwt+acMzlLJtWi4Bh I7dmZ2oQG9WLc101XeDETkSmvLLRy9aEFmPJpup9Dp4pcep//3cI6JFlyljikFl/ WZ3LFD3UEDOnZTWklKHX+QVRYofV+ESajohkRKhf3Dt+6zKuTmLikHNaFYKleZXV e4CMynvs8XnpGPhVtGkQJggb5JwRSxI1yBR9SZrMPmnBAjYLT0/MWxNv00Kka/EO cB3t77usPTqYkTZxB57mufoKjEXSObC8+6885iGQCY/ffL1okRS5pHrhmA6iEPT6 iT1k7pzG6JJxP/uKBGFtRXCM/gwxKN5/KCDbqMoKdpaMPqyiUjdPKf4zGPtNxVjx 4ocglsEKyWIrGumHDu86dL0OsckED1ECe/fwWq3cwL1l4cREGphuAgf4ftNaVz0O aX7Tm4VlmQnCRxAYK1esoGajAC0GLVAXF4Hsyj6N6EuKt2O54Ztrda0f2Uk3IH5+ 38DSo2494yEFWMjo7MIPrqWYrno90a6jQFohAUdRSBvopqlU0yAohSf01F4dvEMZ krvSjCtWlUs= =aW6J -----END PGP SIGNATURE----- --Cp+VOSm8VfVBUvcG-- From backup2.torres@gmail.com Mon Nov 4 17:53: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 04E9E11E8349; Mon, 4 Nov 2013 17:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X85V0tfnCBZL; Mon, 4 Nov 2013 17:53:41 -0800 (PST) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 287B411E81D3; Mon, 4 Nov 2013 17:53:39 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id g12so8015066oah.19 for ; Mon, 04 Nov 2013 17:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=amvnVD84Wa/j6Gm/HQz/fFHixLOnW1AAUgfSb0Dx1nA=; b=tQ7RLXlv7zC4ejhHKODDfe/sSFoizqjBdXco1fNnJYRd8/jL8MbEhbKcgqdAjTB23+ 4vrXKNS6QWF+9qtrknmsnfmO5ipEUZgocIDZFpxzhRRpXmA2F3U1GaB6FfiH/8bJfkTU Q7H7iBGC3kwBcnqx7wK9ihDl2WJIvwNOajBS0YMN6Z5xuh3eozeHaoF/k9Ia9VbaaEzw MSQ1jDfEEbERPjkk4QxUuySm8GLQZkSGz36PyHix6oPqJq892JZe6p/3IDuF8LOwgs/m D22vGaq9bAdfijK3FdeXGLrcIjGGvRTJWrdPseZqG4tABa1yixhtxm/L+PxEa2Cd8dYW d9tQ== MIME-Version: 1.0 X-Received: by 10.182.66.164 with SMTP id g4mr4239051obt.47.1383616418590; Mon, 04 Nov 2013 17:53:38 -0800 (PST) Sender: backup2.torres@gmail.com Received: by 10.60.25.6 with HTTP; Mon, 4 Nov 2013 17:53:38 -0800 (PST) In-Reply-To: References: <5278275C.50206@gont.com.ar> Date: Mon, 4 Nov 2013 23:53:38 -0200 X-Google-Sender-Auth: s83HzSnZ8voQ-H2eglDnc0SRCm4 Message-ID: From: Pedro Torres To: Tim Chown Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 10 Nov 2013 09:25:12 -0800 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 05 Nov 2013 01:53:42 -0000 Tim/Fernando, Wow! I'm scared of these results! (If that was the intention, it worked!) -- Pedro On Mon, Nov 4, 2013 at 9:27 PM, Tim Chown wrote: > Hi, > > Also as per the IEPG discussion, the results I had in conjunction with a = summer MSc project student can be summarised as follows. > > The headline is that he saw a 37.7% failure rate for the Fragmentation He= ader (alone), a bit better than Fernando=92s results, but still not good. > > He tested the top 1,000 IPv6-enabled Alexa sites. > He used the scapy toolkit which supports the four main extension header t= ypes (routing, fragmentation, destination and hop-by-hop) > He tested > a) valid combinations of those 4 extension headers as per RFC 2460 > b) other non-valid combinations > c) duplicated extension headers > d) fragmentation header > Primarily TCP tests, doing HTTP GET requests. > > For single extension headers, acceptance was > Routing header 63.9% > Frag header 62.3% > Hop by hop header 60% > Destination option header 15.8% > When using no extension headers, success rate was 100% > When using multiple headers, the rates fall markedly, not dissimilar with= Fernando=92s numbers for longer headers. > > About 120 sites accept all four types of extension headers. > > A small number of sites accepted illegal combinations/ordering of extensi= on headers. > > A more detailed set of results is being pushed to a conference paper. > > I now have another student taking this further, and validating the above = results, so feel free to contact me off-list if you=92re interested. > > Tim > > On 4 Nov 2013, at 23:01, Fernando Gont wrote: > >> Folks, >> >> I did a presentation on the topic at the IEPG meeting earlier this week. >> It provides some concrete data regarding IPv6 fragmentation and >> Extension Header filtering on the Internet. >> >> The slideware is available at: >> >> >> Certainly there's *much* more work to be done in this area, but I >> thought that this could be good food sfor some of the discussions that >> we were having on the topic. >> >> Thanks, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From hannes@stressinduktion.org Wed Nov 6 05:01: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 8E28621F9E50; Wed, 6 Nov 2013 05:01:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQa4gzLjQGAu; Wed, 6 Nov 2013 05:01:49 -0800 (PST) Received: from order.stressinduktion.org (order.stressinduktion.org [87.106.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 219E621F9FB6; Wed, 6 Nov 2013 05:01:48 -0800 (PST) Received: by order.stressinduktion.org (Postfix, from userid 500) id 3DCDC1A0C287; Wed, 6 Nov 2013 14:01:41 +0100 (CET) Date: Wed, 6 Nov 2013 14:01:40 +0100 From: Hannes Frederic Sowa To: Fernando Gont Message-ID: <20131106130140.GE4962@order.stressinduktion.org> References: <5278275C.50206@gont.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5278275C.50206@gont.com.ar> X-Mailman-Approved-At: Sun, 10 Nov 2013 09:25:12 -0800 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet 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, 06 Nov 2013 13:01:53 -0000 Hi Fernando, On Mon, Nov 04, 2013 at 03:01:48PM -0800, Fernando Gont wrote: > I did a presentation on the topic at the IEPG meeting earlier this week. > It provides some concrete data regarding IPv6 fragmentation and > Extension Header filtering on the Internet. > > The slideware is available at: > > > Certainly there's *much* more work to be done in this area, but I > thought that this could be good food sfor some of the discussions that > we were having on the topic. We had some some bugs in path MTU handling in the linux IPv6 stack which will get resolved with the next stable kernels. If such an experiment is repeated I would suggest keeping a tcpdump of the traffic and an ip -6 monitor route log while doing this experiment. I currently don't know if we report path MTU events back up to user space, and if not, it will be hard to do so because that would confuse user space routing daemons which already listen for route change notifications. But for such an experiment I could provide such a patch. It would be nice that we don't drop path mtu discovery on such busy boxes because of regular routing garbage collector pressure or just because of bugs. Greetings, Hannes From jch@pps.univ-paris-diderot.fr Fri Nov 8 04:24: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 52F8A11E8177; Fri, 8 Nov 2013 04:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPxEdgWx+ekd; Fri, 8 Nov 2013 04:24:01 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 503A111E8122; Fri, 8 Nov 2013 04:24:00 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id rA8CNuoF008925; Fri, 8 Nov 2013 13:23:56 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9B2D45AD5F; Fri, 8 Nov 2013 13:23:56 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id lB5yMqrCzFxY; Fri, 8 Nov 2013 13:23:55 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0E5FB5AD5E; Fri, 8 Nov 2013 13:23:54 +0100 (CET) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1Vel6Q-0008Om-Lx; Fri, 08 Nov 2013 13:23:54 +0100 Date: Fri, 08 Nov 2013 13:23:54 +0100 Message-ID: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Fred Baker (fred)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 08 Nov 2013 13:23:56 +0100 (CET) X-Miltered: at korolev with ID 527CD7DC.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 527CD7DC.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 527CD7DC.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-Mailman-Approved-At: Sun, 10 Nov 2013 09:25:12 -0800 Cc: "v6ops@ietf.org WG" , "ospf@ietf.org" , "homenet@ietf.org Group" , "isis-wg@ietf.org" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 08 Nov 2013 12:24:05 -0000 > The context is: A pity you didn't cite any of the previous work on the subject: http://tools.ietf.org/html/draft-troan-homenet-sadr-01 https://github.com/fingon/hnet-core http://tools.ietf.org/html/draft-boutier-homenet-source-specific-routing http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git > I had breakfast this morning with Shu Yang, who has been writing > Quagga code for several years in the course of his PHd. [...] and > has now implemented (if I understand him correctly) > draft-ietf-ospf-ospfv3-lsa-extend and > draft-baker-ipv6-ospf-dst-src-routing. Excellent. Could we please have a look at the source code ? (It was already promised in Berlin, if memory serves.) Regards, -- Juliusz From yangshu1988@gmail.com Fri Nov 8 04:51: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 17E4511E80EE; Fri, 8 Nov 2013 04:51:47 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmr2sIJ7Asjf; Fri, 8 Nov 2013 04:51:46 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C600621F9F3D; Fri, 8 Nov 2013 04:51:45 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so2109967wid.17 for ; Fri, 08 Nov 2013 04:51:45 -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=w9+Jksh257ryDWT6JsZcR2sdObTNDhDJiMxLs2U5ZfQ=; b=f89r88L2kWPUJuyeJ8dFIDEuexwSsZnsgMEujWgT5vsb3tryyLnpKzy+4vP/PluMH7 +hWcL2sO317uzW9+MQcMIEGz8c8qJqlEgk9Ew0B7giGhJThxPgRtUckEKMMSUXyOJ/l/ NnExU+m72S0CEsA5WB+ntFPz0JX8OlTyctath451/Opz4eStVT9+lXg3HeDtF2Y6eQTI DkvYpsw1XeiDtRqfxuz5tv9yymxvnnrGSTJErgDttzzEYwZOjmA1orbTqV8XTlwsbUWo w5FHBOL53sXFVGWn2x7IWxmbq10fcI9XSlOep3NfsCgaWaVBS/lFxDqlMTexLSYKSAV3 lR4w== MIME-Version: 1.0 X-Received: by 10.180.37.67 with SMTP id w3mr2274557wij.56.1383915104978; Fri, 08 Nov 2013 04:51:44 -0800 (PST) Received: by 10.194.36.196 with HTTP; Fri, 8 Nov 2013 04:51:44 -0800 (PST) In-Reply-To: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> Date: Fri, 8 Nov 2013 20:51:44 +0800 Message-ID: From: Shu Yang To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=e89a8f502cfa3b4f0f04eaa9d83b X-Mailman-Approved-At: Sun, 10 Nov 2013 09:25:12 -0800 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , "ospf@ietf.org" , "homenet@ietf.org Group" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 08 Nov 2013 12:51:47 -0000 --e89a8f502cfa3b4f0f04eaa9d83b Content-Type: text/plain; charset=ISO-8859-1 > Excellent. Could we please have a look at the source code ? (It was > already promised in Berlin, if memory serves.) We will make it public after testing it in live networks (we are still implementing the Click code, and combining quagga and click together). If you want, I can send you the current version privately at this moment. Shu Yang Tsinghua University --e89a8f502cfa3b4f0f04eaa9d83b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Excellent. =A0Could we please have a look at the sour= ce code ? =A0(It was
> already promised in Berlin, if memory serves.)=
We will make it public after testing it in live networks (we are s= till
implementing the Click code, and combining quagga and click
= together).

If you want, I can send you the current= version privately at this moment.

Shu Yang
Tsinghua University
--e89a8f502cfa3b4f0f04eaa9d83b-- From jch@pps.univ-paris-diderot.fr Sun Nov 10 05:37: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 6A80711E8190; Sun, 10 Nov 2013 05:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQeQEEH1gsbp; Sun, 10 Nov 2013 05:37:19 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0333D21F9E4F; Sun, 10 Nov 2013 05:37:07 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id rAADb3SM032731; Sun, 10 Nov 2013 14:37:03 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0B0255AE60; Sun, 10 Nov 2013 14:37:03 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uQAuzS8TC55g; Sun, 10 Nov 2013 14:37:02 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1245A5AE5C; Sun, 10 Nov 2013 14:37:01 +0100 (CET) Received: from localhost ([127.0.0.1] helo=ijon.pps.jussieu.fr) by ijon.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1VfVCI-0002DH-Ln; Sun, 10 Nov 2013 14:37:02 +0100 Date: Sun, 10 Nov 2013 14:37:02 +0100 Message-ID: <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Shu Yang In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 10 Nov 2013 14:37:03 +0100 (CET) X-Miltered: at korolev with ID 527F8BFF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 527F8BFF.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 527F8BFF.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-Mailman-Approved-At: Sun, 10 Nov 2013 09:25:12 -0800 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , "ospf@ietf.org" , "homenet@ietf.org Group" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 10 Nov 2013 13:37:34 -0000 > > Excellent. Could we please have a look at the source code ? (It was > > already promised in Berlin, if memory serves.) > We will make it public after testing it in live networks Ah, I see. > If you want, I can send you the current version privately at this moment. I'd much prefer a public repository, something I can discuss freely with people (and eventually cite) without worrying whether I'm disclosing anything confidential. -- Juliusz From hrogge@googlemail.com Sun Nov 10 06:24: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 7016121E808F; Sun, 10 Nov 2013 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F69NisDODam; Sun, 10 Nov 2013 06:24:36 -0800 (PST) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4017811E80EA; Sun, 10 Nov 2013 06:24:36 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id t7so454854qeb.24 for ; Sun, 10 Nov 2013 06:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cx2jX8ap06xyOckh1Gs6MpCl1Kg/Q9NmtMYJ6WC1Kvw=; b=hgOBrYyFlklgxdCbAuwgL9t0GCKHEdHXykBPxx54uLlbNP+EgQNKmDVHm3wTI6uhvr MGT0d2Kdhb/uXCSgDGxA6ddrjjVxOih41/B4Yql2cCBsRf3eL9QH+6/8E4AYVm6Kk8XH XODz5svhSigCRfWs3TOSoyAoSxTjD6hiFeT5kpO7rYU2dDxlxOU6XxKBCZJnh57F8s4C XGX8BW8Drl6G8G+WAWqp4cQTOS2LopvWOKWKlPwPkZDEDO10lEneFFoKPIMY7kTXU/HV FI/504jvZMGSelmViqT3Pz1ZoG7u4ta8jzW+Uk+5ybcoHkOXIBrIjzrpko+xw+6J2xh6 XJng== X-Received: by 10.224.171.196 with SMTP id i4mr41052709qaz.38.1384093475813; Sun, 10 Nov 2013 06:24:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.200 with HTTP; Sun, 10 Nov 2013 06:24:15 -0800 (PST) In-Reply-To: <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Sun, 10 Nov 2013 15:24:15 +0100 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 10 Nov 2013 09:25:12 -0800 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , "ospf@ietf.org" , "homenet@ietf.org Group" , Routing WG , Shu Yang Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 10 Nov 2013 14:24:37 -0000 On Sun, Nov 10, 2013 at 2:37 PM, Juliusz Chroboczek wrote: >> > Excellent. Could we please have a look at the source code ? (It was >> > already promised in Berlin, if memory serves.) >> >> If you want, I can send you the current version privately at this moment. > > I'd much prefer a public repository, something I can discuss freely > with people (and eventually cite) without worrying whether I'm disclosing > anything confidential. I agree with Juliusz, a public repository would be much better, even if it only contains "in development" code. If the code will be open sourced in the end anyways I don't see any drawbacks. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From hermin.anggawijaya@gmail.com Sun Nov 10 10:09: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 86FD311E8146; Sun, 10 Nov 2013 10:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHS5L7WFejO3; Sun, 10 Nov 2013 10:09:29 -0800 (PST) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3191A11E80E6; Sun, 10 Nov 2013 10:09:29 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id 10so2646151vbe.33 for ; Sun, 10 Nov 2013 10:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zt2DnudiU+2cmNXFhvBjYwTX1+AL8PDS0Z1/nyUgE6k=; b=VP9u2GiBDteepBwT3GgkDjxd/5X66Nla2wpLpTKPaQsp2tTNq2u8ukfBoAcTT5vQ5Q 9g5L/Zem5QOjkEAiCehecKiFln2CfHHXA7eoWxQ/Qi00Wi3WyP82yoIoHRd60KG5XDm/ TgrQgYiNOf2qgN5g3y1k3HT6S845cfGAzMxx4xSjeWCNk/6eXUwGlCn+vq8Hvnsh3404 so1vZir4A4/xal8DReUbP5zZq+faVkBKsCXM0hQ8EMfMKMDlDCLlecIHZkJPAyik2GJr +S1iy6VGtZSOBxjbqGIN+1fOl6d1sD/XWK/RCFZ1pASiVGfjC4R/en6dWqkvOIG3mlT9 MWUA== MIME-Version: 1.0 X-Received: by 10.52.111.161 with SMTP id ij1mr76560vdb.33.1384106968582; Sun, 10 Nov 2013 10:09:28 -0800 (PST) Received: by 10.58.188.72 with HTTP; Sun, 10 Nov 2013 10:09:28 -0800 (PST) In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> Date: Sun, 10 Nov 2013 10:09:28 -0800 Message-ID: From: Hermin Anggawijaya To: Shu Yang Content-Type: multipart/alternative; boundary=bcaec54863463192eb04ead68457 Cc: "ospf@ietf.org" , "v6ops@ietf.org WG" , "homenet@ietf.org Group" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 10 Nov 2013 18:09:30 -0000 --bcaec54863463192eb04ead68457 Content-Type: text/plain; charset=ISO-8859-1 I too would be interested in seeing the code if it's available in a public repo. cheers Angga On Sun, Nov 10, 2013 at 6:24 AM, Henning Rogge wrote: > On Sun, Nov 10, 2013 at 2:37 PM, Juliusz Chroboczek > wrote: > >> > Excellent. Could we please have a look at the source code ? (It was > >> > already promised in Berlin, if memory serves.) > >> > >> If you want, I can send you the current version privately at this > moment. > > > > I'd much prefer a public repository, something I can discuss freely > > with people (and eventually cite) without worrying whether I'm disclosing > > anything confidential. > > I agree with Juliusz, a public repository would be much better, even > if it only contains "in development" code. > > If the code will be open sourced in the end anyways I don't see any > drawbacks. > > Henning Rogge > > -- > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec54863463192eb04ead68457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I too would be interested in seeing the code if = it's available in a public repo.

cheers

Angga=


On Sun, Nov 10, 2013 at 6:24 AM, Henning Rogge <hrogge@googlemail.com<= /a>> wrote:
On Sun, Nov 10, 2013 at 2:37 PM, Juliusz Chroboczek
<jch@pps.univ-paris-did= erot.fr> wrote:
>> > Excellent. =A0Could we please have a look at the source code = ? =A0(It was
>> > already promised in Berlin, if memory serves.)
>>
>> If you want, I can send you the current ve= rsion privately at this moment.
>
> I'd much prefer a public repository, something I can discuss freel= y
> with people (and eventually cite) without worrying whether I'm dis= closing
> anything confidential.

I agree with Juliusz, a public repository would be much better, even<= br> if it only contains "in development" code.

If the code will be open sourced in the end anyways I don't see any dra= wbacks.

Henning Rogge

--
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--bcaec54863463192eb04ead68457-- From fred@cisco.com Sun Nov 10 11:00: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 7CA7921E8133 for ; Sun, 10 Nov 2013 11:00:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJYFwEmajDI6 for ; Sun, 10 Nov 2013 11:00:14 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B0E5321E80F8 for ; Sun, 10 Nov 2013 11:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=634; q=dns/txt; s=iport; t=1384110014; x=1385319614; h=date:from:message-id:to:subject:cc; bh=RwgnPlwjYFglIuBocMVuu2d+pZDZJjZSbjd+V4w6A8E=; b=KMASuJ6YLFWx62DdP8V7bl9/NMkzkTBBFrnCCfmRQrktH1m6if6gu01O IIBcOcoJ/OZPUamGlqjlJQG3fKkGY8tnXTqTrqF3Sj2doOVxiSEFnH4Bf O4RAmCd1uTCC+bd6bWnYW8e7bynW5/gX+eoryu6SSel4hwzeFFRv/dKc9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4GANXWf1KrRDoG/2dsb2JhbABZgwc4rToBkieBJxZ0gxEUPDSIYQ69AY9nHYQaA4lCj3yQW4NH X-IronPort-AV: E=Sophos;i="4.93,673,1378857600"; d="scan'208";a="97167033" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Nov 2013 19:00:13 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAAJ0B3s005285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Nov 2013 19:00:11 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id rAAJ0Bew025355; Sun, 10 Nov 2013 11:00:11 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id rAAJ0AR6025350; Sun, 10 Nov 2013 11:00:10 -0800 (PST) Date: Sun, 10 Nov 2013 11:00:10 -0800 (PST) From: Fred Baker Message-Id: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 10 Nov 2013 19:00:19 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nick.heatley@ee.co.uk Mon Nov 11 00:24:20 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 3A1A921E81A3 for ; Mon, 11 Nov 2013 00:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty8QseMDn45Q for ; Mon, 11 Nov 2013 00:24:14 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id C778F21E813F for ; Mon, 11 Nov 2013 00:24:12 -0800 (PST) Received: from [85.158.139.3:13663] by server-3.bemta-5.messagelabs.com id 14/C5-08905-B2490825; Mon, 11 Nov 2013 08:24:11 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-15.tower-90.messagelabs.com!1384158251!822698!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.9.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9383 invoked from network); 11 Nov 2013 08:24:11 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-15.tower-90.messagelabs.com with SMTP; 11 Nov 2013 08:24:11 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Mon, 11 Nov 2013 08:31:21 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.02.0318.004; Mon, 11 Nov 2013 08:24:10 +0000 From: "Heatley, Nick" To: Gert Doering , Mikael Abrahamsson Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: AQHOyHB1/aS13ASbK0O9Jy+4NHt/ApoWDEUAgAAA1wCAAASNgIAAB+OAgAVLKMCAAFoFAIAA+3cAgABTXICAAs0ZMA== Date: Mon, 11 Nov 2013 08:24:10 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> In-Reply-To: <20131109132552.GQ81676@Space.Net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 11 Nov 2013 08:24:20 -0000 Agree, the questions seem only relevant to the mobile use case (with a no= rmal baseline of IPv4 privates + NAT44). Hopefully you can see that the questions are valid now. I seek arguments why, in an access network dominated by NAT why to prefer= =20one flavour over another? - other than pushing my NAT vendor to achiev= e parity NAT64 <--> NAT44 (they claim both translations are in hardware).= =20If NAT64 is good enough for IPv6-only clients its good enough for Dual= =20Stack NAT? Nick -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= =20Gert Doering Sent: 09 November 2013 13:26 To: Mikael Abrahamsson Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt= Hi, On Sat, Nov 09, 2013 at 09:27:32AM +0100, Mikael Abrahamsson wrote: > On Fri, 8 Nov 2013, Gert Doering wrote: >=20 > > If you have NAT44 and native IPv6, I can't see why you would want to = > > add > > DNS64+NAT64 to the mix. > > > > NAT64 is good when you do *not* want IPv4 at the customer edge. >=20 > Mobile. You don't know if the client is v4 only, v6 only, or dual stack= .=20 > This is up to the client. Understood, and I see your issue here - you would want to announce a "nor= mal" DNS server to a dual-stack client, not a DNS64 server, and you can't= =20do that because you don't know whether he's v6 only or dual-stack. This is somewhat easier in other types of large-scale customer deployment= s, where you can control what the client can get - which will mostly be s= omething like "NAT44+IPv6" for many subscribers for the time to come, so = adding DNS64/NAT64 really does not have much benefit here. Gert Doering =20 -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW From sajjad_akr@yahoo.com Mon Nov 11 02:35: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 5C17F11E8158 for ; Mon, 11 Nov 2013 02:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.982 X-Spam-Level: X-Spam-Status: No, score=0.982 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSbAqGKPvPdT for ; Mon, 11 Nov 2013 02:35:41 -0800 (PST) Received: from nm25-vm5.bullet.mail.ne1.yahoo.com (nm25-vm5.bullet.mail.ne1.yahoo.com [98.138.91.247]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38611E80F5 for ; Mon, 11 Nov 2013 02:35:39 -0800 (PST) Received: from [98.138.101.129] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2013 10:35:33 -0000 Received: from [98.138.101.175] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2013 10:35:33 -0000 Received: from [127.0.0.1] by omp1086.mail.ne1.yahoo.com with NNFMP; 11 Nov 2013 10:35:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 548954.29586.bm@omp1086.mail.ne1.yahoo.com Received: (qmail 11597 invoked by uid 60001); 11 Nov 2013 10:35:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1384166133; bh=g8xdKLKdXF0JekT69eOffyz653qyfRTAStvzv1CVeUs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=RGmlXXTkXu9uyzdWUUOuC70IxVO5QWqpsx/Jz2Yirfj8bCH8x15TlsTMj4O2Dtk7TZZbHGWvNOiKsI4ud5isNSOWGz/cn/fW7ej7mUIhqEaekijGkMK/nDZCTf3PJWKQ9bwO8ARm7FgQzDLJRmW6MEk8iu8r99WqIiC8emBopz8= 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:Subject:To:MIME-Version:Content-Type; b=aamEDZjX5ZF5DOAmewRCWDpeAvuFkoG0FCDkWHS29bjcpdNbFZ5iqZQInllsekEeBVK+esDEE8Qwio76Me54TEKIL9RBcVJECNCMncX4gQUtKiOPmudi9c5mrSZ65qnirlXKjRRsXRQoXYnb6XHXQQZ3fXN6oyfHP8+NzDyACq0=; X-YMail-OSG: tygj.vAVM1mbTU.cLifuEYTTLYN31eMCV2n913BGEXP4JMI HJxLk9_bk._1t32zAPSDveOUPGUd3btMc8nlvY22nsVXYvtPjCWiyMMZyhUo giyIt5XqV0Fo2M9p9vSQ2qxIhJofYnyUd7Cs4udoV8Y9saBi4nSRECWvQoco _SF56PABcWo2UxKwDCrxCxzEnvzEceRCpdcDlGAsI2ByNnjuO2T3HD803yVD ihHQRzb22ebiCGhlpJ1p_uViE8PKzf5g5a1wyQYydmsRw8sgfPt.t4oYTAuG UvIblB6BJg6HYPlsVdA_S5orpOIfkNiYNlTzxDd5Hn_M1t6yVKhn1LZ1NtI5 ZjynotIYFNjCaxdrJI66QO2_8.MLvedY4K0dak1.NqZwHeXl_fKcjVcvUR5Z o1jRT.GWki8.q11t1VrgcDdF2yZ5VQg4_zJgDNBL7UDXkzNnlvxptYBTUlrG Gt4ntq87TwUIwKZqT6x6iLSPTVEAPLkLG1O6Ovn0RUbXM2iz_.N48Wmnei3e 7jfgBXh8BXQYNDrFUuUmTI786_RogFRLsPdFizjSysOiMOgS_N_ytVNqyuES pOq5kMf0XzVMTLK6_oO2qTc8UEVOsAQ-- Received: from [203.99.52.164] by web121504.mail.ne1.yahoo.com via HTTP; Mon, 11 Nov 2013 02:35:33 PST X-Rocket-MIMEInfo: 002.001, RGVhciBmZWxsb3dzCgpJcyB0aGVyZSBhbnkgZGlzY3Vzc2lvbiByZWdhcmRpbmcgSVB2NiBkb3MgYXR0YWNrcyBhbmQgaXQncyBwcmV2ZW50aW9uIGVmZm9ydHM_CgoKUmVnYXJkcwpTYWpqYWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.163.597 Message-ID: <1384166133.10720.YahooMailNeo@web121504.mail.ne1.yahoo.com> Date: Mon, 11 Nov 2013 02:35:33 -0800 (PST) From: sajjad akbar To: "v6ops@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1050781934-71007817-1384166133=:10720" Subject: [v6ops] Is there any working on DoS attacks solutions for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 10:35:48 -0000 --1050781934-71007817-1384166133=:10720 Content-Type: text/plain; charset=us-ascii Dear fellows Is there any discussion regarding IPv6 dos attacks and it's prevention efforts? Regards Sajjad --1050781934-71007817-1384166133=:10720 Content-Type: text/html; charset=us-ascii
Dear fellows

Is there any discussion regarding IPv6 dos attacks and it's prevention efforts?


Regards
Sajjad
--1050781934-71007817-1384166133=:10720-- From warren@kumari.net Mon Nov 11 06:22: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 3D27611E817A for ; Mon, 11 Nov 2013 06:22:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-l39Xhg3OhY for ; Mon, 11 Nov 2013 06:22:49 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E7721F9FBC for ; Mon, 11 Nov 2013 06:22:49 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id C5C0E1B4046D; Mon, 11 Nov 2013 09:22:48 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <1384166133.10720.YahooMailNeo@web121504.mail.ne1.yahoo.com> Date: Mon, 11 Nov 2013 09:22:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <19CD65A9-B377-4E33-9978-033F849D2470@kumari.net> References: <1384166133.10720.YahooMailNeo@web121504.mail.ne1.yahoo.com> To: sajjad akbar X-Mailer: Apple Mail (2.1510) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Is there any working on DoS attacks solutions for IPv6? 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, 11 Nov 2013 14:22:54 -0000 On Nov 11, 2013, at 5:35 AM, sajjad akbar wrote: > Dear fellows >=20 > Is there any discussion regarding IPv6 dos attacks and it's prevention = efforts? Hi there, There is some discussion of that here, but you might also want to look = at the OpSec WG=85 W >=20 >=20 > Regards > Sajjad > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 "He who laughs last, thinks slowest."=20 -- Anonymous From phdgang@gmail.com Mon Nov 11 06:46: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 85A7421E8091 for ; Mon, 11 Nov 2013 06:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKV9Qb0fsWZ5 for ; Mon, 11 Nov 2013 06:46:43 -0800 (PST) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id EB6A921E8064 for ; Mon, 11 Nov 2013 06:46:42 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id d4so4538854qej.35 for ; Mon, 11 Nov 2013 06:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4MZlEPpoEHQ/wHu+0A3g11W7RxyuCeFZmo6to3MVXO0=; b=O9SI0AZLRC/P1mEaMcsN8h6bwyz5opZapJlkxx7vUKiIoU1ustyeOikDY80r7GkMi8 KzJOTSHNWQHvSWVNVjGJLrLcvqUL/It/EDGpLHh4XklIi9JDNO3Nx6ZB93B9QkMSypMl P1FjIwggV60CxK5ki0nBtWcIuq+H2hnwBy4hn/vebfi0h4cXz6Q0cGNNgRJfBTX6L3Fh LVek3Bp8RA5sB/6pJI0UqTblYLlxok7niKtDZox5lPZ8emspwyaWAGAxsqGkMWdXsuMG IiHIc0+8lHC0Dbo0JHF1BNIHLGKIb742LZK/dWS9umnzvr1rDI4xczAruLF0RCGk0kjb CZ6w== MIME-Version: 1.0 X-Received: by 10.229.13.69 with SMTP id b5mr47959723qca.13.1384181202262; Mon, 11 Nov 2013 06:46:42 -0800 (PST) Received: by 10.224.172.135 with HTTP; Mon, 11 Nov 2013 06:46:42 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Mon, 11 Nov 2013 22:46:42 +0800 Message-ID: From: GangChen To: "Heatley, Nick" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 11 Nov 2013 14:46:44 -0000 2013/11/11, Heatley, Nick : > Agree, the questions seem only relevant to the mobile use case (with a > normal baseline of IPv4 privates + NAT44). > Hopefully you can see that the questions are valid now. > I seek arguments why, in an access network dominated by NAT why to prefer > one flavour over another? - other than pushing my NAT vendor to achieve > parity NAT64 <--> NAT44 (they claim both translations are in hardware). If > NAT64 is good enough for IPv6-only clients its good enough for Dual Stack > NAT? the argument here is to let: dual-stack UEs go to NAT44+IPv6 or native IPv4+IPv6 IPv6-only UEs go to NAT64/DNS64 IPv4-only UEs go to NAT44 or native IPv4 It doesn't expect that dual-stack UEs go to NAT64, because IPv4 native connections are preferred over IPv6+NAT64 BRs Gang > Nick > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Gert Doering > Sent: 09 November 2013 13:26 > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt > > Hi, > > On Sat, Nov 09, 2013 at 09:27:32AM +0100, Mikael Abrahamsson wrote: >> On Fri, 8 Nov 2013, Gert Doering wrote: >> >> > If you have NAT44 and native IPv6, I can't see why you would want to >> > add >> > DNS64+NAT64 to the mix. >> > >> > NAT64 is good when you do *not* want IPv4 at the customer edge. >> >> Mobile. You don't know if the client is v4 only, v6 only, or dual stack. >> This is up to the client. > > Understood, and I see your issue here - you would want to announce a > "normal" DNS server to a dual-stack client, not a DNS64 server, and you > can't do that because you don't know whether he's v6 only or dual-stack. > > This is somewhat easier in other types of large-scale customer deployments, > where you can control what the client can get - which will mostly be > something like "NAT44+IPv6" for many subscribers for the time to come, so > adding DNS64/NAT64 really does not have much benefit here. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or use > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachments > are free from any virus, but it remains your responsibility to ensure that > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From gert@space.net Mon Nov 11 06:54: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 5E92721E81DB for ; Mon, 11 Nov 2013 06:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AGLZELtkB+Z for ; Mon, 11 Nov 2013 06:54:54 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id C1FF721F9E44 for ; Mon, 11 Nov 2013 06:54:53 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9A82D608C3 for ; Mon, 11 Nov 2013 15:54:52 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 85424604AF for ; Mon, 11 Nov 2013 15:54:52 +0100 (CET) Received: (qmail 65156 invoked by uid 1007); 11 Nov 2013 15:54:52 +0100 Date: Mon, 11 Nov 2013 15:54:52 +0100 From: Gert Doering To: GangChen Message-ID: <20131111145452.GF81676@Space.Net> References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SK3XQJ7YwHDQqAUa" 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-ietf-v6ops-nat64-experience-04.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, 11 Nov 2013 14:54:55 -0000 --SK3XQJ7YwHDQqAUa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 11, 2013 at 10:46:42PM +0800, GangChen wrote: > It doesn't expect that dual-stack UEs go to NAT64, because IPv4 native > connections are preferred over IPv6+NAT64 How does the UE know that a target can be reached by native IPv4 if=20 DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --SK3XQJ7YwHDQqAUa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUoDvvN9WwGXkzn/FAQKafRAAr08q/VRfXvCDiAQ9ZfXQ3gROxLXx6g5n QsRKrAdSVByOtY7VkkzUQ1io/3JvZqr0yx07TDg90HZ+nIY4LCt9QWS5QyyUjcw0 ++ZVlc6WNtIs6uFm5juw7bLc+XvnNVX7TJfFwjS30gAPf7o0FsgmVZUh3Pz+56pb qUpcZTr7s73x3Goy+EAa5/IC6wu3HCLuId2qC8dvbQZ/2UTIQGqBPcPUgDzFQpxX llq922AyW5u4fOFr5fLyBBsTeDn06Q9s3DJ/XwRMRUYC4cL1QRF0az1fxl3inLbN cYb/X0Qq8rPsVZMd2nY94vWFz4s6m2BW37/oIip8JPZw0vIiT6vFwa2BcKzzkFr5 /37sjtbUCIefcc6sIW3V0QDnWNV+WxPyzc2fuOUhZkE4NvcxFEj8eJp7jMCPMPf/ v1ReyGborkyMlPaANK8Odcem58X3VQIoqRV13bWNNN7+aH7RpqOX4geHJl831XQu RElCL9AD020/8Gj1ah9UlqVScHv1pdM3BTfT2bhojLouP9y7136tyIYzEc+fvSXw eq57ChysVBeJ9caQL9PkcKSd73uzCl2gDNUWa1IDBD3i4mjh0n2+8+zID6vV3Moj R+dsq/fjSBl4AlQ62IduGVbUmtlY/tollI9+98muqtiyyqrqzhn9sIjxnoNMiNds rtUbJt78zkM= =Eb2i -----END PGP SIGNATURE----- --SK3XQJ7YwHDQqAUa-- From fred@cisco.com Mon Nov 11 09:18: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 4D92611E81B8 for ; Mon, 11 Nov 2013 09:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYectFVMP6-U for ; Mon, 11 Nov 2013 09:17:59 -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 3DB2911E81B5 for ; Mon, 11 Nov 2013 09:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1177; q=dns/txt; s=iport; t=1384190279; x=1385399879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mj+0Le+hw390I5ohRYNrH7alLMMQu7io0+tRrcxh9Q8=; b=K60ksRg/wxsN5s4zwTpAB8tDMSiHnw0MXpGqPaC2dZyEtH83LkAQCE8o YGpyaVKhI7WhFWFGLqz5Pg4f50LzkjXE2VTgt29nkHkfcolbaB0T14DgH 5lyuBnUOA/Ubkohtsi4aqvPyVnRN9R81N/ZcWUZ4Q05WOelL1VMoFxWxa o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAKYQgVKtJV2Z/2dsb2JhbABZgwc4U6w7klyBPRZ0giUBAQEDAXkFCwIBCEYyExICBA4FDg2HVAMJBg2+Nox1gnIHgyCBEAOQMIEwhEqBZYEviyOFOIMmgio X-IronPort-AV: E=Sophos;i="4.93,679,1378857600"; d="asc'?scan'208";a="280336610" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 11 Nov 2013 17:17:58 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rABHHv4k004173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 17:17:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 11:17:57 -0600 From: "Fred Baker (fred)" To: sajjad akbar Thread-Topic: [v6ops] Is there any working on DoS attacks solutions for IPv6? Thread-Index: AQHO3wH2+ycra0l4qEeaMrsHAyUMgg== Date: Mon, 11 Nov 2013 17:17:57 +0000 Message-ID: <249D4B28-BB5D-4DC1-A688-0074E94B8948@cisco.com> References: <1384166133.10720.YahooMailNeo@web121504.mail.ne1.yahoo.com> In-Reply-To: <1384166133.10720.YahooMailNeo@web121504.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_408096E3-D908-4390-8F26-6D60F43B32C9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Is there any working on DoS attacks solutions for IPv6? 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, 11 Nov 2013 17:18:09 -0000 --Apple-Mail=_408096E3-D908-4390-8F26-6D60F43B32C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 11, 2013, at 2:35 AM, sajjad akbar wrote: > Is there any discussion regarding IPv6 dos attacks and it's prevention = efforts? As Warren points out, there is quite a bit that is applicable in Opsec. = You can find drafts with links at = http://datatracker.ietf.org/doc/search/?name=3Dopsec&rfcs=3Don&activedraft= s=3Don&sort=3D. The charter, with instructions for joining the = discussion, may be found at = http://datatracker.ietf.org/wg/opsec/charter/. --Apple-Mail=_408096E3-D908-4390-8F26-6D60F43B32C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSgRFDbjEdbHIsm0MRAi4LAJ9Fj7DyORwR+E+NrYR2w/+hLYoyPgCfZiZG cm0+f3tmGKH94SQYc35qiCw= =HRfK -----END PGP SIGNATURE----- --Apple-Mail=_408096E3-D908-4390-8F26-6D60F43B32C9-- From denghui02@gmail.com Mon Nov 11 16:39: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 1672511E814B for ; Mon, 11 Nov 2013 16:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdWvN3oMFnOA for ; Mon, 11 Nov 2013 16:39:37 -0800 (PST) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEB011E812A for ; Mon, 11 Nov 2013 16:39:37 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id f12so3716140vbg.25 for ; Mon, 11 Nov 2013 16:39:37 -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 :content-type; bh=1ZuKmh+vYFiYKxrSNNfkQkF3W3RwcporNkb7vdy8k3c=; b=jtwSOelWBI/to7fRIQ4+jN+Pu1smrkoF7WL7wVJ0O8VWtVU19G1mPG0UbKlTdw6pXW Fgx2BRJwpbqRfgqcNM4ZdYdo0aMPGe09+SMpW2n++h8tEA2A3nQoUzjaKWrZzF+LIoCV yXHCMuTZeNfrL/zthhv4rWgUVQsvxV1NQk9vOww+8ftSj4s1QMlgatgubUcwnPVWU/9u We6J9oukkRJc1ZdriePHKwMJZbOEOE/fuDXzBcKeV+XDRHsIB9ZRubbjdk2GKuQ5oH9K 4avssWjvP40aSNx71AmoRMl47mPQsNmgXSlH1/fT7P5Udg31iTFz2a0rMhHBTflBZeIc 1F+g== MIME-Version: 1.0 X-Received: by 10.58.208.130 with SMTP id me2mr26275176vec.13.1384216777023; Mon, 11 Nov 2013 16:39:37 -0800 (PST) Received: by 10.221.60.8 with HTTP; Mon, 11 Nov 2013 16:39:36 -0800 (PST) In-Reply-To: <5280F33F.4040605@gmail.com> References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> <527E1385.1020506@gmail.com> <527FACE5.6040002@gmail.com> <5280F33F.4040605@gmail.com> Date: Tue, 12 Nov 2013 08:39:36 +0800 Message-ID: From: Hui Deng To: Alexandru Petrescu , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc192c4974a004eaf01501 Subject: Re: [v6ops] Checking an outcome on the list 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, 12 Nov 2013 00:39:39 -0000 --047d7bdc192c4974a004eaf01501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, I may mis removed v6ops during my last reply, here I add again. I tried before, which does roam across couple of GGSNs area without broken. I guess that your geting lost of the continuity might because that your mobile coverage is not very good, after you drive into or train run into some no coverage area, then you need to reconnect with your data connection. this is quite usual case in USA and EU, but not in Asia because of density living area. thanks for the discussion DENG Hui 2013/11/11 Alexandru Petrescu > Hui, > > Thanks for the reply. > > > Le 10/11/2013 23:25, Hui Deng a =E9crit : > >> Alex, I guess that I am not clear in the last email. Home routed >> >> means that there is home GGSN (kind of anchor point), >> > > ok. > > > wherever you go, the address is always the same if you keep visiting >> the internet, local/visiting SGSN will always tunnel your traffic >> back to the home GGSN, >> > > Ok, in principle, by specification. > > > then your session won't break. >> > > But has one tried it in practice? > > I have tried it, and the sessions do seem to break when roaming: train > and car roaming. > > > In the case you turn off your mobile (such as flight to another >> country), after you landed, your phone will get IP address from your >> home GGSN as well, wherever you go in the visiting country, every >> SGSN in the visiting country will always tunnel your traffic back to >> your home GGSN, then your session won't break as well. >> > > I may agree that the network will tunnel back traffic to home operator. > > And I agree that in the plane roaming case, after switching the > smartphone on/off/on, a new address will be acquired and thus sessions > would break. > > On another hand, in the train or car roaming case, when the smartphone > is _not_ turned off, the sessions still do break upon changing from one > country to another. > > How about trying it and reporting? > > Also, I think this discussion is worth discussing publicly. I am sorry > if I may make statements that may sound too direct. > > Alex > > thanks for your discussion Best regards, DENG Hui >> >> >> 2013/11/10 Alexandru Petrescu > > >> >> >> Hui, >> >> Thanks for the email. >> >> Le 10/11/2013 14:32, Hui Deng a =E9crit : >> >> Alex, thanks for your discussion in the list. Inline please, "=3D=3D>" >> >> >> 2013/11/9 Alexandru Petrescu > >> > >> >> >> >> >> Le 07/11/2013 23:56, Fred Baker (fred) a =E9crit : >> >> We say we check f2f decisions on the mailing list to ensure that >> everyone had a chance to speak. Let's do that. >> >> In IETF 88, we discussed a number of drafts. Of these: >> >> [...] >> >> - Should draft-chen-v6ops-ipv6-roaming-____analysis be adopted as WG >> draft draft-ietf-v6ops-ipv6-roaming-____analysis? >> >> >> >> >> I support adoption of this draft. >> >> I just looked at it in some detail. >> >> I think it deserves enumerating a few practical use-cases where IPv6 >> roaming occurs, including extremes like changing operator in same >> place, or through same operator but crossing a national border. >> >> I also wonder about which cellular technology is involved in this >> roaming: 3G, 4G, or CDMA. >> >> =3D=3D> Mobile communication whatever 3G,4G/CDMA could support session >> continuity if you really drive the car country by country. because >> it always home routed.(GGSN,PDSN,PDN GW) >> >> >> Even if it is 'home'-routed I think communications break. (your use >> of the term 'home' is different than the 'Home Agent', I think). >> >> But I noticed when I am in a train and switch country the IP address >> of the mobile changes. I have no Mobile IP in that mobile, so I have >> to restart the ongoing google maps, or the ongoing youtube. >> >> Even if I had Mobile IP software in the mobile terminal, I don't know >> what is the Home Agent address in the cellular operator network? >> Actually I suppose not any operator offers Home Agent address. >> >> In the roaming discussion there are at least two different cases: - I >> stay attached to home operator because that home operator is present >> in the visited country as well. - or I am offered the choice to >> switch to one in a list of different operators in that new country. >> >> For both these cases I think the IP address of the Mobile Terminal >> changes. >> >> >> And to expose that - just like in IPv4 - ongoing IPv6 sessions are >> breaking upon roaming. >> >> =3D=3D> As said in the above both IPv4 and IPv6 don't have signanificant >> issue about roaming >> >> >> It seems to me, Hui, you didnt try it. There doesnt seem to be >> experimentatin behind this... >> >> >> This draft discussed several different cases like v4v6 pdp support >> in the roaming country et al. if every deployed mobile >> gateway/handset can support the latest version, then that won't be >> any issue. >> >> >> Does the latest version require the terminal to use Mobile IP >> software? >> >> Thanks, >> >> Alex >> >> Best regards, DENG Hui >> >> >> Alex >> >> >> I'll collect up the responses in a week and make a determination >> based on that. I'm interested in your viewpoint, whether positive or >> negative. If you would prefer to send it privately to >> v6ops-chairs@tools.ietf.org >> > >> >, that works too. >> >> >> >> ___________________________________________________ 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 >> >> > > >> >> >> >> >> >> > > --047d7bdc192c4974a004eaf01501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex,
=A0
I may mis removed v6= ops during my last reply, here I add again.
=A0
I tried= before, which=A0does roam across couple of GGSNs area without broken.
=A0
I guess that your geting lost of the continuity might because= that your mobile coverage is not very good, after you drive into or train = run into some no coverage area, then you need to reconnect with your data c= onnection. this is quite usual case in USA and EU, but not in Asia because = of density living area.
=A0
thanks for the discussion
=A0
DENG H= ui
=A0


2013/11/11 Alexandru Petrescu <alexandru.petre= scu@gmail.com>
Hui,

Thanks for the reply.


Le 10/11/2013 23:25, Hui Deng a =E9crit :
Alex, I guess that I am not clear in the last email. Home routed

means that there is home GGSN (kind of anchor point),

ok.


wherever you go, the address is always the same if you keep visiting
the internet, local/visiting SGSN will always tunnel your traffic
back to the home GGSN,

Ok, in principle, by specification.


then your session won't break.

But has one tried it in practice?

I have tried it, and the sessions do seem to break when roaming: train
and car roaming.


In the case you turn off your mobile (such as flight to another
country), after you landed, your phone will get IP address from your
=A0home GGSN as well, wherever you go in the visiting country, every
SGSN in the visiting country will always tunnel your traffic back to
your home GGSN, then your session won't break as well.

I may agree that the network will tunnel back traffic to home operator.

And I agree that in the plane roaming case, after switching the
smartphone on/off/on, a new address will be acquired and thus sessions
would break.

On another hand, in the train or car roaming case, when the smartphone
is _not_ turned off, the sessions still do break upon changing from one
country to another.

How about trying it and reporting?

Also, I think this discussion is worth discussing publicly. =A0I am sorry if I may make statements that may sound too direct.

Alex

thanks for your discussion Best regards, DENG Hui


2013/11/10 Alexandru Petrescu <alexandru.petrescu@gmail.com
<mailto:alexandru.petrescu@gmail.com>>


Hui,

Thanks for the email.

Le 10/11/2013 14:32, Hui Deng a =E9crit :

Alex, thanks for your discussion in the list. Inline please, "=3D=3D&g= t;"


2013/11/9 Alexandru Petrescu <alexandru.petrescu@gmail.com
<mailto:alexandru.petrescu@gmail.com>
<mailto:alexand= ru.petrescu@__gma= il.com

<mailto:alexandru.petrescu@gmail.com>>>


Le 07/11/2013 23:56, Fred Baker (fred) a =E9crit :

We say we check f2f decisions on the mailing list to ensure that
everyone had a chance to speak. Let's do that.

In IETF 88, we discussed a number of drafts. Of these:

[...]

- Should draft-chen-v6ops-ipv6-roaming-____analysis be adopted as WG=
draft draft-ietf-v6ops-ipv6-roaming-____analysis?




I support adoption of this draft.

I just looked at it in some detail.

I think it deserves enumerating a few practical use-cases where IPv6
roaming occurs, including extremes like changing operator in same
place, or through same operator but crossing a national border.

I also wonder about which cellular technology is involved in this
roaming: 3G, 4G, or CDMA.

=3D=3D> Mobile communication whatever 3G,4G/CDMA could support session continuity if you really drive the car country by country. because
it always home routed.(GGSN,PDSN,PDN GW)


Even if it is 'home'-routed I think communications break. =A0(your = use
of the term 'home' is different than the 'Home Agent', I th= ink).

But I noticed when I am in a train and switch country the IP address
of the mobile changes. =A0I have no Mobile IP in that mobile, so I have
to restart the ongoing google maps, or the ongoing youtube.

Even if I had Mobile IP software in the mobile terminal, I don't know what is the Home Agent address in the cellular operator network?
Actually I suppose not any operator offers Home Agent address.

In the roaming discussion there are at least two different cases: - I
stay attached to home operator because that home operator is present
in the visited country as well. - or I am offered the choice to
switch to one in a list of different operators in that new country.

For both these cases I think the IP address of the Mobile Terminal
changes.


And to expose that - just like in IPv4 - ongoing IPv6 sessions are
breaking upon roaming.

=3D=3D> As said in the above both IPv4 and IPv6 don't have signanifi= cant
issue about roaming


It seems to me, Hui, you didnt try it. =A0There doesnt seem to be
experimentatin behind this...


This draft discussed several different cases like v4v6 pdp support
in the roaming country et al. if every deployed mobile
gateway/handset can support the latest version, then that won't be
any issue.


Does the latest version require the terminal to use Mobile IP
software?

Thanks,

Alex

Best regards, DENG Hui


Alex


I'll collect up the responses in a week and make a determination
based on that. I'm interested in your viewpoint, whether positive or negative. If you would prefer to send it privately to
v6ops-chai= rs@tools.ietf.org <mailto:v6ops-chairs@tools.ietf.org>
=
<mailto:v6ops-c= hairs@tools.__ietf= .org

<mailto:v6ops-chairs@tools.ietf.org>>, that works too.



___________________________________________________ v6ops mailing list v6ops@ietf.org= <mailto:v6ops@ietf.= org> <mailto:= v6ops@ietf.org
<mailto:v6ops@ietf.o= rg>>
https://www.ietf.org/mailman/____listinfo/v6ops
<https://www.ietf.org/mailman/__listinfo/v6ops>
<https://www.ietf.org/mailman/__listinfo/v6ops
<https://www.ietf.org/mailman/listinfo/v6ops>>



___________________________________________________ v6ops mailing list v6ops@ietf.org= <mailto:v6ops@ietf.= org> <mailto:= v6ops@ietf.org
<mailto:v6ops@ietf.o= rg>>
https://www.ietf.org/mailman/____listinfo/v6ops
<https://www.ietf.org/mailman/__listinfo/v6ops>
<https://www.ietf.org/mailman/__listinfo/v6ops
<https://www.ietf.org/mailman/listinfo/v6ops>>








--047d7bdc192c4974a004eaf01501-- From ida@brumund.ca Mon Nov 11 17:17: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 E847A21E80D9 for ; Mon, 11 Nov 2013 17:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf1JACw7K5jT for ; Mon, 11 Nov 2013 17:17:33 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id C483C21E80D0 for ; Mon, 11 Nov 2013 17:17:17 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id eo20so4588405lab.37 for ; Mon, 11 Nov 2013 17:17:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2YDNQ1WcrA1wKtsM8yWAUj077opddpcDJkI3PHJN+Yc=; b=iVCUiuxJJB/FHBSaTO6PAoBSriSnR68Ggujmo+R6j0L2ipg6dnULoveOE+9jnyNiRn Kj+MLO1pR72TH2/ZVmEZ+hJbCnmd3C4dx9PPdw3g6vsm2v9ZVokiQEk3pfXO4Cltz7Zy gwxXl9MnE86uNg9FqB9f41OIlvn/aAyfmTWW5UR1IWNCAoN0UQdpOuQ/OD+ZSVkHgRHr AHkTfbL6hUogGGQ5N3GfTX0JAEQ+Co06StTcPdjA8wsf5mzRroQ0cCyHg5HTPxjx0y1t w9jCmsmqey6syIWIxNsID/b2yRigdAvz3oPRa2kwmmvWRDVVSeXZx7n48nPvuBECIp+C mjXA== X-Gm-Message-State: ALoCoQkegTyzkCiPptR0mcZH75r1zzdeEOjLNSN6mIxQzO56qt/nwIKRDVYCk5eWo+cxGWb17DBC MIME-Version: 1.0 X-Received: by 10.152.116.109 with SMTP id jv13mr247409lab.30.1384219036680; Mon, 11 Nov 2013 17:17:16 -0800 (PST) Received: by 10.112.168.103 with HTTP; Mon, 11 Nov 2013 17:17:16 -0800 (PST) X-Originating-IP: [24.114.70.141] In-Reply-To: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> Date: Mon, 11 Nov 2013 20:17:16 -0500 Message-ID: From: Ida Leung To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11c3675ef9278904eaf09ba8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Checking an outcome on the list 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, 12 Nov 2013 01:17:38 -0000 --001a11c3675ef9278904eaf09ba8 Content-Type: text/plain; charset=ISO-8859-1 Response to your questions: 1/ I agreed this approach for the draft. 2/ draft-chen-v6ops-ipv6-roaming-analysis should be adopted as WG draft. That helps the mobile operators to realize the problem they are facing and together to find a way to fix it/workaround it. We have been facing some of the roaming issues mentioned in the draft. Thanks, ...Ida ...Ida On Thu, Nov 7, 2013 at 5:56 PM, Fred Baker (fred) wrote: > We say we check f2f decisions on the mailing list to ensure that everyone > had a chance to speak. Let's do that. > > In IETF 88, we discussed a number of drafts. Of these: > - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC on > Monday morning New Zealand time. > - draft-ietf-v6ops-nat64-experience appears to have reached closure. We > have one additional revision coming, and then will do a 1 week last call, > probably early December. > - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to be > a real problem. > 1) In your opinion, should > draft-liu-bonica-v6ops-dhcpv6-slaac-problem be adopted as WG draft > draft-ietf-v6ops-dhcpv6-slaac-problem and matured into a problem statement > to present to 6man? > 2) In your opinion, should v6ops invite a draft (which we might > adopt as a working group draft) that gives current guidance to operators > regarding the use of DHCP and SLAAC in their networks? > - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft > draft-ietf-v6ops-ipv6-roaming-analysis? > > I'll collect up the responses in a week and make a determination based on > that. I'm interested in your viewpoint, whether positive or negative. If > you would prefer to send it privately to v6ops-chairs@tools.ietf.org, > that works too. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c3675ef9278904eaf09ba8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Response to your questions:

1/ I agreed= this approach for the draft. =A0

2/=A0
= =A0draft-chen-v= 6ops-ipv6-roaming-analysis should be adopted as WG draft. =A0That helps the mobile = operators to realize the problem they are facing and together to find a way= to fix it/workaround it. =A0We have been facing some of the roaming issues= mentioned in the draft. =A0

Tha= nks,

...Ida

...Ida


On Thu,= Nov 7, 2013 at 5:56 PM, Fred Baker (fred) <fred@cisco.com> wro= te:
We say we check f2f decisions on the mailing= list to ensure that everyone had a chance to speak. Let's do that.

In IETF 88, we discussed a number of drafts. Of these:
=A0 - draft-ietf-v6ops-balanced-ipv6-security will start a two week WGLC on= Monday morning New Zealand time.
=A0 - draft-ietf-v6ops-nat64-experience appears to have reached closure. We= have one additional revision coming, and then will do a 1 week last call, = probably early December.
=A0 - draft-liu-bonica-v6ops-dhcpv6-slaac-problem documents what seems to b= e a real problem.
=A0 =A0 =A0 1) In your opinion, should draft-liu-bonica-v6ops-dhcpv6-slaac-= problem be adopted as WG draft draft-ietf-v6ops-dhcpv6-slaac-problem and ma= tured into a problem statement to present to 6man?
=A0 =A0 =A0 2) In your opinion, should v6ops invite a draft (which we might= adopt as a working group draft) that gives current guidance to operators r= egarding the use of DHCP and SLAAC in their networks?
=A0 - Should draft-chen-v6ops-ipv6-roaming-analysis be adopted as WG draft = draft-ietf-v6ops-ipv6-roaming-analysis?

I'll collect up the responses in a week and make a determination based = on that. I'm interested in your viewpoint, whether positive or negative= . If you would prefer to send it privately to v6ops-chairs@tools.ietf.org, that works too.

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


--001a11c3675ef9278904eaf09ba8-- From alexandru.petrescu@gmail.com Tue Nov 12 03:06: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 6FBC311E812B for ; Tue, 12 Nov 2013 03:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh-jPCsPQo-p for ; Tue, 12 Nov 2013 03:06:34 -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 2CF0111E80F5 for ; Tue, 12 Nov 2013 03:06:27 -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 rACB6O6v003123; Tue, 12 Nov 2013 12:06:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D37FA205AF2; Tue, 12 Nov 2013 12:06:36 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C5F0F205AF1; Tue, 12 Nov 2013 12:06:36 +0100 (CET) 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 rACB6A2h000405; Tue, 12 Nov 2013 12:06:25 +0100 Message-ID: <52820BA2.8020001@gmail.com> Date: Tue, 12 Nov 2013 12:06:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Hui Deng , "v6ops@ietf.org" References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> <527E1385.1020506@gmail.com> <527FACE5.6040002@gmail.com> <5280F33F.4040605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming (was: Checking an outcome on the list) 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, 12 Nov 2013 11:06:40 -0000 Hello Hui, Le 12/11/2013 01:39, Hui Deng a écrit : > Hi Alex, I may mis removed v6ops during my last reply, here I add > again. I tried before, which does roam across couple of GGSNs area > without broken. In that experimentation, were the GGSNs belonging to the same operator, or to different operators? Did the terminal keep the same IPv6 address? > I guess that your geting lost of the continuity might because that > your mobile coverage is not very good, Well, it is not that simple. In one particular IPv4 trial the train line is covered by several cellular networks, even when crossing national border. > after you drive into or train run into some no coverage area, then > you need to reconnect with your data connection. this is quite usual > case in USA and EU, but not in Asia because of density living area. I am not sure what you mean, but in EU many areas are well populated. I have tried to roam with the IPv6 connection of a particular cellular operator, by going from one country to another, and by switching on and off the handset during travel: either imposed by flight procedures, or because not enough battery. In principle, the IPv6 roaming works fine in several countries in the EU. It all depends what we call 'roaming'. What I have not tried is the following two scenarios: - roam IPv6 from one country to the next, keeping same IPv6 operator, without switching off the handset. Note whether or not the ongoing applications break at handover. Maybe by car or by train. - roam IPv6 from one IPv6 operator to another IPv6 operator, without switching off the handset. Maybe not being mobile at all. They can easily be tried. Intuitively, I would say that applications get interrupted, because there would be change in the IPv6 address allocated to the smartphone. I may be wrong though. Alex > thanks for the discussion DENG Hui > > > 2013/11/11 Alexandru Petrescu > > > Hui, > > Thanks for the reply. > > > Le 10/11/2013 23:25, Hui Deng a écrit : > > Alex, I guess that I am not clear in the last email. Home routed > > means that there is home GGSN (kind of anchor point), > > > ok. > > > wherever you go, the address is always the same if you keep visiting > the internet, local/visiting SGSN will always tunnel your traffic > back to the home GGSN, > > > Ok, in principle, by specification. > > > then your session won't break. > > > But has one tried it in practice? > > I have tried it, and the sessions do seem to break when roaming: > train and car roaming. > > > In the case you turn off your mobile (such as flight to another > country), after you landed, your phone will get IP address from your > home GGSN as well, wherever you go in the visiting country, every > SGSN in the visiting country will always tunnel your traffic back to > your home GGSN, then your session won't break as well. > > > I may agree that the network will tunnel back traffic to home > operator. > > And I agree that in the plane roaming case, after switching the > smartphone on/off/on, a new address will be acquired and thus > sessions would break. > > On another hand, in the train or car roaming case, when the > smartphone is _not_ turned off, the sessions still do break upon > changing from one country to another. > > How about trying it and reporting? > > Also, I think this discussion is worth discussing publicly. I am > sorry if I may make statements that may sound too direct. > > Alex > > thanks for your discussion Best regards, DENG Hui > > > 2013/11/10 Alexandru Petrescu > >> > > > Hui, > > Thanks for the email. > > Le 10/11/2013 14:32, Hui Deng a écrit : > > Alex, thanks for your discussion in the list. Inline please, "==>" > > > 2013/11/9 Alexandru Petrescu > > __g__mail.com > > >>> > > > Le 07/11/2013 23:56, Fred Baker (fred) a écrit : > > We say we check f2f decisions on the mailing list to ensure that > everyone had a chance to speak. Let's do that. > > In IETF 88, we discussed a number of drafts. Of these: > > [...] > > - Should draft-chen-v6ops-ipv6-roaming-______analysis be adopted as > WG draft draft-ietf-v6ops-ipv6-roaming-______analysis? > > > > > I support adoption of this draft. > > I just looked at it in some detail. > > I think it deserves enumerating a few practical use-cases where IPv6 > roaming occurs, including extremes like changing operator in same > place, or through same operator but crossing a national border. > > I also wonder about which cellular technology is involved in this > roaming: 3G, 4G, or CDMA. > > ==> Mobile communication whatever 3G,4G/CDMA could support session > continuity if you really drive the car country by country. because it > always home routed.(GGSN,PDSN,PDN GW) > > > Even if it is 'home'-routed I think communications break. (your use > of the term 'home' is different than the 'Home Agent', I think). > > But I noticed when I am in a train and switch country the IP address > of the mobile changes. I have no Mobile IP in that mobile, so I have > to restart the ongoing google maps, or the ongoing youtube. > > Even if I had Mobile IP software in the mobile terminal, I don't > know what is the Home Agent address in the cellular operator > network? Actually I suppose not any operator offers Home Agent > address. > > In the roaming discussion there are at least two different cases: - > I stay attached to home operator because that home operator is > present in the visited country as well. - or I am offered the choice > to switch to one in a list of different operators in that new > country. > > For both these cases I think the IP address of the Mobile Terminal > changes. > > > And to expose that - just like in IPv4 - ongoing IPv6 sessions are > breaking upon roaming. > > ==> As said in the above both IPv4 and IPv6 don't have signanificant > issue about roaming > > > It seems to me, Hui, you didnt try it. There doesnt seem to be > experimentatin behind this... > > > This draft discussed several different cases like v4v6 pdp support in > the roaming country et al. if every deployed mobile gateway/handset > can support the latest version, then that won't be any issue. > > > Does the latest version require the terminal to use Mobile IP > software? > > Thanks, > > Alex > > Best regards, DENG Hui > > > Alex > > > I'll collect up the responses in a week and make a determination > based on that. I'm interested in your viewpoint, whether positive or > negative. If you would prefer to send it privately to > v6ops-chairs@tools.ietf.org > > __i__etf.org > > >>, that works too. > > > > _____________________________________________________ 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 phdgang@gmail.com Tue Nov 12 06:35: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 BAF2021F842B for ; Tue, 12 Nov 2013 06:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwZSDfAi1CSI for ; Tue, 12 Nov 2013 06:35:52 -0800 (PST) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2621F969F for ; Tue, 12 Nov 2013 06:35:46 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id t7so2520635qeb.10 for ; Tue, 12 Nov 2013 06:35:46 -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=5J8qFTSJPjjshcOC3jrSKvNb1ODNskCphILDApu1NzM=; b=QQt+4vJaelw6ae5NFq8GjG05+HjKI2eXXnBD0KlY8V1L42tKAqZejPySmroRLtwn8S iCbGOkovjBEt6TfLNeqijTLEN5VPF8zFzAvpVs1asuCClg1ZYCfDsrdKMkT173GHkIE/ aMrL+oILFSBRufMJ3MOH4rfzmbeLeuC4d5rDtTAWWraErRAlrh+PRHifIwSf/YPgQLj+ pge+fBjordWe2LqTBXrXq5oncOB3AvcdX3ImaAO3/fi02ZphvihlfW1ZmGflc19rYQwg GImn18zEZEjUiy/3dUHs3sHcsE/+G2Yd/XLp3TnyPiEULZEA2QqQGhNqfUgIzFZeTQOw iuLw== MIME-Version: 1.0 X-Received: by 10.224.63.199 with SMTP id c7mr59007678qai.74.1384266946078; Tue, 12 Nov 2013 06:35:46 -0800 (PST) Received: by 10.224.172.135 with HTTP; Tue, 12 Nov 2013 06:35:45 -0800 (PST) In-Reply-To: <20131111145452.GF81676@Space.Net> References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> Date: Tue, 12 Nov 2013 22:35:45 +0800 Message-ID: From: GangChen To: Gert Doering Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 12 Nov 2013 14:35:52 -0000 2013/11/11, Gert Doering : > Hi, > > On Mon, Nov 11, 2013 at 10:46:42PM +0800, GangChen wrote: >> It doesn't expect that dual-stack UEs go to NAT64, because IPv4 native >> connections are preferred over IPv6+NAT64 > > How does the UE know that a target can be reached by native IPv4 if > DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4? UE may not can determine the existence of IPv4 native connections. However, an network side may could serve the right DNS address according to the UE connection status, for example the solution described at http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-00 Gang > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > From joelja@bogus.com Tue Nov 12 09:44: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 6AE4721E8104 for ; Tue, 12 Nov 2013 09:44:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4STw4akqm8N for ; Tue, 12 Nov 2013 09:44:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DA92721E8157 for ; Tue, 12 Nov 2013 09:41:30 -0800 (PST) Received: from [192.168.1.10] (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id rACHfRrS014490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Nov 2013 17:41:29 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_FD46C409-BEB5-46A7-8B67-F7BE794EB7F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: joel jaeggli In-Reply-To: Date: Tue, 12 Nov 2013 09:41:22 -0800 Message-Id: References: To: Arturo Servin X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 12 Nov 2013 17:41:30 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 12 Nov 2013 17:44:29 -0000 --Apple-Mail=_FD46C409-BEB5-46A7-8B67-F7BE794EB7F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 5, 2013, at 10:16 AM, Arturo Servin = wrote: >=20 > Blocking according to DNS content would be something like Deep Packet = Inspection, isn't it? implementing split horizons on your nameservers is a fairly = straight-forward exercise that doesn=92t involve middle-boxes looking at = packets=85 likewise separating internal authoritative zone resolution from external = ones is well understood and widely deployed in ipv4, afterall I have = practical applications for working forward and reverse for the RFC-1918 = space in my datacenters. I have no need, nor is it benificial for me to = expose those zones/servers to queries from the outside. >=20 > Do we want to go there? >=20 > /as >=20 >=20 > On Tue, Nov 5, 2013 at 3:50 PM, Jen Linkova wrote: > Section 4.2. says that > " >=20 > So when using ULAs in a network, the administrators should clearly > set the scope of the ULAs and configure ACLs on relevant border > routers to block them out of the scope. And if internal DNS are > enabled, the administrators might also need to use internal-only = DNS > names for ULAs. > " > I believe it should that that the administrator MUST configure egress > ACLs on borders routers and MUST ensure that their DNS servers do not > include ULAs in any responses to external clients. >=20 >=20 >=20 >=20 > -- > SY, Jen Linkova aka Furry > _______________________________________________ > 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 --Apple-Mail=_FD46C409-BEB5-46A7-8B67-F7BE794EB7F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKCaEIACgkQ8AA1q7Z/VrIrvQCeKETvgxhLFaQi4TVrdJeAb4nr cuUAnR+T8Lze/n+ynCQhIBqwcxbHQjlP =BnaT -----END PGP SIGNATURE----- --Apple-Mail=_FD46C409-BEB5-46A7-8B67-F7BE794EB7F6-- From tarko@lanparty.ee Tue Nov 12 09:46: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 C78DF21E8141 for ; Tue, 12 Nov 2013 09:46:24 -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_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOhQcq4UFm61 for ; Tue, 12 Nov 2013 09:46:17 -0800 (PST) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) by ietfa.amsl.com (Postfix) with ESMTP id C625521E80C4 for ; Tue, 12 Nov 2013 09:44:27 -0800 (PST) Received: from tuli.elion.ee ([194.126.117.170] helo=[192.168.28.102]) by valgus.lanparty.ee with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VgI0m-0007e4-HK for v6ops@ietf.org; Tue, 12 Nov 2013 19:44:25 +0200 Message-ID: <528268F3.8090501@lanparty.ee> Date: Tue, 12 Nov 2013 19:44:19 +0200 From: Tarko Tikan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> In-Reply-To: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 194.126.117.170 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 12 Nov 2013 17:46:25 -0000 hey, > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. +1 from me (as an operator) for the concept. This is similar to what I plan to deploy but with one exception - we will not do this in the CPE, we will do it in the edge routers via subscriber management instead. This way we can configure it centrally and very easily push new policy for certain subscriber when one wants to have "permit any" inbound. For us this also follows IPv4 operating model (which might not always be the best case but feels like a best case for us). I'm _not_ saying doing this in the CPE is wrong, this is very typical for the cable operators for example - configure everything via modem config files delivered on boot. Or for operators who have no subscriber awareness in the edge routers. YMMV. -- tarko, elion.ee From marc.lampo.ietf@gmail.com Tue Nov 12 11:39: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 196C521E8091 for ; Tue, 12 Nov 2013 11:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_84=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdYe2XOp0JJc for ; Tue, 12 Nov 2013 11:39:37 -0800 (PST) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id E3A0621E80DB for ; Tue, 12 Nov 2013 11:39:36 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id f12so4521578vbg.39 for ; Tue, 12 Nov 2013 11:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+8YT416BusDZK8u2RnbA2xSm42sC3AOonZ9EwhuCLmM=; b=V75Xam4BfUiE7temgX4HZsMNkMRnM6XuGQyt576apgPPDfWMlR7qCIqdW3RVemButA +b+K3qcnj90g7+TOSFOO1CfNUjSOa22Bz86J/3+hrYDXF3sU/C4wYLIvtnhXed8mQ0CV UGGw92ZuYtCZnJUwLO/YhXrA6Kxkfoaz5k8sRqOSNoPwrws8R+TxzAKasnTyRNJGgjS0 98P86r4fv4+XoRVlmhY7OZqp8676SaxdpR9VzsfvU73h+NT11377IJwHtSMOFGtWKcSi V6Cfh9zOJPUT43YIcSZChN9xay4Y88/lZJnc2uMd0MaQ/sQZeWUh9JwJ0rSIhjX6tRnW s3LA== MIME-Version: 1.0 X-Received: by 10.58.133.77 with SMTP id pa13mr10578809veb.21.1384285176149; Tue, 12 Nov 2013 11:39:36 -0800 (PST) Received: by 10.58.227.66 with HTTP; Tue, 12 Nov 2013 11:39:36 -0800 (PST) In-Reply-To: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> Date: Tue, 12 Nov 2013 20:39:36 +0100 Message-ID: From: Marc Lampo To: Fred Baker Content-Type: multipart/alternative; boundary=047d7b673398335caf04eb0002ad Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 12 Nov 2013 19:39:38 -0000 --047d7b673398335caf04eb0002ad Content-Type: text/plain; charset=ISO-8859-1 sorry for being late in the process, but I do have some remarks on the content of this draft : Personally I don't like the 3.1 point 3: Rule openness Open by default, except for a list of configurable/updatable protocol+port numbers. What I would like, in an IPv6 capable home gateway is that I can define what port(s) are allowed to which internal device - either manually or some pcp. So, from RFC 6092, REC-48 (define what is allowed) + REC-33 (drop everything else) In my opinion there is nothing wrong with RFC 6092. Why not implement it ? Why an (informational) RFC on an implementation that does not, and states no explicit reason for not doing it. It is unclear if the list of threats, section 2, is in relationship with what will be achieved by this implementation. Take the last of the list, that refers to : "covert channel" (regardless if a trojanised host, in or out of a botnet is involved) In the book IPv6 & Security, of which you, Erik, are coauthor, the term "covert channel" is linked to the destinations options extension header. But this draft does not elaborate further on covert channel, nor does it state that implementation blocks covert channels. I think it is misleading the reader to refer to the threat and not propose something against it. (at least, I cannot interpret the draft/implementation as : drop any IPv6 packet with a destination options extension header) Although I cannot support a default open policy, and (only just) heard the Berlin audio with the remarks on the port list, but SUN Remote Procedure Call is both UDP and TCP port 111 (for section 3.2) Consequently, in my opinion the "Security" section of the draft is too "soft". Rather then : - unauthorized access blocked because vulnerable ports are blocked why not (from http://tools.ietf.org/html/draft-ietf-mext-firewall-vendor-05) One of the main goals of any firewall is to prevent unsolicited traffic from entering the network. The proposed solution allows such traffic into the network, albeit with a number of restrictions. (that draft seems expired anyway, lucky us) Kind regards, Marc On Sun, Nov 10, 2013 at 8:00 PM, Fred Baker wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security. > Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b673398335caf04eb0002ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
sorry for being late in the proce= ss, but I do have some remarks on the content of this draft :

= Personally I don't like the 3.1 point 3: Rule openness
Op= en by default, except for a list of configurable/updatable protocol+port nu= mbers.


What I would like, in an IPv6 capable home ga= teway is that I can define what port(s)
are allowed to which internal de= vice - either manually or some pcp.
So, from RFC 6092, REC-48= (define what is allowed) + REC-33 (drop everything else)

In my opinion there is nothing wrong with RFC 6092.
Why n= ot implement it ?
Why an (informational) RFC on an implementa= tion that does not, and states no explicit reason for not doing it.


It is unclear if the list of threats, section= 2, is in relationship with what will be achieved by this implementation.
Take the last of the list, that refers to : "covert chann= el"
(regardless if a trojanised host, in or out of a botnet is invol= ved)
In the book IPv6 & Security, of which you, Erik, are= coauthor, the term "covert channel" is linked to
the destinat= ions options extension header.
But this draft does not elaborate further on covert channel, nor= does it state that implementation blocks covert channels.
I = think it is misleading the reader to refer to the threat and not propose so= mething against it.
(at least, I cannot interpret the draft/implementation as : drop= any IPv6 packet with a destination options extension header)


Although I cannot support a default open policy, and (only just) h= eard the Berlin audio with the remarks on the port list,
but SUN Remote Procedure Call is both UDP and TCP port 111 (for = section 3.2)


Consequently, in my opinion the "Securit= y" section of the draft is too "soft".
Rather then = :
- unauthorized access blocked because vulnerable ports are blocked
why not 
   One of the main=
 goals of any firewall is to prevent unsolicited
   traffic from entering the network.  The proposed solution allows such
   traffic into the network, albeit with a number of restrictions.
(th= at draft seems expired anyway, lucky us)


<= /div>
Kind regards,

Marc


O= n Sun, Nov 10, 2013 at 8:00 PM, Fred Baker <fred@cisco.com> wro= te:
This is to initiate a two week working group= last call of
http://tools.ietf.org/html/draft-ietf-v6ops-balanced-= ipv6-security. =A0Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a
statement or finding additional issues that need to be addressed,
please post your comments to the list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b673398335caf04eb0002ad-- From fred@cisco.com Tue Nov 12 11:41: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 420DC21F9EF2 for ; Tue, 12 Nov 2013 11:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.426 X-Spam-Level: X-Spam-Status: No, score=-110.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUGagnLqwQW1 for ; Tue, 12 Nov 2013 11:41:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C711E810B for ; Tue, 12 Nov 2013 11:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1484; q=dns/txt; s=iport; t=1384285293; x=1385494893; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YuJmfCgblJPGsulbzwOEi+QIVXmkrzxNKq47QB4RAHw=; b=U0BixnBfmRGszVS8XQXNe87bQAgBLo/bCZN0J1heENIS01Zo6LJJkxRV QnpAXvBp+1P1/BexJmtb/WGGIzUiG7HYIik1UD0Bm/lWlrHAKMZMLl5XZ CUxWQe7EaIjXSh0DIK0UY+Z0I5YATgDReCc05gy0maNY4jklTJL0tAIXU U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FABmEglKtJV2Z/2dsb2JhbABagweBC78XgSoWdIIlAQEBAwFxCAULAgEIRiERJQIEDgUOh2EDCQa1Tg2JZYxtgnIHgyCBEQOQMIEwhESBa4xShTiDJoIq X-IronPort-AV: E=Sophos;i="4.93,687,1378857600"; d="asc'?scan'208";a="283878818" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 12 Nov 2013 19:41:30 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rACJfUgn022493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 19:41:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 13:41:30 -0600 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHO398uW9KL+QiutECzeTNuuK2QhA== Date: Tue, 12 Nov 2013 19:41:29 +0000 Message-ID: <21C0A698-E56B-4B0B-8454-1323027AD04E@cisco.com> References: <52793827.2040708@gmail.com> In-Reply-To: <52793827.2040708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_52E5B816-78F1-44A1-AA0D-66F4E2773CF5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 12 Nov 2013 19:41:53 -0000 --Apple-Mail=_52E5B816-78F1-44A1-AA0D-66F4E2773CF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2013, at 10:25 AM, Brian E Carpenter = wrote: > No, but that's not what he means. He means split DNS, where > the internal DNS server includes records that are not present > in the external DNS server. That, like it or not, is standard > practice today in many enterprise networks. I'm told that it goes beyond that. There are at least three "directions" = in the split: - inside, where internal-only names are advertised, might use an = internal-only prefix, and even "outside" names might have different = servers and different addresses. - outside, where internal-only names are not advertised - partner, which is "outside" plus some names made accessible to the = partner, and may imply some form of b2b routing as well. --Apple-Mail=_52E5B816-78F1-44A1-AA0D-66F4E2773CF5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSgoRZbjEdbHIsm0MRArcMAKCONPEVtBmk6BRI1vrfr7rGS09gwgCg/Bq/ Nrkb2Zthk1Bo3QP9DJUtko4= =MdZh -----END PGP SIGNATURE----- --Apple-Mail=_52E5B816-78F1-44A1-AA0D-66F4E2773CF5-- From fred@cisco.com Tue Nov 12 13:54: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 2551721E80E4 for ; Tue, 12 Nov 2013 13:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.432 X-Spam-Level: X-Spam-Status: No, score=-110.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZfAxlFtiBCr for ; Tue, 12 Nov 2013 13:54:18 -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 F2AA421F9D28 for ; Tue, 12 Nov 2013 13:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5289; q=dns/txt; s=iport; t=1384293258; x=1385502858; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oWhOeOB9PKS1bwQXxy26k0sPQ5VhhzWeqMuLEhjkFQw=; b=EL0DMMsAkWBwGeEHRFGkjkMAsolimXG8GXls0s4GyRerBj2DDFlAPl6S GR9UAgkJ6sS3Ow9AykG+GLI4c3u25Lp2jOi+CY7Ps7ViCNeHvDB7qrw8M KNXe1bPfR5AwoaTmCyMokGXqgtbRoZHQzOdyko2DqLtYvEf+B/PIgT5MT 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJWiglKtJV2Y/2dsb2JhbABagwc4U78jgSoWdIImAQEEZSQCAQhGMiUCBCEMh2cNvy+OFoFQgyCBEQOQMIEwhi+SCoMmgWoHFwYc X-IronPort-AV: E=Sophos;i="4.93,688,1378857600"; d="asc'?scan'208";a="283918336" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 12 Nov 2013 21:54:17 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACLsHF1025339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Nov 2013 21:54:17 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 15:54:16 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO3/G7AQKm550kHkGXsuv091nq1Q== Date: Tue, 12 Nov 2013 21:54:16 +0000 Message-ID: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_E6159D46-DEB4-43E6-8356-4705C6A8B81F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 12 Nov 2013 21:54:23 -0000 --Apple-Mail=_E6159D46-DEB4-43E6-8356-4705C6A8B81F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This is a comment as a participant, not as a chair. I find myself scratching my head with this, and found myself scratching = my head with what became RFC 6092. My first premise in both cases is that a firewall primarily mitigates = attacks on the bandwidth of a network and an aggregated network. An = attack that actually hits a host or application will have to be defended = against by the host/application or a security service provided by some = other device in the network; firewall rules provide a form of defense in = depth, but no more. I compare a firewall to the human skin. The skin is, = itself, hardly necessary for the "health security" of the body, as the = other systems of the body could be active and mitigate attacks on the = body. However, it makes active use of those capabilities less of a = requirement by preventing certain classes of attacks. My second premise is that any communication attempt directed to a = network, or to a application in a network, that doesn't have a = application in the network that willingly communicates with it is an = attack. Now, we have tools - PCP, UPnP - that enable an application to inform = the network of its approving presence. If I want someone to be able to = connect to a given device using IPsec, when the device comes up, it can = inform the network of a n-tuple {application address, IPsec protocol ID, = }, and "poke a hole" in a firewall regardless of the description of = the firewall. The administration can also log such requests and apply = its own policy on whether it honors them. If I want them to initiate = SMTP or https connections to a given system, it can similarly announce = itself as {address, TCP, port, any, any}, and allow incoming SMTP = connections to it. So regardless of the firewall type, we have tools to enable an = application in the network to make itself available to peers "outside". = And of course, as suggested in zone-based defenses and in RFC 6092, when = a application initiates a connection outside, by implication the = firewall can open a "hole" for the return traffic. So the only protocols, or peers using protocols, under discussion are = those that have no application that is willing to have sessions = initiated to it from the outside of the network. RFC 6092 permits IPsec packets as a blanket rule. That facilitates two = attacks. First, there is a form of network scanning enabled; a = application outside the network can initiate IKE connections to = addresses it thinks might exist in the network (observing, for example, = email envelope information to find such addresses); if it gets a reply, = something is using the address. Second, it can busy out the = verification/decrypt unit in a application simply by sending it IPsec = traffic that does not have a proper key. That can DOS the application's = CPU resources or its communication resources. Now, if a application = wants to communicate in that way and recognizes the vulnerability, it = can open that hole. But if a application doesn't want to communicate = that way (for example, it implements IPsec but the applications it uses = have no keys to validate data with), what is the argument for leaving = the vulnerability open? draft-ietf-v6ops-balanced-ipv6-security implements a similar, and much = wider, vulnerability. I might well have an http server in my network, = but that doesn't imply that all hosts in my network are http servers. = Even if many of the hosts in my network are http servers, that doesn't = imply that my policy enables access to them from all possible clients. = My http server can open a hole for itself, and can be armored to defend = it against the many attacks that plague that protocol. My telephones = (Cisco 9971 and iPhone 5) are, or can be, http servers as well. Does = that mean that my call configuration and history should be available to = anyone who wonders about it? Is the presence of one server a reason to = expose the many hosts in my network that only operate as clients to HTTP = initiated from the outside? = http://www.economist.com/news/science-and-technology/21589383-stung-revela= tions-ubiquitous-surveillance-and-compromised-software =46rom my perspective, I think I would prefer that the firewall - if = implemented - blocked everything, and applications within the network = advised the firewall(s) of traffic that they are willing to receive. If = a potential session has no willing counterpart within my network, I = don't see the argument for letting the first packet in. --Apple-Mail=_E6159D46-DEB4-43E6-8356-4705C6A8B81F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSgqOGbjEdbHIsm0MRArOAAJ9n4uCI0yrKN49R9JYQr3l0I5zmCACg54g5 maxqyIDatGn8xup5JX+S5T8= =B89O -----END PGP SIGNATURE----- --Apple-Mail=_E6159D46-DEB4-43E6-8356-4705C6A8B81F-- From guillaume@leclanche.net Tue Nov 12 14:45: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 CC84911E810B for ; Tue, 12 Nov 2013 14:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lF4+nAQ9pOK for ; Tue, 12 Nov 2013 14:45:32 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0D20D21F9FA2 for ; Tue, 12 Nov 2013 14:45:31 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id jz11so3783219veb.36 for ; Tue, 12 Nov 2013 14:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leclanche.net; s=leclanche-net; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VXE4qqhkMeDZ80XbtUC1D6PkGYEiqXr+NBX+wGa6SRs=; b=TU8JnSbE0umngLyQv/jkpecodaNFhztq/3lzfvSf994S+KUrPJRrcIvw7dGViUMWwx TpkDSwqqmXY0qpCdMseJEmdDmtSkZxxrakgvuiZDAjoZRA/cuEdTntd5rmE7/YEhqzDf ITj5Dg8vuqzoaiWIcR8soq6ThzlC2tVpzehWI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VXE4qqhkMeDZ80XbtUC1D6PkGYEiqXr+NBX+wGa6SRs=; b=V1J0ndXbktSr4Jh1XFB1n+U7deB3FHBreqbAIx/Xb98s06Meww3vwSroyj/1W3vYLs 5h+9g2FrZl3MpYtYCWTYmu5qi6NZNKoucWd7gQsviMSHdjpc7hFR+5/XFxf7PnjUQtsX 2tDmeoB6CT+wdqMT2G7GPMILdS7WBvVg4Htko8TJJWDiVfI8BH3qpFWIy5hTu9P19zb8 qTT2VRqHyDN7NzQJ2IDXchdWa57XXfg0Jtwd94Yu5AwMDWfqJDoWlC0rcCCMq0H5Lsiz d5Sn3TmmIh/SV7kmY53tN4M41CEdjYKtWFT93O7wvYtNLZrI52kqYF6MneOMTwYL5ekS Pmcg== X-Gm-Message-State: ALoCoQlyIMMSMdKb6nlzLjIEEadzMfNHBZTyOeyCL8P3h0CChBABK2nK4QlqY6qybm1085ytywqi X-Received: by 10.220.253.66 with SMTP id mz2mr31634133vcb.10.1384296331237; Tue, 12 Nov 2013 14:45:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.24.200 with HTTP; Tue, 12 Nov 2013 14:44:51 -0800 (PST) X-Originating-IP: [2620:0:230:c000:6e88:14ff:fe69:301c] In-Reply-To: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> From: Guillaume Leclanche Date: Tue, 12 Nov 2013 17:44:51 -0500 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e013c70b816a9e504eb029b72 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 12 Nov 2013 22:45:32 -0000 --089e013c70b816a9e504eb029b72 Content-Type: text/plain; charset=ISO-8859-1 2013/11/12 Fred Baker (fred) > From my perspective, I think I would prefer that the firewall - if > implemented - blocked everything, and applications within the network > advised the firewall(s) of traffic that they are willing to receive. If a > potential session has no willing counterpart within my network, I don't see > the argument for letting the first packet in. I think this calls for the introduction of a new draft that is not existing yet (or, is it ?). I like the proposal, it's simply another preset of settings for a CPE firewall (which, in the end, should always be configurable by the end user). The document could describe how the CPE should behave with this security setting when interacting with the various That way the documents "portfolio" would cover three possible default settings, that could be implemented as presets on CPEs: RFC9092, draft-balanced-security, draft-(strict?)-security. They are complementary. Guillaume --089e013c70b816a9e504eb029b72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/11/12 Fred Baker (fred) <fre= d@cisco.com>
>From my perspective, I think I would prefer that the firewall - if implemen= ted - blocked everything, and applications within the network advised the f= irewall(s) of traffic that they are willing to receive. If a potential sess= ion has no willing counterpart within my network, I don't see the argum= ent for letting the first packet in.

I think this calls for the intro= duction of a new draft that is not existing yet (or, is it ?). I like the p= roposal, it's simply another preset of settings for a CPE firewall (whi= ch, in the end, should always be configurable by the end user). The documen= t could describe how the CPE should behave with this security setting when = interacting with the various

That way the documents "portfolio= " would cover three possible default settings, that could be implement= ed as presets on CPEs: RFC9092, draft-balanced-security, draft-(strict?)-se= curity. They are complementary.

Guillaume
--089e013c70b816a9e504eb029b72-- From guillaume@leclanche.net Tue Nov 12 14:47: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 A905D21E8098 for ; Tue, 12 Nov 2013 14:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWojNQPampwZ for ; Tue, 12 Nov 2013 14:47:57 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1D23321E8100 for ; Tue, 12 Nov 2013 14:47:56 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id jy13so2005699veb.23 for ; Tue, 12 Nov 2013 14:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leclanche.net; s=leclanche-net; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gA8kQS2Bcd3H4DqpxvrYj7xdZ0XUBX4Xq3QrKHh0fgg=; b=XAudy8pbxiHNFZ7PMx9rYxsPJeIcN+BalSPxVrtGNn46UNKmzDJqMUSriMRg0I4tK3 +9vs4HoccxlXhg9YaHcI7GtCaocxU0qd6bWY3VVNHpOUqUXH0I/Fbelx3wF0l0kKQW9F HIeI776FdzHdsbolwCRlf2GJSjx2ijlUb4xnQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gA8kQS2Bcd3H4DqpxvrYj7xdZ0XUBX4Xq3QrKHh0fgg=; b=TaH/aoJW7Nbu4eWlS1sUHzJ4c2idumqMcLA79N20ygCSsfNui+qmVzMeDLwhV4nwDX NrFQ7vVZUDcy/liS2vqg/KCkszquVu+56Se6OAXXrLuDKGxzrx/+pMZkS1iFl1/tP5EM 46+yXUNEzK8D0uDYJH92IDnx8L6tEi3UW/bxMYVrvijcikGNzUALkG127vO5hMtd3f6J S4y3HxMgwijAZadhnC9n9vmdXJwze+pnpeiq6iu9KJvBky6QD/HzKuklg4ereV6rfTK5 xvdre2E+yXhrZpf5nKHrsAzjC6JcQpv2p0q/VMcmOHHq6WwlnKr5Hegdavwf+Mvl8HEz IYpw== X-Gm-Message-State: ALoCoQlx57uZ3AYXYIRGoXLv5/Gi+902uOW2OYDTJECxRA3T+63AY4XKTPm2MqDb1eHfPkI8PfMt X-Received: by 10.52.227.6 with SMTP id rw6mr26546384vdc.19.1384296476309; Tue, 12 Nov 2013 14:47:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.24.200 with HTTP; Tue, 12 Nov 2013 14:47:16 -0800 (PST) X-Originating-IP: [2620:0:230:c000:6e88:14ff:fe69:301c] In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> From: Guillaume Leclanche Date: Tue, 12 Nov 2013 17:47:16 -0500 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e01161660bce79604eb02a333 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 12 Nov 2013 22:47:57 -0000 --089e01161660bce79604eb02a333 Content-Type: text/plain; charset=ISO-8859-1 > > That way the documents "portfolio" would cover three possible default > settings, that could be implemented as presets on CPEs: RFC9092, > draft-balanced-security, draft-(strict?)-security. They are complementary. obviously 6092 not 9092. --089e01161660bce79604eb02a333 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
= That way the documents "portfolio" would cover three possible def= ault settings, that could be implemented as presets on CPEs: RFC9092, draft= -balanced-security, draft-(strict?)-security. They are complementary.

obviously 6092 not 9092.
=
--089e01161660bce79604eb02a333-- From leo.liubing@huawei.com Tue Nov 12 17:55: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 5F35C11E816F for ; Tue, 12 Nov 2013 17:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsisYa+TGaKa for ; Tue, 12 Nov 2013 17:55:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C0CE411E816D for ; Tue, 12 Nov 2013 17:55:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU97515; Wed, 13 Nov 2013 01:55:25 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 01:55:10 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 01:55:25 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 09:55:20 +0800 From: "Liubing (Leo)" To: "Fred Baker (fred)" , Brian E Carpenter Thread-Topic: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHO2k/wLQNmfJ8fNUS0872S7bWPwZoWa54AgAAChYCACxV9gIAA6LLQ Date: Wed, 13 Nov 2013 01:55:19 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F3192@nkgeml506-mbx.china.huawei.com> References: <52793827.2040708@gmail.com> <21C0A698-E56B-4B0B-8454-1323027AD04E@cisco.com> In-Reply-To: <21C0A698-E56B-4B0B-8454-1323027AD04E@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 13 Nov 2013 01:55:38 -0000 Hi, Fred > >=20 > I'm told that it goes beyond that. There are at least three "directions" = in the > split: [Bing] Did you mean you are told from some real deployment, or told from th= e ULA draft? > - inside, where internal-only names are advertised, might use an > internal-only prefix, and even "outside" names might have different serve= rs > and different addresses. > - outside, where internal-only names are not advertised > - partner, which is "outside" plus some names made accessible to the > partner, and may imply some form of b2b routing as well. [Bing] Say if ULAs are used for b2b private routing, in the "partner" case,= does it means the b2b ULAs are stored in the outside DNS, so that the part= ners could get the ULAs through public DNS, and access to the ULAs through = private routing? Best Regards, Bing From swmike@swm.pp.se Tue Nov 12 18:34:20 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 CB46D11E8151 for ; Tue, 12 Nov 2013 18:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkhMLgAkYkXw for ; Tue, 12 Nov 2013 18:34:20 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 33B0D11E80DE for ; Tue, 12 Nov 2013 18:34:19 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6E2CC9C; Wed, 13 Nov 2013 03:34:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6A3349A; Wed, 13 Nov 2013 03:34:17 +0100 (CET) Date: Wed, 13 Nov 2013 03:34:17 +0100 (CET) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 02:34:20 -0000 On Tue, 12 Nov 2013, Fred Baker (fred) wrote: > From my perspective, I think I would prefer that the firewall - if > implemented - blocked everything, and applications within the network > advised the firewall(s) of traffic that they are willing to receive. If > a potential session has no willing counterpart within my network, I > don't see the argument for letting the first packet in. My biggest problem with this resoning, is that I am not aware of any firewall poking mechanism actively being in use for IPv6. This means that if we have a firewall with default-deny for incoming connections, then either hosts need an Internet based machine to coordinate a STUN type of behaviour to get the firewall to accept packets for sessions, or they need to implement a firewall poking mechanism that as far as I know, neither todays firewalls/CPEs nor hosts actually has. So today, implementing default-deny would mean a lot of the benefit of IPv6 wouldn't be seen immediately but would takes many years to realise. Right? Or am I mistaken and uPNP for IPv6 actually functional today? PCP I have never seen in home devices. -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Tue Nov 12 18:53: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 4AFCA21F9EED for ; Tue, 12 Nov 2013 18:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KLvWc-UF+WL for ; Tue, 12 Nov 2013 18:53:45 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 984B421F9FF3 for ; Tue, 12 Nov 2013 18:53:38 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id f4so975783wiw.9 for ; Tue, 12 Nov 2013 18:53:37 -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=ThPkkSGUzbjgZK//IRGUxlu1ikfmPI7mGAOuCnXeq+w=; b=GqOvj7ozMVUtmBQbjrjy08JhKCgC9O6FrNQ0YQgAUOC0TZ/QQ2t9BA8hrOiyaNypXj qI5fuAWyPZSlO6eRE6VB4mgyhtGjCvZ73lRSnscP4O9aXwlqnLhzRT57/9nbUlr0emDa tGVmUYIAMIjnK69iV3gGhNhKEg7LweRuqJrNg7pAcWPIFQ1R+r7Sbvl8kzN3f7++k9Ut H413IVxAjHrAGGfCAJGLTvVsW5gRNfT+pNLOmolsCilLbexFM9acGZBie++98goQBtrq W9PQvK1wlaBbXFdJJG6vDneaZ947mabqnZ5Z8eJPQ/ChP3bmd/nbZ02M4ps7qII7XA6S lK2A== MIME-Version: 1.0 X-Received: by 10.180.77.19 with SMTP id o19mr19068923wiw.34.1384311217763; Tue, 12 Nov 2013 18:53:37 -0800 (PST) Received: by 10.216.99.68 with HTTP; Tue, 12 Nov 2013 18:53:37 -0800 (PST) Received: by 10.216.99.68 with HTTP; Tue, 12 Nov 2013 18:53:37 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Date: Tue, 12 Nov 2013 18:53:37 -0800 Message-ID: From: "cb.list6" To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=f46d043c7f5464ba7704eb0612ab Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 02:53:46 -0000 --f46d043c7f5464ba7704eb0612ab Content-Type: text/plain; charset=ISO-8859-1 On Nov 12, 2013 6:34 PM, "Mikael Abrahamsson" wrote: > > On Tue, 12 Nov 2013, Fred Baker (fred) wrote: > >> From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to receive. If a potential session has no willing counterpart within my network, I don't see the argument for letting the first packet in. > > > My biggest problem with this resoning, is that I am not aware of any firewall poking mechanism actively being in use for IPv6. This means that if we have a firewall with default-deny for incoming connections, then either hosts need an Internet based machine to coordinate a STUN type of behaviour to get the firewall to accept packets for sessions, or they need to implement a firewall poking mechanism that as far as I know, neither todays firewalls/CPEs nor hosts actually has. > > So today, implementing default-deny would mean a lot of the benefit of IPv6 wouldn't be seen immediately but would takes many years to realise. Right? > That's my view too > Or am I mistaken and uPNP for IPv6 actually functional today? PCP I have never seen in home devices. > I would rather restore e2e than deploy pcp. Or firewall related ALGs. At the end of the day, this draft is an excellent start towards restoring e2e in a pragmatic and prudent way. It is deployed and successful and is thusly a reference for us all. I fully support it as written since it will help p2p technologies like webrtc and Microsoft Xbox One, as presented at ietf88. CB > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f46d043c7f5464ba7704eb0612ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 12, 2013 6:34 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Tue, 12 Nov 2013, Fred Baker (fred) wrote:
>
>> From my perspective, I think I would prefer that the firewall - if= implemented - blocked everything, and applications within the network advi= sed the firewall(s) of traffic that they are willing to receive. If a poten= tial session has no willing counterpart within my network, I don't see = the argument for letting the first packet in.
>
>
> My biggest problem with this resoning, is that I am not aware of any f= irewall poking mechanism actively being in use for IPv6. This means that if= we have a firewall with default-deny for incoming connections, then either= hosts need an Internet based machine to coordinate a STUN type of behaviou= r to get the firewall to accept packets for sessions, or they need to imple= ment a firewall poking mechanism that as far as I know, neither todays fire= walls/CPEs nor hosts actually has.
>
> So today, implementing default-deny would mean a lot of the benefit of= IPv6 wouldn't be seen immediately but would takes many years to realis= e. Right?
>

That's my view too

> Or am I mistaken and uPNP for IPv6 actually functional = today? PCP I have never seen in home devices.
>

I would rather restore e2e than deploy pcp. Or firewall=A0 r= elated ALGs.

At the end of the day, this draft is an excellent start towa= rds restoring e2e in a pragmatic and prudent way.=A0 It is deployed and suc= cessful and is thusly a reference for us all.=A0 I fully support it as writ= ten since it will help p2p technologies like webrtc and Microsoft Xbox One,= as presented at ietf88.

CB

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

--f46d043c7f5464ba7704eb0612ab-- From Ted.Lemon@nominum.com Tue Nov 12 19:05:20 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 CE5F521E8085 for ; Tue, 12 Nov 2013 19:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U+FRgqNF6gJ for ; Tue, 12 Nov 2013 19:05:14 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id F0E0021E8064 for ; Tue, 12 Nov 2013 19:05:13 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUoLsaWzDN8das6brAFSFtCrk/7Vo1R+i@postini.com; Tue, 12 Nov 2013 19:05:14 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 87FC81B82D0 for ; Tue, 12 Nov 2013 19:05:13 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6331D19005D; Tue, 12 Nov 2013 19:05:13 -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.03.0158.001; Tue, 12 Nov 2013 19:05:07 -0800 From: Ted Lemon To: Mikael Abrahamsson Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO3kcgifX5dH755Eqorh2n2HqLtpoih2QAgAAloACAAE48gIAACJoA Date: Wed, 13 Nov 2013 03:05:07 +0000 Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> In-Reply-To: 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: <7DAEB6F39CBBB043BEE8C67765C5E119@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 03:05:20 -0000 On Nov 12, 2013, at 9:34 PM, Mikael Abrahamsson wrote: > Or am I mistaken and uPNP for IPv6 actually functional today? PCP I have = never seen in home devices. PCP is present in Apple's Time Capsule gateways. It would be nice to see = an implementation in OpenWRT, but you're right that none exists as of now. = There is a uPNP/NAT-PMP implementation for OpenWRT, but I don't know if i= t supports IPv6. From cb.list6@gmail.com Tue Nov 12 20: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 F20D911E814B for ; Tue, 12 Nov 2013 20:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaxX+OEF0FVl for ; Tue, 12 Nov 2013 20:54:47 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 88E7C11E80F6 for ; Tue, 12 Nov 2013 20:54:39 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so2477786wgg.1 for ; Tue, 12 Nov 2013 20:54:38 -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:content-transfer-encoding; bh=j2igUDGjXng8Fr8gHGB16jDjD+Tf//QWTTSkhvSFrrA=; b=UkaFf4u/DNMoYo6jUDRM24XJm0zhK4erPZr+mml3taDbYTh554pEam/3LIsAAW42Of opYyTZSmBcJEA8ZDP5RVkBtbjLEa95K2zwm6z5XMBtLUdFt5ru2MBlE8Z2Vc+rgDUi9d Y4ZOr1S8Uka06jKM7d3JcS6RJYabCe6f54zb5bmXR/k7HVa69pybYHr3g+31cMMuupnq aokE71h7+xfddKGxYDithrln6ZpPCo+4YGdG8CBg6YOYJdeswdEzFou0YWZ6CVcm9bsu dOkfXUE5TBbk1H9kROk/zi2PH2ECD6tXRKlFkxCQ5NakmZjJ0hA71WJDzDNAvotJzYRo 2HeA== MIME-Version: 1.0 X-Received: by 10.180.79.163 with SMTP id k3mr16735165wix.34.1384318478619; Tue, 12 Nov 2013 20:54:38 -0800 (PST) Received: by 10.216.99.68 with HTTP; Tue, 12 Nov 2013 20:54:38 -0800 (PST) In-Reply-To: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Date: Tue, 12 Nov 2013 20:54:38 -0800 Message-ID: From: "cb.list6" To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 04:54:52 -0000 Hi Fred, On Tue, Nov 12, 2013 at 1:54 PM, Fred Baker (fred) wrote: > This is a comment as a participant, not as a chair. > > I find myself scratching my head with this, and found myself scratching m= y head with what became RFC 6092. > rightfully so. > My first premise in both cases is that a firewall primarily mitigates att= acks on the bandwidth of a network and an aggregated network. An attack tha= t actually hits a host or application will have to be defended against by t= he host/application or a security service provided by some other device in = the network; firewall rules provide a form of defense in depth, but no more= . I compare a firewall to the human skin. The skin is, itself, hardly neces= sary for the "health security" of the body, as the other systems of the bod= y could be active and mitigate attacks on the body. However, it makes activ= e use of those capabilities less of a requirement by preventing certain cla= sses of attacks. > I believe the core of the issue is stateful firewalling, at least the core of the issue for me is stateful firewalls -- so when i say firewall please assume that is what i mean. Networks exist without firewalls, humans do not exist without skin. > My second premise is that any communication attempt directed to a network= , or to a application in a network, that doesn't have a application in the = network that willingly communicates with it is an attack. > I disagree. If you want to call me with WebRTC or Xbox One and i am not willing to talk right now, that is not an attack. I prefer the term attack to be scoped to only that with malicious intent. > Now, we have tools - PCP, UPnP - that enable an application to inform the= network of its approving presence. If I want someone to be able to connect= to a given device using IPsec, when the device comes up, it can inform the= network of a n-tuple {application address, IPsec protocol ID, }, and = "poke a hole" in a firewall regardless of the description of the firewall. = The administration can also log such requests and apply its own policy on w= hether it honors them. If I want them to initiate SMTP or https connections= to a given system, it can similarly announce itself as {address, TCP, port= , any, any}, and allow incoming SMTP connections to it. > PCP and UPnP may be tools to inform the network of something, but if a tree falls in the woods, does it make noise? My point is that i have no plans to support either and if someone requires PCP or UPnP i will suggest they use IPv6. IPv6 does not need these hacks that IPv4 did. I believe these tools are in fact a huge vector for attack, and i believe that is supported by common knowledge that attacks have shifted from networks to applications. And, UPnP and PCP are applications. Thus, UPnP and PCP will become the achilles heel of networks, especially if we come to rely upon them Here is one example of UPnP issues https://community.rapid7.com/community/infosec/blog/2013/01/29/security-fla= ws-in-universal-plug-and-play-unplug-dont-play And, here is an example of why your "router/firewall" should not be given keys to the kingdom, http://seclists.org/fulldisclosure/2013/Nov/76 Or this nakedsecurity.sophos.com/2012/10/01/hacked-routers-brazidnsl-vb2012= / I think we know pretty well that home routers are some of the worst maintained code around. Witness the buffer bloat debacle and the challenge home router CPE is providing for many residential IPv6 deployment. And, security issue after security issue, like this d-link backdoor http://www.kb.cert.org/vuls/id/248083 I think the conversation would be different if the home gateways / routers / firewalls had any credibility as secure devices, but they don't. Moderm mobile and PC operating systems are much much better. > So regardless of the firewall type, we have tools to enable an applicatio= n in the network to make itself available to peers "outside". And of course= , as suggested in zone-based defenses and in RFC 6092, when a application i= nitiates a connection outside, by implication the firewall can open a "hole= " for the return traffic. > An application, including malware may configure your firewall or your provider's CGN. See the above security issues of CPE. > So the only protocols, or peers using protocols, under discussion are tho= se that have no application that is willing to have sessions initiated to i= t from the outside of the network. > Which would exclude anyone using from p2p gaming, WebRTC, ... > RFC 6092 permits IPsec packets as a blanket rule. That facilitates two at= tacks. First, there is a form of network scanning enabled; a application ou= tside the network can initiate IKE connections to addresses it thinks might= exist in the network (observing, for example, email envelope information t= o find such addresses); if it gets a reply, something is using the address.= Second, it can busy out the verification/decrypt unit in a application sim= ply by sending it IPsec traffic that does not have a proper key. That can D= OS the application's CPU resources or its communication resources. Now, if = a application wants to communicate in that way and recognizes the vulnerabi= lity, it can open that hole. But if a application doesn't want to communica= te that way (for example, it implements IPsec but the applications it uses = have no keys to validate data with), what is the argument for leaving the v= ulnerability open? > Your premise is that a stateful firewall disallows inbound connections to protect bandwidth on the LAN Yet, RFC 6092 says we must allows anyone to send us IPsec. Which simply means attackers focus their tools on generating high volumes of IPsec packets and can attack the LAN with a flood of IPsec. So, RFC6092 did not solve the bandwidth attack, yet it encumbered the applications to have to work-around stateful packet filtering with ALG / PCP / UPnP ... This is a lose / lose. > draft-ietf-v6ops-balanced-ipv6-security implements a similar, and much wi= der, vulnerability. I might well have an http server in my network, but tha= t doesn't imply that all hosts in my network are http servers. Even if many= of the hosts in my network are http servers, that doesn't imply that my po= licy enables access to them from all possible clients. My http server can o= pen a hole for itself, and can be armored to defend it against the many att= acks that plague that protocol. My telephones (Cisco 9971 and iPhone 5) are= , or can be, http servers as well. Does that mean that my call configuratio= n and history should be available to anyone who wonders about it? Is the pr= esence of one server a reason to expose the many hosts in my network that o= nly operate as clients to HTTP initiated from the outside? > 1. Your HTP server can open a firewall hole for itself for inbound connections? Please explain this implementation. 2. Your HTTP server iPhone is serving your call records to any client that can make a connection? And you think a firewall is the solution to that ? :) 3. If you believe the internet should only be HTTP clients, this stateful filtering model is for you. On the other hand, the IETF has many efforts to take the internet to a more secure, more distributed p2p model, less "cloud" dependent. > http://www.economist.com/news/science-and-technology/21589383-stung-revel= ations-ubiquitous-surveillance-and-compromised-software > > From my perspective, I think I would prefer that the firewall - if implem= ented - blocked everything, and applications within the network advised the= firewall(s) of traffic that they are willing to receive. If a potential se= ssion has no willing counterpart within my network, I don't see the argumen= t for letting the first packet in. > I would rather have secure hosts, smart endpoints, and simple networks. My view of the world 1. Prior to 1999 network security was not taken very seriously 2. In 2000-2003, NIMDA, Code Red, SQL Slammer were a big deal and we all installed firewalls. These attacks were real bad. 3. 2005 -> future: hosts come with firewalls on by default, the network stack is not a major attack surface, security is concern for all parties. On the other hand, malware has focused on application and user. 4. There is a security industry that still wants to sell you middle boxes, despite the fact they add little to no value. In fact, these middle boxes are themselves the weakest / fragile / stateful link the in chain. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tore@fud.no Tue Nov 12 23:21: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 D7CAA21E8082 for ; Tue, 12 Nov 2013 23:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6C-NqFSfOLX for ; Tue, 12 Nov 2013 23:21:22 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 49D9521E805F for ; Tue, 12 Nov 2013 23:21:22 -0800 (PST) Received: from echo.ms.redpill-linpro.com ([2a02:c0:100:0:9e8e:99ff:fed1:5243]:38358 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VgUlL-0007lY-7Q; Wed, 13 Nov 2013 08:21:19 +0100 Message-ID: <5283286F.8000504@fud.no> Date: Wed, 13 Nov 2013 08:21:19 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alexandru Petrescu , Hui Deng , "v6ops@ietf.org" References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> <527E1385.1020506@gmail.com> <527FACE5.6040002@gmail.com> <5280F33F.4040605@gmail.com> <52820BA2.8020001@gmail.com> In-Reply-To: <52820BA2.8020001@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming 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, 13 Nov 2013 07:21:23 -0000 * Alexandru Petrescu > It all depends what we call 'roaming'. > > What I have not tried is the following two scenarios: > - roam IPv6 from one country to the next, keeping same IPv6 operator, > without switching off the handset. Note whether or not the ongoing > applications break at handover. Maybe by car or by train. > - roam IPv6 from one IPv6 operator to another IPv6 operator, without > switching off the handset. Maybe not being mobile at all. > > They can easily be tried. > > Intuitively, I would say that applications get interrupted, because > there would be change in the IPv6 address allocated to the smartphone. I have experience with your second case above: When I roam from one operator to another within Norway, my IPv6 address does not change, and any existing connections do not get interrupted. Layer 3 appears to be completely unaware that roaming occurs. Next time I drive across the border to Sweden I'll test your first case too. It would surprise me if the behaviour was any different though. Tore From tore@fud.no Wed Nov 13 00:07:03 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 5DBBA21F9E43 for ; Wed, 13 Nov 2013 00:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skU-3Dc6AA-v for ; Wed, 13 Nov 2013 00:07:01 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 1B03E11E8114 for ; Wed, 13 Nov 2013 00:06:48 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=33791 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VgVTG-0000J9-8T; Wed, 13 Nov 2013 09:06:42 +0100 Message-ID: <52833312.5010901@fud.no> Date: Wed, 13 Nov 2013 09:06:42 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , "v6ops@ietf.org WG" References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> In-Reply-To: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 08:07:03 -0000 * Fred Baker (fred) > My first premise in both cases is that a firewall primarily mitigates > attacks on the bandwidth of a network and an aggregated network. For this to actually be the case, the firewall's WAN link must have a higher bandwidth than the LAN it protects. I'd say this is rather uncommon in residential broadband these days, so the even if the CPE's firewall drops absolutely *everything*, a bandwidth attack would still succeed. Tore From swmike@swm.pp.se Wed Nov 13 00: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 8622821E8097 for ; Wed, 13 Nov 2013 00:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z3hMw1a2+XW for ; Wed, 13 Nov 2013 00:30:49 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA221E8082 for ; Wed, 13 Nov 2013 00:30:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 514809C; Wed, 13 Nov 2013 09:30:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B8CC49A; Wed, 13 Nov 2013 09:30:42 +0100 (CET) Date: Wed, 13 Nov 2013 09:30:42 +0100 (CET) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 08:30:54 -0000 On Tue, 12 Nov 2013, Fred Baker (fred) wrote: > My second premise is that any communication attempt directed to a > network, or to a application in a network, that doesn't have a > application in the network that willingly communicates with it is an > attack. If it doesn't want to communicate, then it gives connection refused. For me, a firewall is a way to have a policy that disallows connections to "dumb" services "inside" that can't protect itself. Basically, the firewall means that instead of making the home part of the Internet, it tries to limit its participation. The classic unix model is that services below 1024 are privileged ports, and there lives most of the "sensitive" services. Userspace processes live in 1024 and above. I believe I voiced opinion that I was fine with disallowing unsolicited connections from the outside to inside ports below 1024. This would mean most home services would not be accessible from the outside, but at least most of the peer-to-peer communication applications would work without restrictions since these live in the high ports. The draft being discussed, balanced-security tries to identify weak services. I am fine with this approach as well, since it means the user doesn't have to do administration of for instance ssh services, but still blocks communication for the more common weak services. Having all incoming connections blocked would be a mistake, in my opinion. I therefore support the WGLC of the above draft. -- Mikael Abrahamsson email: swmike@swm.pp.se From tarko@lanparty.ee Wed Nov 13 00:43: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 4F80421E8097 for ; Wed, 13 Nov 2013 00:43:09 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhJ1UMdRaJHg for ; Wed, 13 Nov 2013 00:43:03 -0800 (PST) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) by ietfa.amsl.com (Postfix) with ESMTP id 513D621E8082 for ; Wed, 13 Nov 2013 00:43:03 -0800 (PST) Received: from tuli.elion.ee ([194.126.117.170] helo=[192.168.28.102]) by valgus.lanparty.ee with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VgW2O-00089w-Ak for v6ops@ietf.org; Wed, 13 Nov 2013 10:43:00 +0200 Message-ID: <52833B8F.10708@lanparty.ee> Date: Wed, 13 Nov 2013 10:42:55 +0200 From: Tarko Tikan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> In-Reply-To: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 194.126.117.170 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 08:43:09 -0000 hey, > From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to receive. If a potential session has no willing counterpart within my network, I don't see the argument for letting the first packet in. That would be preferred but as already discussed, there are no suitable protocols (and implementations) for deployment today. And recommending to block all inbound sessions by default is not good idea with IPv6 end2end mentality. To improve on the idea - I don't see why application should signal to CPE, firewalling in CPE is useless against ddos attacks. I'd prefer application to signal to edge routers and have firewall there, this way to-be-denied packets never make it to CPE and will not congest AN uplinks. -- tarko From marc.lampo.ietf@gmail.com Wed Nov 13 01:30: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 5ABA821E8099 for ; Wed, 13 Nov 2013 01:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXnmCJbN2mpb for ; Wed, 13 Nov 2013 01:30:22 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id BB23A21E808D for ; Wed, 13 Nov 2013 01:30:22 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id o19so89234vbm.36 for ; Wed, 13 Nov 2013 01:30:22 -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=GJI//jZ/t6qCCSvdLgiY+8JP6MrGCHDkkTD3KYqFKLY=; b=YpOUCib0JDoOFhhA7cEfpUIQHS9yj6SNcYw3dByUC5fYtXJDLwdi/YIeHh/RFtVq/x K6v/bIq8Eh3RkNizq3c3VvrVGGjKFHxiY/wiflh7yCh+4YbKE5Yje0vketVFjce2/WQ/ UZLgKQXZsCTM6k5JeBdh9ASrn0ofOeB22y0tkarnToE1a6QbzF+gb5ldvXsKIzGwDECt sVqBypJkKgY8zpumlt6bqExGQe4FpzmhA1htLu/UCDZWA9QkccD2qD57nKF2sUG/UI2d SqOf9xoqKJYIac8JPbxpaCXG2CYxbfAKZDwUKjfxkyZQcC2rO6XFvrhC36Y8HR034BLc tRuQ== MIME-Version: 1.0 X-Received: by 10.58.118.84 with SMTP id kk20mr7085778veb.26.1384335022225; Wed, 13 Nov 2013 01:30:22 -0800 (PST) Received: by 10.58.227.66 with HTTP; Wed, 13 Nov 2013 01:30:22 -0800 (PST) In-Reply-To: <52833B8F.10708@lanparty.ee> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> Date: Wed, 13 Nov 2013 10:30:22 +0100 Message-ID: From: Marc Lampo To: Tarko Tikan Content-Type: multipart/alternative; boundary=089e0122a0863ffea604eb0b9da4 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 09:30:23 -0000 --089e0122a0863ffea604eb0b9da4 Content-Type: text/plain; charset=ISO-8859-1 Hello, but is "IPv6 end2end mentality" a good idea, from the security point of view ? I don't think so. Kind regards, On Wed, Nov 13, 2013 at 9:42 AM, Tarko Tikan wrote: > hey, > > > From my perspective, I think I would prefer that the firewall - if >> implemented - blocked everything, and applications within the network >> advised the firewall(s) of traffic that they are willing to receive. If a >> potential session has no willing counterpart within my network, I don't see >> the argument for letting the first packet in. >> > > That would be preferred but as already discussed, there are no suitable > protocols (and implementations) for deployment today. And recommending to > block all inbound sessions by default is not good idea with IPv6 end2end > mentality. > > To improve on the idea - I don't see why application should signal to CPE, > firewalling in CPE is useless against ddos attacks. I'd prefer application > to signal to edge routers and have firewall there, this way to-be-denied > packets never make it to CPE and will not congest AN uplinks. > > -- > tarko > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e0122a0863ffea604eb0b9da4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

but is "IPv6 end2end mentality&quo= t; a good idea, from the security point of view ?=A0 I don't think so.<= br>
Kind regards,


On Wed, Nov 13, 2013 at 9:42 AM, Tarko Tikan <tarko@lanparty.ee> wrote:
hey,


=A0From my perspective, I think I would prefer that the firewall - if imple= mented - blocked everything, and applications within the network advised th= e firewall(s) of traffic that they are willing to receive. If a potential s= ession has no willing counterpart within my network, I don't see the ar= gument for letting the first packet in.

That would be preferred but as already discussed, there are no suitable pro= tocols (and implementations) for deployment today. And recommending to bloc= k all inbound sessions by default is not good idea with IPv6 end2end mental= ity.

To improve on the idea - I don't see why application should signal to C= PE, firewalling in CPE is useless against ddos attacks. I'd prefer appl= ication to signal to edge routers and have firewall there, this way to-be-d= enied packets never make it to CPE and will not congest AN uplinks.

--
tarko

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

--089e0122a0863ffea604eb0b9da4-- From swmike@swm.pp.se Wed Nov 13 01:33: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 83E6821F9D0E for ; Wed, 13 Nov 2013 01:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvrpD9aeQpW5 for ; Wed, 13 Nov 2013 01:33:17 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E18C321F9CF7 for ; Wed, 13 Nov 2013 01:33:16 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D6A39A1; Wed, 13 Nov 2013 10:33:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D03A09A; Wed, 13 Nov 2013 10:33:15 +0100 (CET) Date: Wed, 13 Nov 2013 10:33:15 +0100 (CET) From: Mikael Abrahamsson To: Marc Lampo In-Reply-To: Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 09:33:17 -0000 On Wed, 13 Nov 2013, Marc Lampo wrote: > but is "IPv6 end2end mentality" a good idea, from the security point of > view ? I don't think so. Making things not work is very secure, but not very useful. What is your proposal for tradeoff between these two factors? -- Mikael Abrahamsson email: swmike@swm.pp.se From markzzzsmith@yahoo.com.au Wed Nov 13 02:26: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 E1F8C21E80AD for ; Wed, 13 Nov 2013 02:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3UH36EF7Mj9 for ; Wed, 13 Nov 2013 02:26:03 -0800 (PST) Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15921E80B6 for ; Wed, 13 Nov 2013 02:25:50 -0800 (PST) Received: from [98.139.212.153] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2013 10:25:50 -0000 Received: from [98.139.212.244] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2013 10:25:50 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 13 Nov 2013 10:25:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 286154.64310.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 75421 invoked by uid 60001); 13 Nov 2013 10:25:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1384338350; bh=l2FL6Dp9AygMN9xtmQayJaO1TD8l0gjz2bF8P61fJJI=; 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=ADV+ZEEZGZgWLk2TJ92wBdgSP4B9DDTbunWA7xe7PYZpMqlrEZXbM5EDwXrtvD2Koo5Sqa6/7l5x6FJrkqHi6Cq4Xqi4LXTV2t4JiNQH9rouHDRC42XyF8HFlsAa/kmDbNH9YimN6etKKLfmQh8ekGOkbbA53k9wnuemFje7QWI= 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=amxZURK4EHh18BFkJDWUu6krLIH+lTy66VMqK14/y6mlxygT3EW/OBv1T53/Ll/cC8xiRmSc593G+zQkqlgRu/E/fnZLX9+lyyUvVUXqv2fmM5No08WZXafr6EiR9L236IyQr+lGAVlDbxX1lWVSETPilaNljyqU6wq8ZgMNA7w=; X-YMail-OSG: 3CqGX_QVM1m3grxcNh4eqwlYTKIHHsOVEkxf0PYvf7GdMW7 f0PIl52ZwWE8jDnvmjDUJExRU2fT9Qe62BVsFfhGWY8cm5i.tPPgwLW.stX2 KtGzvPliA.vSJrWuoobbxlxNZfmU60vkyDdMFWdLRGZm5tW68Yl2MDaAj9KA 5SEDnYAXNzcW7tWy8GarJuLgiezdfYqqKxR7BRqjeDYwCXKteSpGF4p_JY4e bSirH53p0EadGr22jxiSSHtQBPlBsQ8cElyAdm1vQesuFm8D58nJrN3NYJZa Fwqv2loqm4TdNDeUSx8rFC9XPHgmXiyyvOm8S0NBhKvdJ2vZQlolA7qAPKHC i2eYXC7OO11LuoZTaSvBU7GQqqJonPpNrqHbxFtJj6AtaSGqTWEnFnPgXiek sLv08laRmZse60hOjwLaELKVa94KhfmlPYkQVO80aWrnLiRK_c0DNxVL3nZB O.T69papjxr3OpmahtRiDa29TlSFt4OO6YeA7CnGGbTP1.zQaAAX4mE.taW5 3o4_Bef_eUlc5.jAvY7k6HyWz8SNR5Bnwpp1N7RYtArrxNWfcE4ztOZuhl66 T6_POojh6k0KmN8fMnFgakdcVsqh48zw1RssSTLqaunc- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Wed, 13 Nov 2013 02:25:49 PST X-Rocket-MIMEInfo: 002.001, Cgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBNYXJjIExhbXBvIDxtYXJjLmxhbXBvLmlldGZAZ21haWwuY29tPgo.VG86IFRhcmtvIFRpa2FuIDx0YXJrb0BsYW5wYXJ0eS5lZT4gCj5DYzogdjZvcHNAaWV0Zi5vcmcgCj5TZW50OiBXZWRuZXNkYXksIDEzIE5vdmVtYmVyIDIwMTMgODozMCBQTQo.U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1iYWxhbmNlZC1pcHY2LXNlY3VyaXR5IFdHTEMKPiAKPgo.Cj5IZWxsbywKPgo.YnV0IGlzICJJUHY2IGVuZDJlbmQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.163.597 References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> Message-ID: <1384338349.75388.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Wed, 13 Nov 2013 02:25:49 -0800 (PST) From: Mark ZZZ Smith To: Marc Lampo , Tarko Tikan 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-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 10:26:08 -0000 =0A=0A>________________________________=0A> From: Marc Lampo =0A>To: Tarko Tikan =0A>Cc: v6ops@ietf.org= =0A>Sent: Wednesday, 13 November 2013 8:30 PM=0A>Subject: Re: [v6ops] draf= t-ietf-v6ops-balanced-ipv6-security WGLC=0A> =0A>=0A>=0A>Hello,=0A>=0A>but = is "IPv6 end2end mentality" a good idea, from the security point of view ?= =A0 I don't think so.=0A>=0A=0AI don't think that mentality will survive cr= ypto and multipathing (e.g. MPTCP).=0A=0AThe mobility of our hosts (such as= smartphones/tablets/laptops)=A0and therefore the operating systems they ru= n has caused them to become far more self reliant (starting probably around= October 2004, the release of Windows XP SP2), because they can't trust the= network to do that job for them. This is a consequence of them being able = to move between many different networks, with various levels of "protection= ". They (or rather, their vendors) assume the worst case of a public IP add= ress on an unfettered Internet connection, and prepare the hosts for that b= y default.=0A=0AMultipathing is going to make that worse, because one path = may be "heavily" protected (e.g., corporate network), while the other path = may have no protection at all (e.g., carrier network, or different Wifi net= work). MPTCP or similar will try to use both at once, and therefore the hos= t will have to encrypt the traffic to be sure of its integrity and protecti= on.=0A=0AI think this draft is just to simplistic. It seems to be making th= e assumption that hosts aren't protecting themselves at all, and that TCP o= r UDP ports are absolute indicators of the security or not of a protocol.= =A0=0A=0AFor example, SSH is blocked, yet SNMP isn't. I'd argue the other w= ay around is correct, except that SNMPv3 is secure, yet it uses the same UD= P ports as SNMPv1 and v2, which aren't adequately secure. Asserting that SS= H should be blocked is really asserting that all people who use single-fact= or SSH authentication have picked bad passwords, and that nobody is using t= wo factor SSH authentication. I think that is a way too coarse and sweeping= generalisation.=0A=0AFor the same reasons, I don't think you can use great= er than or less than 1024 as an absolute security indicator. There are a nu= mber protocols which use ports below 1024 that have encryption or authentic= ation as options or standard features.=0A=0AIf CPE should be doing anything= , I think it should only be providing assistance that the hosts might find = useful (the scenario Fred described), rather than being viewed as the prima= ry and only security device protecting the hosts. If the CPE gets in the wa= y of what the hosts want to do, then the hosts will just use the IPv4 NAT (= "firewall") traversal techniques to traverse IPv6 firewalls that get in the= ir way, or will just wrap everything inside IPsec, completely nullifying an= y protection the CPE might try to provide, and the associated time and effo= rt spent developing that "protection". I think CPE providing tools that wou= ld be of assistance might be useful to hosts, but trying to make absolute j= udgements on-behalf of the hosts without knowing what the hosts actually wa= nt and need would be harmful.=0A=0ARegards,=0AMark.=0A=0A=0A=0A>Kind regard= s,=0A>=0A>=0A>=0A>=0A>On Wed, Nov 13, 2013 at 9:42 AM, Tarko Tikan wrote:=0A>=0A>hey,=0A>>=0A>>=0A>>=0A>>=A0From my perspective, I= think I would prefer that the firewall - if implemented - blocked everythi= ng, and applications within the network advised the firewall(s) of traffic = that they are willing to receive. If a potential session has no willing cou= nterpart within my network, I don't see the argument for letting the first = packet in.=0A>>>=0A>>=0AThat would be preferred but as already discussed, t= here are no suitable protocols (and implementations) for deployment today. = And recommending to block all inbound sessions by default is not good idea = with IPv6 end2end mentality.=0A>>=0A>>To improve on the idea - I don't see = why application should signal to CPE, firewalling in CPE is useless against= ddos attacks. I'd prefer application to signal to edge routers and have fi= rewall there, this way to-be-denied packets never make it to CPE and will n= ot congest AN uplinks.=0A>>=0A>>-- =0A>>tarko=0A>>=0A>>____________________= ___________________________=0A>>v6ops mailing list=0A>>v6ops@ietf.org=0A>>h= ttps://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>=0A>=0A> From fred@cisco.com Wed Nov 13 03:32: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 773FD21E80DE for ; Wed, 13 Nov 2013 03:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.438 X-Spam-Level: X-Spam-Status: No, score=-110.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUUNSCKZA0mg for ; Wed, 13 Nov 2013 03:32:42 -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 3361721E80DF for ; Wed, 13 Nov 2013 03:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2270; q=dns/txt; s=iport; t=1384342359; x=1385551959; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5goCQ2DoiEWT7/d/o1xUiNoHAku47dBITLwKZNba+gk=; b=fQQ1Lt8IRLBb+TH87FlqQrzbVqhJMzfv3h0sdJN7D7LlP7wS+/4BNVxE lQ9Tmi381Ah5DW9YAmrpW0xtpt1Wq7PddtW8U7qZIf1t8OmyBKNFfpZ6T o/QHEsQZRbITJzHUrCyPNjG/sva6nbKozBaPtD+tlEaxLVTQZFg9i+jk8 Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAElig1KtJXHB/2dsb2JhbABRCYMHgQu/KIEhFnSCJQEBAQMBcQgFCwIBCEYyJQIEDgUOh20Gv0uOHYFCB4MggREDkDCBMIYwkguDKIIq X-IronPort-AV: E=Sophos;i="4.93,691,1378857600"; d="asc'?scan'208";a="284005927" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 13 Nov 2013 11:32:38 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rADBWbx4000694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 11:32:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 05:32:37 -0600 From: "Fred Baker (fred)" To: "Liubing (Leo)" Thread-Topic: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHO4GQNv0mlicYJEU2FRYbsUKYjkg== Date: Wed, 13 Nov 2013 11:32:36 +0000 Message-ID: <0CF7584E-B62C-4BB1-B1E2-B8E89BE1B83D@cisco.com> References: <52793827.2040708@gmail.com> <21C0A698-E56B-4B0B-8454-1323027AD04E@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7F3192@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F3192@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_7696A24A-C1D1-493C-B1CA-0A5808F4B4FA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 13 Nov 2013 11:32:48 -0000 --Apple-Mail=_7696A24A-C1D1-493C-B1CA-0A5808F4B4FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 12, 2013, at 5:55 PM, Liubing (Leo) = wrote: > Hi, Fred >=20 >> >>=20 >> I'm told that it goes beyond that. There are at least three = "directions" in the >> split: > [Bing] Did you mean you are told from some real deployment, or told = from the ULA draft? I am on the board of a company that produces a product that is used in = these configurations. One of the engineers told me it is a requirement = his customers present him with. Today, that is generally IPv4, not IPv6, = so I can't comment on ULAs, only extrapolate. I was commenting on the = DNS configuration. >> - inside, where internal-only names are advertised, might use an >> internal-only prefix, and even "outside" names might have different = servers >> and different addresses. >> - outside, where internal-only names are not advertised >> - partner, which is "outside" plus some names made accessible to = the >> partner, and may imply some form of b2b routing as well. > [Bing] Say if ULAs are used for b2b private routing, in the "partner" = case, does it means the b2b ULAs are stored in the outside DNS, so that = the partners could get the ULAs through public DNS, and access to the = ULAs through private routing? In the particular configuration, as I understand what the engineer told = me, "inside", "outside", and in the "partner" case, the identity of the = partner, are attributes in the underlying database. The software looks = at the request, determines what data should be included in the response, = and includes it. --Apple-Mail=_7696A24A-C1D1-493C-B1CA-0A5808F4B4FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSg2NRbjEdbHIsm0MRAuhqAKDVnPxph4We63HKaotNRE22LKtNmACdHF2Y a8g/O39/N12LIEQY2T/gACQ= =WsIo -----END PGP SIGNATURE----- --Apple-Mail=_7696A24A-C1D1-493C-B1CA-0A5808F4B4FA-- From Ted.Lemon@nominum.com Wed Nov 13 07:30: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 72B5E21F9C6C for ; Wed, 13 Nov 2013 07:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1KPouObasAk for ; Wed, 13 Nov 2013 07:29:53 -0800 (PST) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id BB11021F9BC1 for ; Wed, 13 Nov 2013 07:29:53 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUoOa8SKPYSzDf5sY9mRS/msSvmX/dzat@postini.com; Wed, 13 Nov 2013 07:29:53 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 5F9D81B82DC for ; Wed, 13 Nov 2013 07:29:53 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4052319005D; Wed, 13 Nov 2013 07:29:53 -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.03.0158.001; Wed, 13 Nov 2013 07:29:53 -0800 From: Ted Lemon To: Tarko Tikan Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO3kcgifX5dH755Eqorh2n2HqLtpoih2QAgAAloACAALU7gIAAcbEA Date: Wed, 13 Nov 2013 15:29:52 +0000 Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> In-Reply-To: <52833B8F.10708@lanparty.ee> 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: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 15:30:00 -0000 On Nov 13, 2013, at 3:42 AM, Tarko Tikan wrote: > I'd prefer application to signal to edge routers and have firewall there,= this way to-be-denied packets never make it to CPE and will not congest AN= uplinks. You could definitely do this with PCP, but do you really want to encourage = the installation of firewalls in this part of the network? I suspect the = law of unintended consequences is worth paying attention to here. From tarko@lanparty.ee Wed Nov 13 07:58: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 D399221E8063 for ; Wed, 13 Nov 2013 07:58:56 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UcIL0erlv73 for ; Wed, 13 Nov 2013 07:58:51 -0800 (PST) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) by ietfa.amsl.com (Postfix) with ESMTP id E41D621E80AE for ; Wed, 13 Nov 2013 07:58:50 -0800 (PST) Received: from tuli.elion.ee ([194.126.117.170] helo=[192.168.28.102]) by valgus.lanparty.ee with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Vgcq5-0008PW-1v for v6ops@ietf.org; Wed, 13 Nov 2013 17:58:45 +0200 Message-ID: <5283A1AF.1070806@lanparty.ee> Date: Wed, 13 Nov 2013 17:58:39 +0200 From: Tarko Tikan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 194.126.117.170 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 15:58:57 -0000 hey, > You could definitely do this with PCP, but do you really want to encourage the installation of firewalls in this part of the network? I suspect the law of unintended consequences is worth paying attention to here. There are pros and cons like always. Considering people put subscriber awareness, CGN (stateful) etc. into PEs, adding firewalls is not that big of a deal. Scale is an issue but current hardware can already do tens of gigabits worth of stateful firewalling. Then again it adds cost and raises complexity (lower MTBF) and CPEs are there and paid for. -- tarko From fred@cisco.com Wed Nov 13 08:46: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 8663D21E8082 for ; Wed, 13 Nov 2013 08:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLnYhJ7M7z37 for ; Wed, 13 Nov 2013 08:46:39 -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 9E59911E8119 for ; Wed, 13 Nov 2013 08:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2528; q=dns/txt; s=iport; t=1384361199; x=1385570799; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TPidxzKdHymFExu5EnWrmkcVVtko2sg3US3G4sFHTgU=; b=Zaew2L2gKfsGQe7StcT+YkypikhSuFGl80kPvL1gxe6su4BBqUs6AMM6 EAa2lHvvngdVBByOh2zcEo9JrG0BdAEgmpS6MvfH6HfunzCwOMkymLcCB l9p07xA81YJD0vv6/qdRvrEyl3qkf5X409tMOtGrLbhbaJ9aF/6EKgT6Q M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAK+rg1KtJXG8/2dsb2JhbABbgwc4U78ogSMWdIIlAQEBAwFlFAULAgEIRjIlAgQOBQ6HbQbAJY9fB4MggREDkDCBMIYwkguDKIIq X-IronPort-AV: E=Sophos;i="4.93,693,1378857600"; d="asc'?scan'208";a="284342836" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2013 16:46:39 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rADGkddo014856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 16:46:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 10:46:38 -0600 From: "Fred Baker (fred)" To: Tarko Tikan Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO4I/sAG11bn7zoUqMRCwrKgQsrA== Date: Wed, 13 Nov 2013 16:46:38 +0000 Message-ID: <6FE564A3-7FD9-4E17-9910-5B08B9FCA2EF@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> In-Reply-To: <52833B8F.10708@lanparty.ee> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_822ED0EF-0C28-44D5-A1C0-1349E0C89BE0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 16:46:45 -0000 --Apple-Mail=_822ED0EF-0C28-44D5-A1C0-1349E0C89BE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 13, 2013, at 12:42 AM, Tarko Tikan wrote: > hey, >=20 >> =46rom my perspective, I think I would prefer that the firewall - if = implemented - blocked everything, and applications within the network = advised the firewall(s) of traffic that they are willing to receive. If = a potential session has no willing counterpart within my network, I = don't see the argument for letting the first packet in. >=20 > That would be preferred but as already discussed, there are no = suitable protocols (and implementations) for deployment today. And = recommending to block all inbound sessions by default is not good idea = with IPv6 end2end mentality. >=20 > To improve on the idea - I don't see why application should signal to = CPE, firewalling in CPE is useless against ddos attacks. I'd prefer = application to signal to edge routers and have firewall there, this way = to-be-denied packets never make it to CPE and will not congest AN = uplinks. The action of the application would be the same, right? If the user has = a managed service, one can easily imagine the upstream firewall/router = doing this. That simply says where the PCP traffic would go to. The "IPv6 end2end mentality", I would argue, doesn't come into play = here. The phrase "end to end" implies having multiple endpoints. If = there is no application in the network prepared to be the receiving end, = the sending end can do whatever it likes - there is nobody to talk with. = And from a policy perspective, even if there is someone that *could* = talk (the HTTP server on my phone, designed for management use), that = doesn't imply that I want it to. I'm fine with saying there will be no = impedance of traffic that is useful and fits policy. As far as I know, = firewalls aren't supposed to block that anyway. --Apple-Mail=_822ED0EF-0C28-44D5-A1C0-1349E0C89BE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSg6zsbjEdbHIsm0MRAgQGAKDdoIxQKwCDUtQ5+A3yoqiTg9fh+QCfbmeG Lg4jsDUx2ISpw11ttRyua2E= =VXS0 -----END PGP SIGNATURE----- --Apple-Mail=_822ED0EF-0C28-44D5-A1C0-1349E0C89BE0-- From Ted.Lemon@nominum.com Wed Nov 13 10:19: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 8B5D511E81C3 for ; Wed, 13 Nov 2013 10:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptllLh6xMLCY for ; Wed, 13 Nov 2013 10:19:21 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0F21211E81BC for ; Wed, 13 Nov 2013 10:19:18 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUoPCpgokbfyOigrbrgfVRkeb1k9l2aXD@postini.com; Wed, 13 Nov 2013 10:19:19 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 8B4041B8052 for ; Wed, 13 Nov 2013 10:19:18 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6B4A1190043; Wed, 13 Nov 2013 10:19:18 -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.03.0158.001; Wed, 13 Nov 2013 10:19:18 -0800 From: Ted Lemon To: Tarko Tikan Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO3kcgifX5dH755Eqorh2n2HqLtpoih2QAgAAloACAALU7gIAAcbEAgAAIDYCAACdFAA== Date: Wed, 13 Nov 2013 18:19:17 +0000 Message-ID: <0B7E8354-F5DE-4E18-A4A5-2D2E6B999CBB@nominum.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> <5283A1AF.1070806@lanparty.ee> In-Reply-To: <5283A1AF.1070806@lanparty.ee> 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: <548ABF1E32E024478C85222CADFEE946@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 18:19:28 -0000 On Nov 13, 2013, at 10:58 AM, Tarko Tikan wrote: > There are pros and cons like always. Considering people put subscriber aw= areness, CGN (stateful) etc. into PEs, adding firewalls is not that big of = a deal. Scale is an issue but current hardware can already do tens of gigab= its worth of stateful firewalling. You completely missed my point. Do you really want your ISP filtering you= r data stream? From marc.lampo.ietf@gmail.com Wed Nov 13 11:47: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 D46BA21E8162 for ; Wed, 13 Nov 2013 11:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v1ILp4GkmUq for ; Wed, 13 Nov 2013 11:47:08 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF811E81BC for ; Wed, 13 Nov 2013 11:47:05 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id jy13so708924veb.37 for ; Wed, 13 Nov 2013 11:47: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=mjFOATOFkWh4LBospUbnOocT0a04mbum5L5CF7ctsC8=; b=Ly7eUEAIQ5H+k6398Qux6IEba03SSKD9y0ewVVM+34oRAPAmS62df4GhjyI3r7WQ1P tkVIwE9mwKFQHZVR5bhN5jp28iZkxlJi9y+a8g5PQNN8yjoY6ROpISpI6LGaO23b9FeA zMFVyDzK0OYJGtbmfzqIKfOHNmjcmGhDcjblCwl+UmwY4peA+MmqiNRNckvdThjcWPYn QKos4SDFu8jwmYUGUy5suNFeSoFIQCDWAeKtYpnHouxQbl+lc5PpkLKFhHstKiCNMAII wLxSHUTbXG1xlUwAXP+CN6Fd5/4aHsUq6fv61nsDrjy7C/2guO9uJhxqOLHbrpMXXI1A QGsQ== MIME-Version: 1.0 X-Received: by 10.52.117.129 with SMTP id ke1mr72792vdb.83.1384372025221; Wed, 13 Nov 2013 11:47:05 -0800 (PST) Received: by 10.58.227.66 with HTTP; Wed, 13 Nov 2013 11:47:05 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Date: Wed, 13 Nov 2013 20:47:05 +0100 Message-ID: From: Marc Lampo To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec5485846cceb7004eb143a14 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 19:47:14 -0000 --bcaec5485846cceb7004eb143a14 Content-Type: text/plain; charset=ISO-8859-1 I as well would prefer that unsolicited traffic from the Internet is stopped at the border of the network - like RFC 6092 recommends (though I don't see a recommendation for incoming UDP traffic ?) If a device in the network desires to communicate with the outside world, it is probably/hopefully after an act of configuration (of its owner) on that device. That outgoing traffic could be the trigger to allow the rest of the communication. If, in some years, fridges have IPv6 connectivity, perhaps they might send an inventory or shopping list to your mobile device (outgoing traffic) But probably/hopefully that will only happen after it was configured with some destination and authentication data so that the info arrives on your mobile and does indeed come from your fridge. But the fact that the fridge does have connectivity does not imply I would allow my favorite shop to come and look, or some marketing firm, or the fridge of a neighbor in search for eggs (s)he forgot ... So, by default allow the first packet towards ports "considered harmless" ? As Fred already pointed out, the listener on TCP port 80 might not be a webserver; and why would any port (lower or higher than 1024) be harmless ? After all, malware could chose any free port. The number 1024 is only there because, on UNIX, it requires super user privileges to bind to low ports. Hence, in my opinion, the security (and privacy) of IPv6 users is best served by keeping unsolicited traffic out. Kind regards, On Wed, Nov 13, 2013 at 3:34 AM, Mikael Abrahamsson wrote: > On Tue, 12 Nov 2013, Fred Baker (fred) wrote: > > From my perspective, I think I would prefer that the firewall - if >> implemented - blocked everything, and applications within the network >> advised the firewall(s) of traffic that they are willing to receive. If a >> potential session has no willing counterpart within my network, I don't see >> the argument for letting the first packet in. >> > > My biggest problem with this resoning, is that I am not aware of any > firewall poking mechanism actively being in use for IPv6. This means that > if we have a firewall with default-deny for incoming connections, then > either hosts need an Internet based machine to coordinate a STUN type of > behaviour to get the firewall to accept packets for sessions, or they need > to implement a firewall poking mechanism that as far as I know, neither > todays firewalls/CPEs nor hosts actually has. > > So today, implementing default-deny would mean a lot of the benefit of > IPv6 wouldn't be seen immediately but would takes many years to realise. > Right? > > Or am I mistaken and uPNP for IPv6 actually functional today? PCP I have > never seen in home devices. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec5485846cceb7004eb143a14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I as well would prefer that unsolicite= d traffic from the Internet is stopped at the border of the network - like = RFC 6092 recommends (though I don't see a recommendation for incoming U= DP traffic ?)

If a device in the network desires to communicate with the outsid= e world, it is probably/hopefully after an act of configuration (of its own= er) on that device.=A0 That outgoing traffic could be the trigger to allow = the rest of the communication.
If, in some years, fridges have IPv6 connectivity, perhaps they = might send an inventory or shopping list to your mobile device (outgoing tr= affic)
But probably/hopefully that will only happen after it was configu= red with some destination and authentication data so that the info arrives = on your mobile and does indeed come from your fridge.
But the fact that the fridge does have connectivity does not imp= ly I would allow my favorite shop to come and look, or some marketing firm,= or the fridge of a neighbor in search for eggs (s)he forgot ...


So, by default allow the first packet towards ports "cons= idered harmless" ?

As Fred already pointed out, the liste= ner on TCP port 80 might not be a webserver;
and why would any port (low= er or higher than 1024)=A0 be harmless ?
After all, malware could chose any free port.
The number 102= 4 is only there because, on UNIX, it requires super user privileges to bind= to low ports.


Hence, in my opinion, the security (and priv= acy) of IPv6 users is best served by keeping unsolicited traffic out.

Kind regards,

=
On Wed, Nov 13, 2013 at 3:34 AM, Mikael Abra= hamsson <swmike@swm.pp.se> wrote:
On Tue, 12 Nov 2013, Fred = Baker (fred) wrote:

>From my perspective, I think I would prefer that the firewall - if implemen= ted - blocked everything, and applications within the network advised the f= irewall(s) of traffic that they are willing to receive. If a potential sess= ion has no willing counterpart within my network, I don't see the argum= ent for letting the first packet in.

My biggest problem with this resoning, is that I am not aware of any firewa= ll poking mechanism actively being in use for IPv6. This means that if we h= ave a firewall with default-deny for incoming connections, then either host= s need an Internet based machine to coordinate a STUN type of behaviour to = get the firewall to accept packets for sessions, or they need to implement = a firewall poking mechanism that as far as I know, neither todays firewalls= /CPEs nor hosts actually has.

So today, implementing default-deny would mean a lot of the benefit of IPv6= wouldn't be seen immediately but would takes many years to realise. Ri= ght?

Or am I mistaken and uPNP for IPv6 actually functional today? PCP I have ne= ver seen in home devices.
--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se

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

--bcaec5485846cceb7004eb143a14-- From tarko@lanparty.ee Wed Nov 13 13:25: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 0882321E80B4 for ; Wed, 13 Nov 2013 13:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKae3G82RpSt for ; Wed, 13 Nov 2013 13:25:12 -0800 (PST) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) by ietfa.amsl.com (Postfix) with ESMTP id 15F0921E80B3 for ; Wed, 13 Nov 2013 13:25:11 -0800 (PST) Received: from hg.lanparty.ee ([194.126.106.156] helo=[10.10.10.22]) by valgus.lanparty.ee with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Vghvy-000098-2E; Wed, 13 Nov 2013 23:25:10 +0200 Message-ID: <5283EE36.5060607@lanparty.ee> Date: Wed, 13 Nov 2013 23:25:10 +0200 From: Tarko Tikan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Ted Lemon References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <52833B8F.10708@lanparty.ee> <5283A1AF.1070806@lanparty.ee> <0B7E8354-F5DE-4E18-A4A5-2D2E6B999CBB@nominum.com> In-Reply-To: <0B7E8354-F5DE-4E18-A4A5-2D2E6B999CBB@nominum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 194.126.106.156 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 13 Nov 2013 21:25:18 -0000 hey, > You completely missed my point. Do you really want your ISP filtering your data stream? No I didn't. As a provider I worry about DOS hitting my ANs and worms/viruses spreading in my network. As a customer I worry about getting hacked (which didn't happen with v4 NAT - not a strong argument ofc as customers mostly get infected via drive-by malware these days). I also want to manage it myself to some level, minimally just enable/disable. We currently provide stateless filter for our broadband customers. Filtering is done in edge routers and not CPE. Unfortunately customers can't customize the rules because it just wouldn't scale today (would need to create ACL for every customer). -- tarko From swmike@swm.pp.se Wed Nov 13 21: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 155A521E81B0 for ; Wed, 13 Nov 2013 21:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atS6nafMszUs for ; Wed, 13 Nov 2013 21:42: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 7A1EB21E812F for ; Wed, 13 Nov 2013 21:42:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C2AB79C; Thu, 14 Nov 2013 06:42:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BC7B29A; Thu, 14 Nov 2013 06:42:19 +0100 (CET) Date: Thu, 14 Nov 2013 06:42:19 +0100 (CET) From: Mikael Abrahamsson To: Marc Lampo In-Reply-To: Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 05:42:23 -0000 On Wed, 13 Nov 2013, Marc Lampo wrote: > Hence, in my opinion, the security (and privacy) of IPv6 users is best > served by keeping unsolicited traffic out. You and me have a very different opinion what unsolicited is. If the host accepts connections on a port, then it has by definition accepted to handle the connection. There is no reason access control can't be handled on the host. I would rather see a mechanism that the host can use to say "please protect me, I'm helpless" and then the gateways will filter traffic to the device (ie if the host says nothing then default policy is open) than what you're proposing which is "default close". -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Wed Nov 13 22:07: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 03D7111E8106 for ; Wed, 13 Nov 2013 22:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMz4Al+o2h0k for ; Wed, 13 Nov 2013 22:07:30 -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 7D61F21E81B4 for ; Wed, 13 Nov 2013 22:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2025; q=dns/txt; s=iport; t=1384409249; x=1385618849; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e2kZDSdedj1vP5fLgamNv33AXC0pkmSvZi7Hp8OOLS0=; b=LzV4a9z9y5oMGpaBLCL2rYqtc6bfzDAHkHfpyKAAgyXphhOUwd/y1ksM hwXOHB34p2MyGKOiQ6TZa0OvKxpULz0xxvzQpkBC8XbfvLICp70U3OoWr mr/E+SoB59uYWTEsICz/DFd7oDOZk2XI7enN7dgnaQkU86UO9lYSDVd2/ w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFABZohFKtJXG//2dsb2JhbABZgweBC78sgSkWdIIlAQEBAwFlFAULAgEIDgouMiUCBA4FDodtBr9lj18HgyCBEQOQMIEwhjCSDIMogio X-IronPort-AV: E=Sophos;i="4.93,697,1378857600"; d="asc'?scan'208";a="281611065" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2013 06:07:29 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAE67SVV023976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 06:07:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 00:07:28 -0600 From: "Fred Baker (fred)" To: Mikael Abrahamsson Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO4P/Lxg/cd6lkIUaP++DWdjK9IQ== Date: Thu, 14 Nov 2013 06:07:28 +0000 Message-ID: <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_B3F3800A-B99B-47FD-9091-4C4FDB118B1C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 06:07:40 -0000 --Apple-Mail=_B3F3800A-B99B-47FD-9091-4C4FDB118B1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 13, 2013, at 9:42 PM, Mikael Abrahamsson wrote: > On Wed, 13 Nov 2013, Marc Lampo wrote: >=20 >> Hence, in my opinion, the security (and privacy) of IPv6 users is = best served by keeping unsolicited traffic out. >=20 > You and me have a very different opinion what unsolicited is. If the = host accepts connections on a port, then it has by definition accepted = to handle the connection. There is no reason access control can't be = handled on the host. The question here, if I understand Marc, is who sent the first packet. = If the TCP SYN (or counterpart in whatever protocol) was sent by the = host within the domain, an RFC 6092 firewall will permit traffic in = response. If the TCP SYN was sent by the peer to that host, an RFC 6092 = firewall will prevent that and everything following. Having the host say = to the firewall that it is willing to accept unsolicited communications = is quite a bit different than initiating those communications. > I would rather see a mechanism that the host can use to say "please = protect me, I'm helpless" and then the gateways will filter traffic to = the device (ie if the host says nothing then default policy is open) = than what you're proposing which is "default close". What about a host that is so helpless that it doesn't say so? --Apple-Mail=_B3F3800A-B99B-47FD-9091-4C4FDB118B1C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFShGiPbjEdbHIsm0MRAmoNAKC8LLniHCc9bQ18Ehf4LkRr0p40YACdFIq3 OJ9ZqYbavGd/7HHraPMyJTI= =oMRt -----END PGP SIGNATURE----- --Apple-Mail=_B3F3800A-B99B-47FD-9091-4C4FDB118B1C-- From marka@isc.org Wed Nov 13 22:15: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 09B7211E80DE for ; Wed, 13 Nov 2013 22:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKuAKky9bL5P for ; Wed, 13 Nov 2013 22:15:04 -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 B761F21E8087 for ; Wed, 13 Nov 2013 22:15:03 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 7B0A82383CF; Thu, 14 Nov 2013 06:14:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C73CE16043C; Thu, 14 Nov 2013 06:21:19 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 69812160050; Thu, 14 Nov 2013 06:21:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D70EEA5FDB1; Thu, 14 Nov 2013 17:14:54 +1100 (EST) To: "Fred Baker (fred)" From: Mark Andrews References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> In-reply-to: Your message of "Thu, 14 Nov 2013 06:07:28 -0000." <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> Date: Thu, 14 Nov 2013 17:14:54 +1100 Message-Id: <20131114061454.D70EEA5FDB1@rock.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 06:15:11 -0000 In message <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com>, "Fred Baker (fred) " writes: > > On Nov 13, 2013, at 9:42 PM, Mikael Abrahamsson > wrote: > > > On Wed, 13 Nov 2013, Marc Lampo wrote: > > > >> Hence, in my opinion, the security (and privacy) of IPv6 users is best > served by keeping unsolicited traffic out. > > > > You and me have a very different opinion what unsolicited is. If the > host accepts connections on a port, then it has by definition accepted to > handle the connection. There is no reason access control can't be handled > on the host. > > The question here, if I understand Marc, is who sent the first packet. If > the TCP SYN (or counterpart in whatever protocol) was sent by the host > within the domain, an RFC 6092 firewall will permit traffic in response. > If the TCP SYN was sent by the peer to that host, an RFC 6092 firewall > will prevent that and everything following. Having the host say to the > firewall that it is willing to accept unsolicited communications is quite > a bit different than initiating those communications. > > > I would rather see a mechanism that the host can use to say "please > protect me, I'm helpless" and then the gateways will filter traffic to > the device (ie if the host says nothing then default policy is open) than > what you're proposing which is "default close". > > What about a host that is so helpless that it doesn't say so? Then it should be put in the bin. Equipment should expect to be exposed to the Internet as a whole. It's not like this is a new concept. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From holger.metschulat@telekom.de Wed Nov 13 22: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 728F211E811D for ; Wed, 13 Nov 2013 22:45:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPEGSrhymxrm for ; Wed, 13 Nov 2013 22:45:38 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7922311E8101 for ; Wed, 13 Nov 2013 22:45:37 -0800 (PST) From: Received: from he111493.emea1.cds.t-internal.com ([10.206.92.96]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 14 Nov 2013 07:45:24 +0100 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111493.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 14 Nov 2013 07:45:24 +0100 To: , Date: Thu, 14 Nov 2013 07:45:22 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: Ac7e7ieC4Pb3Pzx1RNO0RlkEICeJSgBpm7QA Message-ID: References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> In-Reply-To: <20131111145452.GF81676@Space.Net> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 06:45:44 -0000 Gert, this needs to be resolved in the provider's network by applying DNS64 only = to those UE that have an IPv6-only connection. Usually, IPv6-only connectiv= ity means a separate APN with a dedicated IPv6 pool, so either IPv4 and IPv= 4v6 UE get a different DNS server than the IPv6-only UE, or the DNS server = is the same and it can deduce from the client's IPv6 address whether it's a= n IPv4v6 or and IPv6-only client. Holger -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Gert Doering Gesendet: Montag, 11. November 2013 15:55 An: GangChen Cc: v6ops@ietf.org Betreff: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Hi, On Mon, Nov 11, 2013 at 10:46:42PM +0800, GangChen wrote: > It doesn't expect that dual-stack UEs go to NAT64, because IPv4 native=20 > connections are preferred over IPv6+NAT64 How does the UE know that a target can be reached by native IPv4 if DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From swmike@swm.pp.se Wed Nov 13 22:56: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 4EDBF21E8087 for ; Wed, 13 Nov 2013 22:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0zHbEkbuqdu for ; Wed, 13 Nov 2013 22:56:17 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEEC11E80F6 for ; Wed, 13 Nov 2013 22:56:16 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7F8F29C; Thu, 14 Nov 2013 07:56:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 71CE99A; Thu, 14 Nov 2013 07:56:15 +0100 (CET) Date: Thu, 14 Nov 2013 07:56:15 +0100 (CET) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 06:56:18 -0000 On Thu, 14 Nov 2013, Fred Baker (fred) wrote: > The question here, if I understand Marc, is who sent the first packet. > If the TCP SYN (or counterpart in whatever protocol) was sent by the > host within the domain, an RFC 6092 firewall will permit traffic in > response. If the TCP SYN was sent by the peer to that host, an RFC 6092 > firewall will prevent that and everything following. Having the host say > to the firewall that it is willing to accept unsolicited communications > is quite a bit different than initiating those communications. Absolutely. >> I would rather see a mechanism that the host can use to say "please >> protect me, I'm helpless" and then the gateways will filter traffic to >> the device (ie if the host says nothing then default policy is open) >> than what you're proposing which is "default close". > > What about a host that is so helpless that it doesn't say so? I guess this is what it all boils down to, world view. I want the home to be full part of the Internet as default, whereas others seem to want a filtered view. Most of the devices today can handle themselves having unfiltered access to the Internet. Phones and computers are regularily exposed to the Internet and have sane defaults to handle this. I have plenty of computers and other devices on GUA IPv4 and IPV6 addresses and they have been fine. Most infections happen because of pulled content, not pushed, so I don't really see the big advantage of disallowing incoming connections. What I *would* like to hear from is more application designers, and their view. Are they ok with having incoming connections blocked? What do the vendors of Facetime, Back-to-my-mac, Viber, Skype etc say about this? Ekiga? Cisco Jabber Video? Otoh the vendors of these have infrastructure on the Internet to help them, which others do not. So, Torrent clients? Microsoft One? Microsoft remote desktop stuff? VNC? These are the applications we might be killing with this default close policy that is being proposed. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Nov 13 22:58: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 A0D3C21E80D2 for ; Wed, 13 Nov 2013 22:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2SLQO5+cMMZ for ; Wed, 13 Nov 2013 22:58:51 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id EABF621E81B8 for ; Wed, 13 Nov 2013 22:58:39 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AA7309C; Thu, 14 Nov 2013 07:58:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9EADF9A; Thu, 14 Nov 2013 07:58:38 +0100 (CET) Date: Thu, 14 Nov 2013 07:58:38 +0100 (CET) From: Mikael Abrahamsson To: holger.metschulat@telekom.de In-Reply-To: Message-ID: References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 06:58:56 -0000 On Thu, 14 Nov 2013, holger.metschulat@telekom.de wrote: > this needs to be resolved in the provider's network by applying DNS64 > only to those UE that have an IPv6-only connection. Usually, IPv6-only > connectivity means a separate APN with a dedicated IPv6 pool, so either > IPv4 and IPv4v6 UE get a different DNS server than the IPv6-only UE, or > the DNS server is the same and it can deduce from the client's IPv6 > address whether it's an IPv4v6 or and IPv6-only client. I oppose this reasoning. It brings in unneeded complexity in the mobile core network to handle all this logic, and besides, customers should be able to choose if they want IPv4v6 or IPv6 only, meaning you don't know in advance. It's beneficial if standards allow for less complexity in backend systems. Complex backend systems is less problem for huge ISPs, but it is for smaller ones. Also, even huge ISPs benefit from less complexity in their backend systems. -- Mikael Abrahamsson email: swmike@swm.pp.se From marc.lampo.ietf@gmail.com Wed Nov 13 23:58: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 DED2821F8B04 for ; Wed, 13 Nov 2013 23:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzwoZG7+os2c for ; Wed, 13 Nov 2013 23:58:29 -0800 (PST) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 47D5411E811D for ; Wed, 13 Nov 2013 23:58:23 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id db12so1426195veb.25 for ; Wed, 13 Nov 2013 23:58:22 -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=qa72cVXTP1YKoDyLI6TyQ8+WbgeYDz7hOZ3ATt4O4oI=; b=F5QKX7m8tT6CXCz21XcXXuEkbnPTSCt3WtDfO4rFBOO/MC3J6yMmb4FoZk/QYMzlkz GP3Iu68qnP8xU5kHjbm0XTGoEsXybe62ZFItkvyJiVRmIB3C4Ab6gXPVHhjxYljTvBlm JCA1Ep/NRlbVvA/K+AhDws14dOE9H2lo+BTiJBWJ0gVnoPIGRgUoRgkS6Me2B/wBhbj4 sTkrdiJ+aKTORtsccRIOTsd+G+a+RTMe6fvvEZtxze0+Be6MNSNnA9s3IqawRjmcmZJA bHhR7tEWf94ZSuf7uSNATbCQqpiUNqAv4jm4ggmUr44sB8BNIShyjfI9Fr3/tihbSacR RcTw== MIME-Version: 1.0 X-Received: by 10.52.164.16 with SMTP id ym16mr16301vdb.39.1384415902685; Wed, 13 Nov 2013 23:58:22 -0800 (PST) Received: by 10.58.227.66 with HTTP; Wed, 13 Nov 2013 23:58:22 -0800 (PST) In-Reply-To: <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> Date: Thu, 14 Nov 2013 08:58:22 +0100 Message-ID: From: Marc Lampo To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11c22e5819e04d04eb1e72e1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 07:58:30 -0000 --001a11c22e5819e04d04eb1e72e1 Content-Type: text/plain; charset=ISO-8859-1 by "unsolicited" I understand : the initiative to start the communication is on the Internet side. So, if RFC6092 is implemented, that kind of traffic is not allowed. (Sorry for the confusion on the word) On Thu, Nov 14, 2013 at 7:07 AM, Fred Baker (fred) wrote: > > On Nov 13, 2013, at 9:42 PM, Mikael Abrahamsson > wrote: > > > On Wed, 13 Nov 2013, Marc Lampo wrote: > > > >> Hence, in my opinion, the security (and privacy) of IPv6 users is best > served by keeping unsolicited traffic out. > > > > You and me have a very different opinion what unsolicited is. If the > host accepts connections on a port, then it has by definition accepted to > handle the connection. There is no reason access control can't be handled > on the host. > > The question here, if I understand Marc, is who sent the first packet. If > the TCP SYN (or counterpart in whatever protocol) was sent by the host > within the domain, an RFC 6092 firewall will permit traffic in response. If > the TCP SYN was sent by the peer to that host, an RFC 6092 firewall will > prevent that and everything following. Having the host say to the firewall > that it is willing to accept unsolicited communications is quite a bit > different than initiating those communications. > > > I would rather see a mechanism that the host can use to say "please > protect me, I'm helpless" and then the gateways will filter traffic to the > device (ie if the host says nothing then default policy is open) than what > you're proposing which is "default close". > > What about a host that is so helpless that it doesn't say so? > --001a11c22e5819e04d04eb1e72e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
by "unsolicited" I understand : the initiative t= o start the communication is on the Internet side.=A0 So, if RFC6092 is imp= lemented, that kind of traffic is not allowed.=A0 (Sorry for the confusion = on the word)


On Thu,= Nov 14, 2013 at 7:07 AM, Fred Baker (fred) <fred@cisco.com> = wrote:

On Nov 13, 2013, at 9:42 PM, Mikael Abrahamsson <swmike@swm.pp.se>
=A0wrote:

> On Wed, 13 Nov 2013, Marc Lampo wrote:
>
>> Hence, in my opinion, the security (and privacy) of IPv6 users is = best served by keeping unsolicited traffic out.
>
> You and me have a very different opinion what unsolicited is. If the h= ost accepts connections on a port, then it has by definition accepted to ha= ndle the connection. There is no reason access control can't be handled= on the host.

The question here, if I understand Marc, is who sent the first packet= . If the TCP SYN (or counterpart in whatever protocol) was sent by the host= within the domain, an RFC 6092 firewall will permit traffic in response. I= f the TCP SYN was sent by the peer to that host, an RFC 6092 firewall will = prevent that and everything following. Having the host say to the firewall = that it is willing to accept unsolicited communications is quite a bit diff= erent than initiating those communications.

> I would rather see a mechanism that the host can use to say "plea= se protect me, I'm helpless" and then the gateways will filter tra= ffic to the device (ie if the host says nothing then default policy is open= ) than what you're proposing which is "default close".

What about a host that is so helpless that it doesn't say so?

--001a11c22e5819e04d04eb1e72e1-- From leo.liubing@huawei.com Thu Nov 14 00:18: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 1B1A721F9FAE for ; Thu, 14 Nov 2013 00:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EHvWeq1g7FL for ; Thu, 14 Nov 2013 00:18:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 13D3A21F9005 for ; Thu, 14 Nov 2013 00:18:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAG61304; Thu, 14 Nov 2013 08:18:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 08:17:38 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 08:18:23 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 16:18:16 +0800 From: "Liubing (Leo)" To: "Fred Baker (fred)" Thread-Topic: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHO2k/wLQNmfJ8fNUS0872S7bWPwZoWa54AgAAChYCACxV9gIAA6LLQgAAhCwCAAeDVwA== Date: Thu, 14 Nov 2013 08:18:15 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7F364B@nkgeml506-mbx.china.huawei.com> References: <52793827.2040708@gmail.com> <21C0A698-E56B-4B0B-8454-1323027AD04E@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7F3192@nkgeml506-mbx.china.huawei.com> <0CF7584E-B62C-4BB1-B1E2-B8E89BE1B83D@cisco.com> In-Reply-To: <0CF7584E-B62C-4BB1-B1E2-B8E89BE1B83D@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis 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, 14 Nov 2013 08:18:48 -0000 Hi Fred, Thanks for your detailed explain. It is very useful information. I'll consider to include it in the next version. Best regards, Bing > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Wednesday, November 13, 2013 7:33 PM > To: Liubing (Leo) > Cc: Brian E Carpenter; v6ops@ietf.org > Subject: Re: [v6ops] comment on draft-liu-v6ops-ula-usage-analysis >=20 >=20 > On Nov 12, 2013, at 5:55 PM, Liubing (Leo) > wrote: >=20 > > Hi, Fred > > > >> > >> > >> I'm told that it goes beyond that. There are at least three > >> "directions" in the > >> split: > > [Bing] Did you mean you are told from some real deployment, or told fro= m > the ULA draft? >=20 > I am on the board of a company that produces a product that is used in th= ese > configurations. One of the engineers told me it is a requirement his > customers present him with. Today, that is generally IPv4, not IPv6, so I= can't > comment on ULAs, only extrapolate. I was commenting on the DNS > configuration. >=20 > >> - inside, where internal-only names are advertised, might use an > >> internal-only prefix, and even "outside" names might have different > >> servers and different addresses. > >> - outside, where internal-only names are not advertised > >> - partner, which is "outside" plus some names made accessible to > >> the partner, and may imply some form of b2b routing as well. > > [Bing] Say if ULAs are used for b2b private routing, in the "partner" c= ase, > does it means the b2b ULAs are stored in the outside DNS, so that the > partners could get the ULAs through public DNS, and access to the ULAs > through private routing? >=20 > In the particular configuration, as I understand what the engineer told m= e, > "inside", "outside", and in the "partner" case, the identity of the partn= er, are > attributes in the underlying database. The software looks at the request, > determines what data should be included in the response, and includes it. From tore@fud.no Thu Nov 14 00:55: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 3752521E8087 for ; Thu, 14 Nov 2013 00:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnI2oA6XulAX for ; Thu, 14 Nov 2013 00:55:41 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 5003A21E80C8 for ; Thu, 14 Nov 2013 00:55:40 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=48444 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Vgsi9-00052F-HQ; Thu, 14 Nov 2013 09:55:37 +0100 Message-ID: <52849009.80408@fud.no> Date: Thu, 14 Nov 2013 09:55:37 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gert Doering , GangChen References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> In-Reply-To: <20131111145452.GF81676@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 08:55:42 -0000 * Gert Doering > How does the UE know that a target can be reached by native IPv4 if > DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4? One could use a ULA prefix for DNS64/NAT64, which would make native IPv4 be preferred according to RFC 6724. Tore From swmike@swm.pp.se Thu Nov 14 00:56: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 7AC0521E8163 for ; Thu, 14 Nov 2013 00:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQqF2VjuKWT2 for ; Thu, 14 Nov 2013 00:56:17 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2851A21E8153 for ; Thu, 14 Nov 2013 00:56:14 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CAFAEA1; Thu, 14 Nov 2013 09:56:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BE8199A; Thu, 14 Nov 2013 09:56:11 +0100 (CET) Date: Thu, 14 Nov 2013 09:56:11 +0100 (CET) From: Mikael Abrahamsson To: Marc Lampo In-Reply-To: Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 08:56:23 -0000 On Thu, 14 Nov 2013, Marc Lampo wrote: > by "unsolicited" I understand : the initiative to start the > communication is on the Internet side. So, if RFC6092 is implemented, > that kind of traffic is not allowed. (Sorry for the confusion on the > word) There was no confusion on my side, I understood you exactly this way. It's just that if the device signals to the firewall that it wants to allow certain ports to be allowed, any SYN packet from the outside is still unsolicited. It just happens that you've moved the access control from the host IP stack to an intermediate device that needs to apply the same policy as the host could have done. By accepting SYN packets on port 80, you're soliciting connections. If you don't want to accept SYN port 80 from everywhere, then don't accept it. There is little added benefit in having a signaling mechanism to an intermediate device (firewall) to do the same functionality. -- Mikael Abrahamsson email: swmike@swm.pp.se From tjc@ecs.soton.ac.uk Thu Nov 14 01:17: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 5AD2221E808F for ; Thu, 14 Nov 2013 01:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVDEsmqeHX80 for ; Thu, 14 Nov 2013 01:17:48 -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 7F70821E8092 for ; Thu, 14 Nov 2013 01:17:47 -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 rAE9HcET019329; Thu, 14 Nov 2013 09:17:38 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rAE9HcET019329 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1384420658; bh=CsyoQnKYpGgdX+kxsOAEHzKI55I=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=aM1i/Jl7r2JZye45P3UebYjoOg90idM+p/zGN3Lb/E9rP6zzlhqVK/OFLV8LyP7Cx 5qzwQWIh4UbStSUzXXDh4eiJ19d3PAVzMgw22kPjxip1MlUugupkaeIR3UcGSfD85I CyPMrfPeVZ36qmlpruKUE7s6UU4Zqd4i+4/B/ZvI= 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 pAD9Hc09596597952U ret-id none; Thu, 14 Nov 2013 09:17:38 +0000 Received: from [192.168.0.26] (5ad35a35.bb.sky.com [90.211.90.53] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAE9HWtD016714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Nov 2013 09:17:33 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_9A6FAEA2-1A10-48ED-A18C-47BDB214D09F" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Tim Chown In-Reply-To: <52849009.80408@fud.no> Date: Thu, 14 Nov 2013 09:17:32 +0000 Message-ID: References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> <0154CE2C-C5EF-44FB-9B6D-5B2077267329@ecs.soton.ac.uk> To: Tore Anderson X-Mailer: Apple Mail (2.1822) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pAD9Hc095965979500; tid=pAD9Hc09596597952U; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rAE9HcET019329 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 09:17:51 -0000 --Apple-Mail=_9A6FAEA2-1A10-48ED-A18C-47BDB214D09F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Nov 2013, at 08:55, Tore Anderson wrote: > * Gert Doering >=20 >> How does the UE know that a target can be reached by native IPv4 if=20= >> DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4? >=20 > One could use a ULA prefix for DNS64/NAT64, which would make native = IPv4 > be preferred according to RFC 6724. A related discussion came up some time ago when we were discussing = 3484-bis that became 6724: http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html That was about the NAT64 WKP appearing - or being added to - the 6724 = policy table. There is now a DHCPv6 option for that. Tim --Apple-Mail=_9A6FAEA2-1A10-48ED-A18C-47BDB214D09F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 14 = Nov 2013, at 08:55, Tore Anderson <tore@fud.no> wrote:

* Gert = Doering

How does the UE know that a = target can be reached by native IPv4 if
DNS64 tells it "there is = IPv6 for you" and IPv6 is preferred to IPv4?

One = could use a ULA prefix for DNS64/NAT64, which would make native = IPv4
be preferred according to RFC = 6724.

A related discussion came up some = time ago when we were discussing 3484-bis that became 6724:

That was about the NAT64 WKP appearing - or being = added to - the 6724 policy table.  There is now a DHCPv6 option for = that.

Tim

= --Apple-Mail=_9A6FAEA2-1A10-48ED-A18C-47BDB214D09F-- From gert@space.net Thu Nov 14 01:33: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 3B9BC21E815D for ; Thu, 14 Nov 2013 01:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHKMyo53aEwo for ; Thu, 14 Nov 2013 01:33:20 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 97E0921E8153 for ; Thu, 14 Nov 2013 01:33:19 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5725260950 for ; Thu, 14 Nov 2013 10:33:18 +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 1E58C60917 for ; Thu, 14 Nov 2013 10:33:18 +0100 (CET) Received: (qmail 74657 invoked by uid 1007); 14 Nov 2013 10:33:18 +0100 Date: Thu, 14 Nov 2013 10:33:18 +0100 From: Gert Doering To: Tim Chown Message-ID: <20131114093318.GG81676@Space.Net> References: <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> <0154CE2C-C5EF-44FB-9B6D-5B2077267329@ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p0VvXOh+Vh0d4WRz" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 09:33:21 -0000 --p0VvXOh+Vh0d4WRz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 14, 2013 at 09:17:32AM +0000, Tim Chown wrote: > On 14 Nov 2013, at 08:55, Tore Anderson wrote: >=20 > > One could use a ULA prefix for DNS64/NAT64, which would make native IPv4 > > be preferred according to RFC 6724. >=20 > A related discussion came up some time ago when we were discussing 3484-b= is that became 6724: > http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html >=20 > That was about the NAT64 WKP appearing - or being added to - the 6724 pol= icy table. There is now a DHCPv6 option for that. Nice approach (both). Thanks for pointing that out. Tim, do you know whether there is any implementation that will handle that, that is, accept that DHCPv6 option and add it to the 6724 policy table accordingly ("lower than native IPv4")? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --p0VvXOh+Vh0d4WRz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUoSY3d9WwGXkzn/FAQLH+Q/+LyVSmiNMEsDRIX6cfXDFcE8z3E4WB8a+ 9N2iz7X/x5RDeX1EWcVY5/kv32ptya0gJ1Ypg2F3wPG63KdATHUtSDWfCJ5irvvY JzYtJeUO4wvxwTLYDR19GHs2BKW3xsMEfRl5pmL1/BviSGqJxqWB7Y4gpK4sljrQ xE1lPTsDfN6AQ29LFqCMd6IxHo23MHJ4ftdv40ZRqEH4sIvPiI/959DVPBesTuSC uH0dJZRRpQvKWgEyhsJyTqXNhR+79KSJd0giPb11YdOaW8rzAWmP1XJExb1by1g4 syVNMBXlu92b61WH1pYA4YkOXHrH4bCKjgndYtr5KFaEmZqFehvzCVE31+04XMt1 rqp8Vr+V4L+Ip5iD41S2N4BxqjZ+ksJAIF/Oc0MRKAFPpia1exM/DhQyIvQmr0cE MxEtMaG0d5INRVPLDwF7SKk4Ui3oac6lndSK81qVGwc3D+X4/5wBCRl17sdOhrAV VCFlEhkMCwQN8e5lZMeaDfnMso3KaZCTey0EYiiRzit7AnzDAJt2P7mnRU26FwsE gzystIxSPnSvm4fNZxa/bQJi8nsE36L2aWgBpZAp69v9UDcw8AHXi6XadbjBm238 zmZKV3N0g+OQ8qX7zLzVmBKe1I181lXz1w5UiQnHaL1pK8l4PivzFGz42fNnu2Mr RoeFD5reFcI= =xjjo -----END PGP SIGNATURE----- --p0VvXOh+Vh0d4WRz-- From tjc@ecs.soton.ac.uk Thu Nov 14 02:14: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 C999F21E809C for ; Thu, 14 Nov 2013 02:14: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-5UTAxjrx1V for ; Thu, 14 Nov 2013 02:14:43 -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 DBB9321F9B25 for ; Thu, 14 Nov 2013 02:14:42 -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 rAEAEdIH001607; Thu, 14 Nov 2013 10:14:39 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rAEAEdIH001607 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1384424079; bh=+w+8QogHkwfW3gB80CYpFsCtW7I=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=gvpc1jzSJrf4cgwEQIYNAuHGWAUOFj9De9EGx2mW2CXHCizOT/k3FCZ+m/GhCe2Ku 0FrYUSgFII7Fqg9802545T0UDhovxRVDeR3kd06Uz87w9oiuoWXpnmh681aUFHERmk GvEmQ6PxEMKbBuqaYeAdHbwy3/AxSohyuzO2laFs= 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 pADAEd0959660495cW ret-id none; Thu, 14 Nov 2013 10:14:39 +0000 Received: from dhcp-162-43.wireless.soton.ac.uk (dhcp-162-43.wireless.soton.ac.uk [152.78.162.43]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAEAEWxa032236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Nov 2013 10:14:32 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: <20131114093318.GG81676@Space.Net> Date: Thu, 14 Nov 2013 10:14:28 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> <0154CE2C-C5EF-44FB-9B6D-5B2077267329@ecs.soton.ac.uk> <20131114093318.GG81676@Space.Net> <152585E9-5D19-4F2E-8ED1-32925DE69137@ecs.soton.ac.uk> To: Gert Doering X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pADAEd095966049500; tid=pADAEd0959660495cW; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rAEAEdIH001607 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 10:14:43 -0000 On 14 Nov 2013, at 09:33, Gert Doering wrote: > Hi, >=20 > On Thu, Nov 14, 2013 at 09:17:32AM +0000, Tim Chown wrote: >> On 14 Nov 2013, at 08:55, Tore Anderson wrote: >>=20 >>> One could use a ULA prefix for DNS64/NAT64, which would make native = IPv4 >>> be preferred according to RFC 6724. >>=20 >> A related discussion came up some time ago when we were discussing = 3484-bis that became 6724: >> http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html >>=20 >> That was about the NAT64 WKP appearing - or being added to - the 6724 = policy table. There is now a DHCPv6 option for that. >=20 > Nice approach (both). Thanks for pointing that out. >=20 > Tim, do you know whether there is any implementation that will handle > that, that is, accept that DHCPv6 option and add it to the 6724 policy > table accordingly ("lower than native IPv4")? I believe that at least both Cisco and ISC are working on = implementations. Tim= From gert@space.net Thu Nov 14 02:18: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 844FA21E8200 for ; Thu, 14 Nov 2013 02:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKhCnBc9KWcp for ; Thu, 14 Nov 2013 02:18:31 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id D2A4F21E81F9 for ; Thu, 14 Nov 2013 02:18:30 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id BE27560951 for ; Thu, 14 Nov 2013 11:18:29 +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 9E6A6602E5 for ; Thu, 14 Nov 2013 11:18:29 +0100 (CET) Received: (qmail 6702 invoked by uid 1007); 14 Nov 2013 11:18:29 +0100 Date: Thu, 14 Nov 2013 11:18:29 +0100 From: Gert Doering To: Tim Chown Message-ID: <20131114101829.GM81676@Space.Net> References: <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> <0154CE2C-C5EF-44FB-9B6D-5B2077267329@ecs.soton.ac.uk> <20131114093318.GG81676@Space.Net> <152585E9-5D19-4F2E-8ED1-32925DE69137@ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0QJ8DMHdp6MMZYsr" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 10:18:31 -0000 --0QJ8DMHdp6MMZYsr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 14, 2013 at 10:14:28AM +0000, Tim Chown wrote: > >> That was about the NAT64 WKP appearing - or being added to - the 6724 = policy table. There is now a DHCPv6 option for that. >=20 > I believe that at least both Cisco and ISC are working on implementations. That sounds like "the server side" - which is needed, but shouldn't take a miracle to add. More interesting to me would be "client side" :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --0QJ8DMHdp6MMZYsr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUoSjdd9WwGXkzn/FAQIwRg/+IO4uBzYIJZ3Ltc5jwCr0r7x/1v1aHQxr Gb/6a2k6cYFDmVEYpPFcxiUZ16sHOQFxutoeFyJ5PuK89vOgwUAK8lAogwO+wTS9 f+G+zv2bjYULMCln34ji7M2R0vQaUSOWukT8Pu5GQiRuDIXNcUWVvCS0YrIkkREl 9KzReRwvdo7UVOGXhLWQycZ0MSkyshvlqZr1kLHtSToC3ldparc2/ijj7n/AkSLU qxsz8LwC1uKin1RJyXH0SsrsrwgqufjMfvH4uSw8/zhvdZ4xqDtBNIT/aPO1VN1r igwmp9xeFNMoe/r1r9XLj8EXsNEvIGhLGfRj97pKRZ4vvFu4NOHW2AcB/w85Pfn9 7rUA9Cjz16uJV+Fj1oEqP2dGYwTl3Ef2BUO9yV2APi5BooNZ+6aEPsPJFMgWMKXH cSlQKE4/YxOhih0KxRLsFkjTlDqB3jg4ltLBsXciBUCNEgNxcGUaw3YGF6psz0Ru LpkhYIKl9bV+NLLU0RZaAJOvAXx3nf7g+ZRO12gSlH64cYZY1BHVDbNjkUUXHPw+ DEzihxl9CTb4D4sJHpVVDcyC+IX5odFx7bzb6do59wWbpnOhP7RpCIhb/mabLl+h IK70cW3qcLaZV5O65kpRAnh4UcBKXrQd5R09XqhAcsFoxXw5dPEl8zCJzx10UPBQ RFtlKVwKdI0= =m2HT -----END PGP SIGNATURE----- --0QJ8DMHdp6MMZYsr-- From tjc@ecs.soton.ac.uk Thu Nov 14 02:23: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 41A7F21E81EE for ; Thu, 14 Nov 2013 02:23: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0stghZvvIcba for ; Thu, 14 Nov 2013 02:23:26 -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 53A8121E815A for ; Thu, 14 Nov 2013 02:23:26 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAEANLtp003986; Thu, 14 Nov 2013 10:23:21 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rAEANLtp003986 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1384424602; bh=4j3MJMHcwc0Hg2MZC2cwZtB1mR0=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=xrJCG/yE04qWGQ33tQDDzyn/HmqQUIvTgTGQDSaOATDg66q/37BqCzRGCwB4m/4t3 6V2m9BHOJTbj3rNH3WjxHrXdhxVxA7FtwzIf2cFN9tgUzp3Sp4DYyKK6sX3d2Ui22b 9uQnThRjwVUX0eendnGT/NZ7HnhQZ4ffetoXCXQg= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pADANL0959660585ke ret-id none; Thu, 14 Nov 2013 10:23:22 +0000 Received: from dhcp-162-43.wireless.soton.ac.uk (dhcp-162-43.wireless.soton.ac.uk [152.78.162.43]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAEANJT9002923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Nov 2013 10:23:20 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: <20131114101829.GM81676@Space.Net> Date: Thu, 14 Nov 2013 10:23:20 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> <0154CE2C-C5EF-44FB-9B6D-5B2077267329@ecs.soton.ac.uk> <20131114093318.GG81676@Space.Net> <152585E9-5D19-4F2E-8ED1-32925DE69137@ecs.soton.ac.uk> <20131114101829.GM81676@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pADANL095966058500; tid=pADANL0959660585ke; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rAEANLtp003986 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 14 Nov 2013 10:23:27 -0000 On 14 Nov 2013, at 10:18, Gert Doering wrote: > Hi, >=20 > On Thu, Nov 14, 2013 at 10:14:28AM +0000, Tim Chown wrote: >>>> That was about the NAT64 WKP appearing - or being added to - the = 6724 policy table. There is now a DHCPv6 option for that. >>=20 >> I believe that at least both Cisco and ISC are working on = implementations. >=20 > That sounds like "the server side" - which is needed, but shouldn't = take > a miracle to add. >=20 > More interesting to me would be "client side" :-) Indeed. And always the main problem/challenge with any new DHCPv6 = option. Tim From sander@steffann.nl Thu Nov 14 02:47: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 F07B311E817B for ; Thu, 14 Nov 2013 02:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3K3mDr2Cq9h for ; Thu, 14 Nov 2013 02:46:59 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3FE11E8174 for ; Thu, 14 Nov 2013 02:46:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id CFE964F; Thu, 14 Nov 2013 11:46:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUMSwxNIyOaT; Thu, 14 Nov 2013 11:46:40 +0100 (CET) Received: from [IPv6:2001:9e0:4:12:c1b6:26aa:2245:b3e7] (unknown [IPv6:2001:9e0:4:12:c1b6:26aa:2245:b3e7]) by mail.sintact.nl (Postfix) with ESMTPSA id ED58A8C; Wed, 13 Nov 2013 17:00:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Sander Steffann In-Reply-To: Date: Wed, 13 Nov 2013 17:00:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 10:47:05 -0000 Hi Mikael, Op 13 nov. 2013, om 09:30 heeft Mikael Abrahamsson = het volgende geschreven: > On Tue, 12 Nov 2013, Fred Baker (fred) wrote: >=20 >> My second premise is that any communication attempt directed to a = network, or to a application in a network, that doesn't have a = application in the network that willingly communicates with it is an = attack. >=20 > If it doesn't want to communicate, then it gives connection refused. >=20 > For me, a firewall is a way to have a policy that disallows = connections to "dumb" services "inside" that can't protect itself. = Basically, the firewall means that instead of making the home part of = the Internet, it tries to limit its participation. >=20 > The classic unix model is that services below 1024 are privileged = ports, and there lives most of the "sensitive" services. Userspace = processes live in 1024 and above. >=20 > I believe I voiced opinion that I was fine with disallowing = unsolicited connections from the outside to inside ports below 1024. = This would mean most home services would not be accessible from the = outside, but at least most of the peer-to-peer communication = applications would work without restrictions since these live in the = high ports. >=20 > The draft being discussed, balanced-security tries to identify weak = services. I am fine with this approach as well, since it means the user = doesn't have to do administration of for instance ssh services, but = still blocks communication for the more common weak services. Having all = incoming connections blocked would be a mistake, in my opinion. >=20 > I therefore support the WGLC of the above draft. Well said. I support the WGLC of the above draft as well. Cheers, Sander From marc.lampo.ietf@gmail.com Thu Nov 14 02:50: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 3CB1021E812F for ; Thu, 14 Nov 2013 02:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc-iaEqDXKUc for ; Thu, 14 Nov 2013 02:50:07 -0800 (PST) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 484F321E8090 for ; Thu, 14 Nov 2013 02:50:07 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id g10so1516700vbg.20 for ; Thu, 14 Nov 2013 02:50:06 -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=TdeWHLL81s6a0bfEWqbf5xDSD1MG4OM/f22EWNPceR8=; b=WlLvjAh/olVNYEJKIUEP/SpTumHkK0R7j+JgRCUSEaMdClVBhr2DiA+Ttrsb66esPq S+B0NU6toLyi5Np71ovRvHRwDK18PZOAHWbe7Z2pDs4+SShBn2ieOYtPLWK6akwdm/z9 Kk8ofmXNz8JiQhTSL6xF6vQdXCmy7Un8cddLrSaZSEAc9heHJl3EJK3iXaB14Ci2QfsM +iggnsX/zbuReyYx1UMBQ0XlMhFzpAmRtDXi3Pw0yO8v2sVw9tjyA4fi3C6NEapPtUmy FM0MZ9lSflLpuVw5RFpBwJo7nhp3pzABAucsInL2hkv19tEo8Mn0qTHADuzHDBwmr68H UIng== MIME-Version: 1.0 X-Received: by 10.52.117.129 with SMTP id ke1mr221952vdb.83.1384426206605; Thu, 14 Nov 2013 02:50:06 -0800 (PST) Received: by 10.58.227.66 with HTTP; Thu, 14 Nov 2013 02:50:06 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> Date: Thu, 14 Nov 2013 11:50:06 +0100 Message-ID: From: Marc Lampo To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec548584643379404eb20d8e8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 10:50:08 -0000 --bcaec548584643379404eb20d8e8 Content-Type: text/plain; charset=ISO-8859-1 I realise now that "unsolicited" is a word allowing multiple interpretations (but also used in RFC 6092). But we seem to have got it right. Anyway, the fact that some service, on an internal device, is willing to accept connections on port XYZ, does not, in my opinion, imply that those connections may also come from the outside Internet. Back to the example with the refrigerator : suppose it has a service (port XYZ) that allows it to be queried for its contents. Probably great when one is at home, but does this mean accessible from anywhere on the Internet ? In my opinion : not before the owner has explicitly instructed his CPE to allow incoming connections (RFC 6092, REC-48). Kind regards, On Thu, Nov 14, 2013 at 9:56 AM, Mikael Abrahamsson wrote: > On Thu, 14 Nov 2013, Marc Lampo wrote: > > by "unsolicited" I understand : the initiative to start the communication >> is on the Internet side. So, if RFC6092 is implemented, that kind of >> traffic is not allowed. (Sorry for the confusion on the word) >> > > There was no confusion on my side, I understood you exactly this way. > > It's just that if the device signals to the firewall that it wants to > allow certain ports to be allowed, any SYN packet from the outside is still > unsolicited. It just happens that you've moved the access control from the > host IP stack to an intermediate device that needs to apply the same policy > as the host could have done. > > By accepting SYN packets on port 80, you're soliciting connections. If you > don't want to accept SYN port 80 from everywhere, then don't accept it. > There is little added benefit in having a signaling mechanism to an > intermediate device (firewall) to do the same functionality. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --bcaec548584643379404eb20d8e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I realise now that= "unsolicited" is a word allowing multiple interpretations (but a= lso used in RFC 6092).=A0 But we seem to have got it right.

An= yway, the fact that some service, on an internal device, is willing to acce= pt connections on port XYZ,
does not, in my opinion, imply that those connections may also come f= rom the outside Internet.
Back to the example with the refrigerato= r :
suppose it has a service (port XYZ) that allows it to be queri= ed for its contents.
Probably great when one is at home, but does this mean accessible fro= m anywhere on the Internet ?

In my opinion : not before the ow= ner has explicitly instructed his CPE to allow incoming connections (RFC 60= 92, REC-48).

Kind regards,


<= div class=3D"gmail_quote">On Thu, Nov 14, 2013 at 9:56 AM, Mikael Abrahamss= on <swmike@swm.pp.se> wrote:
On Thu, 14 Nov 2013, Marc = Lampo wrote:

by "unsolicited" I understand : the initiative to start the commu= nication is on the Internet side. =A0So, if RFC6092 is implemented, that ki= nd of traffic is not allowed. =A0(Sorry for the confusion on the word)

There was no confusion on my side, I understood you exactly this way.

It's just that if the device signals to the firewall that it wants to a= llow certain ports to be allowed, any SYN packet from the outside is still = unsolicited. It just happens that you've moved the access control from = the host IP stack to an intermediate device that needs to apply the same po= licy as the host could have done.

By accepting SYN packets on port 80, you're soliciting connections. If = you don't want to accept SYN port 80 from everywhere, then don't ac= cept it. There is little added benefit in having a signaling mechanism to a= n intermediate device (firewall) to do the same functionality.


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se

--bcaec548584643379404eb20d8e8-- From swmike@swm.pp.se Thu Nov 14 02:55:20 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 32FFA11E80F9 for ; Thu, 14 Nov 2013 02:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pyyjTrFLbLX for ; Thu, 14 Nov 2013 02:55:15 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id E72B721E812F for ; Thu, 14 Nov 2013 02:55:14 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C55CAA1; Thu, 14 Nov 2013 11:55:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BFF9D9C; Thu, 14 Nov 2013 11:55:13 +0100 (CET) Date: Thu, 14 Nov 2013 11:55:13 +0100 (CET) From: Mikael Abrahamsson To: Marc Lampo In-Reply-To: Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 10:55:20 -0000 On Thu, 14 Nov 2013, Marc Lampo wrote: > In my opinion : not before the owner has explicitly instructed his CPE > to allow incoming connections (RFC 6092, REC-48). I guess we'll just have to disagree then. I believe the owner should put their devices on a DMZ if they want this behaviour, not that this behaviour should be default. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Thu Nov 14 11:13: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 3C4CB11E8153 for ; Thu, 14 Nov 2013 11:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRCmmRDdU8VA for ; Thu, 14 Nov 2013 11:13:48 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 896BE21E811E for ; Thu, 14 Nov 2013 11:13:42 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id un15so2458490pbc.33 for ; Thu, 14 Nov 2013 11:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5/BdcsK/1YE8w3akVPzeoKNQN3M5MS9rAhohHkfzjlU=; b=cyKNkwADYYt+9bAjg+gZviOVO/+5XskUoEEPmMaZ9ZlZpedWrFUKtGK6DVlOFbsRR2 rw6uJkG+Pqo0QRyG/aRajvV/EYjdGejhHBdEpcihEjcEQFMk7f7NeXOXQIvTMDGNbO4T JekBfAQoOO5cVGE5WezGQzjV1zL42ZiPb2xWsDMQMIU8ph3h+jQmLKEGD5CgWd+HcMui lSF8MfeEWM06fwxKVvHcaPHURedHE4SUAkpTlvTBvCqqjmM6D0Qj9NBGecaf5WTxlMty javfmrxd+dHn8ZPzWG/t75QUvJt8mHvzqhtiT//gErkQHoTt0yl1zRvAYfA8tjOsqYbQ PasA== X-Received: by 10.68.134.200 with SMTP id pm8mr2898677pbb.123.1384456422343; Thu, 14 Nov 2013 11:13:42 -0800 (PST) Received: from [192.168.178.20] (127.199.69.111.dynamic.snap.net.nz. [111.69.199.127]) by mx.google.com with ESMTPSA id xe9sm951900pab.0.2013.11.14.11.13.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:13:41 -0800 (PST) Message-ID: <528520ED.8060902@gmail.com> Date: Fri, 15 Nov 2013 08:13:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 19:13:49 -0000 On 14/11/2013 19:56, Mikael Abrahamsson wrote: ... > Most of the devices today can handle themselves having unfiltered access > to the Internet. Phones and computers are regularily exposed to the > Internet and have sane defaults to handle this. That's a vital point. Mobile devices, including laptops, are potentially exposed to raw Internet, so relying on a separate firewall is totally unsafe. That's not to say that firewalls are pointless - it's helpful if unwanted traffic is dropped at the perimeter - but if your device isn't intrinsically protected, all hope is lost as soon as you step outside the building. In these days of BYOD, unprotected devices will end up infected and will later infect the corporate network, so even screwed-down desktop devices need intrinsic protection. That said, the *informational* draft in question is useful as an example of a possible deployment scenario. Brian From joelja@bogus.com Thu Nov 14 11:22: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 3400A11E8104 for ; Thu, 14 Nov 2013 11:22:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fpH5rh-j6Lo for ; Thu, 14 Nov 2013 11:22:13 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C24CF11E80FA for ; Thu, 14 Nov 2013 11:22:13 -0800 (PST) Received: from 00698a-hsutim.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id rAEJMBqU050426 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 14 Nov 2013 19:22:11 GMT (envelope-from joelja@bogus.com) Message-ID: <528522DD.5010600@bogus.com> Date: Thu, 14 Nov 2013 11:22:05 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Brian E Carpenter , Mikael Abrahamsson References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> <528520ED.8060902@gmail.com> In-Reply-To: <528520ED.8060902@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cqQJjOkOi5KcssVQgXw0cuXFbvVN9dkLg" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Nov 2013 19:22:11 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 19:22:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cqQJjOkOi5KcssVQgXw0cuXFbvVN9dkLg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/14/13, 11:13 AM, Brian E Carpenter wrote: > On 14/11/2013 19:56, Mikael Abrahamsson wrote: > ... >> Most of the devices today can handle themselves having unfiltered acce= ss >> to the Internet. Phones and computers are regularily exposed to the >> Internet and have sane defaults to handle this.=20 >=20 > That's a vital point. Mobile devices, including laptops, are potentiall= y > exposed to raw Internet, so relying on a separate firewall is totally > unsafe. That's not to say that firewalls are pointless - it's helpful i= f > unwanted traffic is dropped at the perimeter - but if your device isn't= > intrinsically protected, all hope is lost as soon as you step outside > the building. In these days of BYOD, unprotected devices will end up > infected and will later infect the corporate network, so even screwed-d= own > desktop devices need intrinsic protection. It is reasonable to suppose that most devices should not assume that a home network is anymore trustworthly or less potentially hostile than any other... Hard crunchy exterior and soft gooey center is best reserved for candy-bars. > That said, the *informational* draft in question is useful as an exampl= e > of a possible deployment scenario. >=20 > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --cqQJjOkOi5KcssVQgXw0cuXFbvVN9dkLg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKFIt4ACgkQ8AA1q7Z/VrIiugCfSJApBjmjhR6RjcE/aW01ubgw 8SAAn0CzjUcxnOwKESpce+Hog9XUedGD =LS9s -----END PGP SIGNATURE----- --cqQJjOkOi5KcssVQgXw0cuXFbvVN9dkLg-- From fred@cisco.com Thu Nov 14 11:39: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 20A2C11E8163 for ; Thu, 14 Nov 2013 11:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.446 X-Spam-Level: X-Spam-Status: No, score=-110.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbylVqxibqcL for ; Thu, 14 Nov 2013 11:39:45 -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 D643921F9A5F for ; Thu, 14 Nov 2013 11:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=967; q=dns/txt; s=iport; t=1384457958; x=1385667558; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D3iFgM4/5Qe1gu+Tyg5wVsjlnSksH4miUIiFh0Bm50Q=; b=Ym9A/qV0K81QEOSRj2Ao9oyYs9KLEjOu5FyiejFRVQqj2Ysmpucly0j0 QHLgfbMb9OXV8mlDFo/3/l2rMk8ZFBPXXMbcxhwI+LLlaS0MWfeRPmjR7 E01Gyba0sqZXPRhVKKxl1J6bUkxSx2KjghKmefbyZrMyIeEWq6a8MvqsV c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAIElhVKtJXG8/2dsb2JhbABbgweBC78ZgSEWdIIlAQEBAwFlFAULAgEIDjgyJQIEDgUOh20GwGKPXweDIIERA5AwgTCGMJIMgyiCKg X-IronPort-AV: E=Sophos;i="4.93,701,1378857600"; d="asc'?scan'208";a="284927345" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2013 19:39:18 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAEJdIh0007547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 19:39:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 13:39:17 -0600 From: "Fred Baker (fred)" To: Mikael Abrahamsson Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO4XE0jhYl6Coh40iOo9fsCqroFw== Date: Thu, 14 Nov 2013 19:39:17 +0000 Message-ID: <00D470BB-E92E-4E1E-A293-B715A4C22818@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_E2F91391-545E-4B06-A9B7-801CB697D0C9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 19:39:57 -0000 --Apple-Mail=_E2F91391-545E-4B06-A9B7-801CB697D0C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2013, at 12:56 AM, Mikael Abrahamsson wrote: > By accepting SYN packets on port 80, you're soliciting connections.=20 No. You are allowing someone else to successfully solicit (SYN) a = connection to you. Sending a SYN is soliciting a connection. --Apple-Mail=_E2F91391-545E-4B06-A9B7-801CB697D0C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFShSbjbjEdbHIsm0MRAnKDAKDCQVPEOcY56yDO0T3RnKJR9bwXwQCeJ9CX INzn3u0cqbVeKcgQDcXs1f8= =53l+ -----END PGP SIGNATURE----- --Apple-Mail=_E2F91391-545E-4B06-A9B7-801CB697D0C9-- From joelja@bogus.com Thu Nov 14 11:48: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 8DD4321E80EC for ; Thu, 14 Nov 2013 11:48:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6TV2Kwmm7jv for ; Thu, 14 Nov 2013 11:48:15 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40521E80B6 for ; Thu, 14 Nov 2013 11:48:15 -0800 (PST) Received: from 00698a-hsutim.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id rAEJm8xW050722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 14 Nov 2013 19:48:08 GMT (envelope-from joelja@bogus.com) Message-ID: <528528F2.9060908@bogus.com> Date: Thu, 14 Nov 2013 11:48:02 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Mikael Abrahamsson References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> <00D470BB-E92E-4E1E-A293-B715A4C22818@cisco.com> In-Reply-To: <00D470BB-E92E-4E1E-A293-B715A4C22818@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tx9BphUFJsMvcihTMRelFvRn9Rx901P51" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Nov 2013 19:48:08 +0000 (UTC) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 19:48:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tx9BphUFJsMvcihTMRelFvRn9Rx901P51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/14/13, 11:39 AM, Fred Baker (fred) wrote: >=20 > On Nov 14, 2013, at 12:56 AM, Mikael Abrahamsson > wrote: >=20 >> By accepting SYN packets on port 80, you're soliciting connections.=20 >=20 > No. You are allowing someone else to successfully solicit (SYN) a conne= ction to you. Sending a SYN is soliciting a connection. If you are a listener new connections are unsolicited. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Tx9BphUFJsMvcihTMRelFvRn9Rx901P51 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKFKPMACgkQ8AA1q7Z/VrIY0wCfaImbGRBp25zRX3wJdXLCdfu2 pXUAniGqQQQHPrpFSSaCRnncUnyGGJTN =zKmx -----END PGP SIGNATURE----- --Tx9BphUFJsMvcihTMRelFvRn9Rx901P51-- From achatz@forthnet.gr Fri Nov 15 10:03: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 3FF0B11E81DC for ; Fri, 15 Nov 2013 10:03:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34PAh4pxwmtG for ; Fri, 15 Nov 2013 10:03:12 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86F11E8128 for ; Fri, 15 Nov 2013 10:03:11 -0800 (PST) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id rAFI39Wt006264 for ; Fri, 15 Nov 2013 20:03:09 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id rAFI39re002677 for ; Fri, 15 Nov 2013 20:03:09 +0200 Received: from [192.168.1.2] (46.246.152.228.dsl.dyn.forthnet.gr [46.246.152.228]) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id rAFI2o7e006234; Fri, 15 Nov 2013 20:02:50 +0200 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnet.gr; spf=pass Authentication-Results: MX-IN-01.forthnet.gr header.from=achatz@forthnet.gr; sender-id=pass Message-ID: <528661C5.3060005@forthnet.gr> Date: Fri, 15 Nov 2013 20:02:45 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22 MIME-Version: 1.0 To: v6ops@ietf.org References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> In-Reply-To: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 15 Nov 2013 18:03:17 -0000 First of all i would like to note that i find this draft very interesting, giving food for thought. If this was going to be a BCP then i would have major objections. Since it's informational, it would be nice to see it published. A general comment: Personally i believe it's too early to decide on anything about IPv6 default security, especially when referring to devices "protecting" grandmas. The percentage of IPv6 eyeballs is way too low to change the current stateful "kind-of-protection", just based on the number/type of recorded ipv6 attacks. I don't see how can someone guarantee that in one year from now when a new exploit will have been found, it will be easily blocked using this type of protection. Threats/attacks evolve at the same speed (or even faster) than the measures we take against them and moving to a default open policy gives them the advantage of knowing how to exploit these weaknesses easier. Instead of focusing on http/sql/rpc/etc attacks we might see other types of attacks rising from the bad guys, since we give them the space to do so. Also, having some means of a centralized homenet security device can be proved valuable, when all "protected" hosts are of different (and sometimes unknown) capabilities. So, although i support this, i would like to see a note warning about some of the above dangers and noting that extra caution is to be used when following this. And some specific comments: > The blocked inbound ports is expected to > be updated as threats come and go. > This document is applicable to off-the-shelves CPE as well to managed > Service Provider CPE or for mobile Service Providers (where it can be > centrally implemented). > The basic goal is to provide a pre-defined security policy which aims > to block known harmful traffic and allow the rest, restoring as much > of end-to-end communication as possible. This pre-defined policy can > be centrally updated and could also be a member of a security policy > menu for the subscriber. > These example lists will probably evolve with the time as new > protocols and new threats appear. The update of the specific rules > could be done by firmware upgrade, policy update (for example by > Broadband Forum TR-69). Experience has shown than CPE updates from vendors are much slower than host updates, so i would expect that new threats would take a while to be fixed in the firmware. TR-069 would solve that only for managed CPEs, assuming a policy could be applied. > 3. Rule ProtectWeakServices: drop all inbound and outbound packets > whose layer-4 destination is part of a limited set (see > Section 3.2, the intent is to protect against the most common > unauthorized access and avoid propagation of worms (even if the > latter is questionable in IPv6); an advanced residential user > should be able to modify this pre-defined list; Set is limited because of a specific reason? hw resources? Comparing this implementation (default permit) with an opposite one (default deny), i would see much more deny entries in this than permit entries in the other. I can't predict the possible growth of each one, but i would give much more chances to denies than to permits. > The authors of the documents believe and the Swisscom deployment > shows that the following attack are mostly stopped: > > o Unauthorized access because vulnerable ports are blocked It would be nice to have a report with some numbers backing this up. -- Tassos Fred Baker wrote on 10/11/2013 21:00: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security. Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Fri Nov 15 10:36: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 B6DC711E8248 for ; Fri, 15 Nov 2013 10:36: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWuNwBqOOJZG for ; Fri, 15 Nov 2013 10:35:51 -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 758C911E81DF for ; Fri, 15 Nov 2013 10:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1384540515; x=1385750115; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bEoKPMcTz0ZSvztGlGTE8rtiov0s7zjnLt1ZybpR68c=; b=iVP7t08V0VZPgjkFaMG2Lb+ZCu1joo1ADmm+K/Eq+FIpNK99Bp1RimPP H2QuQyFd8nzmcArME3bsNKSZrGcw9DdQvxCkS2kkrbUkfZ/AEi/aKe8Lj aomhp5d3Cilzr1BvZMH8Q9t42RZIVpMzxZ8gJjqXL9FXTWX+4sSxlDC2s E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAPpnhlKtJXG//2dsb2JhbABZgwc4U78qgSoWdIIlAQEBAwFlGQsCAQhGMiUCBBMOh20GwSGPcIMggREDkDCBMIYwkg2DKIIq X-IronPort-AV: E=Sophos;i="4.93,709,1378857600"; d="asc'?scan'208";a="285363682" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 15 Nov 2013 18:35:14 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAFIZBH1024865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Nov 2013 18:35:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 12:35:11 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO4jFqwFfRrQERTkW19poqfBMEFA== Date: Fri, 15 Nov 2013 18:35:11 +0000 Message-ID: <2BED1CEF-FBF2-490B-8468-8024BCBEC1F0@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <528661C5.3060005@forthnet.gr> In-Reply-To: <528661C5.3060005@forthnet.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_E547FAE9-A9A2-4892-A179-DBC278B176A2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 15 Nov 2013 18:36:04 -0000 --Apple-Mail=_E547FAE9-A9A2-4892-A179-DBC278B176A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 15, 2013, at 10:02 AM, Tassos Chatzithomaoglou = wrote: > So, although i support this, i would like to see a note warning about = some of the above dangers and noting that extra caution is to be used = when following this. Thanks. Again, speaking as a participant. Where I most scratch my head is that the threat the firewall presumably = is intended to defend against, and the asset it is trying to defend, is = not usually related to a protocol. If we decide that a given protocol = number or port number is "universally OK", such as RFC 6092's comments = on ESP/AH/IKE, one can expect port-agile attacks to use that port number = for whatever protocol they use. If we say that we want a specified = server to act as a listener for a protocol, such as a web server for = http/https, that doesn't imply that all devices implementing listeners = should be exposed as a matter of policy (if you have a Canon MP620 = series printer or a Cisco telephone, and its address is X.X.X.X, open = http://X.X.X.X, and ask yourself if that's information you want = available to the world). So, blocking a couple of ports doesn't seem to accomplish much from a = security perspective. I'm not sure what I would call "security" in this = draft, much less "balanced". What the draft does, as near as I can tell, = is give service providers something that somebody called a firewall, so = that they can tell their customers that have the presence of a firewall = as a market requirement that they are deploying a firewall, but = depending on their customers to be dumb enough to not realize that the = firewall doesn't secure anything. BTW, as chair, I have asked for a security directorate review of this = draft. --Apple-Mail=_E547FAE9-A9A2-4892-A179-DBC278B176A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFShmldbjEdbHIsm0MRAvJUAJ9gG5n1d020ZAb7f6a21EilFMwZUgCeIDgS 9T0XSmFcswKrfUZc83LBpxo= =lAJX -----END PGP SIGNATURE----- --Apple-Mail=_E547FAE9-A9A2-4892-A179-DBC278B176A2-- From cb.list6@gmail.com Fri Nov 15 10:50: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 3EE0611E821B for ; Fri, 15 Nov 2013 10:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2ga0c464C8O for ; Fri, 15 Nov 2013 10:50:11 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5923011E8210 for ; Fri, 15 Nov 2013 10:49:33 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id m15so3843232wgh.6 for ; Fri, 15 Nov 2013 10:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jycGwhl1UBAOro3ws/8tURLaFaN+oYPe6/07ludNxIQ=; b=AqMdDidD1I9ifRtJtENhLvfsYdpD7ZchdCk/gg6IDYhoTqMcTe6w4m/lYV5fXCy5sm 81YmQlcemnWMOe+Mrl7HZVXch8qBJwuBxkbjMQcH3B7gkqofq/ULKFszAQ2mCYa0hDvj X+zaYnT/HMKNe8FQ4oS7Ew+LAnTOVyJ+S+LKHdUiPfb6hFpGRQMm/R8eva3CzhxJZqmj veXkt3dN2vIlfQsBKnxg2UF2taYjmmqZo3kZA+oo1cP6vOJAsgwUnX4ET/XclQnD6+X/ hIiHtvpAboTelIOX4SomcM02LaIqAnZJ2JwLjAY4/Srj+PJED+xCJCKk0A/oaFfdS4jJ MW6Q== MIME-Version: 1.0 X-Received: by 10.180.183.72 with SMTP id ek8mr8397645wic.49.1384541372535; Fri, 15 Nov 2013 10:49:32 -0800 (PST) Received: by 10.217.58.133 with HTTP; Fri, 15 Nov 2013 10:49:32 -0800 (PST) In-Reply-To: <2BED1CEF-FBF2-490B-8468-8024BCBEC1F0@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <528661C5.3060005@forthnet.gr> <2BED1CEF-FBF2-490B-8468-8024BCBEC1F0@cisco.com> Date: Fri, 15 Nov 2013 10:49:32 -0800 Message-ID: From: "cb.list6" To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 15 Nov 2013 18:50:14 -0000 On Fri, Nov 15, 2013 at 10:35 AM, Fred Baker (fred) wrote: > > On Nov 15, 2013, at 10:02 AM, Tassos Chatzithomaoglou wrote: > >> So, although i support this, i would like to see a note warning about so= me of the above dangers and noting that extra caution is to be used when fo= llowing this. > > Thanks. > > Again, speaking as a participant. > > Where I most scratch my head is that the threat the firewall presumably i= s intended to defend against, and the asset it is trying to defend, is not = usually related to a protocol. If we decide that a given protocol number or= port number is "universally OK", such as RFC 6092's comments on ESP/AH/IKE= , one can expect port-agile attacks to use that port number for whatever pr= otocol they use. If we say that we want a specified server to act as a list= ener for a protocol, such as a web server for http/https, that doesn't impl= y that all devices implementing listeners should be exposed as a matter of = policy (if you have a Canon MP620 series printer or a Cisco telephone, and = its address is X.X.X.X, open http://X.X.X.X, and ask yourself if that's inf= ormation you want available to the world). > > So, blocking a couple of ports doesn't seem to accomplish much from a sec= urity perspective. I'm not sure what I would call "security" in this draft,= much less "balanced". What the draft does, as near as I can tell, is give = service providers something that somebody called a firewall, so that they c= an tell their customers that have the presence of a firewall as a market re= quirement that they are deploying a firewall, but depending on their custom= ers to be dumb enough to not realize that the firewall doesn't secure anyth= ing. > Network operators who have deployed this strategy outlined in the draft have penned the draft, they have to deal with the strain on their network and helpdesk calls related to being hacked. I believe the point of the draft is to share deployment experience that there is no material change to the relevant network provider metrics related to those costs of hacking. If i understanding the scenario correctly, Swisscom had IPv4 NAT CPE deployed with "stateful connection inspection" by default They deployed IPv6 on a large scale without "stateful connection inspection" for IPv6 and the relevant metrics of attack traffic and helpdesk calls have not changed. This is not a matter of theory, this a matter of network operators sharing operational experience for the betterment of other network operators. CB > BTW, as chair, I have asked for a security directorate review of this dra= ft. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Fri Nov 15 11:23: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 B35AA11E8174 for ; Fri, 15 Nov 2013 11:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.185 X-Spam-Level: X-Spam-Status: No, score=-110.185 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvIq7lYVXUJu for ; Fri, 15 Nov 2013 11:23:07 -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 4B05911E810D for ; Fri, 15 Nov 2013 11:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3915; q=dns/txt; s=iport; t=1384543383; x=1385752983; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ARdo1M13js1ql+5XXlPUPliaD0le4DaMNVo9QzRnRQ4=; b=B1BAalUNirXPGvVwOYwkAkEqi3bYA6YULY3ZUmnpcMSqjoMEDvl2rdOZ fDAwXeBPcqk63nJttp9wDOHM4y7PmaECqUXL8lpRsUtYU8YFygozL22C9 JMISa/fpdUAdLtcrhgmDt+5nRIrpLj5lczfhtN/GkQyy7ZOd6sc3HJVL6 E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FALVzhlKtJV2Z/2dsb2JhbABZgwc4U78qgSoWdIIlAQEBAwEBAQFiCQsFCwIBCBguIQYLJQIEDgUOh2EDCQYNt00NiUQEjHOCdgeDIIERA5AwgTCERYFrjFWFOIMogio X-IronPort-AV: E=Sophos;i="4.93,709,1378857600"; d="asc'?scan'208";a="285481994" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2013 19:23:02 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFJN2QR013882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 19:23:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 13:23:02 -0600 From: "Fred Baker (fred)" To: "cb.list6" Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC Thread-Index: AQHO4jgZrvtubQWqEEOgPb+wOW623g== Date: Fri, 15 Nov 2013 19:23:02 +0000 Message-ID: <5FC70D46-B3DE-4398-89A8-8561CDEAC5AA@cisco.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <528661C5.3060005@forthnet.gr> <2BED1CEF-FBF2-490B-8468-8024BCBEC1F0@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_25EA0458-CAD5-43AC-9A2B-B7D50FBD0DE7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 15 Nov 2013 19:23:12 -0000 --Apple-Mail=_25EA0458-CAD5-43AC-9A2B-B7D50FBD0DE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Well, that's one of the things the draft says. It also describes a = security model that the IETF is intended to say is adequate for some = purpose. It's that security model that I'm commenting on. On Nov 15, 2013, at 10:49 AM, cb.list6 wrote: > On Fri, Nov 15, 2013 at 10:35 AM, Fred Baker (fred) = wrote: >>=20 >> On Nov 15, 2013, at 10:02 AM, Tassos Chatzithomaoglou = wrote: >>=20 >>> So, although i support this, i would like to see a note warning = about some of the above dangers and noting that extra caution is to be = used when following this. >>=20 >> Thanks. >>=20 >> Again, speaking as a participant. >>=20 >> Where I most scratch my head is that the threat the firewall = presumably is intended to defend against, and the asset it is trying to = defend, is not usually related to a protocol. If we decide that a given = protocol number or port number is "universally OK", such as RFC 6092's = comments on ESP/AH/IKE, one can expect port-agile attacks to use that = port number for whatever protocol they use. If we say that we want a = specified server to act as a listener for a protocol, such as a web = server for http/https, that doesn't imply that all devices implementing = listeners should be exposed as a matter of policy (if you have a Canon = MP620 series printer or a Cisco telephone, and its address is X.X.X.X, = open http://X.X.X.X, and ask yourself if that's information you want = available to the world). >>=20 >> So, blocking a couple of ports doesn't seem to accomplish much from a = security perspective. I'm not sure what I would call "security" in this = draft, much less "balanced". What the draft does, as near as I can tell, = is give service providers something that somebody called a firewall, so = that they can tell their customers that have the presence of a firewall = as a market requirement that they are deploying a firewall, but = depending on their customers to be dumb enough to not realize that the = firewall doesn't secure anything. >>=20 >=20 > Network operators who have deployed this strategy outlined in the > draft have penned the draft, they have to deal with the strain on > their network and helpdesk calls related to being hacked. >=20 > I believe the point of the draft is to share deployment experience > that there is no material change to the relevant network provider > metrics related to those costs of hacking. >=20 > If i understanding the scenario correctly, Swisscom had IPv4 NAT CPE > deployed with "stateful connection inspection" by default >=20 > They deployed IPv6 on a large scale without "stateful connection > inspection" for IPv6 and the relevant metrics of attack traffic and > helpdesk calls have not changed. >=20 > This is not a matter of theory, this a matter of network operators > sharing operational experience for the betterment of other network > operators. >=20 > CB >=20 >> BTW, as chair, I have asked for a security directorate review of this = draft. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 --Apple-Mail=_25EA0458-CAD5-43AC-9A2B-B7D50FBD0DE7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFShnSUbjEdbHIsm0MRAp7aAJoC5aEsUvcu1Aw916dVnX7I8CdSLQCgmWE1 mBDHSZ4ZqNnjGjLAljGKLlc= =Hnsi -----END PGP SIGNATURE----- --Apple-Mail=_25EA0458-CAD5-43AC-9A2B-B7D50FBD0DE7-- From markzzzsmith@yahoo.com.au Fri Nov 15 22:06: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 41A6511E8125 for ; Fri, 15 Nov 2013 22:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZb9I2RrmXNt for ; Fri, 15 Nov 2013 22:06:21 -0800 (PST) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 3215F11E8135 for ; Fri, 15 Nov 2013 22:06:17 -0800 (PST) Received: from [98.139.212.152] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2013 06:06:15 -0000 Received: from [98.139.212.241] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2013 06:06:15 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 16 Nov 2013 06:06:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 579666.83402.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 36489 invoked by uid 60001); 16 Nov 2013 06:06:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1384581975; bh=hGrg/WKZg/qZd3jHtz/hqJvT1wKaDqOh5v6VrqzOjMA=; 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=By/lUsOFpqjWvJVuZJCAAR3fd/12DWbJDMFlJwcW2r2z06ynnnTtueBm8DlHvXDJn206lvo+2KFzYG4Upr+WF4CulvtRSiNE9D0f0leAT3EodCWKdccD7DI40bZlrrXdsADufpD1MODc5hNb7RSqRnYdR/ksy3m5Rz/ErvvLGqM= 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=MIBaBbUUmmXSktxH/Pg7lBY8IjjfvpraOhl4HX/DkZip8j753znsbsFIdDeSyXzeYaq0uOcUbrinVQlH0vpq55dEi0Oj904bXeiRNsKxLk1uwjvhKKDve/TDFaZjjdiTr8JwjKIhx2KGHCAVFAd8lV4OfxsR7XYxqp2aoTIYzK8=; X-YMail-OSG: g9tsym8VM1mZ.35jXGomWdYzfnutqqpdvQ2pY3OXvfUlLPS HD8YUuBCz38SUmydCOcCuSwT20cT..WjISrcRdPJ31KBv8l7RXPEbNTqfDn. rVGWGwOHURqXhRiAmwjJFFV4YZ8SbWmMfSCQxb1QlTlhwsa_F8dKxHxjpBlq Ymijlobeho48gBStUrkgGBk6W.8Ylm_HmzzmwXUNNm7gHzsEE1XzCofFiSBS dGui04cALJy8Nm0w8Ni45byODWRBwyclE.jiJCvd2AWCE2iQ4eUgkkDx0ufr FQgpVGkSoUwdnoM_HFqqzXokdbefGSKIQUuZ6Hc6mbE8sKQnxL2P5dNt_whB cXXjs_A_41HFni0DscUmS10UfwGe4ghybXaR75IAXV.7lMDKQJbIzUs8h9C7 yEEaxCSvqxoBlqtLDIAFmCYxUN5NA5l_CY1SQN.dRbswkCvnwBHNp.Mig_O2 Tg5G_5kGvfSj25rynOe6bOvBVC.xPKjkEbPHGZm4QOoZji9pdjuE4PLPllM. WKzZR3JM._.a88maU27t6f5WXQBxtjGZx9eSf2v2UosnEu5gWBKcl4yvHFfI fM8ACBw.LQKDSpPGwuenGbWPE3JrE3HwU1l9zMVnEoCo- Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Fri, 15 Nov 2013 22:06:14 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBjYi5saXN0NiA8Y2IubGlzdDZAZ21haWwuY29tPgo.IFRvOiBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFNhdHVyZGF5LCAxNiBOb3ZlbWJlciAyMDEzIDU6NDkgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWJhbGFuY2VkLWlwdjYtc2VjdXJpdHkgV0dMQwo.IAo.IE9uIEZyaSwgTm92IDE1LCAyMDEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.163.597 References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <528661C5.3060005@forthnet.gr> <2BED1CEF-FBF2-490B-8468-8024BCBEC1F0@cisco.com> Message-ID: <1384581974.34052.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Fri, 15 Nov 2013 22:06:14 -0800 (PST) From: Mark ZZZ Smith To: "cb.list6" , "Fred Baker \(fred\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 06:06:29 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: cb.list6 =0A> To: Fred Baker (fred) =0A> Cc: "v6ops@ietf.org WG= " =0A> Sent: Saturday, 16 November 2013 5:49 AM=0A> Subject= : Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC=0A> =0A> On Fri,= Nov 15, 2013 at 10:35 AM, Fred Baker (fred) =0A> wrote:= =0A>> =0A>> On Nov 15, 2013, at 10:02 AM, Tassos Chatzithomaoglou =0A> wrote:=0A>> =0A>>> So, although i support this, i would = like to see a note warning about =0A> some of the above dangers and noting = that extra caution is to be used when =0A> following this.=0A>> =0A>> Than= ks.=0A>> =0A>> Again, speaking as a participant.=0A>> =0A>> Where I most = scratch my head is that the threat the firewall presumably is =0A> intended= to defend against, and the asset it is trying to defend, is not usually = =0A> related to a protocol. If we decide that a given protocol number or po= rt number =0A> is "universally OK", such as RFC 6092's comments on ESP/AH/I= KE, =0A> one can expect port-agile attacks to use that port number for what= ever protocol =0A> they use. If we say that we want a specified server to a= ct as a listener for a =0A> protocol, such as a web server for http/https, = that doesn't imply that all =0A> devices implementing listeners should be e= xposed as a matter of policy (if you =0A> have a Canon MP620 series printer= or a Cisco telephone, and its address is =0A> X.X.X.X, open http://X.X.X.X= , and ask yourself if that's information you =0A> want available to the wor= ld).=0A>> =0A>> So, blocking a couple of ports doesn't seem to accomplish = much from a =0A> security perspective. I'm not sure what I would call "secu= rity" in =0A> this draft, much less "balanced". What the draft does, as nea= r as I =0A> can tell, is give service providers something that somebody cal= led a firewall, =0A> so that they can tell their customers that have the pr= esence of a firewall as a =0A> market requirement that they are deploying a= firewall, but depending on their =0A> customers to be dumb enough to not r= ealize that the firewall doesn't secure =0A> anything.=0A>> =0A> =0A> Netwo= rk operators who have deployed this strategy outlined in the=0A> draft have= penned the draft, they have to deal with the strain on=0A> their network a= nd helpdesk calls related to being hacked.=0A> =0A> I believe the point of = the draft is to share deployment experience=0A> that there is no material c= hange to the relevant network provider=0A> metrics related to those costs o= f hacking.=0A>=A0=0A> If i understanding the scenario correctly, Swisscom h= ad IPv4 NAT CPE=0A=0A> deployed with "stateful connection inspection" by de= fault=0A> =0A> They deployed IPv6 on a large scale without "stateful connec= tion=0A> inspection"=A0 for IPv6 and the relevant metrics of attack traffic= and=0A> helpdesk calls have not changed.=0A>=A0=0A=0AFrom the draft,=A0=0A= =0A"This model has been deployed successfully=0A=A0 =A0in Switzerland by Sw= isscom without any known security incident."=0A=0AThis is not evidence that= this measure has been of any effect at all. Equally, IPv6's billions of bi= llions times larger address space could also be the reason there has been n= o known security incident, as unsolicited inbound attacks are far, far less= likely to be successful. Finally, there may have been a security incident,= but Swisscom aren't aware of it. This is the "Correlation does not imply c= ausation" trap.=0A=0ATo support their argument, I'd be looking to see the p= acket captures of the IPv6 packets aimed towards their subscribers, for the= ports that they've blocked, before and after they've been blocked, to show= that this security measure has been effective. This would have to be for I= Pv6 addresses that actually exist, otherwise it isn't evidence that an atta= ck was prevented, just evidence that a packet was pro-actively dropped earl= ier than it would have been without the CPE filter.=0A=0AI wouldn't object = to this being published as an Information RFC, but I think it must only det= ail exactly what Swisscom did and their rational for doing so, and make it = very clear that it is only what Swisscom did, not what the IETF suggest and= recommend. To me it reads too much like the latter.=0A=0A=0AIf this is to = be published, then I think the following is an example of how. I don't real= ly agree with what Comcast did (it's a man-in-the-middle attack), however I= agree that it is useful to publish how one particular ISP has solved a par= ticular problem.=0A=0A=0AComcast's Web Notification System Design=0Ahttp://= tools.ietf.org/html/rfc6108=0A=0A=0A=0ARegards,=0AMark.=0A=0A=0A> This is n= ot a matter of theory, this a matter of network operators=0A> sharing opera= tional experience for the betterment of other network=0A> operators.=0A> = =0A> CB=0A> =0A>> BTW, as chair, I have asked for a security directorate r= eview of this =0A> draft.=0A>> =0A>> _____________________________________= __________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.= ietf.org/mailman/listinfo/v6ops=0A> =0A>> =0A> ____________________________= ___________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://w= ww.ietf.org/mailman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Fri Nov 15 22:30:20 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 BE86E11E8125 for ; Fri, 15 Nov 2013 22:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3xGrsOJZFk8 for ; Fri, 15 Nov 2013 22:30:15 -0800 (PST) Received: from nm46-vm10.bullet.mail.bf1.yahoo.com (nm46-vm10.bullet.mail.bf1.yahoo.com [216.109.114.203]) by ietfa.amsl.com (Postfix) with ESMTP id 038F311E815A for ; Fri, 15 Nov 2013 22:30:14 -0800 (PST) Received: from [66.196.81.174] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2013 06:30:14 -0000 Received: from [98.139.212.216] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2013 06:30:14 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 16 Nov 2013 06:30:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 410133.39092.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 4318 invoked by uid 60001); 16 Nov 2013 06:30:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1384583414; bh=eQqSBx4Y3PWN/+3KfWoEhdIAkTzUXjPhA4kXzU67fuw=; 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=t1LZGGFXpgmhN4P5m3kRW5qpEit7Ez94G4aSdQgUnlnUaYtYBl9bd2r4Tl4Ys+KbeugKSgghCFSHdfTHN1OSB4TNwCQi1OJ/By7u4gl3rfG6OEvkU04HAb8JJhlnZd8DFlAntDZKxovfSLjqSVLoEsDxf2o9YO+GbYCKuY2Lk8Y= 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=lcV2vga9qA5khjy2tl3Nk+l3CnUVOnHsWNgBtqcM1oqCD7eL6pPPH9ba2RSiXctueZrSW7XrzvommKj1IFrcJgf1Z68zi8EBX4YuQN5L0KbWdyVo+1yyO9KTv39d+YBkc/4cG2ObvnF8Tfb/+YrYnu5r9JQSDvZCcz5POzMaCbI=; X-YMail-OSG: xz5pfHAVM1mP1TlZGkY0FCMhsgUJCU3K2r8vFU_rH002bnL 6vo2H2bOZp9yC5G1xDSw0Xo6kz2iFKZwZMq3pPAXCgybuDQ3OesroMXQxwv_ X9dyi2u.cBKT51jrepssfusWmkN3QargcGMZiyU1y8_gJVL3oGOnFSteW9LS ESOcEPfhdBCJuj_Qcte567Zn4qDLzt5D_Z9zUb19W7QUoHwYNn0mYp9iXfYR Al9Ry7mEZ_uIdtWFctDIo8EwbXYBka2uEZEVe1wG76fqJCb2vZq.dJrKarIP I_zinmFQH1qRpI7wSulpV0J2Zacv.V.4JlRFH4daMUt2vbT062Bhf_gmep09 eh11gpLDgcrQLTPZuT4kXZmyH0tyIsax5lmu99rmMVezNAx1JcD3VgTtX1gS frJByv1nYQaMk5L8XSc9qTVp0Lsm3le.ViTzL45tQp9jma2NKLFkJLxuJBLl f8f5uNxZXzE_7n5QsXTlg9bIGUMc0Gv3k3VhyT8nMP0jKIXbNAek6OS41Idt wuLAfqb0EAB0tORrSL0ysc_Bt2_AoDy2GJZruREAjz1PJm_83tNRykRKyYz0 K6TShyCN7frWGta5.jCPw8dyBM_09qbav54G0Frsax_c- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Fri, 15 Nov 2013 22:30:13 PST X-Rocket-MIMEInfo: 002.001, Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IE1hcmMgTGFtcG8gPG1hcmMubGFtcG8uaWV0ZkBnbWFpbC5jb20.Cj5UbzogTWlrYWVsIEFicmFoYW1zc29uIDxzd21pa2VAc3dtLnBwLnNlPiAKPkNjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBUaHVyc2RheSwgMTQgTm92ZW1iZXIgMjAxMyA5OjUwIFBNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWJhbGFuY2VkLWlwdjYtc2VjdXJpdHkgV0dMQwo.IAo.Cj4KPkkgcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.163.597 References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> Message-ID: <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Fri, 15 Nov 2013 22:30:13 -0800 (PST) From: Mark ZZZ Smith To: Marc Lampo , Mikael Abrahamsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 06:30:21 -0000 =0A>________________________________=0A> From: Marc Lampo =0A>To: Mikael Abrahamsson =0A>Cc: "v6ops@ietf= .org WG" =0A>Sent: Thursday, 14 November 2013 9:50 PM=0A>S= ubject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC=0A> =0A>= =0A>=0A>I realise now that "unsolicited" is a word allowing multiple interp= retations (but also used in RFC 6092).=A0 But we seem to have got it right.= =0A>=0A>Anyway, the fact that some service, on an internal device, is willi= ng to accept connections on port XYZ,=0A>does not, in my opinion, imply tha= t those connections may also come from the outside Internet.=0A>Back to the= example with the refrigerator :=0A>suppose it has a service (port XYZ) tha= t allows it to be queried for its contents.=0A=0A>Probably great when one i= s at home, but does this mean accessible from anywhere on the Internet ?=0A= >=0A>In my opinion : not before the owner has explicitly instructed his CPE= to allow incoming connections (RFC 6092, REC-48).=0A>=0A=0AActually, I thi= nk you're probably going to want your refrigerator to be able to access the= Internet, as well as your toaster, answering machine, rice cooker, washing= machine etc.=0A=0AI think appliances, if they aren't already, are going to= become computers, with as much done via software/firmware as possible, ins= tead of hardware, because hardware is much harder and more expensive to cha= nge, both during development and after it is sold to the customer.=0A=0AHow= ever, software/firmware is still hard to change if the customer has to eith= er take it back to the manufacturer, or plug a PC or USB stick into it to u= pdate the software/firmware. Having the device be able to update itself ove= r the Internet will be both much more user/customer friendly and much cheap= er for the manufacturer.=A0=0A=0ASo manufacturers have an incentive to make= their appliances be able to attach to the Internet, and their customers ha= ve an incentive to attach them. As with tablets and smartphones, the manufa= cturer won't be able to vouch for the existence of any upstream network "fi= rewalls", nor will they successfully be able to ask the customer of their e= xistence,=A0so the manufacturer will have to assume the worst, and therefor= e harden the appliance against publicly addressed unfettered Internet acces= s.=0A=0ARegards,=0AMark.=0A From achatz@forthnet.gr Thu Nov 14 14:00: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 AD13D21E80AF for ; Thu, 14 Nov 2013 14:00:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgd5VzCMSZgS for ; Thu, 14 Nov 2013 14:00:50 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id EBE6B11E810D for ; Thu, 14 Nov 2013 14:00:49 -0800 (PST) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id rAEM0lAk018897 for ; Fri, 15 Nov 2013 00:00:47 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id rAEM0lnX014828 for ; Fri, 15 Nov 2013 00:00:47 +0200 Received: from [192.168.1.2] (46.246.212.255.dsl.dyn.forthnet.gr [46.246.212.255]) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id rAEM0k63017394; Fri, 15 Nov 2013 00:00:47 +0200 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnet.gr; spf=pass Authentication-Results: MX-IN-01.forthnet.gr header.from=achatz@forthnet.gr; sender-id=pass Message-ID: <5285480A.9080001@forthnet.gr> Date: Fri, 15 Nov 2013 00:00:42 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22 MIME-Version: 1.0 To: v6ops@ietf.org References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> In-Reply-To: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 17 Nov 2013 08:27:53 -0800 Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 14 Nov 2013 22:00:55 -0000 First of all i would like to note that i find this draft very interesting, giving food for thought. If this was going to be a BCP then i would have major objections. Since it's informational, it would be nice to see it published. A general comment: Personally i believe it's too early to decide on anything about IPv6 default security, especially when referring to devices "protecting" grandmas. The percentage of IPv6 eyeballs is way too low to change the current stateful "kind-of-protection", just based on the number/type of recorded ipv6 attacks. I don't see how can someone guarantee that in one year from now when a new exploit will have been found, it will be easily blocked using this type of protection. Threats/attacks evolve at the same speed (or even faster) than the measures we take against them and moving to a default open policy gives them the advantage of knowing how to exploit these weaknesses easier. Instead of focusing on http/sql/rpc/etc attacks we might see other types of attacks rising from the bad guys, since we give them the space to do so. Also, having some means of a centralized homenet security device can be proved valuable, when all "protected" hosts are of different (and sometimes unknown) capabilities. So, although i support this, i would like to see a paragraph warning about some of the above dangers and noting that extra caution is to be used when following this. And some specific comments: > The blocked inbound ports is expected to > be updated as threats come and go. > This document is applicable to off-the-shelves CPE as well to managed > Service Provider CPE or for mobile Service Providers (where it can be > centrally implemented). > The basic goal is to provide a pre-defined security policy which aims > to block known harmful traffic and allow the rest, restoring as much > of end-to-end communication as possible. This pre-defined policy can > be centrally updated and could also be a member of a security policy > menu for the subscriber. > These example lists will probably evolve with the time as new > protocols and new threats appear. The update of the specific rules > could be done by firmware upgrade, policy update (for example by > Broadband Forum TR-69). Experience has shown than CPE updates from vendors are much slower than host updates, so i would expect that new threats would take a while to be fixed in the firmware. TR-069 would solve that only for managed CPEs, assuming a policy could be applied. > 3. Rule ProtectWeakServices: drop all inbound and outbound packets > whose layer-4 destination is part of a limited set (see > Section 3.2 ), the intent is to protect against the most common > unauthorized access and avoid propagation of worms (even if the > latter is questionable in IPv6); an advanced residential user > should be able to modify this pre-defined list; Set is limited because of a specific reason? hw resources? Comparing this implementation (default permit) with an opposite one (default deny), i would see much more deny entries in this than permit entries in the other. I can't predict the possible growth of each one, but i would give much more chances to denies than to permits. > The authors of the documents believe and the Swisscom deployment > shows that the following attack are mostly stopped: > > o Unauthorized access because vulnerable ports are blocked It would be nice to have a report with some numbers backing this up. -- Tassos Fred Baker wrote on 10/11/2013 21:00: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security. Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From yangshu1988@gmail.com Sun Nov 10 23:06: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 32B8F21E8127; Sun, 10 Nov 2013 23:06:29 -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, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57C5UHb85BLv; Sun, 10 Nov 2013 23:06:27 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2C21E811A; Sun, 10 Nov 2013 23:06:06 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id q59so4247042wes.11 for ; Sun, 10 Nov 2013 23:06:06 -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=5hidhRXKtLkFr2S1fTOLEVwKv0AQKter4JziILQkFOc=; b=fvrB88Uwe2WO+a+bWmjBRpAoQuS1Nk656ePHi1WSOzcTfajdntNgSUQaFjx2fBPY4M UeLhIe0/fjrWHSUyIbeZ2iB9eiNgjoFwOAMEUEZpoTGxuUhPYT87WKn3InqqPcBEoX/j QZIdGfWHinwCmfYNMGamOH6+dpOQcNJ7fUZeiAikV5SkveA2FfDyk/QPK9kbBh5nlEqL SdpeJ2TtLpm554dbv7w7Rs5fSwusC5iFC3cdYxM2pONqn8JW0skgvmlPQZknZxcNjELJ wcYXqg7qrLf2crOWvugNL0dYW7Q7uSsk9z8dRrZEotSrsfQcqXouhIaidGYeYwEGU/vI gy0A== MIME-Version: 1.0 X-Received: by 10.180.85.226 with SMTP id k2mr11178775wiz.31.1384153566060; Sun, 10 Nov 2013 23:06:06 -0800 (PST) Received: by 10.194.36.196 with HTTP; Sun, 10 Nov 2013 23:06:05 -0800 (PST) In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 11 Nov 2013 15:06:05 +0800 Message-ID: From: Shu Yang To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 17 Nov 2013 08:27:55 -0800 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Juliusz Chroboczek , "ospf@ietf.org" , "homenet@ietf.org Group" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing 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, 11 Nov 2013 07:06:29 -0000 > I agree with Juliusz, a public repository would be much better, even > if it only contains "in development" code. > > If the code will be open sourced in the end anyways I don't see any drawbacks. > > Henning Rogge Ok, we will make it public in this week. Shu Yang From v6ops@globis.net Sun Nov 17 09:25: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 36F7F11E81AD for ; Sun, 17 Nov 2013 09:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVSb3XpLVql5 for ; Sun, 17 Nov 2013 09:25:53 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 91D8611E817A for ; Sun, 17 Nov 2013 09:25:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2C609870080; Sun, 17 Nov 2013 18:25:43 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqKGQ9CFVkVj; Sun, 17 Nov 2013 18:25:43 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 058DC87007E; Sun, 17 Nov 2013 18:25:42 +0100 (CET) Message-ID: <5288FC15.5080508@globis.net> Date: Sun, 17 Nov 2013 18:25:41 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> In-Reply-To: <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 17 Nov 2013 17:25:56 -0000 Fred Baker (fred) wrote: > This is a comment as a participant, not as a chair. > > I find myself scratching my head with this, and found myself scratching= my head with what became RFC 6092. > > My first premise in both cases is that a firewall primarily mitigates a= ttacks on the bandwidth of a network and an aggregated network. An attack= that actually hits a host or application will have to be defended agains= t by the host/application or a security service provided by some other de= vice in the network; firewall rules provide a form of defense in depth, b= ut no more. I compare a firewall to the human skin. The skin is, itself, = hardly necessary for the "health security" of the body, as the other syst= ems of the body could be active and mitigate attacks on the body. However= , it makes active use of those capabilities less of a requirement by prev= enting certain classes of attacks. > > My second premise is that any communication attempt directed to a netwo= rk, or to a application in a network, that doesn't have a application in = the network that willingly communicates with it is an attack. > > Now, we have tools - PCP, UPnP - that enable an application to inform t= he network of its approving presence. If I want someone to be able to con= nect to a given device using IPsec, when the device comes up, it can info= rm the network of a n-tuple {application address, IPsec protocol ID, }, and "poke a hole" in a firewall regardless of the description of the = firewall. The administration can also log such requests and apply its own= policy on whether it honors them. If I want them to initiate SMTP or htt= ps connections to a given system, it can similarly announce itself as {ad= dress, TCP, port, any, any}, and allow incoming SMTP connections to it. > > So regardless of the firewall type, we have tools to enable an applicat= ion in the network to make itself available to peers "outside". And of co= urse, as suggested in zone-based defenses and in RFC 6092, when a applica= tion initiates a connection outside, by implication the firewall can open= a "hole" for the return traffic. > > So the only protocols, or peers using protocols, under discussion are t= hose that have no application that is willing to have sessions initiated = to it from the outside of the network. > > RFC 6092 permits IPsec packets as a blanket rule. That facilitates two = attacks. First, there is a form of network scanning enabled; a applicatio= n outside the network can initiate IKE connections to addresses it thinks= might exist in the network (observing, for example, email envelope infor= mation to find such addresses); if it gets a reply, something is using th= e address. Second, it can busy out the verification/decrypt unit in a app= lication simply by sending it IPsec traffic that does not have a proper k= ey. That can DOS the application's CPU resources or its communication res= ources. Now, if a application wants to communicate in that way and recogn= izes the vulnerability, it can open that hole. But if a application doesn= 't want to communicate that way (for example, it implements IPsec but the= applications it uses have no keys to validate data with), what is the ar= gument for leaving the vulnerability open? > > draft-ietf-v6ops-balanced-ipv6-security implements a similar, and much = wider, vulnerability. I might well have an http server in my network, but= that doesn't imply that all hosts in my network are http servers. Even i= f many of the hosts in my network are http servers, that doesn't imply th= at my policy enables access to them from all possible clients. My http se= rver can open a hole for itself, and can be armored to defend it against = the many attacks that plague that protocol. My telephones (Cisco 9971 and= iPhone 5) are, or can be, http servers as well. Does that mean that my c= all configuration and history should be available to anyone who wonders a= bout it? Is the presence of one server a reason to expose the many hosts = in my network that only operate as clients to HTTP initiated from the out= side? > > http://www.economist.com/news/science-and-technology/21589383-stung-rev= elations-ubiquitous-surveillance-and-compromised-software > > From my perspective, I think I would prefer that the firewall - if impl= emented - blocked everything, and applications within the network advised= the firewall(s) of traffic that they are willing to receive. If a potent= ial session has no willing counterpart within my network, I don't see the= argument for letting the first packet in. I have read the draft. Summary: I don't have answers to my own points below, but neither does this draft, so whilst I welcome the authors sharing their experiences, I can't support publishing it as-is as a v6ops WG document. The bottom line is that I wouldn't be happy if my own ISP adopted the policy exactly as-documented in the draft. I think we probably need something more sophisticated. And being realistic, we're probably not yet ready to write it. Detailed Points (IMHO) I don't think the threat model listed in the draft is particularly up to date or complete. 1. Experience in enterprises has really convincingly demonstrated that the firewall that switches off at 5pm is rather limited in it's efficacy (mobile nodes that cross the border at night to travel home, and then which re-enter the secure zone the next morning) 2. Trojanized hosts are pretty much impossible to stop. Attempting to address or prevent covert channels is a red-herring on the Internet, as they are inherently possible given the underlying Internet architecture. Preventing them would require )at least) the introduction of formal message syntax (and timing) to every single protocol, and stifle innovati= on. 3. The concept of "inside" and "outside" is just too simplistic. Even in a typical home network, there are going to be multiple classes of devices. Some of which are going to have poorly maintained code that never updates, and others that are going to be "on the Internet" 7x24 and are well-patched. There are going to be network devices that control real physical objects that may have a real-world financial or security impact if they are controlled by an unauthorised person. The vulnerability levels of these classes, and the impact of a successful attack, is likely to be very different. So a one-size-fits-all single-zone solution for Homenet is in itself problematic IMHO. 4. There's no denying that blocking of port 25 has helped fight spam. But it has also deprived many end-users of access to SMTP, and forced them to use centralised services. I think there's a very valid debate to be conducted about whether it is the responsibility of an ISP to protect customers' devices, or to protect their own network, or both, or neither. It isn't clear to me how much of this draft is focussed on each of these goals. 5. A port-based model of application classification is outdated. Almost everything runs on port 80 anyway today. HTTP can be extremely useful for users. But it can also be very harmful. As has been pointed out by others, SNMPv3 is considered "secure". Yet it uses the same ports as SNMPv1 and SNMPv2. So blocking HTTP and SNMPv1 and SNMPv2 may be considered "helpful" to the end user. But blocking HTTP SNMPv3 may well be "harmful" and may deprive them of Internet functionality. 6. Who determines what is weak? SSH with plain text passwords and root access may be weak. SSH with a certificate, and only authorised for certain users and certain commands, has no such weakness AFAIK. Life's a lot more complex than just blanket blocking a port for an entire ISP network. Are the ISP's going to conduct a Business Impact Analysis per end user? 7. Is the CPE the correct place to control access? CPE's are some of the worst maintained code on the planet. So why try to control access at this point? 8. The Internet is not homogenous. There are end users that are experts, and there are end users who most definitely aren't. There are AS's that have very good record of tracking down bad-guys backed up by law enforcements, and others that are not so good. I'd like to see a threat model that also incorporates some form of reputation of the local and remote users, e.g. via an AS source, or at least address block. Although of course I'd agree that's a bit of an ineffective sledgehammer, it's still probably one step better than "allow all" or "deny all". That way the ISP could protect it's own equipment from locally infected systems, without blocking traffic from users who are not infected, or who have never caused a problem. 9. Is the underlying problem the network, the host implementation, or is the vulnerability in the security model of the protocol itself? There's a role for many parties to play here. The IETF should probably be concentrating efforts on ensuring all core protocols can survive on the Internet. Network operators need to protect their own services. And host vendors should not be shipping devices where vulnerable ports/ services are running by default. --=20 Regards, RayH From fred@cisco.com Sun Nov 17 11:00: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 9753211E90C1 for ; Sun, 17 Nov 2013 11:00:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ0DwsrGn74k for ; Sun, 17 Nov 2013 11:00:17 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3E511E90AE for ; Sun, 17 Nov 2013 11:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1384714815; x=1385924415; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=LpjEAiwEIi+F2r9+V6LUYUCqpFENylIoRCtk4ujSvrIDtvrEmG8wbbEa 31RpVNk6G8hoIjTUCg3iGFWCpLCe4zDEhAzA0RZucnHzZhRTfDjNjPlcR HMp26AUwdX7KgyWpD2x8Tc1KlkqXPHQczwuihtcCWaLuT8LJoT7l2LW4Y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4GAEgRiVKrRDoJ/2dsb2JhbABZgweuDwGSJoEQFnSCSUgUPDSIYcEWF49pHYQbA4lCoFuDSQ X-IronPort-AV: E=Sophos;i="4.93,719,1378857600"; d="scan'208";a="97942412" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 17 Nov 2013 19:00:15 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAHJ0DQR010028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2013 19:00:13 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id rAHJ0BMv012453; Sun, 17 Nov 2013 11:00:13 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id rAHJ0BJs012452; Sun, 17 Nov 2013 11:00:11 -0800 (PST) Date: Sun, 17 Nov 2013 11:00:11 -0800 (PST) From: Fred Baker Message-Id: <201311171900.rAHJ0BJs012452@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 17 Nov 2013 19:00:22 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From marc.lampo.ietf@gmail.com Sun Nov 17 23:42: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 E9F2A11E85E9 for ; Sun, 17 Nov 2013 23:42: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4lxxrKPVrMF for ; Sun, 17 Nov 2013 23:42:08 -0800 (PST) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id DC34511E85E8 for ; Sun, 17 Nov 2013 23:42:07 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id x16so127789vbf.21 for ; Sun, 17 Nov 2013 23:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=93XNRwQzWPKkGPpdyKQfMWgzOqnpHr+YX0zOca6qO3Y=; b=sJ8VfeAtqH4JCxH8JuL+x3KUzV8PAW7YiIhi3UJY7sbSHF/KdMdWEBczte55INutFP gjqiJzwUTRHry7qQl8leZjYEliQOXlFLLKOXUIgMz+Slvzbt0ZFmTRDWeX8/7ckcSVSO /DoTf5B5d+wa+hzUB9/QAbHpSnN5ezn1zOfnnhnWZn4dl3bnMyumJLCytD/VlqofXfyT HykwxCYE9ZLZDPhTAI6to4cOro0nwne5RHf1dzaAbwEorM8aQTHUN9qHEVvc6JS+vknY 8GSaRTdLVKvmc5Mmi83bCPMjuh5/yVbgiX4+zDEvTVIEwHCeTVUPn+PXSqyyszwwiMpl acYQ== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr14289572vcb.16.1384760527342; Sun, 17 Nov 2013 23:42:07 -0800 (PST) Received: by 10.58.227.66 with HTTP; Sun, 17 Nov 2013 23:42:07 -0800 (PST) In-Reply-To: <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 18 Nov 2013 08:42:07 +0100 Message-ID: From: Marc Lampo To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7b5db26a54d0d104eb6eaff8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 18 Nov 2013 07:42:09 -0000 --047d7b5db26a54d0d104eb6eaff8 Content-Type: text/plain; charset=ISO-8859-1 Probably true - all of your points - but, INHO, this does not imply that the Internet should get access by default to most ports. And RFC 6092, REC-31 (for TCP), satisfies those needs. But if the Internet can access an internal device, that should first be allowed by the "operator" of the CPE, as per RFC 6092, REC-48. And whoever is OK with that (open) policy, can make use of RFC 6092, REC-49, and go for "transparent" mode. I acknowledge other contributions in this list stating that any device can end up with infected/hostile neighbors in the local network, but is this a reason/excuse to have a "mostly open policy for incoming traffic" ? So, personally I cannot support publishing this draft as a WG document because it is, at least partly - but then : on an important point, in contradiction with RFC 6092. I would be more in favor if the approach chosen (blocking some ports) would have been to strengthen RFC 6092, REC-49 : "transparent mode", but not for all ports. On Sat, Nov 16, 2013 at 7:30 AM, Mark ZZZ Smith wrote: > > >________________________________ > > From: Marc Lampo > >To: Mikael Abrahamsson > >Cc: "v6ops@ietf.org WG" > >Sent: Thursday, 14 November 2013 9:50 PM > >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC > > > > > > > >I realise now that "unsolicited" is a word allowing multiple > interpretations (but also used in RFC 6092). But we seem to have got it > right. > > > >Anyway, the fact that some service, on an internal device, is willing to > accept connections on port XYZ, > >does not, in my opinion, imply that those connections may also come from > the outside Internet. > >Back to the example with the refrigerator : > >suppose it has a service (port XYZ) that allows it to be queried for its > contents. > > >Probably great when one is at home, but does this mean accessible from > anywhere on the Internet ? > > > >In my opinion : not before the owner has explicitly instructed his CPE to > allow incoming connections (RFC 6092, REC-48). > > > > Actually, I think you're probably going to want your refrigerator to be > able to access the Internet, as well as your toaster, answering machine, > rice cooker, washing machine etc. > > I think appliances, if they aren't already, are going to become computers, > with as much done via software/firmware as possible, instead of hardware, > because hardware is much harder and more expensive to change, both during > development and after it is sold to the customer. > > However, software/firmware is still hard to change if the customer has to > either take it back to the manufacturer, or plug a PC or USB stick into it > to update the software/firmware. Having the device be able to update itself > over the Internet will be both much more user/customer friendly and much > cheaper for the manufacturer. > > So manufacturers have an incentive to make their appliances be able to > attach to the Internet, and their customers have an incentive to attach > them. As with tablets and smartphones, the manufacturer won't be able to > vouch for the existence of any upstream network "firewalls", nor will they > successfully be able to ask the customer of their existence, so the > manufacturer will have to assume the worst, and therefore harden the > appliance against publicly addressed unfettered Internet access. > > Regards, > Mark. > > --047d7b5db26a54d0d104eb6eaff8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Probably true - all of = your points - but, INHO, this does not imply that the Internet should get a= ccess by default to most ports.
And RFC 6092, REC-31 (for TCP), sa= tisfies those needs.

But if the Internet can access an internal device, that should fi= rst be allowed by the "operator" of the CPE, as per RFC 6092, REC= -48.
And whoever is OK with that (open) policy, can make use of RF= C 6092, REC-49, and go for "transparent" mode.

I acknowledge other contributions in this list stating that any d= evice can end up with infected/hostile neighbors in the local network,
<= /div>but is this a reason/excuse to have a "mostly open policy for inc= oming traffic" ?

So, personally I cannot support publishing this draft as a WG doc= ument because it is, at least partly - but then : on an important point,in contradiction with RFC 6092.
I would be more in favor if the approac= h chosen (blocking some ports) would have been to strengthen RFC 6092, REC-= 49 :
"transparent mode", but not for all ports.


On Sat, N= ov 16, 2013 at 7:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au<= /a>> wrote:

>________________________________
> From: Marc Lampo <marc= .lampo.ietf@gmail.com>
>To: Mikael Abrahamsson <sw= mike@swm.pp.se>
>Cc: "v6ops@ietf.org WG"= <v6ops@ietf.org>
>Sent: Thursday, 14 November 2013 9:50 PM
>Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-s= ecurity WGLC
>
>
>
>I realise now that "unsolicited" is a= word allowing multiple interpretations (but also used in RFC 6092).=A0 But= we seem to have got it right.
>
>Anyway, the fact that some service, on an internal device, is willing t= o accept connections on port XYZ,
>does not, in my opinion, imply that those connections may also come fro= m the outside Internet.
>Back to the example with the refrigerator :
>suppose it has a service (port XYZ) that allows it to be queried for it= s contents.

>Probably great when one is at home, but does this mean accessible from = anywhere on the Internet ?
>
>In my opinion : not before the owner has explicitly instructed his CPE = to allow incoming connections (RFC 6092, REC-48).
>

Actually, I think you're probably going to want your refrigerator= to be able to access the Internet, as well as your toaster, answering mach= ine, rice cooker, washing machine etc.

I think appliances, if they aren't already, are going to become compute= rs, with as much done via software/firmware as possible, instead of hardwar= e, because hardware is much harder and more expensive to change, both durin= g development and after it is sold to the customer.

However, software/firmware is still hard to change if the customer has to e= ither take it back to the manufacturer, or plug a PC or USB stick into it t= o update the software/firmware. Having the device be able to update itself = over the Internet will be both much more user/customer friendly and much ch= eaper for the manufacturer.=A0

So manufacturers have an incentive to make their appliances be able to atta= ch to the Internet, and their customers have an incentive to attach them. A= s with tablets and smartphones, the manufacturer won't be able to vouch= for the existence of any upstream network "firewalls", nor will = they successfully be able to ask the customer of their existence,=A0so the = manufacturer will have to assume the worst, and therefore harden the applia= nce against publicly addressed unfettered Internet access.

Regards,
Mark.


--047d7b5db26a54d0d104eb6eaff8-- From touch@isi.edu Mon Nov 18 00: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 8C79911E810B for ; Mon, 18 Nov 2013 00:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.602 X-Spam-Level: X-Spam-Status: No, score=-104.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEyhUM-teSy3 for ; Mon, 18 Nov 2013 00:09:49 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 514C611E80F2 for ; Mon, 18 Nov 2013 00:09:49 -0800 (PST) Received: from [192.168.1.110] (24.115.166.40.res-cmts.flt.ptd.net [24.115.166.40]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id rAI891Jw023258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Nov 2013 00:09:11 -0800 (PST) References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-43075C1B-22E6-426D-9651-6D53ABC1217A Message-Id: X-Mailer: iPhone Mail (11B554a) From: Joe Touch Date: Mon, 18 Nov 2013 03:09:01 -0500 To: Marc Lampo X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 18 Nov 2013 08:09:55 -0000 --Apple-Mail-43075C1B-22E6-426D-9651-6D53ABC1217A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Nov 18, 2013, at 2:42 AM, Marc Lampo wrote:= >=20 > Probably true - all of your points - but, INHO, this does not imply that t= he Internet should get access by default to most ports. If it doesn't it isn't on the Internet.=20 Many devices are - at best - tethered to the Internet by a proxy. But that d= oesn't make it either right or sufficient. =20 > And RFC 6092, REC-31 (for TCP), satisfies those needs. >=20 > But if the Internet can access an internal device, that should first be al= lowed by the "operator" of the CPE, as per RFC 6092, REC-48. > And whoever is OK with that (open) policy, can make use of RFC 6092, REC-4= 9, and go for "transparent" mode. >=20 > I acknowledge other contributions in this list stating that any device can= end up with infected/hostile neighbors in the local network, > but is this a reason/excuse to have a "mostly open policy for incoming tra= ffic" ? >=20 > So, personally I cannot support publishing this draft as a WG document bec= ause it is, at least partly - but then : on an important point, > in contradiction with RFC 6092. See the beginning of sec 1.2 of that doc. It informational only, despite th= e use of requirements language.=20 > I would be more in favor if the approach chosen (blocking some ports) woul= d have been to strengthen RFC 6092, REC-49 : > "transparent mode", but not for all ports. RFC 6092 carries zero weight. If you want to strengthen it, you need to star= t by having it be reconsidered and ultimately reissued as BCP or some such. = =20 Joe >=20 >=20 >> On Sat, Nov 16, 2013 at 7:30 AM, Mark ZZZ Smith wrote: >>=20 >> >________________________________ >> > From: Marc Lampo >> >To: Mikael Abrahamsson >> >Cc: "v6ops@ietf.org WG" >> >Sent: Thursday, 14 November 2013 9:50 PM >> >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC >> > >> > >> > >> >I realise now that "unsolicited" is a word allowing multiple interpretat= ions (but also used in RFC 6092). But we seem to have got it right. >> > >> >Anyway, the fact that some service, on an internal device, is willing to= accept connections on port XYZ, >> >does not, in my opinion, imply that those connections may also come from= the outside Internet. >> >Back to the example with the refrigerator : >> >suppose it has a service (port XYZ) that allows it to be queried for its= contents. >>=20 >> >Probably great when one is at home, but does this mean accessible from a= nywhere on the Internet ? >> > >> >In my opinion : not before the owner has explicitly instructed his CPE t= o allow incoming connections (RFC 6092, REC-48). >> > >>=20 >> Actually, I think you're probably going to want your refrigerator to be a= ble to access the Internet, as well as your toaster, answering machine, rice= cooker, washing machine etc. >>=20 >> I think appliances, if they aren't already, are going to become computers= , with as much done via software/firmware as possible, instead of hardware, b= ecause hardware is much harder and more expensive to change, both during dev= elopment and after it is sold to the customer. >>=20 >> However, software/firmware is still hard to change if the customer has to= either take it back to the manufacturer, or plug a PC or USB stick into it t= o update the software/firmware. Having the device be able to update itself o= ver the Internet will be both much more user/customer friendly and much chea= per for the manufacturer.=20 >>=20 >> So manufacturers have an incentive to make their appliances be able to at= tach to the Internet, and their customers have an incentive to attach them. A= s with tablets and smartphones, the manufacturer won't be able to vouch for t= he existence of any upstream network "firewalls", nor will they successfully= be able to ask the customer of their existence, so the manufacturer will ha= ve to assume the worst, and therefore harden the appliance against publicly a= ddressed unfettered Internet access. >>=20 >> Regards, >> Mark. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-43075C1B-22E6-426D-9651-6D53ABC1217A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On Nov 18, 2013, at 2:42 AM, Marc Lampo <marc.lampo.ietf@gmail.com> wrote:

Probably true - all of your points - but, INHO, this does not imply that the Internet should get access by default to most ports.

If it doesn't it isn't on the Internet. 

Many devices are - at best - tethered to the Internet by a proxy.  But that doesn't make it either right or sufficient.  

And RFC 6092, REC-31 (for TCP), satisfies those needs.

But if the Internet can access an internal device, that should first be allowed by the "operator" of the CPE, as per RFC 6092, REC-48.
And whoever is OK with that (open) policy, can make use of RFC 6092, REC-49, and go for "transparent" mode.

I acknowledge other contributions in this list stating that any device can end up with infected/hostile neighbors in the local network,
but is this a reason/excuse to have a "mostly open policy for incoming traffic" ?

So, personally I cannot support publishing this draft as a WG document because it is, at least partly - but then : on an important point,
in contradiction with RFC 6092.

See the beginning of sec 1.2 of that doc.  It informational only, despite the use of requirements language. 

I would be more in favor if the approach chosen (blocking some ports) would have been to strengthen RFC 6092, REC-49 :
"transparent mode", but not for all ports.

RFC 6092 carries zero weight. If you want to strengthen it, you need to start by having it be reconsidered and ultimately reissued as BCP or some such.  

Joe



On Sat, Nov 16, 2013 at 7:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:

>________________________________
> From: Marc Lampo <marc.lampo.ietf@gmail.com>
>To: Mikael Abrahamsson <swmike@swm.pp.se>
>Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
>Sent: Thursday, 14 November 2013 9:50 PM
>Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
>
>
>
>I realise now that "unsolicited" is a word allowing multiple interpretations (but also used in RFC 6092).  But we seem to have got it right.
>
>Anyway, the fact that some service, on an internal device, is willing to accept connections on port XYZ,
>does not, in my opinion, imply that those connections may also come from the outside Internet.
>Back to the example with the refrigerator :
>suppose it has a service (port XYZ) that allows it to be queried for its contents.

>Probably great when one is at home, but does this mean accessible from anywhere on the Internet ?
>
>In my opinion : not before the owner has explicitly instructed his CPE to allow incoming connections (RFC 6092, REC-48).
>

Actually, I think you're probably going to want your refrigerator to be able to access the Internet, as well as your toaster, answering machine, rice cooker, washing machine etc.

I think appliances, if they aren't already, are going to become computers, with as much done via software/firmware as possible, instead of hardware, because hardware is much harder and more expensive to change, both during development and after it is sold to the customer.

However, software/firmware is still hard to change if the customer has to either take it back to the manufacturer, or plug a PC or USB stick into it to update the software/firmware. Having the device be able to update itself over the Internet will be both much more user/customer friendly and much cheaper for the manufacturer. 

So manufacturers have an incentive to make their appliances be able to attach to the Internet, and their customers have an incentive to attach them. As with tablets and smartphones, the manufacturer won't be able to vouch for the existence of any upstream network "firewalls", nor will they successfully be able to ask the customer of their existence, so the manufacturer will have to assume the worst, and therefore harden the appliance against publicly addressed unfettered Internet access.

Regards,
Mark.


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--Apple-Mail-43075C1B-22E6-426D-9651-6D53ABC1217A-- From swmike@swm.pp.se Mon Nov 18 00:20: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 1EFA321F8E2D for ; Mon, 18 Nov 2013 00:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[AWL=1.705, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-6IlmU8BukL for ; Mon, 18 Nov 2013 00:19:54 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 385A821F8D62 for ; Mon, 18 Nov 2013 00:19:54 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 87875A1; Mon, 18 Nov 2013 09:19:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8300D9A for ; Mon, 18 Nov 2013 09:19:52 +0100 (CET) Date: Mon, 18 Nov 2013 09:19:52 +0100 (CET) From: Mikael Abrahamsson To: "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5FC5FC3F-B933-4ACE-A7A9-00A1E275B4EF@cisco.com> <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 18 Nov 2013 08:20:00 -0000 On Mon, 18 Nov 2013, Marc Lampo wrote: > I acknowledge other contributions in this list stating that any device > can end up with infected/hostile neighbors in the local network, but is > this a reason/excuse to have a "mostly open policy for incoming traffic" > ? It all comes down to "better safe than sorry" as opposed to "make things work without operator invention". Do you want devices to be part of the Internet as default or not is the major philosophical question. Should devices have a one-way peep-hole to the Internet by default or should they be open and be reachable from the Internet by default. Gated community and don't care about locking your door because you trust the neighborhood, or open community and take care of your own security. There is no right answer here, but I am in favour of the open variant and let hosts take care of their own security. Most devices today are hardened enough to handle being exposed to the Internet, is my opinion. From your reasoning I guess you do not agree. My background is that I worked for 7 years for a mobile operator that didn't have any filters apart from outgoing port 25 and a few other things (very similar to balanced security proposal). Even less for residential access. No bad effects from this even with millions of customers. So I think it's up to the people who want to put filters in CPEs by default to prove that applications work well with this, and give advice to application implementers what they need to do in order to make things work. Do they need to do STUN-like functionality always, even though there is no NAT, just to make sure the stateful filtering device actually sees this as a wanted session? -- Mikael Abrahamsson email: swmike@swm.pp.se From savitha.kumar@wipro.com Mon Nov 18 01:02: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 806D111E80FA for ; Mon, 18 Nov 2013 01:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxEDLRxoLHFS for ; Mon, 18 Nov 2013 01:02:05 -0800 (PST) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBC711E8214 for ; Mon, 18 Nov 2013 01:01:26 -0800 (PST) X-AuditID: cb5bdd57-b7f086d00000541c-59-5289d758a03f Received: from BLR-OUT-EDG02.wipro.com ( [203.91.193.32]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by wipro-blr-out01.wipro.com (Symantec Mail Security) with SMTP id A5.FB.21532.857D9825; Mon, 18 Nov 2013 14:31:13 +0530 (IST) Received: from BLR-EC-MBX6.wipro.com (10.208.51.116) by BLR-OUT-EDG02.wipro.com (203.91.193.32) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 14:31:09 +0530 Received: from BLR-EC-MBX5.wipro.com ([169.254.5.110]) by BLR-EC-MBX6.wipro.com ([169.254.6.216]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 14:31:12 +0530 From: To: Thread-Topic: Unsubscribe Thread-Index: Ac7kPK9YKRd0qoFpQUm2doaF037K2g== Date: Mon, 18 Nov 2013 09:01:11 +0000 Message-ID: <39B5BE047018DA46A8870182E737D5058746B483@BLR-EC-MBX5.wipro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.12.23] Content-Type: multipart/alternative; boundary="_000_39B5BE047018DA46A8870182E737D5058746B483BLRECMBX5wiproc_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsVyOvqggm7k9c4gg9vvWS1OH9vL7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL8TvrAXvBGouP/nKEsD4w++LkZODgkBE4lnC64wQthiEhfu rWfrYuTiEBKYziSxcNs1RghnM6PEtnPr2SGcRYwSr7sOsoG0sAnIS3xa/Z4ZxBYREJHYPeUu O4gtDGS/PX0fKi4pcf3keiYIW09i3qu7YDaLgKrEmTlPwVbzCvhIbF87nRXEZgQ64/upNWA1 zALiEreezGeCOE9AYsme88wQtqjEy8f/WCFsBYk9vRtYIerzJVa+vs4OMVNQ4uTMJyxdjBxA R6tILOsVm8AoMgvJ1FlIOmYh6YCI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGCXLMwuK 8nWTcop080tLDAz1wHy95PzcTYzgaLobvoOxud/uEKMAB6MSD++Hmx1BQqyJZcWVuYcYJTmY lER5F13pDBLiS8pPqcxILM6ILyrNSS0+xCjBwawkwjvrIlCONyWxsiq1KB8mJc3BoiTOa15e EyQkkJ5YkpqdmlqQWgSTleHgUJLg7boG1ChYlJqeWpGWmVOCkGbi4AQZzgM0vAekhre4IDG3 ODMdIn+KUVFKnFfrKlBCACSRUZoH1wtLdq8YxYFeEea9DXI3DzBRwnW/AhrMBDT4+PM2kMEl iQgpqQZGVZl+28eTQ2+1ZK6z1P73SdhBPlx4W2u94cJ10Soz9v1Km79ONf1pU8ecN6EFbrvN NHivO7csip5v8O+dh2C38csXNWU28+boP5l9SsG91Yd7vauEt9tf493+LnsD9xS4VwYt+xY5 9yfPsie7DD54HbxSMueXZdLUx0ZdO57F+E1Pq9U5Y2agxFKckWioxVxUnAgASCoTiVEDAAA= Subject: [v6ops] Unsubscribe 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, 18 Nov 2013 09:02:11 -0000 --_000_39B5BE047018DA46A8870182E737D5058746B483BLRECMBX5wiproc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_39B5BE047018DA46A8870182E737D5058746B483BLRECMBX5wiproc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_39B5BE047018DA46A8870182E737D5058746B483BLRECMBX5wiproc_-- From markus.debruen@bsi.bund.de Mon Nov 18 02:37: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 E5B0011E8132 for ; Mon, 18 Nov 2013 02:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.489 X-Spam-Level: X-Spam-Status: No, score=-7.489 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU7j8b9VyGtR for ; Mon, 18 Nov 2013 02:37:34 -0800 (PST) Received: from m3-bn.bund.de (m3-bn.bund.de [77.87.228.75]) by ietfa.amsl.com (Postfix) with ESMTP id A471F11E80F6 for ; Mon, 18 Nov 2013 02:37:33 -0800 (PST) Received: from m3.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m3-bn.bund.de (8.14.3/8.14.3) with ESMTP id rAIAbVFr030812 for ; Mon, 18 Nov 2013 11:37:31 +0100 (CET) Received: (from localhost) by m3.mfw.bn.ivbb.bund.de (MSCAN) id 5/m3.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Mon Nov 18 11:37:31 2013 X-P350-Id: 144f6f2a54fd3e80 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: "de =?iso-8859-1?q?Br=FCn?=, Markus" Organization: BSI Bonn To: v6ops@ietf.org, Mark ZZZ Smith Date: Mon, 18 Nov 2013 11:37:21 +0100 User-Agent: KMail/1.9.10 (enterprise35 20130923.8c03dfc) References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <201311181137.21672.markus.debruen@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.2.12.144; VDF: 7.11.114.48; host: sgasmtp2.bsi.de); id=15866-AJWI7j Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 18 Nov 2013 10:37:38 -0000 > >[...], but does this mean accessible from anywhere on the Internet ? > Actually, I think you're probably going to want your refrigerator to be > able to access the Internet, [...] "Access to the internet" and "accessible from the internet" are two seperat= e=20 things.Perhaps I want my fridge to access the internet but not the other wa= y=20 around. There was a vulnerability in some heating-systems a few month ago [1]. An=20 attacker could remotely shut down the heating. This is the kind of thing on= e=20 does not want to happen. Regards, Markus [1]=20 http://www.heise.de/security/meldung/Vaillant-Heizungen-mit-Sicherheits-Lec= k-1840919.html __________ urspr=FCngliche Nachricht __________ Von: Mark ZZZ Smith Datum: Samstag, 16. November 2013, 07:30:13 An: Marc Lampo , Mikael Abrahamsson=20 Kopie: "v6ops@ietf.org WG" Betr.: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC > >________________________________ > > From: Marc Lampo > >To: Mikael Abrahamsson > >Cc: "v6ops@ietf.org WG" > >Sent: Thursday, 14 November 2013 9:50 PM > >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC > > > > > > > >I realise now that "unsolicited" is a word allowing multiple > > interpretations (but also used in RFC 6092).=A0 But we seem to have got= it > > right. > > > >Anyway, the fact that some service, on an internal device, is willing to > > accept connections on port XYZ, does not, in my opinion, imply that tho= se > > connections may also come from the outside Internet. Back to the example > > with the refrigerator : > >suppose it has a service (port XYZ) that allows it to be queried for its > > contents. > > > >Probably great when one is at home, but does this mean accessible from > > anywhere on the Internet ? > > > >In my opinion : not before the owner has explicitly instructed his CPE to > > allow incoming connections (RFC 6092, REC-48). > > Actually, I think you're probably going to want your refrigerator to be > able to access the Internet, as well as your toaster, answering machine, > rice cooker, washing machine etc. > > I think appliances, if they aren't already, are going to become computers, > with as much done via software/firmware as possible, instead of hardware, > because hardware is much harder and more expensive to change, both during > development and after it is sold to the customer. > > However, software/firmware is still hard to change if the customer has to > either take it back to the manufacturer, or plug a PC or USB stick into it > to update the software/firmware. Having the device be able to update itse= lf > over the Internet will be both much more user/customer friendly and much > cheaper for the manufacturer.=A0 > > So manufacturers have an incentive to make their appliances be able to > attach to the Internet, and their customers have an incentive to attach > them. As with tablets and smartphones, the manufacturer won't be able to > vouch for the existence of any upstream network "firewalls", nor will they > successfully be able to ask the customer of their existence,=A0so the > manufacturer will have to assume the worst, and therefore harden the > appliance against publicly addressed unfettered Internet access. > > Regards, > Mark. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marc.lampo.ietf@gmail.com Mon Nov 18 02:44: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 08B5A11E815B for ; Mon, 18 Nov 2013 02:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPZZyLcyI+bu for ; Mon, 18 Nov 2013 02:44:52 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A603111E80DE for ; Mon, 18 Nov 2013 02:44:51 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id ie18so3458707vcb.41 for ; Mon, 18 Nov 2013 02:44:51 -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=pWBhFsclogjObSyEz5WEnI4K0VRhC8vseLgtkm0GuoA=; b=iVgY5LcJkBlO4nzH/j8U+YnykTgmoGmZVKUB42AGAqkHDvRmVT2i+zl/FjA+DxsJ1x X31RMjogxv2rJ6UCq2Pf1LQL3gJMryzPDQUvYCO52bvXz1CUyNM2vVH/8kme859cMPeq nZ8WwQFHF+WktKdjFCnXesxsniCgX30e1da//yYEarHTRb5CO/d6XufgL94ZENNL1rW1 rc3RbPAO03XnTGyavOFc/ZQ4BEHp9PLyC9Q1i9lUd3oH5vUDULPnK13cX6wdpnKqZrPA Y7p+xGOCVAIfQMoyfE50CvugZL6dDq0xbPvnZI/c9dCwfVKgA5VrVWQKyJiMUmK0nwfJ oLfg== MIME-Version: 1.0 X-Received: by 10.52.32.66 with SMTP id g2mr12973081vdi.14.1384771491126; Mon, 18 Nov 2013 02:44:51 -0800 (PST) Received: by 10.58.227.66 with HTTP; Mon, 18 Nov 2013 02:44:51 -0800 (PST) In-Reply-To: <201311181137.21672.markus.debruen@bsi.bund.de> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> <201311181137.21672.markus.debruen@bsi.bund.de> Date: Mon, 18 Nov 2013 11:44:51 +0100 Message-ID: From: Marc Lampo To: =?ISO-8859-1?Q?de_Br=FCn=2C_Markus?= Content-Type: multipart/alternative; boundary=bcaec51d255ed2e37c04eb713c11 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC 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, 18 Nov 2013 10:44:53 -0000 --bcaec51d255ed2e37c04eb713c11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do I understand this is an argument against the "mostly open policy" of the draft ? (although the draft proposes to keep tcp port 80 closed and this particular vulnerability seems to be against port 80) On Mon, Nov 18, 2013 at 11:37 AM, de Br=FCn, Markus < markus.debruen@bsi.bund.de> wrote: > > >[...], but does this mean accessible from anywhere on the Internet ? > > > Actually, I think you're probably going to want your refrigerator to be > > able to access the Internet, [...] > > "Access to the internet" and "accessible from the internet" are two > seperate > things.Perhaps I want my fridge to access the internet but not the other > way > around. > > There was a vulnerability in some heating-systems a few month ago [1]. An > attacker could remotely shut down the heating. This is the kind of thing > one > does not want to happen. > > Regards, > Markus > > [1] > > http://www.heise.de/security/meldung/Vaillant-Heizungen-mit-Sicherheits-L= eck-1840919.html > > > > __________ urspr=FCngliche Nachricht __________ > > Von: Mark ZZZ Smith > Datum: Samstag, 16. November 2013, 07:30:13 > An: Marc Lampo , Mikael Abrahamsso= n > > Kopie: "v6ops@ietf.org WG" > Betr.: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC > > > >________________________________ > > > From: Marc Lampo > > >To: Mikael Abrahamsson > > >Cc: "v6ops@ietf.org WG" > > >Sent: Thursday, 14 November 2013 9:50 PM > > >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC > > > > > > > > > > > >I realise now that "unsolicited" is a word allowing multiple > > > interpretations (but also used in RFC 6092). But we seem to have got > it > > > right. > > > > > >Anyway, the fact that some service, on an internal device, is willing = to > > > accept connections on port XYZ, does not, in my opinion, imply that > those > > > connections may also come from the outside Internet. Back to the > example > > > with the refrigerator : > > >suppose it has a service (port XYZ) that allows it to be queried for i= ts > > > contents. > > > > > >Probably great when one is at home, but does this mean accessible from > > > anywhere on the Internet ? > > > > > >In my opinion : not before the owner has explicitly instructed his CPE > to > > > allow incoming connections (RFC 6092, REC-48). > > > > Actually, I think you're probably going to want your refrigerator to be > > able to access the Internet, as well as your toaster, answering machine= , > > rice cooker, washing machine etc. > > > > I think appliances, if they aren't already, are going to become > computers, > > with as much done via software/firmware as possible, instead of hardwar= e, > > because hardware is much harder and more expensive to change, both duri= ng > > development and after it is sold to the customer. > > > > However, software/firmware is still hard to change if the customer has = to > > either take it back to the manufacturer, or plug a PC or USB stick into > it > > to update the software/firmware. Having the device be able to update > itself > > over the Internet will be both much more user/customer friendly and muc= h > > cheaper for the manufacturer. > > > > So manufacturers have an incentive to make their appliances be able to > > attach to the Internet, and their customers have an incentive to attach > > them. As with tablets and smartphones, the manufacturer won't be able t= o > > vouch for the existence of any upstream network "firewalls", nor will > they > > successfully be able to ask the customer of their existence, so the > > manufacturer will have to assume the worst, and therefore harden the > > appliance against publicly addressed unfettered Internet access. > > > > Regards, > > Mark. > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec51d255ed2e37c04eb713c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do I understand this is an argument against the "= ;mostly open policy" of the draft ?

(although the draft p= roposes to keep tcp port 80 closed and this particular vulnerability seems = to be against port 80)


On Mon,= Nov 18, 2013 at 11:37 AM, de Br=FCn, Markus <markus.debruen@bsi= .bund.de> wrote:
> >[...], but does this mean accessibl= e from anywhere on the Internet ?

> Actually, I think you're probably going to want your refrigerator = to be
> able to access the Internet, [...]

"Access to the internet" and "accessible from the internet&q= uot; are two seperate
things.Perhaps I want my fridge to access the internet but not the other wa= y
around.

There was a vulnerability in some heating-systems a few month ago [1]. An attacker could remotely shut down the heating. This is the kind of thing on= e
does not want to happen.

Regards,
Markus

[1]
http://www.heise.de/security/m= eldung/Vaillant-Heizungen-mit-Sicherheits-Leck-1840919.html



__________ urspr=FCngliche Nachricht __________

Von: =A0 =A0 =A0 =A0 =A0 =A0Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Datum: =A0Samstag, 16. November 2013, 07:30:13
An: =A0 =A0 =A0 =A0 =A0 =A0 Marc Lampo <marc.lampo.ietf@gmail.com>, Mikael Abrahamsson
<swmike@swm.pp.se>
Kopie: =A0"v6ops@ietf.org WG&quo= t; <v6ops@ietf.org>
Betr.: =A0Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

> >________________________________
> > From: Marc Lampo <marc.lampo.ietf@gmail.com>
> >To: Mikael Abrahamsson <swm= ike@swm.pp.se>
> >Cc: "v6ops@ietf.org WG&= quot; <v6ops@ietf.org>
> >Sent: Thursday, 14 November 2013 9:50 PM
> >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC<= br> > >
> >
> >
> >I realise now that "unsolicited" is a word allowing mult= iple
> > interpretations (but also used in RFC 6092).=A0 But we seem to ha= ve got it
> > right.
> >
> >Anyway, the fact that some service, on an internal device, is will= ing to
> > accept connections on port XYZ, does not, in my opinion, imply th= at those
> > connections may also come from the outside Internet. Back to the = example
> > with the refrigerator :
> >suppose it has a service (port XYZ) that allows it to be queried f= or its
> > contents.
> >
> >Probably great when one is at home, but does this mean accessible = from
> > anywhere on the Internet ?
> >
> >In my opinion : not before the owner has explicitly instructed his= CPE to
> > allow incoming connections (RFC 6092, REC-48).
>
> Actually, I think you're probably going to want your refrigerator = to be
> able to access the Internet, as well as your toaster, answering machin= e,
> rice cooker, washing machine etc.
>
> I think appliances, if they aren't already, are going to become co= mputers,
> with as much done via software/firmware as possible, instead of hardwa= re,
> because hardware is much harder and more expensive to change, both dur= ing
> development and after it is sold to the customer.
>
> However, software/firmware is still hard to change if the customer has= to
> either take it back to the manufacturer, or plug a PC or USB stick int= o it
> to update the software/firmware. Having the device be able to update i= tself
> over the Internet will be both much more user/customer friendly and mu= ch
> cheaper for the manufacturer.=A0
>
> So manufacturers have an incentive to make their appliances be able to=
> attach to the Internet, and their customers have an incentive to attac= h
> them. As with tablets and smartphones, the manufacturer won't be a= ble to
> vouch for the existence of any upstream network "firewalls",= nor will they
> successfully be able to ask the customer of their existence,=A0so the<= br> > manufacturer will have to assume the worst, and therefore harden the > appliance against publicly addressed unfettered Internet access.
>
> Regards,
> Mark.
>
> __________________= _____________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--bcaec51d255ed2e37c04eb713c11-- From nick.heatley@ee.co.uk Mon Nov 18 05:32: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 98D0811E841B for ; Mon, 18 Nov 2013 05:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1lz04fJzC3r for ; Mon, 18 Nov 2013 05:32:25 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3A11E8628 for ; Mon, 18 Nov 2013 05:32:00 -0800 (PST) Received: from [85.158.139.3:28428] by server-8.bemta-5.messagelabs.com id 8F/47-29838-DC61A825; Mon, 18 Nov 2013 13:31:57 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-90.messagelabs.com!1384781516!31365343!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.9.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10009 invoked from network); 18 Nov 2013 13:31:57 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-8.tower-90.messagelabs.com with SMTP; 18 Nov 2013 13:31:57 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Mon, 18 Nov 2013 13:39:36 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([fe80::5093:62a6:6ee3:7198%11]) with mapi id 14.02.0318.004; Mon, 18 Nov 2013 13:31:56 +0000 From: "Heatley, Nick" To: GangChen , Gert Doering Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: AQHOyHB1/aS13ASbK0O9Jy+4NHt/ApoWDEUAgAAA1wCAAASNgIAAB+OAgAVLKMCAAFoFAIAA+3cAgABTXICAAs0ZMIAAbiUAgAACSACAAYz+gIABX4RQ Date: Mon, 18 Nov 2013 13:31:56 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303A246E4@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.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, 18 Nov 2013 13:32:42 -0000 SW4gc3VtbWFyeSBvZiB0aGlzIHRocmVhZCwgYXMgYmVzdCBJIHVuZGVyc3RhbmQgaXQ6DQpXZSBh Z3JlZSB0aGF0IGEgbWl4ZWQgZW52aXJvbm1lbnQgd2l0aCBJUHY2LW9ubHkgYW5kIGR1YWwgc3Rh Y2sgY2xpZW50cyB3aXRoIE5BVDY0IGFuZCBOQVQ0NCBnYXRld2F5cyBpcyBhICJtb2JpbGUgUkZD MTkxOCBob3N0ICIgdXNlIGNhc2UuDQpUaGVyZSBhcHBlYXIgdmFsaWQgY29uY2VybnMgYWJvdXQg MSkgcGVyZm9ybWFuY2Ugb24gZGlmZmVyZW50IHBhdGhzIChhbmQgY2xpZW50cyBwaWNraW5nIHRo b3NlIHBhdGhzIGR5bmFtaWNhbGx5KSwgMikgdHJhY2VhYmlsaXR5IGZvciBPcGVyYXRpb25zLCAz KSB0aGUgcmVsYXRpdmUgc3RhdGUgb2YgTkFUNDQgYW5kIE5BVDY0IEFMR3MsIGFuZCA0KSBjYXBh Y2l0eSBvciBydW5uaW5nIE5BVDQ0IGFuZCBOQVQ2NCBnYXRld2F5cy4NCg0KSG93IHRvIHByb3Zp ZGUgY29ubmVjdGl2aXR5IHRvIElQdjQtb25seSBjb250ZW50IGluIHN1Y2ggYSBtaXhlZCBOQVQ0 NC9OQVQ2NCBlbnZpcm9ubWVudD8NCi0gb25lIGFwcHJvYWNoIGlzIHRvIHRyeSB0byBrZWVwIGR1 YWwgc3RhY2sgaG9zdHMgdW5jaGFuZ2VkIC8gb24gYSBwdXJlIE5BVDQ0IHBhdGggKHRoZSByZWNv bW1lbmRhdGlvbiBvZiB0aGUgZHJhZnQpDQotIGFub3RoZXIgZG9jdW1lbnRlZCBhcHByb2FjaCBp cyB0byBhZGQgbW9yZSBzb3BoaXN0aWNhdGVkIGZ1bmN0aW9uYWxpdHkgdG8gc3RlZXIgdGhlIGRp ZmZlcmVudCBjbGllbnRzIHRvIHN1aXRhYmxlIEROUyBhcyBwZXIgZHJhZnQgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy1kaGMtZG5zLXJlY29uZmlndXJlLTAwDQoNCkkgYW0g dGhpbmtpbmcgSSB3aWxsIHRyaWFsIGFub3RoZXIgYXBwcm9hY2ggZm9yIHRoZSBOQVQ0NC9OQVQ2 NCBlbnZpcm9ubWVudDsgdG8gbGV0IFJGQzE5MTggZHVhbCBzdGFjayBob3N0cyBwcmVmZXIgdGhl IE5BVDY0IHBhdGguDQpUbyBhZGRyZXNzIHRoZSBjb25jZXJucyBhYm92ZSwgdGhpcyBhcHByb2Fj aCB3b3VsZCByZWx5IG9uOg0KYSkgcGFyaXR5IG9mIE5BVDQ0IGFuZCBOQVQ2NCBBTEdzIChJIG5l ZWQgdG8gcHVzaCBteSB2ZW5kb3IpDQphbmQgYikgZnJvbSBhIGNhcGFjaXR5IGFuZCB0cmFjZWFi aWxpdHkgcGVyc3BlY3RpdmUsIHdpbGwgcnVuIG9uIGEgY29tYmluZWQgTkFUNDQvTkFUNjQgcGxh dGZvcm0uDQoNCkEgdHJpYWwgd2lsbCBiZSBpbiBhIG1vYmlsZSBlbnZpcm9ubWVudCwgaXQgd2ls bCBiZSBhIG1peCBvZiBJUHY0LW9ubHkgVUVzLCBkdWFsIHN0YWNrIFVFcyBhbmQgSVB2Ni1vbmx5 ICsgNDY0eGxhdCBVRXMgKGhhdHMgb2ZmIHRvIENhbWVyb24gdGhlcmUpLg0KQW55IG90aGVyIHBv aW50ZXJzL2NvbmNlcm5zIHdvdWxkIGJlIGdyYXRlZnVsbHkgcmVjZWl2ZWQuDQpSZWdhcmRzLA0K Tmljaw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHYW5nQ2hlbiBbbWFp bHRvOnBoZGdhbmdAZ21haWwuY29tXSANClNlbnQ6IDEyIE5vdmVtYmVyIDIwMTMgMTQ6MzYNClRv OiBHZXJ0IERvZXJpbmcNCkNjOiBIZWF0bGV5LCBOaWNrOyBNaWthZWwgQWJyYWhhbXNzb247IHY2 b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UtMDQudHh0DQoNCjIwMTMvMTEvMTEsIEdlcnQgRG9lcmlu ZyA8Z2VydEBzcGFjZS5uZXQ+Og0KPiBIaSwNCj4NCj4gT24gTW9uLCBOb3YgMTEsIDIwMTMgYXQg MTA6NDY6NDJQTSArMDgwMCwgR2FuZ0NoZW4gd3JvdGU6DQo+PiBJdCBkb2Vzbid0IGV4cGVjdCB0 aGF0IGR1YWwtc3RhY2sgVUVzIGdvIHRvIE5BVDY0LCBiZWNhdXNlIElQdjQgDQo+PiBuYXRpdmUg Y29ubmVjdGlvbnMgYXJlIHByZWZlcnJlZCBvdmVyICBJUHY2K05BVDY0DQo+DQo+IEhvdyBkb2Vz IHRoZSBVRSBrbm93IHRoYXQgYSB0YXJnZXQgY2FuIGJlIHJlYWNoZWQgYnkgbmF0aXZlIElQdjQg aWYNCj4gRE5TNjQgdGVsbHMgaXQgInRoZXJlIGlzIElQdjYgZm9yIHlvdSIgYW5kIElQdjYgaXMg cHJlZmVycmVkIHRvIElQdjQ/DQoNClVFIG1heSBub3QgY2FuIGRldGVybWluZSB0aGUgZXhpc3Rl bmNlIG9mIElQdjQgbmF0aXZlIGNvbm5lY3Rpb25zLg0KSG93ZXZlciwgYW4gbmV0d29yayBzaWRl IG1heSBjb3VsZCBzZXJ2ZSB0aGUgcmlnaHQgRE5TIGFkZHJlc3MgYWNjb3JkaW5nIHRvIHRoZSBV RSBjb25uZWN0aW9uIHN0YXR1cywgZm9yIGV4YW1wbGUgdGhlIHNvbHV0aW9uIGRlc2NyaWJlZCBh dCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLWRoYy1kbnMtcmVjb25maWd1 cmUtMDANCg0KR2FuZw0KDQo+IEdlcnQgRG9lcmluZw0KPiAgICAgICAgIC0tIE5ldE1hc3Rlcg0K PiAtLQ0KPiBoYXZlIHlvdSBlbmFibGVkIElQdjYgb24gc29tZXRoaW5nIHRvZGF5Li4uPw0KPg0K PiBTcGFjZU5ldCBBRyAgICAgICAgICAgICAgICAgICAgICAgIFZvcnN0YW5kOiBTZWJhc3RpYW4g di4gQm9taGFyZA0KPiBKb3NlcGgtRG9sbGluZ2VyLUJvZ2VuIDE0ICAgICAgICAgIEF1ZnNpY2h0 c3JhdHN2b3JzLjogQS4gR3J1bmRuZXItQ3VsZW1hbm4NCj4gRC04MDgwNyBNdWVuY2hlbiAgICAg ICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pDQo+IFRlbDogKzQ5ICgwKTg5 LzMyMzU2LTQ0NCAgICAgICAgICAgVVN0LUlkTnIuOiBERTgxMzE4NTI3OQ0KPg0KDQpOT1RJQ0Ug QU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBp cyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBk ZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3Ig dXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFu ZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhh dmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMg YXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxp dHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0K DQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJl Z2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJp ZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5 QlcNCg== From rbonica@juniper.net Mon Nov 18 13:50:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7D11AE5C6; Mon, 18 Nov 2013 13:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDbfUSPjdS8b; Mon, 18 Nov 2013 13:50:54 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0A31AE5C4; Mon, 18 Nov 2013 13:50:51 -0800 (PST) Received: from mail144-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Mon, 18 Nov 2013 21:50:45 +0000 Received: from mail144-tx2 (localhost [127.0.0.1]) by mail144-tx2-R.bigfish.com (Postfix) with ESMTP id 98B4B1C00CC; Mon, 18 Nov 2013 21:50:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz62a3I9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068h5eeeKz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail144-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(252514010)(51704005)(13464003)(199002)(189002)(377454003)(164054003)(19580395003)(81342001)(15975445006)(81686001)(85306002)(74502001)(80022001)(63696002)(15202345003)(80976001)(47446002)(83322001)(65816001)(31966008)(74662001)(87936001)(19580405001)(2656002)(69226001)(76786001)(74316001)(81816001)(56776001)(74706001)(50986001)(76796001)(49866001)(47736001)(33646001)(51856001)(53806001)(54356001)(76576001)(77982001)(79102001)(54316002)(76482001)(81542001)(66066001)(83072001)(47976001)(4396001)(59766001)(46102001)(77096001)(56816003)(74876001)(87266001)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail144-tx2 (localhost.localdomain [127.0.0.1]) by mail144-tx2 (MessageSwitch) id 1384811443373733_8803; Mon, 18 Nov 2013 21:50:43 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.235]) by mail144-tx2.bigfish.com (Postfix) with ESMTP id 531203A0052; Mon, 18 Nov 2013 21:50:43 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 18 Nov 2013 21:50:43 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 18 Nov 2013 21:50:42 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 18 Nov 2013 21:50:40 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.67]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.69]) with mapi id 15.00.0785.001; Mon, 18 Nov 2013 21:50:39 +0000 From: Ronald Bonica To: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Thread-Topic: Some stats on IPv6 fragments and EH filtering on the Internet Thread-Index: AQHO2bHohYR0s3IRQE+Bh6lCddmviporl0bw Date: Mon, 18 Nov 2013 21:50:39 +0000 Message-ID: <5a9e4532c4e14bddbd9d824133820157@CO1PR05MB442.namprd05.prod.outlook.com> References: <5278275C.50206@gont.com.ar> In-Reply-To: <5278275C.50206@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] x-forefront-prvs: 00342DD5BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:50:57 -0000 Folks, Fernando presents two studies in . The second study is more interesting to = me, because duplicate addresses are removed. The following are a few questions regarding Fernando's second study: 1) Fernando observes that 41% of sites discard fragmented packets. However,= in a similar study (http://www.nlnetlabs.nl/downloads/publications/pmtu-bl= ack-holes-msc-thesis.pdf) only 10% of sites discarded fragmented packets. I= wonder why the two studies yield such divergent results. 2) Fernando observes that 44% of sites discard packets containing an 8 byte= destination header, while 89% of sites discard packet containing 1 kilobyt= e of extension headers. Because the first number (44%) is so high, can I co= nclude that the second (89%) is insignificant. Could it be that extension header length is a non-issue, because so many si= tes filter packets containing extension headers, regardless of their length= ? Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: Monday, November 04, 2013 6:02 PM > To: 6man@ietf.org; IPv6 Operations > Subject: Some stats on IPv6 fragments and EH filtering on the Internet >=20 > Folks, >=20 > I did a presentation on the topic at the IEPG meeting earlier this > week. > It provides some concrete data regarding IPv6 fragmentation and > Extension Header filtering on the Internet. >=20 > The slideware is available at: > eh.pdf> >=20 > Certainly there's *much* more work to be done in this area, but I > thought that this could be good food sfor some of the discussions that > we were having on the topic. >=20 > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From brian.e.carpenter@gmail.com Mon Nov 18 20:35:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AC51AEB0E; Mon, 18 Nov 2013 20:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYgnLUm4nOmx; Mon, 18 Nov 2013 20:35:37 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 293771AE6FE; Mon, 18 Nov 2013 20:35:37 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kp14so1959659pab.18 for ; Mon, 18 Nov 2013 20:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7j9Kaexv2KvtEj6+B4t1fLaJ4UmmycnSwLlltG/N2Qg=; b=MP47aoX/rqA11y7dA15+rdIu/5MJRboEP/rGbQZz8D2n5D53rAzPwTMPYkh+ZfyH+i 8MMktNpo8AjRpt0G6J9y1LCkK7lNB+EA45HYuumTrm/l4evTQuV6Ug17wvdAxsOrjLE2 gsRk6VRnqQI4v1hqbVxZGgA1nqeHylvD6502WQMdGlE1pmW0s1N29a7nqVDoZDW7tWDB CRwWBefON2ogPNA0nPEODyYmsBQpmSf1kAp9a03R3dQBZF2+S3btHPJFBGvPz5EpDc06 Z0qbwRx41QQsyJstedirrlhqV1ep19S01v7or6UJkC6a4xG0979R7A71LTlpk9m9a7im T8ow== X-Received: by 10.66.154.1 with SMTP id vk1mr24806729pab.85.1384835731207; Mon, 18 Nov 2013 20:35:31 -0800 (PST) Received: from [192.168.178.20] (200.192.69.111.dynamic.snap.net.nz. [111.69.192.200]) by mx.google.com with ESMTPSA id wp8sm27209940pbc.26.2013.11.18.20.35.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 20:35:30 -0800 (PST) Message-ID: <528AEA8D.1070804@gmail.com> Date: Tue, 19 Nov 2013 17:35:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica References: <5278275C.50206@gont.com.ar> <5a9e4532c4e14bddbd9d824133820157@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <5a9e4532c4e14bddbd9d824133820157@CO1PR05MB442.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 04:35:39 -0000 On 19/11/2013 10:50, Ronald Bonica wrote: > Folks, > > Fernando presents two studies in . The second study is more interesting to me, because duplicate addresses are removed. > > The following are a few questions regarding Fernando's second study: > > 1) Fernando observes that 41% of sites discard fragmented packets. However, in a similar study (http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf) only 10% of sites discarded fragmented packets. I wonder why the two studies yield such divergent results. Well, that depends on whether there are significant differences between the observation points and/or the set of target sites for the two studies. There's certainly no law of physics that prevents both measurements being correct. > 2) Fernando observes that 44% of sites discard packets containing an 8 byte destination header, while 89% of sites discard packet containing 1 kilobyte of extension headers. Because the first number (44%) is so high, can I conclude that the second (89%) is insignificant. > Could it be that extension header length is a non-issue, because so many sites filter packets containing extension headers, regardless of their length? I don't think so. We've just agreed on an update to RFC 2460 that, if it is adopted by middleboxes, will fix or at least clarify the issue of what happens to short extension headers. We need to wait a few years to see if that happens, of course. That seems to me to be quite disjoint from the issue of whether boxes that inspect extension headers have big enough buffers, and distinct again from whether they handle fragmented headers. I think there are three problems, needing three solutions. Brian Ron > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Fernando Gont >> Sent: Monday, November 04, 2013 6:02 PM >> To: 6man@ietf.org; IPv6 Operations >> Subject: Some stats on IPv6 fragments and EH filtering on the Internet >> >> Folks, >> >> I did a presentation on the topic at the IEPG meeting earlier this >> week. >> It provides some concrete data regarding IPv6 fragmentation and >> Extension Header filtering on the Internet. >> >> The slideware is available at: >> > eh.pdf> >> >> Certainly there's *much* more work to be done in this area, but I >> thought that this could be good food sfor some of the discussions that >> we were having on the topic. >> >> Thanks, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: >> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From rbonica@juniper.net Tue Nov 19 07:29:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D11AE02F; Tue, 19 Nov 2013 07:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWPhjcJlbiwa; Tue, 19 Nov 2013 07:29:19 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id A0E7D1AE026; Tue, 19 Nov 2013 07:29:19 -0800 (PST) Received: from mail145-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Tue, 19 Nov 2013 15:29:13 +0000 Received: from mail145-va3 (localhost [127.0.0.1]) by mail145-va3-R.bigfish.com (Postfix) with ESMTP id 76F7F1A00F9; Tue, 19 Nov 2013 15:29:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z579ehzbb2dI62a3I98dI9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail145-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(199002)(189002)(164054003)(479174003)(51704005)(252514010)(24454002)(13464003)(51856001)(53806001)(49866001)(33646001)(47736001)(79102001)(76576001)(77982001)(54356001)(74706001)(56776001)(50986001)(76796001)(4396001)(59766001)(46102001)(83072001)(47976001)(74876001)(87266001)(74366001)(77096001)(56816003)(76482001)(54316002)(66066001)(81542001)(80022001)(74502001)(63696002)(81342001)(19580395003)(15975445006)(81686001)(85306002)(76786001)(69226001)(81816001)(74316001)(83322001)(80976001)(47446002)(87936001)(31966008)(65816001)(74662001)(15202345003)(2656002)(19580405001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail145-va3 (localhost.localdomain [127.0.0.1]) by mail145-va3 (MessageSwitch) id 1384874951327190_26656; Tue, 19 Nov 2013 15:29:11 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.231]) by mail145-va3.bigfish.com (Postfix) with ESMTP id 3EE853E00C9; Tue, 19 Nov 2013 15:29:11 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 19 Nov 2013 15:29:04 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 19 Nov 2013 15:29:04 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 19 Nov 2013 15:29:01 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.67]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.146]) with mapi id 15.00.0785.001; Tue, 19 Nov 2013 15:29:01 +0000 From: Ronald Bonica To: Brian E Carpenter Thread-Topic: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet Thread-Index: AQHO2bHohYR0s3IRQE+Bh6lCddmviporl0bwgAB23YCAALUaAA== Date: Tue, 19 Nov 2013 15:29:00 +0000 Message-ID: <26b868a1fe7b45c5a1dd2f688caefc19@CO1PR05MB442.namprd05.prod.outlook.com> References: <5278275C.50206@gont.com.ar> <5a9e4532c4e14bddbd9d824133820157@CO1PR05MB442.namprd05.prod.outlook.com> <528AEA8D.1070804@gmail.com> In-Reply-To: <528AEA8D.1070804@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] x-forefront-prvs: 0035B15214 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 15:29:22 -0000 QnJpYW4sDQoNCkkgc2VlIHlvdXIgcG9pbnQuIElmIHdlIGZpeCB0aGUgcHJvYmxlbXMgYXNzb2Np YXRlZCB3aXRoIGV4dGVuc2lvbiBoZWFkZXJzLCBwZW9wbGUgd2lsbCBjb25maWd1cmUgdGhlaXIg bWlkZGxlLWJveGVzIHRvIGFsbG93IHRoZW0uIFNvLCBpZiB3ZSByZXBlYXQgRmVybmFuZG8ncyBl eHBlcmltZW50IGluIGEgZmV3IHllYXJzLCB3ZSBtYXkgc2VlIHZlcnkgZGlmZmVyZW50IHJlc3Vs dHMuIA0KDQpZb3Ugc2F5IHRoYXQgdGhlcmUgYXJlIHRocmVlIGRpc3RpbmN0IHByb2JsZW1zLiBJ IGFtIGF3YXJlIG9mIHRoZSBmb2xsb3dpbmc6DQoNCi0gdGhlIHRpbnkgZnJhZ21lbnQgcHJvYmxl bSAoYWRkcmVzc2VkIGJ5IGRyYWZ0LWlldGYtNm1hbi1vdmVyc2l6ZWQtaGVhZGVyIGNoYWluKQ0K LSB0aGUgbG9uZyBoZWFkZXIgY2hhaW4gcHJvYmxlbSAoYWRkcmVzc2VkIGJ5IGRyYWZ0LWt1bWFy aS02bWFuLWxvbmctaGVhZGVycykNCg0KV2hhdCBpcyB0aGUgdGhpcmQgcHJvYmxlbT8NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0 bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIg MTgsIDIwMTMgMTE6MzUgUE0NCj4gVG86IFJvbmFsZCBCb25pY2ENCj4gQ2M6IEZlcm5hbmRvIEdv bnQ7IDZtYW5AaWV0Zi5vcmc7IElQdjYgT3BlcmF0aW9ucw0KPiBTdWJqZWN0OiBSZTogW3Y2b3Bz XSBTb21lIHN0YXRzIG9uIElQdjYgZnJhZ21lbnRzIGFuZCBFSCBmaWx0ZXJpbmcgb24NCj4gdGhl IEludGVybmV0DQo+IA0KPiBPbiAxOS8xMS8yMDEzIDEwOjUwLCBSb25hbGQgQm9uaWNhIHdyb3Rl Og0KPiA+IEZvbGtzLA0KPiA+DQo+ID4gRmVybmFuZG8gcHJlc2VudHMgdHdvIHN0dWRpZXMgaW4g PGh0dHA6Ly93d3cuaWVwZy5vcmcvMjAxMy0xMS0NCj4gaWV0Zjg4L2Znb250LWllcGctaWV0Zjg4 LWlwdjYtZnJhZy1hbmQtZWgucGRmPi4gVGhlIHNlY29uZCBzdHVkeSBpcw0KPiBtb3JlIGludGVy ZXN0aW5nIHRvIG1lLCBiZWNhdXNlIGR1cGxpY2F0ZSBhZGRyZXNzZXMgYXJlIHJlbW92ZWQuDQo+ ID4NCj4gPiBUaGUgZm9sbG93aW5nIGFyZSBhIGZldyBxdWVzdGlvbnMgcmVnYXJkaW5nIEZlcm5h bmRvJ3Mgc2Vjb25kIHN0dWR5Og0KPiA+DQo+ID4gMSkgRmVybmFuZG8gb2JzZXJ2ZXMgdGhhdCA0 MSUgb2Ygc2l0ZXMgZGlzY2FyZCBmcmFnbWVudGVkIHBhY2tldHMuDQo+IEhvd2V2ZXIsIGluIGEg c2ltaWxhciBzdHVkeQ0KPiAoaHR0cDovL3d3dy5ubG5ldGxhYnMubmwvZG93bmxvYWRzL3B1Ymxp Y2F0aW9ucy9wbXR1LWJsYWNrLWhvbGVzLW1zYy0NCj4gdGhlc2lzLnBkZikgb25seSAxMCUgb2Yg c2l0ZXMgZGlzY2FyZGVkIGZyYWdtZW50ZWQgcGFja2V0cy4gSSB3b25kZXINCj4gd2h5IHRoZSB0 d28gc3R1ZGllcyB5aWVsZCBzdWNoIGRpdmVyZ2VudCByZXN1bHRzLg0KPiANCj4gV2VsbCwgdGhh dCBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlcmUgYXJlIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJl dHdlZW4NCj4gdGhlIG9ic2VydmF0aW9uIHBvaW50cyBhbmQvb3IgdGhlIHNldCBvZiB0YXJnZXQg c2l0ZXMgZm9yIHRoZSB0d28NCj4gc3R1ZGllcy4gVGhlcmUncyBjZXJ0YWlubHkgbm8gbGF3IG9m IHBoeXNpY3MgdGhhdCBwcmV2ZW50cyBib3RoDQo+IG1lYXN1cmVtZW50cyBiZWluZyBjb3JyZWN0 Lg0KPiANCj4gPiAyKSBGZXJuYW5kbyBvYnNlcnZlcyB0aGF0IDQ0JSBvZiBzaXRlcyBkaXNjYXJk IHBhY2tldHMgY29udGFpbmluZyBhbg0KPiA4IGJ5dGUgZGVzdGluYXRpb24gaGVhZGVyLCB3aGls ZSA4OSUgb2Ygc2l0ZXMgZGlzY2FyZCBwYWNrZXQgY29udGFpbmluZw0KPiAxIGtpbG9ieXRlIG9m IGV4dGVuc2lvbiBoZWFkZXJzLiBCZWNhdXNlIHRoZSBmaXJzdCBudW1iZXIgKDQ0JSkgaXMgc28N Cj4gaGlnaCwgY2FuIEkgY29uY2x1ZGUgdGhhdCB0aGUgc2Vjb25kICg4OSUpIGlzIGluc2lnbmlm aWNhbnQuDQo+IA0KPiA+IENvdWxkIGl0IGJlIHRoYXQgZXh0ZW5zaW9uIGhlYWRlciBsZW5ndGgg aXMgYSBub24taXNzdWUsIGJlY2F1c2Ugc28NCj4gbWFueSBzaXRlcyBmaWx0ZXIgcGFja2V0cyBj b250YWluaW5nIGV4dGVuc2lvbiBoZWFkZXJzLCByZWdhcmRsZXNzIG9mDQo+IHRoZWlyIGxlbmd0 aD8NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgc28uIFdlJ3ZlIGp1c3QgYWdyZWVkIG9uIGFuIHVwZGF0 ZSB0byBSRkMgMjQ2MCB0aGF0LCBpZg0KPiBpdCBpcyBhZG9wdGVkIGJ5IG1pZGRsZWJveGVzLCB3 aWxsIGZpeCBvciBhdCBsZWFzdCBjbGFyaWZ5IHRoZSBpc3N1ZSBvZg0KPiB3aGF0IGhhcHBlbnMg dG8gc2hvcnQgZXh0ZW5zaW9uIGhlYWRlcnMuIFdlIG5lZWQgdG8gd2FpdCBhIGZldyB5ZWFycyB0 bw0KPiBzZWUgaWYgdGhhdCBoYXBwZW5zLCBvZiBjb3Vyc2UuIFRoYXQgc2VlbXMgdG8gbWUgdG8g YmUgcXVpdGUgZGlzam9pbnQNCj4gZnJvbSB0aGUgaXNzdWUgb2Ygd2hldGhlciBib3hlcyB0aGF0 IGluc3BlY3QgZXh0ZW5zaW9uIGhlYWRlcnMgaGF2ZSBiaWcNCj4gZW5vdWdoIGJ1ZmZlcnMsIGFu ZCBkaXN0aW5jdCBhZ2FpbiBmcm9tIHdoZXRoZXIgdGhleSBoYW5kbGUgZnJhZ21lbnRlZA0KPiBo ZWFkZXJzLiBJIHRoaW5rIHRoZXJlIGFyZSB0aHJlZSBwcm9ibGVtcywgbmVlZGluZyB0aHJlZSBz b2x1dGlvbnMuDQo+IA0KPiAgICBCcmlhbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogaXB2Ni1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPj4gT2YgRmVybmFuZG8gR29udA0K PiA+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDA0LCAyMDEzIDY6MDIgUE0NCj4gPj4gVG86IDZt YW5AaWV0Zi5vcmc7IElQdjYgT3BlcmF0aW9ucw0KPiA+PiBTdWJqZWN0OiBTb21lIHN0YXRzIG9u IElQdjYgZnJhZ21lbnRzIGFuZCBFSCBmaWx0ZXJpbmcgb24gdGhlDQo+ID4+IEludGVybmV0DQo+ ID4+DQo+ID4+IEZvbGtzLA0KPiA+Pg0KPiA+PiBJIGRpZCBhIHByZXNlbnRhdGlvbiBvbiB0aGUg dG9waWMgYXQgdGhlIElFUEcgbWVldGluZyBlYXJsaWVyIHRoaXMNCj4gPj4gd2Vlay4NCj4gPj4g SXQgcHJvdmlkZXMgc29tZSBjb25jcmV0ZSBkYXRhIHJlZ2FyZGluZyBJUHY2IGZyYWdtZW50YXRp b24gYW5kDQo+ID4+IEV4dGVuc2lvbiBIZWFkZXIgZmlsdGVyaW5nIG9uIHRoZSBJbnRlcm5ldC4N Cj4gPj4NCj4gPj4gVGhlIHNsaWRld2FyZSBpcyBhdmFpbGFibGUgYXQ6DQo+ID4+IDxodHRwOi8v d3d3LmllcGcub3JnLzIwMTMtMTEtaWV0Zjg4L2Znb250LWllcGctaWV0Zjg4LWlwdjYtZnJhZy1h bmQtDQo+ID4+IGVoLnBkZj4NCj4gPj4NCj4gPj4gQ2VydGFpbmx5IHRoZXJlJ3MgKm11Y2gqIG1v cmUgd29yayB0byBiZSBkb25lIGluIHRoaXMgYXJlYSwgYnV0IEkNCj4gPj4gdGhvdWdodCB0aGF0 IHRoaXMgY291bGQgYmUgZ29vZCBmb29kIHNmb3Igc29tZSBvZiB0aGUgZGlzY3Vzc2lvbnMNCj4g Pj4gdGhhdCB3ZSB3ZXJlIGhhdmluZyBvbiB0aGUgdG9waWMuDQo+ID4+DQo+ID4+IFRoYW5rcywN Cj4gPj4gLS0NCj4gPj4gRmVybmFuZG8gR29udA0KPiA+PiBlLW1haWw6IGZlcm5hbmRvQGdvbnQu Y29tLmFyIHx8IGZnb250QHNpNm5ldHdvcmtzLmNvbSBQR1ANCj4gRmluZ2VycHJpbnQ6DQo+ID4+ IDc4MDkgODRGNSAzMjJFIDQ1QzcgRjFDOSAzOTQ1IDk2RUUgQTlFRiBEMDc2IEZGRjENCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3Jv dXAgbWFpbGluZyBsaXN0DQo+ID4+IGlwdjZAaWV0Zi5vcmcNCj4gPj4gQWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2 b3BzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KPiA+DQo+IA0KDQo= From yangshu1988@gmail.com Tue Nov 19 00:10:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB71ACC85; Tue, 19 Nov 2013 00:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_PdXOrqIuQh; Tue, 19 Nov 2013 00:10:25 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EA8501ACC82; Tue, 19 Nov 2013 00:10:24 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id p61so2604651wes.22 for ; Tue, 19 Nov 2013 00:10:18 -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=Ul8+qQpxkayDnb1bwSaehMZBdpQ7F9SZO/ZWdoshbdA=; b=e8LJRttNBhJjjeO9YydI4LA/YAJXcxGV24AiTglNXsc0QJ9HL+Z/I3rVuLnXggUbgP CcMPCeyoR0SpL96i6C02mt8KAcR4kvE5UV2xjrqtyu1k7zpyqHdTKD35OSJfoSc7YzdG kEhWtPYmz88i+RcWnSu4ZCXfPbETY/S+7QWZW/z9OLmkv4Dd1hVZu49QACO+s7YyK2bP N4hU2CEwj+SXTkfWjxXp8tzG1htbuIO147xCRe3O1qx21Q2kh0wmgUcVnVQNlHz6RiQy RrkvM4+qjA6q4OQAZX41ZY3vBjMKzL8U7SULjlZxPadCcb5mov+U7EJqXqqfSp45xevG mUgw== MIME-Version: 1.0 X-Received: by 10.194.200.100 with SMTP id jr4mr5102157wjc.37.1384848618423; Tue, 19 Nov 2013 00:10:18 -0800 (PST) Received: by 10.194.36.196 with HTTP; Tue, 19 Nov 2013 00:10:18 -0800 (PST) In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 19 Nov 2013 16:10:18 +0800 Message-ID: From: Shu Yang To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7bb03e1ef80e9104eb83316c X-Mailman-Approved-At: Tue, 19 Nov 2013 08:12:57 -0800 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Juliusz Chroboczek , "ospf@ietf.org" , "homenet@ietf.org Group" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 08:10:27 -0000 --047d7bb03e1ef80e9104eb83316c Content-Type: text/plain; charset=ISO-8859-1 > Ok, we will make it public in this week. The page for the project is here: https://github.com/t-routing/traffic-class-routing-system-based-on-OSPFv3 It's still in development status, and we will keep improving it. Shu Yang On Mon, Nov 11, 2013 at 3:06 PM, Shu Yang wrote: > > I agree with Juliusz, a public repository would be much better, even > > if it only contains "in development" code. > > > > If the code will be open sourced in the end anyways I don't see any > drawbacks. > > > > Henning Rogge > > Ok, we will make it public in this week. > > Shu Yang > --047d7bb03e1ef80e9104eb83316c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Ok, we will make it public in this week.
<= div>The page for the project is here:=A0https://github.com/t-routing/traffic-class-routing-system-= based-on-OSPFv3
It's still in development status,= and we will keep improving it.

Shu Yang


On Mon,= Nov 11, 2013 at 3:06 PM, Shu Yang <yangshu1988@gmail.com> wrote:
> I agree with Juliusz,= a public repository would be much better, even
> if it only contains "in development" code.
>
> If the code will be open sourced in the end anyways I don't see an= y drawbacks.
>
> Henning Rogge

Ok, we will make it public in this week.

Shu Yang

--047d7bb03e1ef80e9104eb83316c-- From jch@pps.univ-paris-diderot.fr Tue Nov 19 02:22:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6700D1AD8CD; Tue, 19 Nov 2013 02:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9We4TGlFZnZ; Tue, 19 Nov 2013 02:22:47 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5121AD8F4; Tue, 19 Nov 2013 02:22:47 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id rAJAMafL003582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Nov 2013 11:22:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id rAJAMaI5004749; Tue, 19 Nov 2013 11:22:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1D97F5B449; Tue, 19 Nov 2013 11:22:36 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ucBultFNswwi; Tue, 19 Nov 2013 11:22:34 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 817C45B446; Tue, 19 Nov 2013 11:22:34 +0100 (CET) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1ViiS2-0007SV-9s; Tue, 19 Nov 2013 11:22:34 +0100 Date: Tue, 19 Nov 2013 11:22:34 +0100 Message-ID: <7i8uwky9lh.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Shu Yang In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 19 Nov 2013 11:22:36 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 19 Nov 2013 11:22:36 +0100 (CET) X-Miltered: at korolev with ID 528B3BEC.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 528B3BEC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 528B3BEC.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 528B3BEC.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 528B3BEC.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 528B3BEC.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham X-Mailman-Approved-At: Tue, 19 Nov 2013 08:12:57 -0800 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Henning Rogge , "ospf@ietf.org" , "homenet@ietf.org Group" , Routing WG Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:22:49 -0000 > > Ok, we will make it public in this week. > The page for the project is here: https://github.com/t-routing/ > traffic-class-routing-system-based-on-OSPFv3 Thanks, but could you please point us at your code? That's a full Quagga tree merged with a full Click tree, with no development history. (I've quickly checked the Quagga-FIB interface, and haven't found anything new in there, but then perhaps I haven't looked hard enough.) -- Juliusz From markus.stenberg@iki.fi Tue Nov 19 02:31:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FF51ADBE8; Tue, 19 Nov 2013 02:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7WCcTnc7CxG; Tue, 19 Nov 2013 02:31:18 -0800 (PST) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id EEAD81ADBF7; Tue, 19 Nov 2013 02:31:17 -0800 (PST) Received: from kosame.lan (80.220.67.193) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 526FA42301E20C0F; Tue, 19 Nov 2013 12:31:09 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Markus Stenberg In-Reply-To: <7i8uwky9lh.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 19 Nov 2013 12:30:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> <7i8uwky9lh.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Tue, 19 Nov 2013 08:12:57 -0800 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Henning Rogge , Markus Stenberg , "ospf@ietf.org" , "homenet@ietf.org Group" , Routing WG , Shu Yang Subject: Re: [v6ops] [homenet] Tsinghua work on source/destination routing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:31:20 -0000 On 19.11.2013, at 12.22, Juliusz Chroboczek = wrote: >>> Ok, we will make it public in this week. >=20 >> The page for the project is here: https://github.com/t-routing/ >> traffic-class-routing-system-based-on-OSPFv3 >=20 > Thanks, but could you please point us at your code? That's a full > Quagga tree merged with a full Click tree, with no development = history. >=20 > (I've quickly checked the Quagga-FIB interface, and haven't found > anything new in there, but then perhaps I haven=92t looked hard = enough.) Looks like the integration with click is done right from ospf6d and it = never even goes to zebra.=20 Two tips for next github export: - save history so it=92s more convenient to compare with baseline (now I = needed to do fairly arcane diff due to non-clean tree + no history) - put cleaned tree (no *~, no binaries such as *.o) Kind of sad, I was hoping for general src+dst aware Quagga code :) Cheers, -Markus= From markzzzsmith@yahoo.com.au Tue Nov 19 11:09:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2A31AE171 for ; Tue, 19 Nov 2013 11:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.502 X-Spam-Level: * X-Spam-Status: No, score=1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua4sgwX5CRBE for ; Tue, 19 Nov 2013 11:09:37 -0800 (PST) Received: from nm46.bullet.mail.bf1.yahoo.com (nm46.bullet.mail.bf1.yahoo.com [216.109.114.62]) by ietfa.amsl.com (Postfix) with ESMTP id 33AC01AE137 for ; Tue, 19 Nov 2013 11:09:37 -0800 (PST) Received: from [98.139.215.140] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 19 Nov 2013 19:09:31 -0000 Received: from [98.139.212.209] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 19 Nov 2013 19:09:30 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 19 Nov 2013 19:09:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 756767.87643.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 31645 invoked by uid 60001); 19 Nov 2013 19:09:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1384888170; bh=nLuOp7eMaa0R70wuKWckQ+TLeMtQ/+czXKMBmeOiZpM=; 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=dz0J42PxunYds4wctIfseg8cpwXE5uVJPzoLpmP4XZlMWYIjeD1aBP3n3drga95yL3apXAJzpqBAP0sJ2vBoB1gYeggB2rJPooqi/jVoot9H6ZkWQcXX+ywoTD3Q0a0qdJfjF04xziBNdgvp587c3DiKes3/yuC9zGw5VBewWf8= 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=StoQ2Mg6YR/0OQdYGLmiWdbGBVrH2cQlRpb6/Tk4xHSLSRPVhpSd/NuzewdfDkc28rzOPAAR2qeW0tememFjLCZ8alXYsCeZaSGZ76XvsUHuB3C4tS1VNYPjnLuhPWtVjO1QNxshH0lz6eF9M8l6o+dmHQ/l2aRESKjnEJBXdH8=; X-YMail-OSG: BJDxPtgVM1l1w2uKxQfE2YpAO1Wvo5ic5it7CfoHdo9EBuc 9QMeuI481h_ZJ9V1.q8M1vXq4mB.7aRjXupQdZaz3xV2GJcaJkItk050Ly6c RJhDPXGiG_RKeoMpFTBo1dfoeJzzSsJ8rQguHBm1BoAwQOJ_F20V680_h8m1 jkiwFCenDZWgk6vY0SIC7JloAGStZVFPn__IR400fpC5Kle4Xs54YWQTjSPG g0H8kYrG26xIpTLVFYeWblhXGwoAUVXUcKJ00.q1YUSb2MR73w4AoPja_uxk XZhFtj.vJ_VMyx0fhpKzvrLnfrfjkwGIzzFr0XVntD7AOZk_lvO8X9_VSbgS dUtOyXZ6vQFoNWEn.TZ1uejS5o.YEdmXi22TkiYRR.YQz0Hox6LhSYEjTutN VJ_ovJlKStANm.MqqYGR6Dzfrv2.zODhtfAaiIsBE8YnpSRj6CpQ3O65yuTE _uJmWx40pljrBpFkMbXMZ6v9UgcQq14FZN21k1TabbKs.BGDlk0dghp7H0Ju 2ajluAS00uzYF4KRQrT6_XmQaM7JKSivlRohzcM3ND2ee2.zXVw.5d6sUHvM fNyuk0R8ETDzuE5KBK1H0jY1llcEyVcIfZjTmjf8.fX8bBh9GiCkrI7w7.iH Uqnh_cxEV7gWEgv4dk3prZvWWG9IrxrgyO3ZblH98ymFhvdTmWGESaQGfhck PPKWnkBMZda9jVSW97wR.mEwQwNZrT_.OptTFwE.xP6qMxKiE_0Epq4BID0t Joz.H5ZYiyQpV8a.s9MLRoDea.loKaD9oOFl0KpX5Y4YqkME4zbSaN490HLS 6Kwan3ROhtRszmakTgqWRB_WDjFOzJna0rpHjQQwcuIy5DjfRaU34tIFOV4I .ElHyFvVikdHnpTRIOIC8JX69B0Bjfu2p2GoSpfPt Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Tue, 19 Nov 2013 11:09:30 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiZGUgQnLDvG4sIE1hcmt1cyIgPG1hcmt1cy5kZWJydWVuQGJzaS5idW5kLmRlPgo.IFRvOiB2Nm9wc0BpZXRmLm9yZzsgTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6IE1hcmMgTGFtcG8gPG1hcmMubGFtcG8uaWV0ZkBnbWFpbC5jb20.OyBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.Cj4gU2VudDogTW9uZGF5LCAxOCBOb3ZlbWJlciAyMDEzIDk6MzcgUE0KPiBTdWJqZWN0OiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.166.601 References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <1384583413.2103.YahooMailNeo@web142501.mail.bf1.yahoo.com> <201311181137.21672.markus.debruen@bsi.bund.de> Message-ID: <1384888170.31515.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Tue, 19 Nov 2013 11:09:30 -0800 (PST) From: Mark ZZZ Smith To: =?iso-8859-1?Q?de_Br=FCn=2C_Markus?= , "v6ops@ietf.org" In-Reply-To: <201311181137.21672.markus.debruen@bsi.bund.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 19:09:40 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "de Br=FCn, Markus" =0A> To: v6ops@ietf.org; Mark ZZZ Smith =0A> Cc: Marc Lampo ; Mikael Abr= ahamsson =0A> Sent: Monday, 18 November 2013 9:37 PM=0A> = Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC=0A> =0A>>= =A0 >[...], but does this mean accessible from anywhere on the Internet ?= =0A> =0A>>=A0 Actually, I think you're probably going to want your refriger= ator to be=0A>>=A0 able to access the Internet, [...]=0A> =0A> "Access to t= he internet" and "accessible from the internet" =0A> are two seperate =0A> = things.Perhaps I want my fridge to access the internet but not the other wa= y =0A> around.=0A>=A0=0A=0AIt might depend on whether you want to find out = what is in it when you're at the supermarket. It might be convenient to kno= w if you need to buy milk when you're there.=0A=0A=0A> There was a vulnerab= ility in some heating-systems a few month ago [1]. An =0A> attacker could r= emotely shut down the heating. This is the kind of thing one =0A> does not = want to happen.=0A>=A0=0A=0ATrue.=0A=0AHowever, if you were the manufacture= r of this heating system, how could you be sure your customers are not atta= ching the device directly to an unfettered Internet connection? You could t= ry putting a warning on the box or in the manual saying "Don't plug into th= e Internet" or "There MUST be a firewall in front of this device." That mig= ht not confuse people like us, but I'm pretty sure it will confuse the majo= rity of consumers.=0A=0AThe only way for a manufacturer to be sure of the s= ecurity of the device is to assume the worst and have the device be totally= self reliant for its Internet protection. If the manufacturer does that, t= hen there are no warnings in the manual or on the box that may be ignored, = or phone calls from confused customers. That was my experience with my "sma= rt" Internet connected TV and Blu-ray player. I've 'nmap' scanned them, and= they look as they they've been Internet hardened.=0A=0AIt is also worth ke= eping in mind that the CPE itself may not be perfectly secure, and may be a= target itself. If it is compromised, then any protection it used to provid= e may now be gone. I'd forgotten about it, however the ISP I worked for in = 2009 had quite a number of customers who's CPE was infected by this malware= :=0A=0Ahttp://en.wikipedia.org/wiki/Psyb0t=0A=0A=0AIIRC, impacted customers= numbered in the 100s, I suspect because the CPE model was quite old at tha= t point (it was already being sold in 2005 when I started there), so many c= ustomers had replaced it. It would have remained unnoticed by both us and t= he customers if it hadn't caused customers' Internet connections to fail.= =0A=0AThe Carna Botnet also leveraged insecure CPE to conduct the "Internet= Census 2012", which I think is further evidence that there shouldn't be ab= solute faith in the security of CPE . (http://lists.ausnog.net/pipermail/au= snog/2013-September/020338.html)=0A=0ASo I think device manufacturers would= be wise to make a device/appliance protect itself, even if they believe th= ere commonly might be an upstream networking device perform some sort of fi= rewalling function.=0A=0A=0ARegards,=0AMark.=0A=0A=A0=0A=0A=A0=0A=0A=0A=0A= =0A> Regards,=0A> Markus=0A> =0A> [1] =0A> http://www.heise.de/security/mel= dung/Vaillant-Heizungen-mit-Sicherheits-Leck-1840919.html=0A> =0A> =0A> =0A= > __________ urspr=FCngliche Nachricht __________=0A> =0A> Von:=A0=A0=A0 = =A0=A0=A0 Mark ZZZ Smith =0A> Datum:=A0=A0=A0 Sa= mstag, 16. November 2013, 07:30:13=0A> An:=A0=A0=A0 =A0=A0=A0 Marc Lampo , Mikael Abrahamsson =0A> =0A> K= opie:=A0=A0=A0 "v6ops@ietf.org WG" =0A> Betr.:=A0=A0=A0 Re:= [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC=0A> =0A>>=A0 >_______= _________________________=0A>>=A0 > From: Marc Lampo =0A>>=A0 >To: Mikael Abrahamsson =0A>>=A0 >Cc: "v6op= s@ietf.org WG" =0A>>=A0 >Sent: Thursday, 14 November 2013 9= :50 PM=0A>>=A0 >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-securit= y WGLC=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >I realise now that "unsolicit= ed" is a word allowing multiple=0A>>=A0 > interpretations (but also used in= RFC 6092).=A0 But we seem to have got =0A> it=0A>>=A0 > right.=0A>>=A0 >= =0A>>=A0 >Anyway, the fact that some service, on an internal device, is wil= ling =0A> to=0A>>=A0 > accept connections on port XYZ, does not, in my opin= ion, imply that =0A> those=0A>>=A0 > connections may also come from the out= side Internet. Back to the =0A> example=0A>>=A0 > with the refrigerator := =0A>>=A0 >suppose it has a service (port XYZ) that allows it to be queried = for =0A> its=0A>>=A0 > contents.=0A>>=A0 >=0A>>=A0 >Probably great when one= is at home, but does this mean accessible from=0A>>=A0 > anywhere on the I= nternet ?=0A>>=A0 >=0A>>=A0 >In my opinion : not before the owner has expli= citly instructed his CPE =0A> to=0A>>=A0 > allow incoming connections (RFC = 6092, REC-48).=0A>> =0A>>=A0 Actually, I think you're probably going to wan= t your refrigerator to be=0A>>=A0 able to access the Internet, as well as y= our toaster, answering machine,=0A>>=A0 rice cooker, washing machine etc.= =0A>> =0A>>=A0 I think appliances, if they aren't already, are going to bec= ome =0A> computers,=0A>>=A0 with as much done via software/firmware as poss= ible, instead of hardware,=0A>>=A0 because hardware is much harder and more= expensive to change, both during=0A>>=A0 development and after it is sold = to the customer.=0A>> =0A>>=A0 However, software/firmware is still hard to = change if the customer has to=0A>>=A0 either take it back to the manufactur= er, or plug a PC or USB stick into it=0A>>=A0 to update the software/firmwa= re. Having the device be able to update itself=0A>>=A0 over the Internet wi= ll be both much more user/customer friendly and much=0A>>=A0 cheaper for th= e manufacturer.=A0=0A>> =0A>>=A0 So manufacturers have an incentive to make= their appliances be able to=0A>>=A0 attach to the Internet, and their cust= omers have an incentive to attach=0A>>=A0 them. As with tablets and smartph= ones, the manufacturer won't be able =0A> to=0A>>=A0 vouch for the existenc= e of any upstream network "firewalls", nor =0A> will they=0A>>=A0 successfu= lly be able to ask the customer of their existence,=A0so the=0A>>=A0 manufa= cturer will have to assume the worst, and therefore harden the=0A>>=A0 appl= iance against publicly addressed unfettered Internet access.=0A>> =0A>>=A0 = Regards,=0A>>=A0 Mark.=0A>> =0A>>=A0 ______________________________________= _________=0A>>=A0 v6ops mailing list=0A> =0A>>=A0 v6ops@ietf.org=0A>>=A0 ht= tps://www.ietf.org/mailman/listinfo/v6ops=0A> From brian.e.carpenter@gmail.com Tue Nov 19 11:27:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7B61AE1A9; Tue, 19 Nov 2013 11:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3zn0G18T3z8; Tue, 19 Nov 2013 11:27:03 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 057EC1AE1A5; Tue, 19 Nov 2013 11:27:02 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id lf10so1552082pab.0 for ; Tue, 19 Nov 2013 11:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=i7NSRTWRZo0HjtUiNbJ0UUOX1aiK3oypX6cQYoWXVqw=; b=Jy09ZyrZHCW98C8xeNBT2aYn/nzJtbyPd7tOHV6NjSp4A00XIbPRh1ZG9d8iVImFxW sALxv3N2AJH0Md83W/eUTBfhOJfobjJSpVFAdRbM285f6HSct4RtnSFgKx2zS+orgsbq rt99d6B+kPmM+XWIrZASPADtp+YcB8aP1PDdkRlgP+dDEYA8MjusmTCBsWSAT8Nbiq1J dvy+j/FN0wjcRREBasj4cwUDMXwbMH9IbZPVTMxzKwIg0GJL5fPe3wr6Yo8ZD802MteR THhk7ho7MOL3CI1p0LN4aTHECRKfSZyAqa6e2/TRXsNlF/SinKBttrakh2ls1C/s/HvK uQ5A== X-Received: by 10.68.203.73 with SMTP id ko9mr2641514pbc.170.1384889217015; Tue, 19 Nov 2013 11:26:57 -0800 (PST) Received: from [192.168.178.20] (240.200.69.111.dynamic.snap.net.nz. [111.69.200.240]) by mx.google.com with ESMTPSA id dq3sm32283058pbc.35.2013.11.19.11.26.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 11:26:55 -0800 (PST) Message-ID: <528BBB80.5010508@gmail.com> Date: Wed, 20 Nov 2013 08:26:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica References: <5278275C.50206@gont.com.ar> <5a9e4532c4e14bddbd9d824133820157@CO1PR05MB442.namprd05.prod.outlook.com> <528AEA8D.1070804@gmail.com> <26b868a1fe7b45c5a1dd2f688caefc19@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <26b868a1fe7b45c5a1dd2f688caefc19@CO1PR05MB442.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 19:27:05 -0000 On 20/11/2013 04:29, Ronald Bonica wrote: > Brian, > > I see your point. If we fix the problems associated with extension headers, people will configure their middle-boxes to allow them. So, if we repeat Fernando's experiment in a few years, we may see very different results. > > You say that there are three distinct problems. I am aware of the following: > > - the tiny fragment problem (addressed by draft-ietf-6man-oversized-header chain) > - the long header chain problem (addressed by draft-kumari-6man-long-headers) > > What is the third problem? - middleboxes that don't deal with all header types (addressed by draft-ietf-6man-ext-transmit) Brian > > Ron > > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, November 18, 2013 11:35 PM >> To: Ronald Bonica >> Cc: Fernando Gont; 6man@ietf.org; IPv6 Operations >> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on >> the Internet >> >> On 19/11/2013 10:50, Ronald Bonica wrote: >>> Folks, >>> >>> Fernando presents two studies in > ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. The second study is >> more interesting to me, because duplicate addresses are removed. >>> The following are a few questions regarding Fernando's second study: >>> >>> 1) Fernando observes that 41% of sites discard fragmented packets. >> However, in a similar study >> (http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc- >> thesis.pdf) only 10% of sites discarded fragmented packets. I wonder >> why the two studies yield such divergent results. >> >> Well, that depends on whether there are significant differences between >> the observation points and/or the set of target sites for the two >> studies. There's certainly no law of physics that prevents both >> measurements being correct. >> >>> 2) Fernando observes that 44% of sites discard packets containing an >> 8 byte destination header, while 89% of sites discard packet containing >> 1 kilobyte of extension headers. Because the first number (44%) is so >> high, can I conclude that the second (89%) is insignificant. >> >>> Could it be that extension header length is a non-issue, because so >> many sites filter packets containing extension headers, regardless of >> their length? >> >> I don't think so. We've just agreed on an update to RFC 2460 that, if >> it is adopted by middleboxes, will fix or at least clarify the issue of >> what happens to short extension headers. We need to wait a few years to >> see if that happens, of course. That seems to me to be quite disjoint >> from the issue of whether boxes that inspect extension headers have big >> enough buffers, and distinct again from whether they handle fragmented >> headers. I think there are three problems, needing three solutions. >> >> Brian >> Ron >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >>>> Of Fernando Gont >>>> Sent: Monday, November 04, 2013 6:02 PM >>>> To: 6man@ietf.org; IPv6 Operations >>>> Subject: Some stats on IPv6 fragments and EH filtering on the >>>> Internet >>>> >>>> Folks, >>>> >>>> I did a presentation on the topic at the IEPG meeting earlier this >>>> week. >>>> It provides some concrete data regarding IPv6 fragmentation and >>>> Extension Header filtering on the Internet. >>>> >>>> The slideware is available at: >>>> >>> eh.pdf> >>>> >>>> Certainly there's *much* more work to be done in this area, but I >>>> thought that this could be good food sfor some of the discussions >>>> that we were having on the topic. >>>> >>>> Thanks, >>>> -- >>>> Fernando Gont >>>> e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP >> Fingerprint: >>>> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From dwing@cisco.com Tue Nov 19 12:04:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9226E1AE19D for ; Tue, 19 Nov 2013 12:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zWeJJ1CXw5P for ; Tue, 19 Nov 2013 12:04:19 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA5D1AE032 for ; Tue, 19 Nov 2013 12:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=985; q=dns/txt; s=iport; t=1384891453; x=1386101053; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Yt2fgHlk0+E6wwuh1MDq3h7LuaNyycMYhuwwf0DqqNY=; b=AGjPLrrFRVVItsAw2OfumsjuH2cA6XzhZV1uhsn+SvZubB6PpxrHwOXa b/ZuuH2TWtuJZE/I+QSB74mpyEiTuIa+YnSffNk9rpUIb4oK5xHwaMJTZ xMW7vz5QeHK3C/4TZRwGRh+lCUVyRA7iS71C4Cygxeej/a3HpP+t0iPsq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIXDi1KrRDoI/2dsb2JhbABZDoJ5wEuBIRZ0giUBAQEDATo/BQsLDgouVwYTh3sFv2MXjyQzB4MggRIDiUKOUJINgmlgGw X-IronPort-AV: E=Sophos;i="4.93,731,1378857600"; d="scan'208";a="94960768" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 19 Nov 2013 20:04:13 +0000 Received: from sjc-vpn1-158.cisco.com (sjc-vpn1-158.cisco.com [10.21.96.158]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAJK43LL028291; Tue, 19 Nov 2013 20:04:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Tue, 19 Nov 2013 12:04:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> <0154CE2C-C5EF-44FB-9B6D-5B2077267329@ecs.soton.ac.uk> <20131114093318.GG81676@Space.Net> <152585E9-5D19-4F2E-8ED1-32925DE69137@ecs.soton.ac.uk> <20131114101829.GM81676@Space.Net> To: Tim Chown X-Mailer: Apple Mail (2.1510) Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 20:04:20 -0000 On Nov 14, 2013, at 2:23 AM, Tim Chown wrote: > On 14 Nov 2013, at 10:18, Gert Doering wrote: >=20 >> Hi, >>=20 >> On Thu, Nov 14, 2013 at 10:14:28AM +0000, Tim Chown wrote: >>>>> That was about the NAT64 WKP appearing - or being added to - the = 6724 policy table. There is now a DHCPv6 option for that. >>>=20 >>> I believe that at least both Cisco and ISC are working on = implementations. >>=20 >> That sounds like "the server side" - which is needed, but shouldn't = take >> a miracle to add. >>=20 >> More interesting to me would be "client side" :-) >=20 > Indeed. And always the main problem/challenge with any new DHCPv6 = option. "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050 = (previously draft-ietf-behave-nat64-discovery-heuristic)] does not rely = on the DHCP option. Folks say it works. But there is a general dislike = for heuristics, for lots of good reasons.=20 -d From lorenzo@google.com Tue Nov 19 22:21:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2B31AE338 for ; Tue, 19 Nov 2013 22:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roLOcObPohhI for ; Tue, 19 Nov 2013 22:21:10 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA11AE336 for ; Tue, 19 Nov 2013 22:21:09 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so6937429iec.19 for ; Tue, 19 Nov 2013 22:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H63Q8lRYfvCOCoP8a6rSYfh4MjMakm0UZJ7CkLeoyIg=; b=jUTvyGaM8mMqeSp7P5iwBXAJaa6NxwYvhA0KzyPnr78TgaNna3emgxRXHR3x8ACQoG wQGqbkfqid0mOST/1FosPraMk39ISt9RCsyPgIMLHeQX14998vFg2JcusOn5oZ8mkEGR 6luPkHFn+Kt4rwA+471nVLd96tqylORXXP9mb0GvQWDb1/6TJtax7juigI7gAdpK42+h A7lnSGH4NUUSxPVVMTQXITDQp2BBItnN4eXTqZjI9qobZW1cqymTOLvdyXzaBPXIxhTB iX+KxkIPxph2H0jZgjR2mAygS5t9UbBMEn/b24QhvenR9s2vCW07CNGB4hwPERd0c2x+ A34A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H63Q8lRYfvCOCoP8a6rSYfh4MjMakm0UZJ7CkLeoyIg=; b=bokUjl8LZ28RTqQELgZQfwA3LQuMtLHKIpszu20x0hm/CeuMsAhhfj3u5R7SH7Riz6 iB5GCUdL3M0YUGJS7aX4R8NgEWp52wVr7aMe+CRF+LPc9BsyL88HL5WT17imAei9DVoE jHUGxYUBIF+t7CpRg7y9zXLrHd/rMIhaQJ9YkAr2UodqkcLPbs8GB8xlJJmIDfGtuzik ZExjjDd70knWbB826hcLQEk3hE3zyMS1VriBt9zMefYWW+H/23agZaPWtrqj5jIU/Q47 Rca9XqrhNGdYjJL0RYmU7AA3llr/GoZWW/A0Hkrl1sFP/bWQfufGixyi5Ouv3oWUjn3H KmlQ== X-Gm-Message-State: ALoCoQnD0xMnvZvm0uR3Z71q7lK/lz+7ht3ux7GTovItAeUIWJEkxL1nnVAhoisppdw+gfxT8+QUzPaCOivMg3e7ZSSVYjLjlt/aolhYX5u0Gg/m1Niw9Kjfa/MC1NkP7uA5OmQj/xeJHSLjgwbFTHK8BApkcTnKz0ZNEvKO4+TZWhG502qlEIKI+OnIxjYCOVdFJ1pqTj1+ X-Received: by 10.42.250.148 with SMTP id mo20mr3888825icb.34.1384928463654; Tue, 19 Nov 2013 22:21:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Tue, 19 Nov 2013 22:20:43 -0800 (PST) In-Reply-To: <52849009.80408@fud.no> References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> From: Lorenzo Colitti Date: Wed, 20 Nov 2013 15:20:43 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=20cf300e4e511dacb304eb95c9b7 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:21:11 -0000 --20cf300e4e511dacb304eb95c9b7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 14, 2013 at 5:55 PM, Tore Anderson wrote: > One could use a ULA prefix for DNS64/NAT64, which would make native > IPv4 be preferred according to RFC 6724. > But then if you have IPv6-only with 464xlat you end up preferring 464xlat over NAT64. --20cf300e4e511dacb304eb95c9b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --20cf300e4e511dacb304eb95c9b7-- From lorenzo@google.com Tue Nov 19 22:51:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBFF1AE35E for ; Tue, 19 Nov 2013 22:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkHJdNHhUStP for ; Tue, 19 Nov 2013 22:51:07 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9598F1AE35D for ; Tue, 19 Nov 2013 22:51:07 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id u16so12623822iet.20 for ; Tue, 19 Nov 2013 22:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=me5EGiaco+gdh1/Of3zgSVbdvAMjVQm2hOTmPy5L0ro=; b=ThecD09ds0FWlk8zwv3GxY1jHBCEKjw7afb0rZOBk6tv/qJD27uAMJZw/UqqlpJ8G8 WcaKVd7Q7/mTYYLv8nOu06WhLLYe85d3v3q1FTggTtK2Qw0S+VkzL/tVFn0f9Khk868w QrWY8HsQxWKcxck/GNEeTv4DtjIZt59hiJOsTXZJk/qQ57qQKGdSh355VRsxCaojkUHc Mv5dW/CAIcTAkRPbAsbgyoUeWBuBKekluO6m5P8rgZCVV1R3d0C0G4I4UkTJ7iFQBedS ySGPG/Vbqqnvx6F8WZ+HypkWgL9n/QHqWHAEs3huBCKtbhiThDhYbWhQEXceaAsZtq8O oFgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=me5EGiaco+gdh1/Of3zgSVbdvAMjVQm2hOTmPy5L0ro=; b=TmuZ6+w26hXem09KKLoU2EAybzDSNLuEZoLNKkh5t6fNF+ERy1QP+TacRKVVDRyeWY /Q4BzlvXDVIc6VDAFC1ly+UYisefZD9fs4qa71N8Fpu5buoqTc+XexSyveCgdH3GSHg/ sxEANZq43CmnZSorfyXDEm0SnN/EFTIdSMzqB9oWuSi2GAQSQSCeMvy2SFT2AFdxa2BB +7M2PcJiU76TyYUFqW7PxoQm55wk3hNV2YaKG9Png+JLPtsKCf49JQnblcj2GAGnQpKO QmM1igcwN9QQu1uzAPcktFmoomPVcsJuWymKH1T6g6hh96f/OutFo8FmqetLlAkH2onp U61w== X-Gm-Message-State: ALoCoQl3yjvSdwc27h8qnTLG+OpE8errKk2k7VFsuug2lAAzC5zH4Vimo2tuKYbrLqN++WYig24txx/OIiGYXS4ZkLO7WEq04jl2MThda2B/1v7/9nxy61WK868S+vtPnMD4gSOg7lRpa55e6d9POpqP1yNrkQiXVSmYyMpQ1ULFgtQUTTMOK2kgIlwHZ57yyfnN41FyGx90 X-Received: by 10.50.43.131 with SMTP id w3mr22277294igl.17.1384930261145; Tue, 19 Nov 2013 22:51:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Tue, 19 Nov 2013 22:50:41 -0800 (PST) In-Reply-To: <5288FC15.5080508@globis.net> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> From: Lorenzo Colitti Date: Wed, 20 Nov 2013 15:50:41 +0900 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=047d7bfea18641415d04eb9634a1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:51:09 -0000 --047d7bfea18641415d04eb9634a1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 18, 2013 at 2:25 AM, Ray Hunter wrote: > Summary: I don't have answers to my own points below, but neither does > this draft, so whilst I welcome the authors sharing their experiences, I > can't support publishing it as-is as a v6ops WG document. > > The bottom line is that I wouldn't be happy if my own ISP adopted the > policy exactly as-documented in the draft. > Would you be happier if your ISP implemented the "simple security" recommendations in RFC 6092 and dropped all unsolicited packets to your network except IPsec? I think we probably need something more sophisticated. And being > realistic, we're probably not yet ready to write it. > So let's not throw out the baby with the bathwater then? This group exists to share operational experience, and that is what this draft does. It does not make any recommendations; even the rules it presents are examples. I can't see anyone construing this as a recommendation or endorsement of any sort. We published RFC 6092. Why shouldn't we publish this one? It seems to me that there's no real difference between this document and RFC 6092; fundamentally, they both simply describe a security profile without making any claim about whether it is a recommended profile. If anything, at least this one has the advantage that it was deployed before it was standardized... I support this document. --047d7bfea18641415d04eb9634a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 18, 2013 at 2:25 AM, Ray Hunter <v6ops@globis.= net> wrote:
Summary: I don't have ans= wers to my own points below, but neither does
this draft, so whilst I welcome the authors sharing their experiences, I can't support publishing it as-is as a v6ops WG document.

The bottom line is that I wouldn't be happy if my own ISP adopted the policy exactly as-documented in the draft.

<= div>Would you be happier if your ISP implemented the "simple security&= quot; recommendations in RFC 6092 and dropped all unsolicited packets to yo= ur network except IPsec?

I think we probably need something more sop= histicated. And being
realistic, we're probably not yet ready to write it.

So let's not throw out the baby with the bathwater th= en? This group exists to share operational experience, and that is what thi= s draft does. It does not make any recommendations; even the rules it prese= nts are examples. I can't see anyone construing this as a recommendatio= n or endorsement of any sort.

We published RFC 6092. Why shouldn't we publis= h this one? It seems to me that there's no real difference between this= document and RFC 6092; fundamentally, they both simply describe a security= profile without making any claim about whether it is a recommended profile= . If anything, at least this one has the advantage that it was deployed bef= ore it was standardized...

I support this document.
--047d7bfea18641415d04eb9634a1-- From holger.metschulat@telekom.de Tue Nov 19 23:53:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26521AC4C1 for ; Tue, 19 Nov 2013 23:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScufHocIjeWH for ; Tue, 19 Nov 2013 23:53:31 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABA31AE17E for ; Tue, 19 Nov 2013 23:53:30 -0800 (PST) From: Received: from he111493.emea1.cds.t-internal.com ([10.206.92.96]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 20 Nov 2013 08:53:23 +0100 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111493.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 20 Nov 2013 08:53:22 +0100 To: Date: Wed, 20 Nov 2013 08:53:23 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: Ac7hBvNb2G3OI+r/R3q0cwKj0TMpSQES9Ddg Message-ID: References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:53:34 -0000 Hello Mikael, I agree, but are there any other choices?=20 One could argue that the UE is responsible by itself to use NAT64 correctly= when attaching to an IPv6-only context, e.g. by performing automatic NAT64= prefix detection and performing DNS64 internally (which would have the ben= efit to work with DNSSEC) in addition to 464Xlat. Holger -----Urspr=FCngliche Nachricht----- Von: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Gesendet: Donnerstag, 14. November 2013 07:59 An: Metschulat, Holger Cc: gert@space.net; phdgang@gmail.com; v6ops@ietf.org Betreff: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt On Thu, 14 Nov 2013, holger.metschulat@telekom.de wrote: > this needs to be resolved in the provider's network by applying DNS64=20 > only to those UE that have an IPv6-only connection. Usually, IPv6-only=20 > connectivity means a separate APN with a dedicated IPv6 pool, so=20 > either > IPv4 and IPv4v6 UE get a different DNS server than the IPv6-only UE,=20 > or the DNS server is the same and it can deduce from the client's IPv6=20 > address whether it's an IPv4v6 or and IPv6-only client. I oppose this reasoning. It brings in unneeded complexity in the mobile cor= e network to handle all this logic, and besides, customers should be able t= o choose if they want IPv4v6 or IPv6 only, meaning you don't know in advanc= e. It's beneficial if standards allow for less complexity in backend systems.= =20 Complex backend systems is less problem for huge ISPs, but it is for smalle= r ones. Also, even huge ISPs benefit from less complexity in their backend = systems. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From marc.lampo.ietf@gmail.com Wed Nov 20 00:01:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06521AE397 for ; Wed, 20 Nov 2013 00:01:36 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr6XpPl2hDvz for ; Wed, 20 Nov 2013 00:01:34 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5461E1AE390 for ; Wed, 20 Nov 2013 00:01:34 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id cz12so6908399veb.19 for ; Wed, 20 Nov 2013 00:01:27 -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=mi1EKpqwbCcKcdFDrcOy71+GLWyaxtBXZmrZVh/WTu4=; b=e9qaMgSw9KzXtXNrl2eJzich67vWnTgErZ8UL8NNsY19OKcWd5sSmpbcGbVZntz4vQ TpnUDwAWrDk/7CKBgcr2ZHJZCJz1+7+iPfuwZpWFhaixQeUsdYhZHtiDJmvm0y0ZzZcg 9Tl1KncF3nGfFuvcLy1qEwurEZCdgt+hY9isRSMIo2wnFMNrFmbUHweSpYhnuVZcKswM EwHq6BqXcBqAVYMH/tHon7OjAoR0h4tvxItUfLHq4qhLQ4deMEqnS4YHpcekPogrUXnc Rk3DT9DBYYpZ/iQ1g4G4aQVGHTMJq3/g+oMuwrwfot4x3UMS9UVi9diQZ5tVlz00fDbM V5yQ== MIME-Version: 1.0 X-Received: by 10.58.23.33 with SMTP id j1mr20692vef.27.1384934487905; Wed, 20 Nov 2013 00:01:27 -0800 (PST) Received: by 10.58.227.66 with HTTP; Wed, 20 Nov 2013 00:01:27 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> Date: Wed, 20 Nov 2013 09:01:27 +0100 Message-ID: From: Marc Lampo To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b339df9305b4604eb9730cc Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:01:37 -0000 --047d7b339df9305b4604eb9730cc Content-Type: text/plain; charset=ISO-8859-1 This document states, for several recommendations in RFC 6092, exactly the opposite of that document. In addition, as I touched in my very first reaction, this draft lists a number of threats - section 2. But, in my opinion, none of those threats are addressed by the rules for balanced security - section 3.1. (my first comment only referred to the last threat on covert channels, but I must rephrase) Only "unauthorised use of services" is partly addressed, by blocking access to some ports. The later users it might be misleading : like if implementing these balanced security rules, something is done about those threats. In reply to the question : yes, personally I would be happier if the ISP dropped all unsolicited packets towards my network (except IPsec). An analogy : is the front door of your home locked when nobody is at home ? or do you have locks on the door towards the living room, kitchen and bedrooom (only) and allow free access to the bathroom ? Perhaps proper use of the bathroom is not dangerous, but it the unknown visitor (ab)uses the electricity outlet in the bathroom ? On Wed, Nov 20, 2013 at 7:50 AM, Lorenzo Colitti wrote: > On Mon, Nov 18, 2013 at 2:25 AM, Ray Hunter wrote: > >> Summary: I don't have answers to my own points below, but neither does >> this draft, so whilst I welcome the authors sharing their experiences, I >> can't support publishing it as-is as a v6ops WG document. >> >> The bottom line is that I wouldn't be happy if my own ISP adopted the >> policy exactly as-documented in the draft. >> > > Would you be happier if your ISP implemented the "simple security" > recommendations in RFC 6092 and dropped all unsolicited packets to your > network except IPsec? > > I think we probably need something more sophisticated. And being >> realistic, we're probably not yet ready to write it. >> > > So let's not throw out the baby with the bathwater then? This group exists > to share operational experience, and that is what this draft does. It does > not make any recommendations; even the rules it presents are examples. I > can't see anyone construing this as a recommendation or endorsement of any > sort. > > We published RFC 6092. Why shouldn't we publish this one? It seems to me > that there's no real difference between this document and RFC 6092; > fundamentally, they both simply describe a security profile without making > any claim about whether it is a recommended profile. If anything, at least > this one has the advantage that it was deployed before it was > standardized... > > I support this document. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b339df9305b4604eb9730cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This document states, for several recommendations in RFC 6092, exact= ly the opposite of that document.

In addition, as I touched in= my very first reaction, this draft lists a number of threats - section 2.<= br>
But, in my opinion, none of those threats are addressed by the rules = for balanced security - section 3.1.
=A0(my first comment only ref= erred to the last threat on covert channels, but I must rephrase)

Only "unauthorised use of services" is partly addressed, by= blocking access to some ports.

The later users it might be mi= sleading : like if implementing these balanced security rules,
=A0something is done about those threats.


In reply to the = question : yes, personally I would be happier if the ISP dropped all unsoli= cited packets towards my network (except IPsec).
An analogy :
is the front door of your home locked when nobody is at home ?
or = do you have locks on the door towards the living room, kitchen and bedrooom= (only)
=A0and allow free access to the bathroom ?
Perhap= s proper use of the bathroom is not dangerous,
=A0but it the unknown visitor (ab)uses the electricity outlet in the = bathroom ?



On Wed, Nov 20, 2013 at 7:50 AM, Lorenzo Colitti <lorenz= o@google.com> wrote:
On Mon, N= ov 18, 2013 at 2:25 AM, Ray Hunter <v6ops@globis.net> wrote:<= br>
Summary: I don't have ans= wers to my own points below, but neither does
this draft, so whilst I welcome the authors sharing their experiences, I can't support publishing it as-is as a v6ops WG document.

The bottom line is that I wouldn't be happy if my own ISP adopted the policy exactly as-documented in the draft.

<= /div>
Would you be happier if your ISP implemented the "simple sec= urity" recommendations in RFC 6092 and dropped all unsolicited packets= to your network except IPsec?

I think we probably need something more sop= histicated. And being
realistic, we're probably not yet ready to write it.

So let's not throw out the baby with the bathwa= ter then? This group exists to share operational experience, and that is wh= at this draft does. It does not make any recommendations; even the rules it= presents are examples. I can't see anyone construing this as a recomme= ndation or endorsement of any sort.

We published RFC 6092. Why shouldn't we publis= h this one? It seems to me that there's no real difference between this= document and RFC 6092; fundamentally, they both simply describe a security= profile without making any claim about whether it is a recommended profile= . If anything, at least this one has the advantage that it was deployed bef= ore it was standardized...

I support this document.

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


--047d7b339df9305b4604eb9730cc-- From swmike@swm.pp.se Wed Nov 20 00:09:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEFE1AE0EA for ; Wed, 20 Nov 2013 00:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNJFkDEMFaF4 for ; Wed, 20 Nov 2013 00:09:10 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 656761AC4C1 for ; Wed, 20 Nov 2013 00:09:10 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 24748A1; Wed, 20 Nov 2013 09:09:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1E9E29A; Wed, 20 Nov 2013 09:09:01 +0100 (CET) Date: Wed, 20 Nov 2013 09:09:01 +0100 (CET) From: Mikael Abrahamsson To: holger.metschulat@telekom.de In-Reply-To: Message-ID: References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:09:12 -0000 On Wed, 20 Nov 2013, holger.metschulat@telekom.de wrote: > I agree, but are there any other choices? We could provide the problem case and have "someone" develop standards to fix it? I think it's a pretty common case going forward that the network supports a combination of IPv4, DS and IPv6 devices being connected even to a wifi network or LAN (not necessarily mobile). Then one doesn't have the choice to have different APNs. One way would be to have a recommendation to detect NAT64 and then detect NAT44, and in the case of both being present, prefer one of them consistently? Hardest case to handle would be GUA IPv4 and IPv6 with NAT64, then there would have to be heuristics to actively detect the DNS64 doing A->AAAA and not use the AAAA pointing to the NAT64 prefix, but instead use A records for those.... if that's what we want. -- Mikael Abrahamsson email: swmike@swm.pp.se From v6ops@globis.net Wed Nov 20 00:10:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796661AE39B for ; Wed, 20 Nov 2013 00:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhY7FXLoO3dN for ; Wed, 20 Nov 2013 00:10:39 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 46D8B1AE38A for ; Wed, 20 Nov 2013 00:10:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2A2F0870070; Wed, 20 Nov 2013 09:10:32 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLst-nTwoUMi; Wed, 20 Nov 2013 09:10:32 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id F0926870040; Wed, 20 Nov 2013 09:10:31 +0100 (CET) Message-ID: <528C6E76.1010704@globis.net> Date: Wed, 20 Nov 2013 09:10:30 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Lorenzo Colitti References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:10:40 -0000 > Lorenzo Colitti > 20 November 2013 07:50 > On Mon, Nov 18, 2013 at 2:25 AM, Ray Hunter wrote: > >> Summary: I don't have answers to my own points below, but neither does >> this draft, so whilst I welcome the authors sharing their experiences, I >> can't support publishing it as-is as a v6ops WG document. >> >> The bottom line is that I wouldn't be happy if my own ISP adopted the >> policy exactly as-documented in the draft. >> > > Would you be happier if your ISP implemented the "simple security" > recommendations in RFC 6092 and dropped all unsolicited packets to your > network except IPsec? Yes. Provided the ISP gave me the ability to override that default setting (either via a web site, PCP, UPnP, or some other mechanism) At least I'd know for certain what ISP settings I needed to override. They could even ask me to sign in blood in advance that all risks to my equipment were my risk. Whereas with this draft, we're going to have to merge two vaguely-defined and time-variant security policies (my policy and the ISP's policy). If I open port 25 and the ISP closes it, which setting takes precedence? And if the order that the requests arrive is different? > > I think we probably need something more sophisticated. And being >> realistic, we're probably not yet ready to write it. >> > > So let's not throw out the baby with the bathwater then? This group exists > to share operational experience, and that is what this draft does. It does > not make any recommendations; even the rules it presents are examples. I > can't see anyone construing this as a recommendation or endorsement of any > sort. > > We published RFC 6092. Why shouldn't we publish this one? It seems to me > that there's no real difference between this document and RFC 6092; > fundamentally, they both simply describe a security profile without making > any claim about whether it is a recommended profile. If anything, at least > this one has the advantage that it was deployed before it was > standardized... > > I support this document. > > > ------------------------------------------------------------------------ -- Regards, RayH From lorenzo@google.com Wed Nov 20 00:11:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E79F1AE38A for ; Wed, 20 Nov 2013 00:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urSm1I9O6Q1L for ; Wed, 20 Nov 2013 00:11:26 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A08D41AE382 for ; Wed, 20 Nov 2013 00:11:26 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so2694997ieb.32 for ; Wed, 20 Nov 2013 00:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CKatr+04LVUBLQl+R1otMlOmUIS815fN0MorlC6+X3I=; b=pUd6RVbhyTAFhnpzTOTjqOu72A3aSBbIe3j17OHRT9CfgWuXnRxuQEww+yTnV0LMY7 2QaQENI4udaa8R5StcwVRWRkbPbGnG+Jr1iBK4Mc+4Y583SU5PoovZb8NT6vFYmnzNVm cuZXl4Z2ZyjMGi/eAsa4363x0jUo98Sq4NRLLFlWCNewG3G7tzx9Kyh/27RHfO7Xk1jx M/mSUgyYfqUEZCvHtrwZeIWwLyKGFMYgYETfsmcGtTMhrvtUsnzgznNv2Sq/Iu9f3Ed7 qWbsVbOIfELcav/7GciH1y8DirUHV79VUg5+zOinmmqDovPVOfpnV8WgIu4Us7mOSzgd SPDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CKatr+04LVUBLQl+R1otMlOmUIS815fN0MorlC6+X3I=; b=fTRq+ealekHjsHXxYdvQTTuulO0NVnC1G53ml/LvwiHxcYQezGJEry8E0YqIkmTLmv k8uHQ3uQR12tgKGYAjXfGvkarWi6Nea4Qsj3I9clQkI64qu4Of13EbP1Pun9VpXLA1N7 PHQhlnCltVFDgOONVolClP+1NE73qKWub48YSGh4P/8c+ZB8VYt9r6mXOgmR//hXoda4 L4GN5XRkdy6APNXdZsRw51JHtFDYDXCRNhyuOo4skJz4IUTgt8Ia+61IiCWCOrS8VIFA UbmcSnXBh/FwxrxYIrLCEzQNpA/LYaFordwTqazMLjhz3RPfHkp8OmeV8pSY7DhvvY3p ST8w== X-Gm-Message-State: ALoCoQl1Uh30TaWUnbXse9bJoG42y3T1eRyYNGwC/arqXFVPIZHw4N9+JI8yoJZNlhluSMKigbTgJSx9U4bKOc2WFDFrOm1c5GUW8vzttLNIA2OoxCrysL5QhfL3b5a329J0mjyG0Y6FwQ2I7J125oaWaMsVCos84gM6LtYMO+qYfldwHio+ItpFjyKF+ymSUBBV4EXMLNbi X-Received: by 10.50.40.102 with SMTP id w6mr22610274igk.20.1384935080301; Wed, 20 Nov 2013 00:11:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 20 Nov 2013 00:10:59 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> From: Lorenzo Colitti Date: Wed, 20 Nov 2013 17:10:59 +0900 Message-ID: To: Marc Lampo Content-Type: multipart/alternative; boundary=089e0112c7fe7fc7c304eb97531a Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:11:28 -0000 --089e0112c7fe7fc7c304eb97531a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 5:01 PM, Marc Lampo wrote: > This document states, for several recommendations in RFC 6092, exactly the > opposite of that document. > Which ones? Obviously you're not suggesting that RFC 6092 recommends that unsolicited inbound packets be dropped by default, right? Because it doesn't say that. > In addition, as I touched in my very first reaction, this draft lists a > number of threats - section 2. > But, in my opinion, none of those threats are addressed by the rules for > balanced security - section 3.1. > (my first comment only referred to the last threat on covert channels, > but I must rephrase) > Do you have text to suggest? > In reply to the question : yes, personally I would be happier if the ISP > dropped all unsolicited packets towards my network (except IPsec). > And there are people in this working group that will never agree with you. For example, I will never agree with you. But fortunately, that has no relevance on this document. Since this document does not recommend a security policy, saying "I don't like the security policy" (which is your opinion, and one you're perfectly entitled to) is not a valid reason not to publish this document. --089e0112c7fe7fc7c304eb97531a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2013 at 5:01 PM, Marc Lampo <marc= .lampo.ietf@gmail.com> wrote:
<= div class=3D"gmail_quote">
This document states, for several rec= ommendations in RFC 6092, exactly the opposite of that document.

Which ones? Obviously you're = not suggesting that RFC 6092 recommends that unsolicited inbound packets be= dropped by default, right? Because it doesn't say that.
=A0
In addition, as I touch= ed in my very first reaction, this draft lists a number of threats - sectio= n 2.
But, in my opinion, none of those threats are addressed by the rules = for balanced security - section 3.1.
=A0(my first comment only ref= erred to the last threat on covert channels, but I must rephrase)

Do you have text to suggest?
=A0
In reply= to the question : yes, personally I would be happier if the ISP dropped al= l unsolicited packets towards my network (except IPsec).

And there are people in this working group that will never agree with= you. For example, I will never agree with you.

But fortunately, that has no relevance on this document. Since this documen= t does not recommend a security policy, saying "I don't like the s= ecurity policy" (which is your opinion, and one you're perfectly e= ntitled to) is not a valid reason not to publish this document.
--089e0112c7fe7fc7c304eb97531a-- From lorenzo@google.com Wed Nov 20 00:14:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1567F1AC8F5 for ; Wed, 20 Nov 2013 00:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9gb5KwBKXmD for ; Wed, 20 Nov 2013 00:14:28 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id A93E51AC7F0 for ; Wed, 20 Nov 2013 00:14:28 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so6456408iej.12 for ; Wed, 20 Nov 2013 00:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sJ1x48lyuGc60W2BAYpg8tqNQ5gDKUr3nYiBes+fzTo=; b=b7VASK0k7vLtmChqdCJ7TGu+16phWvMM/yXsLuoq0vOcPFestJMkqmnCiOZ2YSgZrT 8eviExNvReqsTd4UWqiK61PIYZyOCxCeTZp2yfLY3BlYv/Y5y1dxx4Ynlf6x78uUwMpv cSBEyB0sfR8gX0k3RaIlkcHMsvPH/FhxcuxULfe33PZviAexRbRTH3Tf8nTWTPsIdrlI kutVpvTsE4UmhQHWTv/BfYUup9pkIWlBteuPZYd9ynbzi5zX44/IN9snyvtgsLxEctZb 0vIPK1i+BVDXU4tcKtB/RpHzTZTXwPwu4tgDqVcqezsYiNkmavsGwwEwyRvKcrnYWehA 7vfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sJ1x48lyuGc60W2BAYpg8tqNQ5gDKUr3nYiBes+fzTo=; b=Auz52YFfyOTtg8gcpD0hbxhl4eoQlIh76yklSlZ/yTTJM97/mDAueMR2EaQj/LYOG0 uS4+AURgBsR/+NXexLVZJA3+lmKXpFI1uX1vo9fY9FdLmo8G8WWUFLB5QfafuFVX9FbX zArFBW8iWeohH8Zmhlq6NTfVquHDGgkEITu4XKzD4WOLyH/7zWhF5iIaIOTny9RHyEEU 8DJPIkvkbz3Qb9wi1CyQWdIuKHBuW6+R47dEVwcXJXlLMXEB5v575zH8u6Ofx2Epcvrm FRdQCi8jj/LqaEDAhqocSdcktlYid03cPqT2XOX3NgvYhY0PoY9Uy2R18VL399zj/J99 EHIw== X-Gm-Message-State: ALoCoQlGEtGmk/dA13W3qW5FrmAnla/scfiTtbroenzIX2bV6ibvV3LSpYsPnh8VT0IreEGzzu0kudmJfMwnAP+D9yNDN+adJWfy2u7LNRDD8uarc8frBaQeXLCqDKGFcdz9WxzlnBR+Mwz8nZgwZ4fPm6UbuE9p7d29eaViNMPUmk1Y5NZaAkqtC6Z1i18vNYro0XF03doQ X-Received: by 10.50.40.102 with SMTP id w6mr22618286igk.20.1384935262379; Wed, 20 Nov 2013 00:14:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 20 Nov 2013 00:14:02 -0800 (PST) In-Reply-To: <528C6E76.1010704@globis.net> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528C6E76.1010704@globis.net> From: Lorenzo Colitti Date: Wed, 20 Nov 2013 17:14:02 +0900 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=089e0112c7fe59f9d704eb975e25 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:14:30 -0000 --089e0112c7fe59f9d704eb975e25 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 5:10 PM, Ray Hunter wrote: > Yes. > > Provided the ISP gave me the ability to override that default setting > (either via a web site, PCP, UPnP, or some other mechanism) > > At least I'd know for certain what ISP settings I needed to override. > Er... which is what this draft says? These are an example set of generic rules to be applied. Each would normally be configurable, either by the user directly or on behalf of the user by a subscription service. --089e0112c7fe59f9d704eb975e25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2013 at 5:10 PM, Ray Hunter <v6ops@globis.= net> wrote:
Yes.

Provided the ISP gave me the ability to override that default setting
(either via a web site, PCP, UPnP, or some other mechanism)

At least I'd know for certain what ISP settings I needed to override.

Er... which is what this draft says?

=A0 =A0These are an example set of generic rules= to be applied. =A0Each would
=A0 =A0normally be configurable, either by the user directly or on beh= alf of
=A0 =A0the user by a subscription service.
--089e0112c7fe59f9d704eb975e25-- From tore@fud.no Wed Nov 20 01:16:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36AF1AD738 for ; Wed, 20 Nov 2013 01:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUpAFZT8k1m5 for ; Wed, 20 Nov 2013 01:16:32 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id DC3711AD687 for ; Wed, 20 Nov 2013 01:16:31 -0800 (PST) Received: from [2a02:c0:2:3:1194:17:0:1000] (port=46237 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Vj3tW-0007ys-Kr; Wed, 20 Nov 2013 10:16:22 +0100 Message-ID: <528C7DE5.2080407@fud.no> Date: Wed, 20 Nov 2013 10:16:21 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <52849009.80408@fud.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 09:16:33 -0000 * Lorenzo Colitti > On Thu, Nov 14, 2013 at 5:55 PM, Tore Anderson > wrote: > > One could use a ULA prefix for DNS64/NAT64, which would make native > IPv4 be preferred according to RFC 6724. > > But then if you have IPv6-only with 464xlat you end up preferring > 464xlat over NAT64. True, although the question was about dual-stack UEs with native IPv4. I suppose that if one additionally has to support single-stack UEs with NAT64/464XLAT one can't have it both ways, unless those UEs modify their RFC6724 policy table to add a separate low-precedence entry for the 464XLAT address (and possibly one for the NAT64 prefix as well). But then again, it might not matter much these days, as it becomes more and more uncommon to provision UEs with native IPv4. Tore From marc.lampo.ietf@gmail.com Wed Nov 20 01:37:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53031AD687 for ; Wed, 20 Nov 2013 01:37:21 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z14Gf7tUvkwX for ; Wed, 20 Nov 2013 01:37:20 -0800 (PST) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id E2D721ACC91 for ; Wed, 20 Nov 2013 01:37:19 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id x16so2355090vbf.35 for ; Wed, 20 Nov 2013 01:37:13 -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=sN9kCVa4JmxDimjYuJTr3BQz7UNS1pQQfNQp7dD4ktM=; b=OIboQQeD6anvHwUGFD8RgpT5sO5r93qSwsgLQ4d/ggWD9BP88BylJ0vWIwIy1kK0Nz whB5eJmNnkpeEDJupd7qZS2TZFVIi9Ppylg4AeT0J2k36NPHOsXnsr4qgLu4SCPWnSfr FX7/JWMDKhlJT35x06uPfFaKOQZ6FoNd7oOnIwf/jg02UYbD6UpjbPBQvVDyJGawp9uQ ExNesATM3GOXrs4eyDYmwH5mnl/Qd1TwXuKWHLMjzD8GAXQXLvRIbAp/aiA8J1h9oZ97 zhyhVmZIEtrR17+3AbhgLtwnpE9kjXV08r9NR+SpHXtkZlYaCuDvOfriKYLWZcb7ZE86 p9gg== MIME-Version: 1.0 X-Received: by 10.221.44.136 with SMTP id ug8mr25682487vcb.13.1384940233450; Wed, 20 Nov 2013 01:37:13 -0800 (PST) Received: by 10.58.227.66 with HTTP; Wed, 20 Nov 2013 01:37:13 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> Date: Wed, 20 Nov 2013 10:37:13 +0100 Message-ID: From: Marc Lampo To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a113378d8a66fc604eb988623 Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 09:37:22 -0000 --001a113378d8a66fc604eb988623 Content-Type: text/plain; charset=ISO-8859-1 Yes, RFC 6092 recommends that unsolicited packets be dropped by default ! REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited), to any unsolicited inbound SYN packet after waiting at least 6 seconds without first forwarding the associated outbound SYN or SYN/ACK from the interior peer. "transparent mode" "MAY" be the default (which, in the context, I interpret as a kind of "second choice") REC-49 Internet gateways with IPv6 simple security capabilities MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e., not to use the IPv6 simple security capabilities of the gateway. The transparent mode of operation MAY be the default configuration. On Wed, Nov 20, 2013 at 9:10 AM, Lorenzo Colitti wrote: > On Wed, Nov 20, 2013 at 5:01 PM, Marc Lampo wrote: > >> This document states, for several recommendations in RFC 6092, exactly >> the opposite of that document. >> > > Which ones? Obviously you're not suggesting that RFC 6092 recommends that > unsolicited inbound packets be dropped by default, right? Because it > doesn't say that. > > >> In addition, as I touched in my very first reaction, this draft lists a >> number of threats - section 2. >> But, in my opinion, none of those threats are addressed by the rules >> for balanced security - section 3.1. >> (my first comment only referred to the last threat on covert channels, >> but I must rephrase) >> > > Do you have text to suggest? > > >> In reply to the question : yes, personally I would be happier if the ISP >> dropped all unsolicited packets towards my network (except IPsec). >> > > And there are people in this working group that will never agree with you. > For example, I will never agree with you. > > But fortunately, that has no relevance on this document. Since this > document does not recommend a security policy, saying "I don't like the > security policy" (which is your opinion, and one you're perfectly entitled > to) is not a valid reason not to publish this document. > --001a113378d8a66fc604eb988623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, RFC 6092 recommends that unsolicited packets be = dropped by default !
  REC-34  By DEFAULT, a gatew=
ay MUST respond with an ICMPv6
           "Destination Unreachable" error code 1 (Communication =
with
           destination administratively prohibited), to any unsolicited
           inbound SYN packet after waiting at least 6 seconds without
           first forwarding the associated outbound SYN or SYN/ACK from
           the interior peer.
"transparent mode" "MAY&q= uot; be the default (which, in the context, I interpret as a kind of "= second choice")
   REC-49  Internet gateways with I=
Pv6 simple security capabilities MUST
           provide an easily selected configuration option that permits
           a "transparent mode" of operation that forwards all
           unsolicited flows regardless of forwarding direction, i.e.,
           not to use the IPv6 simple security capabilities of the
           gateway.  The transparent mode of operation MAY be the
           default configuration.




On Wed, Nov 20, 2013 at 9:10 AM, Lorenzo Colitti &= lt;lorenzo@google.c= om> wrote:
On Wed, N= ov 20, 2013 at 5:01 PM, Marc Lampo <marc.lampo.ietf@gmail.com&= gt; wrote:
This document states, for several rec= ommendations in RFC 6092, exactly the opposite of that document.

Which ones? Obviously you&#= 39;re not suggesting that RFC 6092 recommends that unsolicited inbound pack= ets be dropped by default, right? Because it doesn't say that.
=A0
In addition, as I touch= ed in my very first reaction, this draft lists a number of threats - sectio= n 2.
But, in my opinion, none of those threats are addressed by the rules = for balanced security - section 3.1.
=A0(my first comment only ref= erred to the last threat on covert channels, but I must rephrase)

Do you have text to suggest?
=A0
In reply= to the question : yes, personally I would be happier if the ISP dropped al= l unsolicited packets towards my network (except IPsec).

And there are people in this working group that will never agre= e with you. For example, I will never agree with you.

But fortunately, that has no relevance on this document. Since this documen= t does not recommend a security policy, saying "I don't like the s= ecurity policy" (which is your opinion, and one you're perfectly e= ntitled to) is not a valid reason not to publish this document.

--001a113378d8a66fc604eb988623-- From v6ops@globis.net Wed Nov 20 02:01:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7971AE054 for ; Wed, 20 Nov 2013 02:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em8IfkH3hbBk for ; Wed, 20 Nov 2013 02:01:38 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 51D891AD8F2 for ; Wed, 20 Nov 2013 02:01:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D3E2E870071; Wed, 20 Nov 2013 11:01:29 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx-fIiHRiOT6; Wed, 20 Nov 2013 11:01:29 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id AE5DF870040; Wed, 20 Nov 2013 11:01:29 +0100 (CET) Message-ID: <528C8878.4090808@globis.net> Date: Wed, 20 Nov 2013 11:01:28 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Lorenzo Colitti References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528C6E76.1010704@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:01:40 -0000 > Lorenzo Colitti > 20 November 2013 09:14 > > Er... which is what this draft says? > > These are an example set of generic rules to be applied. Each would > normally be configurable, either by the user directly or on behalf of > the user by a subscription service. > So what does the draft really say? Here's some filtering rules, that you may or may not like, which may or may not be overridden, which may change over time, which only mitigate a very limited number of threats, and maybe the ISP will manage the security policy but maybe the end user wants to take this responsibility ...... Where's the evidence to say that this approach is any better than an open security policy of "allow everything bi-directionally" ? The threats are listed in the draft as: o denial of service by packet flooding: overwhelming either the access bandwidth or the bandwidth of a slower link in the residential network (like a slow home automation network) or the CPU power of a slow IPv6 host (like networked thermostat or any other sensor type nodes); not covered. o denial of service by Neighbor Discovery cache exhaustion [RFC6583]: the outside attacker floods the inside prefix(es) with packets with a random destination address forcing the CPE to exhaust its memory and its CPU in useless Neighbor Solicitations; not covered. o denial of service by service requests: like sending print jobs from the Internet to an ink jet printer until the ink cartridge is empty or like filing some file server with junk data; not covered.e.g. port 515 o unauthorized use of services: like accessing a webcam or a file server which are open to anonymous access within the residential network but should not be accessed from outside of the home network or accessing to remote desktop or SSH with weak password protection; not covered. e.g. port 8080. o exploiting a vulnerability in the host in order to get access to data or to execute some arbitrary code in the attacked host such as several against old versions of Windows; not covered. o trojanized host (belonging to a Botnet) can communicate via a covert channel to its master and launch attacks to Internet targets. not covered. And in the Security section, the draft only addresses "Unauthorized access because vulnerable ports are blocked" ? IMHO this threat is anyway blocked by machine firewalls running on every modern OS shipping today (any device that is likely to support IPv6) -- Regards, RayH From lorenzo@google.com Wed Nov 20 02:02:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF2F1AD945 for ; Wed, 20 Nov 2013 02:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waOay1FSgUme for ; Wed, 20 Nov 2013 02:02:17 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD531AE3D1 for ; Wed, 20 Nov 2013 02:02:10 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so6273631iej.40 for ; Wed, 20 Nov 2013 02:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PM9t5oRiK07HVO2bexk4k1WVv9BcHLvJTCrUYseQ3PY=; b=G/vOelcufPN07uY4RcmWGWo8NB9C64eJD7BhwV6DXf9/f2eA84VISiQ9px/lSxpNBZ Jvd/erauibqmijETaRYJx6b+KatdVnv/EIRnGiE5FY+bG2RubvdZh+HGC8S7XamYAvOD OmZk9rXGr8i8bAs1c/Ko/ZNl95oAT3Dc789lC7B3/ugWBQnbBvv8mQbXoxbQ60NaVQTV tMXGqfgB7/tsUthmki/mlsB2Cea3rLapcQwmeX6kD21iQPdKQFwcsKKsZ8kOfsoYCcoU OsGwwTrtvquGuJ0fm8GDlg6OE8URQHgAMNNbMANBTx7R59n5nJ/zS0pwrM8+fFxn3WRj 9wLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PM9t5oRiK07HVO2bexk4k1WVv9BcHLvJTCrUYseQ3PY=; b=ZnH8DFdn4zuwLpqy7vEox+Ild6izu+JCtVdj8ZqlYZLwfVZNphXg4hTn6aUhqJrVEg XBkyzSrVVYUNjHScCbZyVwoYgFF+LZyfCeFC3vhjPfsJJs90RihR9+QDYiwXgWGVAVjO wzeB2qnrtXs8OHHYD4cBZUXd+KjSIud66lrG2+HL8p5iGljRu+d/RD78gcjITlIOMO5g 5YTQ1bONgQNf3MihvX23c8sELwCO1VWYoSy/Gkfic4p0mdJ7LnWiIY0AMWVaDNTY3uIw MGY2UrxNzPUgxKBBQaZ2T/nkGHtUpWhtAuhxPt+tAq22SvO8+VxNN/TB+fAG20r+IXgI Aolw== X-Gm-Message-State: ALoCoQnPX5kfrjioulSVkiMsfWrpouN1tcMAVy0f5nmCfZuY5pkVZ6rledzIcL865U4hqB6KylGpxUMKNXHCL4o/jO7jqSiWaku5U5f/INsskGh4uCtu9b7iW6UCpJFDgeIQiWo+NTHEAcj46ueTElD5Kj5qusfF4BuH5zjeX/Z12MOlnnokwd1Fy/Z0WaFCKXAC3AeFv9vQ X-Received: by 10.50.43.131 with SMTP id w3mr22743629igl.17.1384941723979; Wed, 20 Nov 2013 02:02:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 20 Nov 2013 02:01:43 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> From: Lorenzo Colitti Date: Wed, 20 Nov 2013 19:01:43 +0900 Message-ID: To: Marc Lampo Content-Type: multipart/alternative; boundary=047d7bfea1867e310104eb98df68 Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:02:19 -0000 --047d7bfea1867e310104eb98df68 Content-Type: text/plain; charset=ISO-8859-1 It's not a second choice: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. So no, RFC6092 and this document do not disagree. If you read the MAY in REC-49 as "is", then the two documents are compatible (the other point you cite, REC-34, is sort of irrelevant at that point). On Wed, Nov 20, 2013 at 6:37 PM, Marc Lampo wrote: > Yes, RFC 6092 recommends that unsolicited packets be dropped by default ! > > REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 > "Destination Unreachable" error code 1 (Communication with > destination administratively prohibited), to any unsolicited > inbound SYN packet after waiting at least 6 seconds without > first forwarding the associated outbound SYN or SYN/ACK from > the interior peer. > > "transparent mode" "MAY" be the default (which, in the context, I > interpret as a kind of "second choice") > > REC-49 Internet gateways with IPv6 simple security capabilities MUST > provide an easily selected configuration option that permits > a "transparent mode" of operation that forwards all > unsolicited flows regardless of forwarding direction, i.e., > not to use the IPv6 simple security capabilities of the > gateway. The transparent mode of operation MAY be the > default configuration. > > > > > > On Wed, Nov 20, 2013 at 9:10 AM, Lorenzo Colitti wrote: > >> On Wed, Nov 20, 2013 at 5:01 PM, Marc Lampo wrote: >> >>> This document states, for several recommendations in RFC 6092, exactly >>> the opposite of that document. >>> >> >> Which ones? Obviously you're not suggesting that RFC 6092 recommends that >> unsolicited inbound packets be dropped by default, right? Because it >> doesn't say that. >> >> >>> In addition, as I touched in my very first reaction, this draft lists a >>> number of threats - section 2. >>> But, in my opinion, none of those threats are addressed by the rules >>> for balanced security - section 3.1. >>> (my first comment only referred to the last threat on covert channels, >>> but I must rephrase) >>> >> >> Do you have text to suggest? >> >> >>> In reply to the question : yes, personally I would be happier if the ISP >>> dropped all unsolicited packets towards my network (except IPsec). >>> >> >> And there are people in this working group that will never agree with >> you. For example, I will never agree with you. >> >> But fortunately, that has no relevance on this document. Since this >> document does not recommend a security policy, saying "I don't like the >> security policy" (which is your opinion, and one you're perfectly entitled >> to) is not a valid reason not to publish this document. >> > > --047d7bfea1867e310104eb98df68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It's not a second choice:

5. MAY =A0 This word, or the adjective "OPTIONAL", mean that an= item is
=A0 =A0truly optional. =A0One vendor may choose to inclu= de the item because a
=A0 =A0particular marketplace requires it or because the vendor feels = that
=A0 =A0it enhances the product while another vendor may omit= the same item.

So no, RFC6092 and this document d= o not disagree. If you read the MAY in REC-49 as "is", then the t= wo documents are compatible (the other point you cite, REC-34, is sort of i= rrelevant at that point).

On Wed, Nov 20, 2013 at 6:37 PM, Marc Lampo <marc.l= ampo.ietf@gmail.com> wrote:
Yes, RFC 6092 recommends that unsoli= cited packets be dropped by default !
  REC-34  By DEFAULT, a gateway MUST respond with an ICMPv6
           "Destination Unreachable" error code 1 (Communication =
with
           destination administratively prohibited), to any unsolicited
           inbound SYN packet after waiting at least 6 seconds without
           first forwarding the associated outbound SYN or SYN/ACK from
           the interior peer.
"transparent mode" "MAY&q= uot; be the default (which, in the context, I interpret as a kind of "= second choice")
   REC-49  Internet gateways with IPv6 simple =
security capabilities MUST
           provide an easily selected configuration option that permits
           a "transparent mode" of operation that forwards all
           unsolicited flows regardless of forwarding direction, i.e.,
           not to use the IPv6 simple security capabilities of the
           gateway.  The transparent mode of operation MAY be the
           default configuration.




On Wed, Nov 20, 2013 at 9:10 AM, L= orenzo Colitti <lorenzo@google.com> wrote:
On Wed, Nov 20, 2013 at 5:01 PM, Mar= c Lampo <marc.lampo.ietf@gmail.com> wrote:
<= div>
This document states, for several recommendations in RF= C 6092, exactly the opposite of that document.

Which ones? Obviously you&#= 39;re not suggesting that RFC 6092 recommends that unsolicited inbound pack= ets be dropped by default, right? Because it doesn't say that.
=A0
In addition, as I touched in my very fir= st reaction, this draft lists a number of threats - section 2.
But, in my opinion, none of those threats are addressed by the rules = for balanced security - section 3.1.
=A0(my first comment only ref= erred to the last threat on covert channels, but I must rephrase)

Do you have text to suggest?
=A0
In reply= to the question : yes, personally I would be happier if the ISP dropped al= l unsolicited packets towards my network (except IPsec).

And there are people in this working group that will never agre= e with you. For example, I will never agree with you.

But fortunately, that has no relevance on this document. Since this documen= t does not recommend a security policy, saying "I don't like the s= ecurity policy" (which is your opinion, and one you're perfectly e= ntitled to) is not a valid reason not to publish this document.


--047d7bfea1867e310104eb98df68-- From lorenzo@google.com Wed Nov 20 02:18:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF0A1AD937 for ; Wed, 20 Nov 2013 02:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r92VhHBfOfDe for ; Wed, 20 Nov 2013 02:17:59 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D81471AD8F7 for ; Wed, 20 Nov 2013 02:17:58 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so236182ief.6 for ; Wed, 20 Nov 2013 02:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sr1Ks0riXIow4Y+mgWp3sBhi1i4MLdoI4iiY65KSUL0=; b=o1IOwkhWgo57dXy7cN4dLAMelNds0iRx5DwjEu/c7Co0SUcbWaoKzSKCQY43D86UQs PGRUZxt97pPR9o/WWUzqSd4RhpjZjcj25RF7hyoQYCWxeC244TpLKlrh2nJkGWiMdwXv LXYYBk+xDQ33431U0kY/XYRLRO0/+PBju/N03a0uYYiQmFGxGw9iiOp1+O4b6t290aQN eynVIwQqSV2Iklb9OuR1Uwxbz1l87aL9jx6hz6tufIf441hh8fHDCht94l+xUBIXm2Hn LNQukOHOtaUtervUtuPKdwfS7+LtknJSXjLFBeeO7XxJSpk7OA/d/vskdiOpNOilVxCL yLqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sr1Ks0riXIow4Y+mgWp3sBhi1i4MLdoI4iiY65KSUL0=; b=dw8wVuTXISvz2jROIdGxKhCUyS8zh4UcNr+qHODjyDCxZqT2IcjrLysyYXlf6rwkqL 2DG9I323wHIbYz+E5nrki8vq/17qEGrt6aR4giG6kZ6IYgenJDLC2JuMq+4vMMi5zoGm 4f6pIqwxx5OA/GSHVyH7xKmYseBq7PsQPT0YByCJiTZpGsXx008HbOPj4kBCMYYE9Lj6 15I1pR/zrwQHrzK/RZdosbNAmhm4aPzu1CD8+jGrmUiA7GnOomO4g0n3E6G552d4b9Gs NJucGMYF7PYGWqzZ5ngalKsgvuIC4RqHGUGMvX9jzjC3emVbNZLQ3IwQcaraajhk7h9k jyrQ== X-Gm-Message-State: ALoCoQlyK4+H7W+pHtm9Zo+gQRTRCw+ZsLjSuGfyeywTLqYhQ4TE21VLUtqhCJPwhLJFQCUtuB6WkLCqGXLhguBQ3/LK2L48Mj3zAsxRS2hfNWWTcRmM9/vKoXR0ZbGkMwzctXamT9no86RFktXehiassioeMZRfb8PAzu6A15bVNHDTLFN+DqPFLmIgbL2mRdi3ro9bX/G7 X-Received: by 10.50.153.50 with SMTP id vd18mr22303858igb.6.1384942672327; Wed, 20 Nov 2013 02:17:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 20 Nov 2013 02:17:31 -0800 (PST) In-Reply-To: <528C8878.4090808@globis.net> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528C6E76.1010704@globis.net> <528C8878.4090808@globis.net> From: Lorenzo Colitti Date: Wed, 20 Nov 2013 19:17:31 +0900 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=089e013a009e04d53a04eb99180f Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:18:01 -0000 --089e013a009e04d53a04eb99180f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 7:01 PM, Ray Hunter wrote: > So what does the draft really say? > > Here's some filtering rules, that you may or may not like, which may or > may not be overridden, which may change over time, which only mitigate a > very limited number of threats, and maybe the ISP will manage the > security policy but maybe the end user wants to take this responsibility > Pretty much. Oh, and "this ISP has rolled it out and has not seen any issues so far". > Where's the evidence to say that this approach is any better than an > open security policy of "allow everything bi-directionally" ? > None, but none is required because nobody is trying to make such a statement. Which is good, because there is zero chance of this or any other IETF working group (or actually, any group of more than... oh, about 3 engineers) agreeing on such statement. > The threats are listed in the draft as: > > o denial of service by packet flooding: overwhelming either the > access bandwidth or the bandwidth of a slower link in the > residential network (like a slow home automation network) or the > CPU power of a slow IPv6 host (like networked thermostat or any > other sensor type nodes); > > not covered. > o denial of service by Neighbor Discovery cache exhaustion > [RFC6583]: the outside attacker floods the inside prefix(es) with > packets with a random destination address forcing the CPE to > exhaust its memory and its CPU in useless Neighbor Solicitations; > > not covered. > o denial of service by service requests: like sending print jobs > from the Internet to an ink jet printer until the ink cartridge is > empty or like filing some file server with junk data; > > not covered.e.g. port 515 > > o unauthorized use of services: like accessing a webcam or a file > server which are open to anonymous access within the residential > network but should not be accessed from outside of the home > network or accessing to remote desktop or SSH with weak password > protection; > > not covered. e.g. port 8080. > > o exploiting a vulnerability in the host in order to get access to > data or to execute some arbitrary code in the attacked host such > as several against old versions of Windows; > > not covered. > > o trojanized host (belonging to a Botnet) can communicate via a > covert channel to its master and launch attacks to Internet > targets. > > not covered. > Right. And the draft doesn't claim that to addresses those threats. > And in the Security section, the draft only addresses "Unauthorized > access because vulnerable ports are blocked" ? > Yep. As the abstract says, it's a balance. But the point about this draft is not the filtering policy itself, and in fact, the document makes no claims about what the policy should be. (This is good, because there's no chance of the WG ever agreeing on any specific policy.) It simply says, "here are some threats. here's what we rolled out. here's what we found out." IMO this is perfectly acceptable for an operational group such as this one, and it is of value because it represents real operational experience. IMHO this threat is anyway blocked by machine firewalls running on every > modern OS shipping today (any device that is likely to support IPv6) > I agree with you, but good luck finding lots of other people who do. As an aside, I'm confused how can you simultaneously make the argument that the draft doesn't cover port 515 and port 8080, and then in the same breath say that that threat is blocked anyway by any device that is likely to support IPv6. But again, neither is really the point of this draft. Cheees, Lorenzo --089e013a009e04d53a04eb99180f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2013 at 7:01 PM, Ray Hunter <v6ops@globis.= net> wrote:
So what does the draft really say?

Here's some filtering rules, that you may or may not like, which may or=
may not be overridden, which may change over time, which only mitigate a very limited number of threats, and maybe the ISP will manage the
security policy but maybe the end user wants to take this responsibility

Pretty much. Oh, and "this ISP has r= olled it out and has not seen any issues so far".
=A0
Where's the evidence to say that this approach is any = better than an
open security policy of "allow everything bi-directionally" ?
=

None, but none is required because nobody = is trying to make such a statement. Which is good, because there is zero ch= ance of this or any other IETF working group (or actually, any group of mor= e than... oh, about 3 engineers) agreeing on such statement.
=A0
The threats are listed in the draft as:

=A0 =A0o =A0denial of service by packet flooding: overwhelming either the =A0 =A0 =A0 access bandwidth or the bandwidth of a slower link in the
=A0 =A0 =A0 residential network (like a slow home automation network) or th= e
=A0 =A0 =A0 CPU power of a slow IPv6 host (like networked thermostat or any=
=A0 =A0 =A0 other sensor type nodes);

not covered.=A0

=A0 =A0o =A0denial of service by Neighbor Discovery cache exhaustion
=A0 =A0 =A0 [RFC6583]: the outside attacker floods the inside prefix(es) wi= th
=A0 =A0 =A0 packets with a random destination address forcing the CPE to =A0 =A0 =A0 exhaust its memory and its CPU in useless Neighbor Solicitation= s;

not covered.=A0

=A0 =A0o =A0denial of service by service requests: like sending print jobs<= br> =A0 =A0 =A0 from the Internet to an ink jet printer until the ink cartridge= is
=A0 =A0 =A0 empty or like filing some file server with junk data;

not covered.e.g. port 515

=A0 =A0o =A0unauthorized use of services: like accessing a webcam or a file=
=A0 =A0 =A0 server which are open to anonymous access within the residentia= l
=A0 =A0 =A0 network but should not be accessed from outside of the home
=A0 =A0 =A0 network or accessing to remote desktop or SSH with weak passwor= d
=A0 =A0 =A0 protection;

not covered. e.g. port 8080.

=A0 =A0o =A0exploiting a vulnerability in the host in order to get access t= o
=A0 =A0 =A0 data or to execute some arbitrary code in the attacked host suc= h
=A0 =A0 =A0 as several against old versions of Windows;

not covered.

=A0 =A0o =A0trojanized host (belonging to a Botnet) can communicate via a =A0 =A0 =A0 covert channel to its master and launch attacks to Internet
=A0 =A0 =A0 targets.

not covered.

Right. And the draft doesn= 't claim that to addresses those threats.
=A0
And in the Security section, the draft only addresses "Unauthorized access because vulnerable ports are blocked" ?
Yep. As the abstract says, it's a balance.

<= /div>
But the point about this draft is not the filtering policy itself= , and in fact, the document makes no claims about what the policy should be= . (This is good, because there's no chance of the WG ever agreeing on a= ny specific policy.) It simply says, "here are some threats. here'= s what we rolled out. here's what we found out." IMO this is perfe= ctly acceptable for an operational group such as this one, and it is of val= ue because it represents real operational experience.

IMHO this threat is anyway blocked by machi= ne firewalls running on every
modern OS shipping today (any device that is likely to support IPv6)

I agree with you, but good luck finding lots = of other people who do.

As an aside, I'm confu= sed how can you simultaneously make the argument that the draft doesn't= cover port 515 and port 8080, and then in the same breath say that that th= reat is blocked anyway by any device that is likely to support IPv6. But ag= ain, neither is really the point of this draft.

Cheees,
Lorenzo
--089e013a009e04d53a04eb99180f-- From simon.perreault@viagenie.ca Wed Nov 20 07:19:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1EF1AE405 for ; Wed, 20 Nov 2013 07:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaLWA7PLhFeW for ; Wed, 20 Nov 2013 07:19:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC5971ADFED for ; Wed, 20 Nov 2013 07:19:04 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5A2D5401FE for ; Wed, 20 Nov 2013 10:18:57 -0500 (EST) Message-ID: <528CD2E1.1060001@viagenie.ca> Date: Wed, 20 Nov 2013 10:18:57 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@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-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 15:19:06 -0000 Le 2013-11-20 03:09, Mikael Abrahamsson a écrit : > One way would be to have a recommendation to detect NAT64 and then > detect NAT44, and in the case of both being present, prefer one of them > consistently? The current state-of-the-art in NAT traversal expressly discourages this kind of one-size-fits-all discovery. You need to think about NAT on a per-flow basis, not on a per-host basis. The presence or kind of NAT that you will discover may depend on IP source or destination, transport protocol, port number, load on the NAT device, time of day, phase of the moon, etc. ICE for every flow? Built into the OS? Yuck! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Nov 20 07:21:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37AC1AE42C for ; Wed, 20 Nov 2013 07:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXIHf7FBBcI2 for ; Wed, 20 Nov 2013 07:21:48 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 976901AE425 for ; Wed, 20 Nov 2013 07:21:48 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1FAA5401FE for ; Wed, 20 Nov 2013 10:21:42 -0500 (EST) Message-ID: <528CD385.4090500@viagenie.ca> Date: Wed, 20 Nov 2013 10:21:41 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> <528CD2E1.1060001@viagenie.ca> In-Reply-To: <528CD2E1.1060001@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 15:21:50 -0000 Le 2013-11-20 10:18, Simon Perreault a écrit : > Le 2013-11-20 03:09, Mikael Abrahamsson a écrit : >> One way would be to have a recommendation to detect NAT64 and then >> detect NAT44, and in the case of both being present, prefer one of them >> consistently? > > The current state-of-the-art in NAT traversal expressly discourages this > kind of one-size-fits-all discovery. You need to think about NAT on a > per-flow basis, not on a per-host basis. The presence or kind of NAT > that you will discover may depend on IP source or destination, transport > protocol, port number, load on the NAT device, time of day, phase of the > moon, etc. I forgot to finish my thoughts: but it might be good enough if we scope what we want to accomplish with discovery tightly enough. For example, using the information for prioritization in happy eyeballs might be more than fine. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From brian.e.carpenter@gmail.com Wed Nov 20 11:42:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087041AE097 for ; Wed, 20 Nov 2013 11:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXuhjzhT9OXd for ; Wed, 20 Nov 2013 11:42:50 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 848881A1F3E for ; Wed, 20 Nov 2013 11:42:50 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so7903159pde.20 for ; Wed, 20 Nov 2013 11:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NV8c2Z5BZNN3Mfqd3SrMuZN3Pm3MFVax3ZjRULqlw14=; b=WeZyavZYb6J1zKDi6AuJnZTNAsyjqlgtVQkDzgCAv2G4WQYFSc6NGGbDKfgUqdTdDH Qqc+MSsxnayjYGCUdg9s/MmlgUiByhWo8muDX69lrI5Xq9zr6gpWqGjThOe3Q1ewCS+L BAAL753/iVoSPsS2UipmB7+0FMi8u3Bt03J9dACuBnKx1dAVHxngDJv6TKOzWQRTGwqI lq4ozOPHeY/c1QBaCZJM/whLdNR9NsA27rxoebYRN9Kd5eE2lFcWzpV3qWaOKkGzZoEn 1dbOamdDmIr89zPmBrN2l6k9pOPf1lSYUgOGYvOpVke6UICHAR7s+kkQxh7yzcBbZgTQ wv9A== X-Received: by 10.68.105.35 with SMTP id gj3mr2394065pbb.202.1384976564056; Wed, 20 Nov 2013 11:42:44 -0800 (PST) Received: from [192.168.178.20] (118.199.69.111.dynamic.snap.net.nz. [111.69.199.118]) by mx.google.com with ESMTPSA id yh1sm39857368pbc.21.2013.11.20.11.42.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 11:42:43 -0800 (PST) Message-ID: <528D10B7.8080201@gmail.com> Date: Thu, 21 Nov 2013 08:42:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Lampo References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: [v6ops] RFC 6092 [was draft-ietf-v6ops-balanced-ipv6-security WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:42:52 -0000 On 20/11/2013 22:37, Marc Lampo wrote: > Yes, RFC 6092 recommends that unsolicited packets be dropped by default ! > > REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 > "Destination Unreachable" error code 1 (Communication with > destination administratively prohibited), to any unsolicited > inbound SYN packet after waiting at least 6 seconds without > first forwarding the associated outbound SYN or SYN/ACK from > the interior peer. Er, no, it recommends that unacknowledged unsolicited SYNs should cause Destination Unreachable, if no TCP listener has responded after 6 seconds. The gateway isn't dropping anything. It is required to be stateful for 6 seconds in case there is a response. > "transparent mode" "MAY" be the default (which, in the context, I interpret > as a kind of "second choice") That interpretation is not justified by RFC 2119. > > REC-49 Internet gateways with IPv6 simple security capabilities MUST > provide an easily selected configuration option that permits > a "transparent mode" of operation that forwards all > unsolicited flows regardless of forwarding direction, i.e., > not to use the IPv6 simple security capabilities of the > gateway. The transparent mode of operation MAY be the > default configuration. Brian From markzzzsmith@yahoo.com.au Wed Nov 20 11:52:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4D61AE47D for ; Wed, 20 Nov 2013 11:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfeuLb_LH-kh for ; Wed, 20 Nov 2013 11:52:24 -0800 (PST) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id 87AC11AE1A6 for ; Wed, 20 Nov 2013 11:52:24 -0800 (PST) Received: from [98.139.212.150] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2013 19:52:17 -0000 Received: from [98.139.212.222] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2013 19:52:17 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 20 Nov 2013 19:52:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 867214.70124.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 18861 invoked by uid 60001); 20 Nov 2013 19:52:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1384977137; bh=OBVDMBrNwDVXk9R0Wg8MyVXfHnH3835YYXVO5wWd44M=; 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=0P2irdLMTMwulBorsjEph8cTC5co/t/QIm5yACjjwIxVA7j/YfLPnQfr7zoPUXWn6UDqnfnWYnNJOtn4LG52XgxwvxZASN5Cp51ufi8a126ZsZT6KELbclLQSnH1O4ddo/o6FDZLZYeQy7357q0N1Uh9HJhbwVzhY/0ZTEZtiF0= 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=Zhj/ZiT5nj4Ndre0Z/ORSEU2BPFGBSwteTQXE83iZ8BULXHf+SzqAeVHscTpaRuR2nQLdRc5pVnsgVmaL2ZLCkKitR/hDgHa2d5IaBhUyPnpNvwF/cEnuMPpLoEg/uklfx1niRqk24uMCWFk0I1tgQxuTCg2yekL71CMD2L/gj0=; X-YMail-OSG: dlf_ai8VM1kOEhXIYIWthngrSBB5ITlslcepBH81n00go34 NwHyjJLiQIRd.GTPRanS3xIhMFyhaqlq3X0jPoOrSvNorbMeQHfZvuYaEzDM kJbaXxe3fDz7D8jYiGRhSxb9aWXniQNr3A9VpuVBeGwAvY1ZiYwsSIR84P0d lm83dyuvoNj0FvbSvZS1h0OlaEX9en10gQLlNzVjGNt632LHwrTep1tkRW7e EFaCw35aN0oMm3rGt6PlpQufZR6tgC6RLRu6jV9AiljqM2RpJA8uZkKEZZx1 y2D4KnFEeUVwxOIkjNBKoVfm86_RIlRGZ6nkrrrtesy8JaU7p8gmkLrpH4jn bOyFDPkHBw3f6HeIovMivqkxAtAfHT8IAu.MhZOBkXor2dElTbKppRCFWq_C 1_ufq5PvTkddvycbRYUrKvO0CUNzuGSBX8zTaAYxlOSVWbsEpjPvHd1KTYBS 685MZXs3R60QnJSv9CNsY95K6iNWag2RJVpAwrig_Glw4fcGXURBU2dUZ0UQ QRp50w5TBG6OABi1oD6L1FXNbXlxgGBwP1BL5WhFy3ja6OmkAHNSO8tLj5.X 9ouLtnAggiNqeGNT4TjjF61fr4bEUKAbWlBlrsUKGq.o5 Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Wed, 20 Nov 2013 11:52:17 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBNYXJjIExhbXBvIDxtYXJjLmxhbXBvLmlldGZAZ21haWwuY29tPiAKPkNjOiBSYXkgSHVudGVyIDx2Nm9wc0BnbG9iaXMubmV0PjsgInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.IAo.U2VudDogV2VkbmVzZGF5LCAyMCBOb3ZlbWJlciAyMDEzIDc6MTAgUE0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtYmFsYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.166.601 References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> Message-ID: <1384977137.17317.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Wed, 20 Nov 2013 11:52:17 -0800 (PST) From: Mark ZZZ Smith To: Lorenzo Colitti , Marc Lampo In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:52:26 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Marc Lampo =0A>Cc: = Ray Hunter ; "v6ops@ietf.org WG" =0A>Sen= t: Wednesday, 20 November 2013 7:10 PM=0A>Subject: Re: [v6ops] draft-ietf-v= 6ops-balanced-ipv6-security WGLC=0A> =0A>=0A>=0A>On Wed, Nov 20, 2013 at 5:= 01 PM, Marc Lampo wrote:=0A>=0A>This document s= tates, for several recommendations in RFC 6092, exactly the opposite of tha= t document.=0A>>=0A>=0A>=0A>Which ones? Obviously you're not suggesting tha= t RFC 6092 recommends that unsolicited inbound packets be dropped by defaul= t, right? Because it doesn't say that.=0A>=A0=0A>In addition, as I touched = in my very first reaction, this draft lists a number of threats - section 2= .=0A>>But, in my opinion, none of those threats are addressed by the rules = for balanced security - section 3.1.=0A>>=A0(my first comment only referred= to the last threat on covert channels, but I must rephrase)=0A>>=0A>=0A>= =0A>Do you have text to suggest?=0A>=A0=0A>In reply to the question : yes, = personally I would be happier if the ISP dropped all unsolicited packets to= wards my network (except IPsec).=0A>>=0A>=0A>=0A>And there are people in th= is working group that will never agree with you. For example, I will never = agree with you.=0A>=0A>=0A>But fortunately, that has no relevance on this d= ocument. Since this document does not recommend a security policy, saying "= I don't like the security policy" (which is your opinion, and one you're pe= rfectly entitled to) is not a valid reason not to publish this document.=0A= >=0A=0AWith a title like "Balanced Security for IPv6 Residential CPE" it ha= s strong overtures of being IETF recommendations.=0A=0AWith a title like "S= wisscomm's IPv6 CPE Firewalling Policy Deployment", it doesn't.=0A=0A=0A=0A= =0A>_______________________________________________=0A>v6ops mailing list= =0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A>= =0A> From markzzzsmith@yahoo.com.au Wed Nov 20 12:05:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF431AE14E for ; Wed, 20 Nov 2013 12:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSBNhstuA1Ei for ; Wed, 20 Nov 2013 12:05:49 -0800 (PST) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7C1AE12D for ; Wed, 20 Nov 2013 12:05:48 -0800 (PST) Received: from [98.139.215.142] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2013 20:05:42 -0000 Received: from [98.139.212.193] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2013 20:05:42 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 20 Nov 2013 20:05:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 437999.32440.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 86916 invoked by uid 60001); 20 Nov 2013 20:05:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1384977942; bh=DMQ/+gcZwie5cgOC9pQsmHl9Zj5m9dV+6crs2auMKjM=; 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=w4NCrQAIygI/rvWdIsTDZiPblRBEZCdpiPsySsSBvLUUAN4e3/NMipCA8jVnHNB1TFWS4D5Jmet6HpyfCtax4PkZqbMEMaqyQIfmXktFDpn8CWkX5x3/vIOUfDb7HFJbuQAYoHd8bNk/D/2zGnSksE3XmgWp1jAjkU6qTdF/alY= 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=3+A3IueAi/pwGrTRDJsb2OMZM2U/x9T2zbDoF2GF1jgv54qjd0YSb2vQv0qSPRmkdkS2FXoqLLnYu0BotA05Yx07BrVTyDVagffwLutx4oQG4H+8dh/mh4TgCLnqXixbQtbGHcOSFlOtL+UjeY1w9zAVX9mXCtQE0o08ScoS6tA=; X-YMail-OSG: eHwuk64VM1lQ57CuV9kK1JAQQ8dukV38ZmWNMjnHHKxJqwv X6cCDcnXLwIECw6F4yb9i9T00wjHwZukA6IE4wAct6NFsg7jlQrTyGGOW6Pz PkGMqNq3QScSn3wHqFG.tlMVarftw9fFO0mIJD.BFJ2oN_NeWVbG6ofsYyDC dHuZsg8EI2SApFUmBnDQoytGoxjc0xORFN6kTrPTFZAw.AMis7ptloovrm2Y jU6kBGV0d7yCjDO3lZUJiGsLivANPD1_.DJnv03PMCJhfTwogzxhb41YShLq DQEgNRywUZHCGo61f4aLc.7EN5m82PodbK8T1P_41YxRnwHiiOQn1R.vn8OI gLFeRA7jNIyKw94rv7BCzdAAP7tVA9GAA1ArVzs.gpLGJiYawgsXXgix2WMA .3NLN8GLYLOk2sTDYqqeNpld_6tmPNt_Ws35ohkrjOB.c9vNzO8XhEbLg2.v uHAdSSZDTkMavOk14mKQgbw1kBRlMfbk8ckTn7NfUE4Ja.gcBxHjcsXKrU0I 0D026asJyhsWxEBBCu08DZ2cBQlDr2WAmpyG.gm6Vby.1.rSwAzlyUGjxGgF 9ZTql_4nVsDkX.Sl99u.FG1AnxwfR0vMVmZDyw6_fD08R Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 20 Nov 2013 12:05:41 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBSYXkgSHVudGVyIDx2Nm9wc0BnbG9iaXMubmV0PiAKPkNjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBXZWRuZXNkYXksIDIwIE5vdmVtYmVyIDIwMTMgOToxNyBQTQo.U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1iYWxhbmNlZC1pcHY2LXNlY3VyaXR5IFdHTEMKPiAKPgo.Cj5PbiBXZWQsIE4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.166.601 References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528C6E76.1010704@globis.net> <528C8878.4090808@globis.net> Message-ID: <1384977941.86783.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 20 Nov 2013 12:05:41 -0800 (PST) From: Mark ZZZ Smith To: Lorenzo Colitti , Ray Hunter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:05:51 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Ray Hunter =0A>Cc: "v6ops@ie= tf.org WG" =0A>Sent: Wednesday, 20 November 2013 9:17 PM= =0A>Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC=0A> = =0A>=0A>=0A>On Wed, Nov 20, 2013 at 7:01 PM, Ray Hunter = wrote:=0A>=0A>So what does the draft really say?=0A>>=0A>>Here's some filte= ring rules, that you may or may not like, which may or=0A>>may not be overr= idden, which may change over time, which only mitigate a=0A>>very limited n= umber of threats, and maybe the ISP will manage the=0A>>security policy but= maybe the end user wants to take this responsibility=0A>>=0A>=0A>=0A>Prett= y much. Oh, and "this ISP has rolled it out and has not seen any issues so = far".=0A>=A0=0A=0AHow do they know? What methods have they used to be sure = of that? All it sounds like is that they've passively waited for any compla= ints after deploying this, and as they haven't heard any, they've decided t= hat the _only reason_ they haven't heard complaints is because their measur= e has worked. That is not evidence.=0A=0AHow do they know IPv6's large addr= ess space isn't the actual thing that has prevented their customers being a= ttacked?=0A=0AHow do they know that host based firewalls isn't the reason t= hat there hasn't been a successful attack?=0A=0A=0AHow do they know that th= ere hasn't been an attack, and it is just that they don't know about it?=A0= =0A=0AWhere is the _measurement_ of the effectiveness or not of this, and w= here is the evidence that some other measure isn't the reason that there ha= ven't been any known attacks?=0A=0A=0A=0A>Where's the evidence to say that = this approach is any better than an=0A>>open security policy of "allow ever= ything bi-directionally" ?=0A>>=0A>=0A>=0A>None, but none is required becau= se nobody is trying to make such a statement. Which is good, because there = is zero chance of this or any other IETF working group (or actually, any gr= oup of more than... oh, about 3 engineers) agreeing on such statement.=0A>= =A0=0A>The threats are listed in the draft as:=0A>>=0A>>=A0 =A0o =A0denial = of service by packet flooding: overwhelming either the=0A>>=A0 =A0 =A0 acce= ss bandwidth or the bandwidth of a slower link in the=0A>>=A0 =A0 =A0 resid= ential network (like a slow home automation network) or the=0A>>=A0 =A0 =A0= CPU power of a slow IPv6 host (like networked thermostat or any=0A>>=A0 = =A0 =A0 other sensor type nodes);=0A>>=0A>>not covered.=A0=0A>=0A>>=A0 =A0o= =A0denial of service by Neighbor Discovery cache exhaustion=0A>>=A0 =A0 = =A0 [RFC6583]: the outside attacker floods the inside prefix(es) with=0A>>= =A0 =A0 =A0 packets with a random destination address forcing the CPE to=0A= >>=A0 =A0 =A0 exhaust its memory and its CPU in useless Neighbor Solicitati= ons;=0A>>=0A>>not covered.=A0=0A>=0A>>=A0 =A0o =A0denial of service by serv= ice requests: like sending print jobs=0A>>=A0 =A0 =A0 from the Internet to = an ink jet printer until the ink cartridge is=0A>>=A0 =A0 =A0 empty or like= filing some file server with junk data;=0A>>=0A>>not covered.e.g. port 515= =0A>>=0A>>=A0 =A0o =A0unauthorized use of services: like accessing a webcam= or a file=0A>>=A0 =A0 =A0 server which are open to anonymous access within= the residential=0A>>=A0 =A0 =A0 network but should not be accessed from ou= tside of the home=0A>>=A0 =A0 =A0 network or accessing to remote desktop or= SSH with weak password=0A>>=A0 =A0 =A0 protection;=0A>>=0A>>not covered. e= .g. port 8080.=0A>>=0A>>=A0 =A0o =A0exploiting a vulnerability in the host = in order to get access to=0A>>=A0 =A0 =A0 data or to execute some arbitrary= code in the attacked host such=0A>>=A0 =A0 =A0 as several against old vers= ions of Windows;=0A>>=0A>>not covered.=0A>>=0A>>=A0 =A0o =A0trojanized host= (belonging to a Botnet) can communicate via a=0A>>=A0 =A0 =A0 covert chann= el to its master and launch attacks to Internet=0A>>=A0 =A0 =A0 targets.=0A= >>=0A>>not covered.=0A>>=0A>=0A>=0A>Right. And the draft doesn't claim that= to addresses those threats.=0A>=A0=0A>And in the Security section, the dra= ft only addresses "Unauthorized=0A>>access because vulnerable ports are blo= cked" ?=0A>>=0A>=0A>=0A>Yep. As the abstract says, it's a balance.=0A>=0A>= =0A>But the point about this draft is not the filtering policy itself, and = in fact, the document makes no claims about what the policy should be. (Thi= s is good, because there's no chance of the WG ever agreeing on any specifi= c policy.) It simply says, "here are some threats. here's what we rolled ou= t. here's what we found out." IMO this is perfectly acceptable for an opera= tional group such as this one, and it is of value because it represents rea= l operational experience.=0A>=0A>=0A>IMHO this threat is anyway blocked by = machine firewalls running on every=0A>>modern OS shipping today (any device= that is likely to support IPv6)=0A>>=0A>=0A>=0A>I agree with you, but good= luck finding lots of other people who do.=0A>=0A>=0A>As an aside, I'm conf= used how can you simultaneously make the argument that the draft doesn't co= ver port 515 and port 8080, and then in the same breath say that that threa= t is blocked anyway by any device that is likely to support IPv6. But again= , neither is really the point of this draft.=0A>=0A>=0A>Cheees,=0A>Lorenzo= =0A>=0A>_______________________________________________=0A>v6ops mailing li= st=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A>= =0A> From marc.lampo.ietf@gmail.com Wed Nov 20 22:51:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FF51AE024 for ; Wed, 20 Nov 2013 22:51:38 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwWr7bOoNuzH for ; Wed, 20 Nov 2013 22:51:37 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C0CAC1ADFD6 for ; Wed, 20 Nov 2013 22:51:36 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id 10so3617515vbe.23 for ; Wed, 20 Nov 2013 22:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qDbeHcnZjSRXTkJKoql0UotGJSbmfjW8j0RKDM82RaY=; b=0eU9XWTFfUIZd9i/lwGJCy7Zgan8ddmpp8YiRmHvfJ1EzpoYqWo5jeL81JfLChUByY DRZuL4/ZkuSLzdE2VGbznMYZcRSL5+Xf/hNUdkpA5rxo9mhNSP5VU3vuGL92vT+zPzy3 mbgJQwZPa48A58ODSswtkpI8EygG+Ad6J3WDCwBFnmXx26JoU9Zwc2JqSChzJwbmeYSo NU/sphYBJN8jCOzRyYKkuIdc77N3hbYs6dtShSldJV0yBUpDFd7zLYf1JTdKOBtDAV3A ovYRpRXq30nxqgB1WDnHTnaP2o6cqjoCo9Het86QOCjrYYvyp8Dzw1S149QJhJyF2Pgi IL1A== MIME-Version: 1.0 X-Received: by 10.58.255.233 with SMTP id at9mr4458054ved.20.1385016690031; Wed, 20 Nov 2013 22:51:30 -0800 (PST) Received: by 10.58.227.66 with HTTP; Wed, 20 Nov 2013 22:51:29 -0800 (PST) In-Reply-To: <528D10B7.8080201@gmail.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528D10B7.8080201@gmail.com> Date: Thu, 21 Nov 2013 07:51:29 +0100 Message-ID: From: Marc Lampo To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7bf15fc8d1427404ebaa53f3 Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] RFC 6092 [was draft-ietf-v6ops-balanced-ipv6-security WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 06:51:38 -0000 --047d7bf15fc8d1427404ebaa53f3 Content-Type: text/plain; charset=ISO-8859-1 A pity that the text can be interpreted in various ways and that those lead to completely opposite results. (written by a politician ? ;-) On Wed, Nov 20, 2013 at 8:42 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 20/11/2013 22:37, Marc Lampo wrote: > > Yes, RFC 6092 recommends that unsolicited packets be dropped by default ! > > > > REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 > > "Destination Unreachable" error code 1 (Communication with > > destination administratively prohibited), to any unsolicited > > inbound SYN packet after waiting at least 6 seconds without > > first forwarding the associated outbound SYN or SYN/ACK from > > the interior peer. > > Er, no, it recommends that unacknowledged unsolicited SYNs should cause > Destination Unreachable, if no TCP listener has responded after 6 seconds. > The gateway isn't dropping anything. It is required to be stateful for > 6 seconds in case there is a response. > > > "transparent mode" "MAY" be the default (which, in the context, I > interpret > > as a kind of "second choice") > > That interpretation is not justified by RFC 2119. > > > > > REC-49 Internet gateways with IPv6 simple security capabilities MUST > > provide an easily selected configuration option that permits > > a "transparent mode" of operation that forwards all > > unsolicited flows regardless of forwarding direction, i.e., > > not to use the IPv6 simple security capabilities of the > > gateway. The transparent mode of operation MAY be the > > default configuration. > > Brian > > --047d7bf15fc8d1427404ebaa53f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A pity that the text can be interpreted in various wa= ys and that those lead to completely opposite results.

(writte= n by a politician ? ;-)


On Wed, Nov 20, 2013 at 8:42 PM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 20/11/2013 22:37, Marc Lampo wrote:
> Yes, RFC 6092 recommends that unsolicited packets be dropped by defaul= t !
>
> =A0 REC-34 =A0By DEFAULT, a gateway MUST respond with an ICMPv6
> =A0 =A0 =A0 =A0 =A0 =A0"Destination Unreachable" error code = 1 (Communication with
> =A0 =A0 =A0 =A0 =A0 =A0destination administratively prohibited), to an= y unsolicited
> =A0 =A0 =A0 =A0 =A0 =A0inbound SYN packet after waiting at least 6 sec= onds without
> =A0 =A0 =A0 =A0 =A0 =A0first forwarding the associated outbound SYN or= SYN/ACK from
> =A0 =A0 =A0 =A0 =A0 =A0the interior peer.

Er, no, it recommends that unacknowledged unsolicited SYNs should cause
Destination Unreachable, if no TCP listener has responded after 6 seconds.<= br> The gateway isn't dropping anything. It is required to be stateful for<= br> 6 seconds in case there is a response.

> "transparent mode" "MAY" be the default (which, in= the context, I interpret
> as a kind of "second choice")

That interpretation is not justified by RFC 2119.

>
> =A0 =A0REC-49 =A0Internet gateways with IPv6 simple security capabilit= ies MUST
> =A0 =A0 =A0 =A0 =A0 =A0provide an easily selected configuration option= that permits
> =A0 =A0 =A0 =A0 =A0 =A0a "transparent mode" of operation tha= t forwards all
> =A0 =A0 =A0 =A0 =A0 =A0unsolicited flows regardless of forwarding dire= ction, i.e.,
> =A0 =A0 =A0 =A0 =A0 =A0not to use the IPv6 simple security capabilitie= s of the
> =A0 =A0 =A0 =A0 =A0 =A0gateway. =A0The transparent mode of operation M= AY be the
> =A0 =A0 =A0 =A0 =A0 =A0default configuration.

=A0 =A0Brian


--047d7bf15fc8d1427404ebaa53f3-- From lorenzo@google.com Wed Nov 20 22:57:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185A11AE02F for ; Wed, 20 Nov 2013 22:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMA89ZHQx0Yd for ; Wed, 20 Nov 2013 22:57:09 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D6CB41AE07C for ; Wed, 20 Nov 2013 22:57:08 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so9414428iec.19 for ; Wed, 20 Nov 2013 22:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=g1xc1K8DEVF0Vo2sbGZrmvT0Q5FK2JQpageCmdlNO7o=; b=fIaT0L/6Zx/p7rqyZNkYbEGsFlYZL2k6dgXvM0sWmfSuy7YODJbpESyN09myHdibvB 3ZsAm9V1D1ufA1fqT6wxvKJifLKeY+8LpqpywG3iKvUB1FzvBckTG60eOcVRnCFkJVrE dY2Ahx7A0jEqT2KcoqKQG0Unl6HxGKhZcabEKotf8xVUDMlKT24/NNk/Y+r4TVZlZhFO G1AGFX/A9nvs2J9TdCpW7NtWy6ikoj69wSlnF8Kq6ownjKkfv3s2kgSWoVsddVIIsLXZ ufF5MAnlcc9otxKK4R17NamS5RbC7wMb1sur5vsmomciW0PQXvLMXtMvu2zXKT/q3c3C HxSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=g1xc1K8DEVF0Vo2sbGZrmvT0Q5FK2JQpageCmdlNO7o=; b=K/StRtzYBw9bFLNt3GdVGbYeNxwgvZnM18BEyX1qy+YAGDgmzh8TLMSo0Q8D9jR9O0 afpX5+FV4WrVUQqJj4kapRBZQkJRXUblqIYYA+nYxzyFISHYqwlv/Qt4ArO9MB921lFf Ny5+VcDnepfCzuBqrgme/ju2B2LnSxLsyBY3iLnYcgl6oTfH8ay+9fj0tExOtNs8Hv8f tssf0Cmw/RHcBREEBOblUiSuLFLkGKkIg0nd3ZV0S3yVSX0PjGzTjX9zYwf5Y1dWjL3x wRZWFNs83nU0gHIpAdYNefuM1pEkBf4PvtLh/Ts6e7wfc9O2Xz+64zOmH6YLJmgmPkpE v1zw== X-Gm-Message-State: ALoCoQkHrf4QMcqseTZ2zhETUUA8sa/4KkcVyutZcbPH5+rlM3Y1Z+hrmWSzL5iOCARUUNYrbdG2JHrWwOiToNvesRr+ucoZqNKTAvh5FWVxE+T+eq2sBXRv82WWc+AY8wA2cqwaj1vP5lSBMGAC4jJQ8rdi/IkjG+hZYezbCTx4GenhHfFOMwe4Yn0Ds4GJqAPsVtMKvbWx X-Received: by 10.50.66.163 with SMTP id g3mr4256393igt.20.1385017022024; Wed, 20 Nov 2013 22:57:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 20 Nov 2013 22:56:41 -0800 (PST) In-Reply-To: References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528D10B7.8080201@gmail.com> From: Lorenzo Colitti Date: Thu, 21 Nov 2013 15:56:41 +0900 Message-ID: To: Marc Lampo Content-Type: multipart/alternative; boundary=047d7bdca31c9b3a7204ebaa6796 Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] RFC 6092 [was draft-ietf-v6ops-balanced-ipv6-security WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 06:57:10 -0000 --047d7bdca31c9b3a7204ebaa6796 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 21, 2013 at 3:51 PM, Marc Lampo wrote: > A pity that the text can be interpreted in various ways and that those > lead to completely opposite results. > So can the text, "Here's how to configure the firewall. The firewall can be turned on or off." --047d7bdca31c9b3a7204ebaa6796 Content-Type: text/html; charset=ISO-8859-1
On Thu, Nov 21, 2013 at 3:51 PM, Marc Lampo <marc.lampo.ietf@gmail.com> wrote:
A pity that the text can be interpreted in various ways and that those lead to completely opposite results.

So can the text, "Here's how to configure the firewall. The firewall can be turned on or off."
--047d7bdca31c9b3a7204ebaa6796-- From v6ops@globis.net Wed Nov 20 23:31:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E975D1AE08B for ; Wed, 20 Nov 2013 23:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7LaBG6gQAZW for ; Wed, 20 Nov 2013 23:31:23 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 761D51A1F55 for ; Wed, 20 Nov 2013 23:31:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4009387008A; Thu, 21 Nov 2013 08:31:16 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR2H4iCmkGfl; Thu, 21 Nov 2013 08:31:16 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 163D987007B; Thu, 21 Nov 2013 08:31:16 +0100 (CET) Message-ID: <528DB6C2.9020609@globis.net> Date: Thu, 21 Nov 2013 08:31:14 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Mark ZZZ Smith References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <1384977137.17317.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1384977137.17317.YahooMailNeo@web142503.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 07:31:25 -0000 Mark ZZZ Smith wrote: > > > >> ________________________________ >> From: Lorenzo Colitti >> To: Marc Lampo >> Cc: Ray Hunter ; "v6ops@ietf.org WG" >> Sent: Wednesday, 20 November 2013 7:10 PM >> Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC >> >> >> >> On Wed, Nov 20, 2013 at 5:01 PM, Marc Lampo wrote: >> >> This document states, for several recommendations in RFC 6092, exactly the opposite of that document. >> Which ones? Obviously you're not suggesting that RFC 6092 recommends that unsolicited inbound packets be dropped by default, right? Because it doesn't say that. >> >> In addition, as I touched in my very first reaction, this draft lists a number of threats - section 2. >>> But, in my opinion, none of those threats are addressed by the rules for balanced security - section 3.1. >>> (my first comment only referred to the last threat on covert channels, but I must rephrase) >>> >> Do you have text to suggest? >> >> In reply to the question : yes, personally I would be happier if the ISP dropped all unsolicited packets towards my network (except IPsec). >> And there are people in this working group that will never agree with you. For example, I will never agree with you. >> >> >> But fortunately, that has no relevance on this document. Since this document does not recommend a security policy, saying "I don't like the security policy" (which is your opinion, and one you're perfectly entitled to) is not a valid reason not to publish this document. >> > > With a title like "Balanced Security for IPv6 Residential CPE" it has strong overtures of being IETF recommendations. > > With a title like "Swisscomm's IPv6 CPE Firewalling Policy Deployment", it doesn't. > > +1 Would this be better as an individual submission instead of a v6ops WG doc? >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > -- Regards, RayH From brian.e.carpenter@gmail.com Thu Nov 21 11:23:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032E91AE06D for ; Thu, 21 Nov 2013 11:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjuMsDyyEV7D for ; Thu, 21 Nov 2013 11:23:51 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD721AE05D for ; Thu, 21 Nov 2013 11:23:51 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rr13so193596pbb.9 for ; Thu, 21 Nov 2013 11:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HAQj1kK7CkWzgpBeZXqAfNrzW7KimBjsbYEzRi7wY1I=; b=yQtR0xjbyDdKWMPnSOLAnw2MnO9VdmuFknJbREPT7OhjPVxwSKmrsxvnXU4XelYiya 6rE4orP7qmqkEtJWXlMogcifVM4o6PBu6rEAn09nmWNtNUkI2QGPHoR6WzbjcmmuCYis tY6pf74PIRtF166Hz9jH6xMVU/eLrudyrq/TQjA4zD2S0bUB6tqI248oSmZBKneLbYlb Tn0myrLJxf1lN3GlFx6U4y7utbceGDkNCreLRj72/Gs17WT/2GLWksj9E/mh88nbZLbJ 2OVK2nifiVHHaG7x5lQAlkflO/EsUpHfvEy81f4uem04ltns57An+RI/mcR7CkQmk4MU biiQ== X-Received: by 10.68.139.233 with SMTP id rb9mr7960110pbb.29.1385061824516; Thu, 21 Nov 2013 11:23:44 -0800 (PST) Received: from [192.168.178.20] (131.200.69.111.dynamic.snap.net.nz. [111.69.200.131]) by mx.google.com with ESMTPSA id iu7sm47770776pbc.45.2013.11.21.11.23.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 11:23:43 -0800 (PST) Message-ID: <528E5DC2.2040108@gmail.com> Date: Fri, 22 Nov 2013 08:23:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Lampo References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528D10B7.8080201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] RFC 6092 [was draft-ietf-v6ops-balanced-ipv6-security WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:23:53 -0000 On 21/11/2013 19:51, Marc Lampo wrote: > A pity that the text can be interpreted in various ways and that those lead > to completely opposite results. Well yes, I'd say that text is unclear and should have been fixed before publication. However, when you think of how to implement it, the requirement to wait at least 6 seconds tells you that (a) the firewall is stateful and (b) there might be a response packet coming, so the firewall must have forwarded the incoming SYN. > > (written by a politician ? ;-) No, just a careless engineer, and reviewed by other careless engineers! We all share the blame ;-) Brian > > > On Wed, Nov 20, 2013 at 8:42 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 20/11/2013 22:37, Marc Lampo wrote: >>> Yes, RFC 6092 recommends that unsolicited packets be dropped by default ! >>> >>> REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 >>> "Destination Unreachable" error code 1 (Communication with >>> destination administratively prohibited), to any unsolicited >>> inbound SYN packet after waiting at least 6 seconds without >>> first forwarding the associated outbound SYN or SYN/ACK from >>> the interior peer. >> Er, no, it recommends that unacknowledged unsolicited SYNs should cause >> Destination Unreachable, if no TCP listener has responded after 6 seconds. >> The gateway isn't dropping anything. It is required to be stateful for >> 6 seconds in case there is a response. >> >>> "transparent mode" "MAY" be the default (which, in the context, I >> interpret >>> as a kind of "second choice") >> That interpretation is not justified by RFC 2119. >> >>> REC-49 Internet gateways with IPv6 simple security capabilities MUST >>> provide an easily selected configuration option that permits >>> a "transparent mode" of operation that forwards all >>> unsolicited flows regardless of forwarding direction, i.e., >>> not to use the IPv6 simple security capabilities of the >>> gateway. The transparent mode of operation MAY be the >>> default configuration. >> Brian >> >> > From v6ops@globis.net Thu Nov 21 12:21:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB51AE2C7 for ; Thu, 21 Nov 2013 12:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug5o6oyKX3ZB for ; Thu, 21 Nov 2013 12:21:17 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E652F1AE2C3 for ; Thu, 21 Nov 2013 12:21:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 193A3870F99; Thu, 21 Nov 2013 21:21:09 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQZs+0ys5ct2; Thu, 21 Nov 2013 21:21:09 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E86DE87007B; Thu, 21 Nov 2013 21:21:08 +0100 (CET) Message-ID: <528E6B33.7050405@globis.net> Date: Thu, 21 Nov 2013 21:21:07 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Lorenzo Colitti References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528C6E76.1010704@globis.net> <528C8878.4090808@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 20:21:18 -0000 > Lorenzo Colitti > 20 November 2013 11:17 > On Wed, Nov 20, 2013 at 7:01 PM, Ray Hunter wrote: > >> So what does the draft really say? >> >> Here's some filtering rules, that you may or may not like, which may or >> may not be overridden, which may change over time, which only mitigate a >> very limited number of threats, and maybe the ISP will manage the >> security policy but maybe the end user wants to take this responsibility >> > > Pretty much. Oh, and "this ISP has rolled it out and has not seen any > issues so far". > > >> Where's the evidence to say that this approach is any better than an >> open security policy of "allow everything bi-directionally" ? >> > > None, but none is required because nobody is trying to make such a > statement. Which is good, because there is zero chance of this or any other > IETF working group (or actually, any group of more than... oh, about 3 > engineers) agreeing on such statement. > >> The threats are listed in the draft as: >> >> o denial of service by packet flooding: overwhelming either the >> access bandwidth or the bandwidth of a slower link in the >> residential network (like a slow home automation network) or the >> CPU power of a slow IPv6 host (like networked thermostat or any >> other sensor type nodes); >> >> not covered. > > >> o denial of service by Neighbor Discovery cache exhaustion >> [RFC6583]: the outside attacker floods the inside prefix(es) with >> packets with a random destination address forcing the CPE to >> exhaust its memory and its CPU in useless Neighbor Solicitations; >> >> not covered. > > >> o denial of service by service requests: like sending print jobs >> from the Internet to an ink jet printer until the ink cartridge is >> empty or like filing some file server with junk data; >> >> not covered.e.g. port 515 >> >> o unauthorized use of services: like accessing a webcam or a file >> server which are open to anonymous access within the residential >> network but should not be accessed from outside of the home >> network or accessing to remote desktop or SSH with weak password >> protection; >> >> not covered. e.g. port 8080. >> >> o exploiting a vulnerability in the host in order to get access to >> data or to execute some arbitrary code in the attacked host such >> as several against old versions of Windows; >> >> not covered. >> >> o trojanized host (belonging to a Botnet) can communicate via a >> covert channel to its master and launch attacks to Internet >> targets. >> >> not covered. >> > > Right. And the draft doesn't claim that to addresses those threats. > > >> And in the Security section, the draft only addresses "Unauthorized >> access because vulnerable ports are blocked" ? >> > > Yep. As the abstract says, it's a balance. > > But the point about this draft is not the filtering policy itself, and in > fact, the document makes no claims about what the policy should be. (This > is good, because there's no chance of the WG ever agreeing on any specific > policy.) It simply says, "here are some threats. here's what we rolled out. > here's what we found out." IMO this is perfectly acceptable for an > operational group such as this one, and it is of value because it > represents real operational experience. Thanks to the authors for sharing experiences, and kudos to them, but I am still confused about why this draft should be stamped approved as a v6ops WG document, because it hasn't really been widely debated as a generic security model, and it seems more geared to describing what one provider has done. > IMHO this threat is anyway blocked by machine firewalls running on every >> modern OS shipping today (any device that is likely to support IPv6) >> > > I agree with you, but good luck finding lots of other people who do. > > As an aside, I'm confused how can you simultaneously make the argument that > the draft doesn't cover port 515 and port 8080, and then in the same breath > say that that threat is blocked anyway by any device that is likely to > support IPv6. But again, neither is really the point of this draft. There is nothing to say that an ACL on a router and an end user device are mutually exclusive, depending on whose security model you are implementing (ISP's or end user's). But IMHO "Half an ACL" is worse than no ACL at all, or a complete blocking ACL: It stops legitimate users performing their normal tasks, whilst leaving the system wide open to the abusers. And it's a complete pain to debug or explain to a help desk or users. If you're going to block a function because it's a threat, then block all of the associated ports. Thinking about this further: if port 8080 and 443 were open for the duration of this trial, and there were no incidents, doesn't that rather suggest that there were no real issues with allowing incoming sessions to web servers in general, and thus the block on port 80 was in fact redundant? Similarly if LPD was open for the duration of the trial, doesn't it suggest that there was no real problem with remote (ab)users printing to customer's printers? regards, > > Cheees, > Lorenzo > > -- Regards, RayH From cb.list6@gmail.com Thu Nov 21 14:40:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294F81AE345 for ; Thu, 21 Nov 2013 14:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA0LYUMTPnf5 for ; Thu, 21 Nov 2013 14:40:11 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id DC4A51AE1A8 for ; Thu, 21 Nov 2013 14:40:10 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so424463wes.12 for ; Thu, 21 Nov 2013 14:40:03 -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=gH2jVROd9Vpso97E2La6skXhQNEnIzYMm2y+siDIRYI=; b=RozTwfAFgmGe4YjH5Tjzn9pvCwIeSmoj0jZGTLEfFN51dLsQMfvc6tAIYJ+FZ5hmbF 1y4SseDd20LnufjxFsMO6kOaGpqdlc8kcZOF0n+F1J/cRRbBfWesUyFuLGkLdNcMIINu U1rfGe2JCDAiqd8mvFwsOxCYtbDB1Hqjc/qsytXrZOYTAQNhUMGSbSlF7BETS/ARSMRh 8K1JdY9hItrtL8L5XpWtyHcvhBgTbeP7Sv4uRZc8W3nYWjb2f7e0WvqVtaB1SdGR1o00 kEWIXRLYB5+ylcjVM3b7mQw09PcJT+am9c7MOGqG2kUhKCf+gyMvK+lrH4YjQb+7xu8z jp4g== MIME-Version: 1.0 X-Received: by 10.180.219.33 with SMTP id pl1mr7870644wic.49.1385073603588; Thu, 21 Nov 2013 14:40:03 -0800 (PST) Received: by 10.217.58.133 with HTTP; Thu, 21 Nov 2013 14:40:03 -0800 (PST) Received: by 10.217.58.133 with HTTP; Thu, 21 Nov 2013 14:40:03 -0800 (PST) In-Reply-To: <528E5DC2.2040108@gmail.com> References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528D10B7.8080201@gmail.com> <528E5DC2.2040108@gmail.com> Date: Thu, 21 Nov 2013 14:40:03 -0800 Message-ID: From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1134c92821373b04ebb79446 Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] RFC 6092 [was draft-ietf-v6ops-balanced-ipv6-security WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 22:40:13 -0000 --001a1134c92821373b04ebb79446 Content-Type: text/plain; charset=ISO-8859-1 On Nov 21, 2013 11:23 AM, "Brian E Carpenter" wrote: > > On 21/11/2013 19:51, Marc Lampo wrote: > > A pity that the text can be interpreted in various ways and that those lead > > to completely opposite results. > > Well yes, I'd say that text is unclear and should have been fixed before > publication. However, when you think of how to implement it, the requirement > to wait at least 6 seconds tells you that (a) the firewall is stateful and > (b) there might be a response packet coming, so the firewall must have > forwarded the incoming SYN. > > > > > (written by a politician ? ;-) > > No, just a careless engineer, and reviewed by other careless engineers! > We all share the blame ;-) > Well. The stateful inspection debate did not have a strong consensus then, like now. When consensus is weak, the guidance is weak. Death by 1,000 cuts. Many network operators think stateful inspection is an Achilles heel of a network and an affront to the internet model (me) .Others think it is a "must have" . The ietf should not guide either way since there is no strong consensus. This I-D is very useful for networks that choose no stateful inspection of ipv6 -- including me, Swisscom, Alitbox... CB > Brian > > > > > > > On Wed, Nov 20, 2013 at 8:42 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 20/11/2013 22:37, Marc Lampo wrote: > >>> Yes, RFC 6092 recommends that unsolicited packets be dropped by default ! > >>> > >>> REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 > >>> "Destination Unreachable" error code 1 (Communication with > >>> destination administratively prohibited), to any unsolicited > >>> inbound SYN packet after waiting at least 6 seconds without > >>> first forwarding the associated outbound SYN or SYN/ACK from > >>> the interior peer. > >> Er, no, it recommends that unacknowledged unsolicited SYNs should cause > >> Destination Unreachable, if no TCP listener has responded after 6 seconds. > >> The gateway isn't dropping anything. It is required to be stateful for > >> 6 seconds in case there is a response. > >> > >>> "transparent mode" "MAY" be the default (which, in the context, I > >> interpret > >>> as a kind of "second choice") > >> That interpretation is not justified by RFC 2119. > >> > >>> REC-49 Internet gateways with IPv6 simple security capabilities MUST > >>> provide an easily selected configuration option that permits > >>> a "transparent mode" of operation that forwards all > >>> unsolicited flows regardless of forwarding direction, i.e., > >>> not to use the IPv6 simple security capabilities of the > >>> gateway. The transparent mode of operation MAY be the > >>> default configuration. > >> Brian > >> > >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1134c92821373b04ebb79446 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 21, 2013 11:23 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:<= br> >
> On 21/11/2013 19:51, Marc Lampo wrote:
> > A pity that the text can be interpreted in various ways and that = those lead
> > to completely opposite results.
>
> Well yes, I'd say that text is unclear and should have been fixed = before
> publication. However, when you think of how to implement it, the requi= rement
> to wait at least 6 seconds tells you that (a) the firewall is stateful= and
> (b) there might be a response packet coming, so the firewall must have=
> forwarded the incoming SYN.
>
> >
> > (written by a politician ? ;-)
>
> No, just a careless engineer, and reviewed by other careless engineers= !
> We all share the blame ;-)
>

Well.=A0 The stateful inspection debate did not have a stron= g consensus then, like now.

When consensus is weak, the guidance is weak. Death by 1,000= cuts.=A0

Many network operators think stateful inspection is an Achil= les heel of a network and an affront to the internet model (me) .Others thi= nk it is a "must have"=A0 .

The ietf should not guide either way since there is no stron= g consensus.

This I-D is very useful for networks that choose no stateful= inspection of ipv6 -- including me, Swisscom,=A0 Alitbox...

CB

> =A0 =A0 Brian
>
> >
> >
> > On Wed, Nov 20, 2013 at 8:42 PM, Brian E Carpenter <
> > brian.e.carpenter@= gmail.com> wrote:
> >
> >> On 20/11/2013 22:37, Marc Lampo wrote:
> >>> Yes, RFC 6092 recommends that unsolicited packets be drop= ped by default !
> >>>
> >>> =A0 REC-34 =A0By DEFAULT, a gateway MUST respond with an = ICMPv6
> >>> =A0 =A0 =A0 =A0 =A0 =A0"Destination Unreachable"= ; error code 1 (Communication with
> >>> =A0 =A0 =A0 =A0 =A0 =A0destination administratively prohi= bited), to any unsolicited
> >>> =A0 =A0 =A0 =A0 =A0 =A0inbound SYN packet after waiting a= t least 6 seconds without
> >>> =A0 =A0 =A0 =A0 =A0 =A0first forwarding the associated ou= tbound SYN or SYN/ACK from
> >>> =A0 =A0 =A0 =A0 =A0 =A0the interior peer.
> >> Er, no, it recommends that unacknowledged unsolicited SYNs sh= ould cause
> >> Destination Unreachable, if no TCP listener has responded aft= er 6 seconds.
> >> The gateway isn't dropping anything. It is required to be= stateful for
> >> 6 seconds in case there is a response.
> >>
> >>> "transparent mode" "MAY" be the defau= lt (which, in the context, I
> >> interpret
> >>> as a kind of "second choice")
> >> That interpretation is not justified by RFC 2119.
> >>
> >>> =A0 =A0REC-49 =A0Internet gateways with IPv6 simple secur= ity capabilities MUST
> >>> =A0 =A0 =A0 =A0 =A0 =A0provide an easily selected configu= ration option that permits
> >>> =A0 =A0 =A0 =A0 =A0 =A0a "transparent mode" of = operation that forwards all
> >>> =A0 =A0 =A0 =A0 =A0 =A0unsolicited flows regardless of fo= rwarding direction, i.e.,
> >>> =A0 =A0 =A0 =A0 =A0 =A0not to use the IPv6 simple securit= y capabilities of the
> >>> =A0 =A0 =A0 =A0 =A0 =A0gateway. =A0The transparent mode o= f operation MAY be the
> >>> =A0 =A0 =A0 =A0 =A0 =A0default configuration.
> >> =A0 =A0Brian
> >>
> >>
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a1134c92821373b04ebb79446-- From brian.e.carpenter@gmail.com Thu Nov 21 14:52:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6A71AE3D9 for ; Thu, 21 Nov 2013 14:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj-SAaxTCpR7 for ; Thu, 21 Nov 2013 14:52:31 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id AAE501AE3C5 for ; Thu, 21 Nov 2013 14:52:31 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id w10so401084pde.21 for ; Thu, 21 Nov 2013 14:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ez1HahFQf2tCuwgFvyvSJtEx+Aoafm76/bU2JmiJqeY=; b=ul5zAynKXcvoiOaLfpMg2qqZtONv/WAHK+UXMkFP3gmKUMaXYBUIFUDYZoHkpRHdJh h8hjiyNK6wCMdDo+8FagN9Ptx9JFoMmvu55VhWtnjmkyUTt9zEpHFLi8hJVPL58PA4Zz ezQTccwiik5Pkk/wjIlzlEQDglcqbEQEAtp3YAKeToDF6a1JHdOKIvgXzBn86JnrK7aY V/iZnlij6s8AghfOCAG80+dbWV1aGvG8OhDj2a+d0eEgL3y4rxmJwue4SFKkGLHuIWyT SEKb7LsttMp+3hT4Ksxazs830Kg5A+2ggZzNPm/vV1h6VsV4yj4mLeXjl1Siq+7PWMG6 0Aig== X-Received: by 10.67.3.3 with SMTP id bs3mr8820280pad.46.1385074344889; Thu, 21 Nov 2013 14:52:24 -0800 (PST) Received: from [192.168.178.20] (131.200.69.111.dynamic.snap.net.nz. [111.69.200.131]) by mx.google.com with ESMTPSA id qv8sm48523031pbc.31.2013.11.21.14.52.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 14:52:24 -0800 (PST) Message-ID: <528E8EAF.6080001@gmail.com> Date: Fri, 22 Nov 2013 11:52:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <989B8ED6-273E-45D4-BFD8-66A1793A1C9F@cisco.com> <5288FC15.5080508@globis.net> <528C6E76.1010704@globis.net> <528C8878.4090808@globis.net> <528E6B33.7050405@globis.net> In-Reply-To: <528E6B33.7050405@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 22:52:33 -0000 On 22/11/2013 09:21, Ray Hunter wrote: ... > Thanks to the authors for sharing experiences, and kudos to them, but I > am still confused about why this draft should be stamped approved as a > v6ops WG document, because it hasn't really been widely debated as a > generic security model, and it seems more geared to describing what one > provider has done. That's exactly what it says, and it would be published as Informational, tagged with the "IETF Stream" boilerplate. Of course there's an alternative, resubmitting it to the Independent Submission stream, probably with the word "Swisscom" prepended to the title. Then it would appear with different boilerplate, but the magic words "This document is not an Internet Standards Track specification" would still appear. Brian From wwwrun@rfc-editor.org Fri Nov 22 10:43:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190FD1AE3D5; Fri, 22 Nov 2013 10:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruRgUq7A0JKn; Fri, 22 Nov 2013 10:43:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C54BD1AE3E0; Fri, 22 Nov 2013 10:43:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9E61C75E017; Fri, 22 Nov 2013 10:33:01 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131122183301.9E61C75E017@rfc-editor.org> Date: Fri, 22 Nov 2013 10:33:01 -0800 (PST) Cc: drafts-update-ref@iana.org, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:43:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7084 Title: Basic Requirements for IPv6 Customer Edge Routers Author: H. Singh, W. Beebee, C. Donley, B. Stark Status: Informational Stream: IETF Date: November 2013 Mailbox: shemant@cisco.com, wbeebee@cisco.com, c.donley@cablelabs.com, barbara.stark@att.com Pages: 21 Characters: 46569 Obsoletes: RFC 6204 I-D Tag: draft-ietf-v6ops-6204bis-12.txt URL: http://www.rfc-editor.org/rfc/rfc7084.txt This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From paul.hoffman@vpnc.org Sun Nov 24 18:09:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D281AE399; Sun, 24 Nov 2013 18:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI1Www8T34pd; Sun, 24 Nov 2013 18:09:55 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 55CAB1AE2D9; Sun, 24 Nov 2013 18:09:55 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAP29rDj046069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Nov 2013 19:09:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Nov 2013 18:09:51 -0800 Message-Id: <95E90374-1EC4-4AFB-99E1-C24653BE8EA3@vpnc.org> To: secdir Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Cc: v6ops@ietf.org Subject: [v6ops] SecDir and WG LC review of draft-ietf-v6ops-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 02:09:56 -0000 Greetings. The v6ops chairs apparently asked for an early (pre-IETF-LC) = review of draft-ietf-v6ops-balanced-ipv6-security, "Balanced Security = for IPv6 Residential CPE" which is in WG LC. In short: from a security = standpoint, the document seems fine if you are of the same point of view = as the authors, and terrible if you are not. Neither point of view is = better than the other, so this review will probably not make anyone = happy. The topic of the document is what the initial firewall configuration for = an IPv6 residential gateway should be. It is based on actual deployment = experiences from an ISP. The view of the authors of the document is, = approximately, "IPv6 lets us re-enable the end-to-end principle, so make = that the default for home gateways, modulo closing a couple of = long-standing vulnerabilities". The opposing camp is "end hosts in the = home often have terrible security, so you need to prevent initial = contact from the Internet", with a subset of that group saying "but let = those hosts do PCP to open holes". The IPv6 aspect of the argument seems = to be mostly lost in the noise of the WG LC comments, even though it is = the lead for the draft itself. Calling this draft "Balanced" is kind of like titling a security = protocol with "Simple" (something that I am guilty of...). Please = consider changing the title to something more representative of the = discussion, such as "Permissive" or "Open". =46rom a security standpoint, the document seems self-consistent in its = stance (and certainly more than RFC 6092 was). The list of threats in = section 2 has a few problems, however: - Most of the bullet points are about incoming threats, but then the = last bullet talks about an outgoing threat, and not very well at that. = Either the list should be broken into two and my more outgoing threats = listed, or the last bullet should be removed. - The list doesn't include denial of service from the outside that = exhausts stateful tables in the CPE itself. Give that what is being = described is small-footprint firewalls, this seems like a great attack = that could cause some interesting failure modes. - The example of vulnerable hosts being "old versions of Windows" is out = of place. New versions of all operating systems that live in the home, = and even the CPE itself, are often vulnerable. Given the large amount of discussion from the "closed, open it with PCP" = folks, it is odd that PCP isn't mentioned at all in Section 3, even for = the services that are initially blocked such as HTTP. Given the number = of HTTP-based devices out there that someone might want to control from = outside the home, this seems like a major oversight. The AllowManagement rule in Section 3.1 mentions Broadband Forum TR-69 = as if it is done either at layer 2 or using some non-IP protocol at = layer 3. This should be described in a bit more detail, and that should = be an informative reference. The paragraph after Table 2 makes it seem like doing firmware updates = and policy updates to a CPE are equivalent. =46rom a security = standpoint, that's a terrible comparison. Updating firmware can = introduce many more security issues than updating a policy table. Please = consider removing the firmware option. The last paragraph of Section 3.2 has sexist bullshit in it. I guess I = should give you points for not making it racist too, but still. --Paul Hoffman= From Carl.Wuyts@technicolor.com Mon Nov 25 04:56:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AD21AD687; Mon, 25 Nov 2013 04:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtT_sbibF519; Mon, 25 Nov 2013 04:56:57 -0800 (PST) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 15DF01AD34C; Mon, 25 Nov 2013 04:56:54 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKUpNJAOrkBsEKutEUSisBdIazGi1Uxx0O@postini.com; Mon, 25 Nov 2013 04:56:58 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Nov 2013 13:54:39 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 25 Nov 2013 13:54:40 +0100 From: Wuyts Carl To: "rfc-editor@rfc-editor.org" , "ietf-announce@ietf.org" , "rfc-dist@rfc-editor.org" Date: Mon, 25 Nov 2013 13:54:38 +0100 Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers Thread-Index: Ac7ns3Z0rQMXWKIHQG2+pEydokN41wCKbm7g Message-ID: <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> In-Reply-To: <20131122183301.9E61C75E017@rfc-editor.org> 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: "drafts-update-ref@iana.org" , "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:57:00 -0000 All, I can still see it is impossible today to fully comply to this as, IMHO, t= he following requirement is impossible to meet (the SHOULD part): "" WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. [RFC6177] covers the recommendations for service providers for prefix allocation sizes. "" Checking if a ia_Pd is "too small" is impossible, i.e., what is "too small"= ? What if certain changes are done after initial ia_pd ? What .... ? Regs Carl -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of rfc-editor@rfc-edi= tor.org Sent: vrijdag 22 november 2013 19:33 To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org; v6ops@ietf.org; rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Rout= ers A new Request for Comments is now available in online RFC libraries. =20 RFC 7084 Title: Basic Requirements for IPv6 Customer=20 Edge Routers=20 Author: H. Singh, W. Beebee, C. Donley, B. Stark Status: Informational Stream: IETF Date: November 2013 Mailbox: shemant@cisco.com,=20 wbeebee@cisco.com,=20 c.donley@cablelabs.com, barbara.stark@att.com Pages: 21 Characters: 46569 Obsoletes: RFC 6204 I-D Tag: draft-ietf-v6ops-6204bis-12.txt URL: http://www.rfc-editor.org/rfc/rfc7084.txt This document specifies requirements for an IPv6 Customer Edge (CE) router.= Specifically, the current version of this document focuses on the basic p= rovisioning of an IPv6 CE router and the provisioning of IPv6 hosts attache= d to it. The document also covers IP transition technologies. Two transit= ion technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructure= s (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the documen= t. The document obsoletes RFC 6204. This document is a product of the IPv6 Operations Working Group of the IETF= . INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this = memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_sear= ch.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From victor@jvknet.com Mon Nov 25 05:35:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1881AD9AB for ; Mon, 25 Nov 2013 05:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar76Fb48jwTR for ; Mon, 25 Nov 2013 05:35:53 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 42A841AD94A for ; Mon, 25 Nov 2013 05:35:53 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so5441654wid.3 for ; Mon, 25 Nov 2013 05:35:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jytJC6f3RSunFAjaiqpeGVgu3Xf2cyvsilq7Cl/DZ4c=; b=Y8AsxKQEY/sSHVmYa6nLWE1HMFdbzYnkWZGW0e91qSmqssycq1oBcknc4BMzbDSnyh k21si4tjFEa3wLsxI0gx3fPcEnY0XB4xDg7O8Ebz+KqZVoCzpKvmWJvgMWjvkZkoGY5A CshuDedxVEZA4IHNJDAQtTUTVahcvsZckGnE+GCX6eY747PqiA4535Pc2qMKPz8zbblp GcA1/MtP99z8y7H79C4xyo5B6nzH3zny52QEuvTxydZu2tZU31ysJ74qtyVw1yf0khZm DXMPdpPQBhW8OSi+xz8uBnhs1a78usU3cE5nNsDyzP4/tKH57y4qZRd3oBEhtp28ZQC2 op+g== X-Gm-Message-State: ALoCoQmfD4MKgs3VflzGc1K+Ofy/uS5nIuGBqwtUSVHhKcW1HEVn4zfKcGImVs10NRowihfuGvRz MIME-Version: 1.0 X-Received: by 10.180.185.130 with SMTP id fc2mr13516001wic.43.1385386552787; Mon, 25 Nov 2013 05:35:52 -0800 (PST) Received: by 10.216.35.4 with HTTP; Mon, 25 Nov 2013 05:35:52 -0800 (PST) In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> Date: Mon, 25 Nov 2013 08:35:52 -0500 Message-ID: From: Victor Kuarsingh To: Wuyts Carl Content-Type: multipart/alternative; boundary=001a11c350da5b17c104ec007114 Cc: "drafts-update-ref@iana.org" , "v6ops@ietf.org" , "rfc-dist@rfc-editor.org" , "ietf-announce@ietf.org" , "rfc-editor@rfc-editor.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 13:35:56 -0000 --001a11c350da5b17c104ec007114 Content-Type: text/plain; charset=ISO-8859-1 Carl, Are you saying that vendors will be unable to determine the number of [local] interfaces during this initialization step? As for "what is too small", is WPD-2 not sufficient in determining that? WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. As for changes after initial IA_PD, are you concerned about new interfaces coming up on the box after IPv6 initialization? If so, should those not be part of the PD size request upfront? E.g. Ask for /64 for all active and inactive interfaces. regards, Victor K On Mon, Nov 25, 2013 at 7:54 AM, Wuyts Carl wrote: > All, > I can still see it is impossible today to fully comply to this as, IMHO, > the following requirement is impossible to meet (the SHOULD part): > "" > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > prefix size different from what is given in the hint. If the > delegated prefix is too small to address all of its > interfaces, the IPv6 CE router SHOULD log a system management > error. [RFC6177] covers the recommendations for service > providers for prefix allocation sizes. > "" > Checking if a ia_Pd is "too small" is impossible, i.e., what is "too > small" ? What if certain changes are done after initial ia_pd ? What .... > ? > > Regs > Carl > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: vrijdag 22 november 2013 19:33 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org; v6ops@ietf.org; rfc-editor@rfc-editor.org > Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge > Routers > > A new Request for Comments is now available in online RFC libraries. > > > RFC 7084 > > Title: Basic Requirements for IPv6 Customer > Edge Routers > Author: H. Singh, W. Beebee, > C. Donley, B. Stark > Status: Informational > Stream: IETF > Date: November 2013 > Mailbox: shemant@cisco.com, > wbeebee@cisco.com, > c.donley@cablelabs.com, > barbara.stark@att.com > Pages: 21 > Characters: 46569 > Obsoletes: RFC 6204 > > I-D Tag: draft-ietf-v6ops-6204bis-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc7084.txt > > This document specifies requirements for an IPv6 Customer Edge (CE) > router. Specifically, the current version of this document focuses on the > basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts > attached to it. The document also covers IP transition technologies. Two > transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 > Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered > in the document. The document obsoletes RFC 6204. > > This document is a product of the IPv6 Operations Working Group of the > IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see > http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the author > of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for unlimited > distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > 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 > --001a11c350da5b17c104ec007114 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Carl,

Are you saying that vendors will = be unable to determine the number of [local] interfaces during this initial= ization step? =A0As for "what is too small", is WPD-2 not suffici= ent in determining that?

   WPD-2:  The IPv6 CE router MAY indica=
te as a hint to the delegating
           router the size of the prefix it requires.  If so, it MUST
           ask for a prefix large enough to assign one /64 for each of
           its interfaces, rounded up to the nearest nibble, and SHOULD
           be configurable to ask for more.

As for changes after initial IA_PD, are you concerned= about new interfaces coming up on the box after IPv6 initialization? =A0If= so, should those not be part of the PD size request upfront? E.g. Ask for = /64 for all active and inactive interfaces.

regards,

Victor K=


On Mon,= Nov 25, 2013 at 7:54 AM, Wuyts Carl <Carl.Wuyts@technicolor.com<= /a>> wrote:
All,
I can still see it is impossible today to fully comply to this as, IMHO, = =A0the following requirement is impossible to meet (the SHOULD part):
""
WPD-3: =A0The IPv6 CE router MUST be prepared to accept a delegated
=A0 =A0 =A0 =A0 =A0 =A0prefix size different from what is given in the hint= . =A0If the
=A0 =A0 =A0 =A0 =A0 =A0delegated prefix is too small to address all of its<= br> =A0 =A0 =A0 =A0 =A0 =A0interfaces, the IPv6 CE router SHOULD log a system m= anagement
=A0 =A0 =A0 =A0 =A0 =A0error. =A0[RFC6177] covers the recommendations for s= ervice
=A0 =A0 =A0 =A0 =A0 =A0providers for prefix allocation sizes.
""
Checking if a ia_Pd is "too small" is impossible, i.e., what is &= quot;too small" ? =A0What if certain changes are done after initial ia= _pd ? =A0What .... ?

Regs
Carl


-----Original Message-----
From: v6ops [mailto:v6ops-bounces= @ietf.org] On Behalf Of rf= c-editor@rfc-editor.org
Sent: vrijdag 22 november 2013 19:33
To: ietf-announce@ietf.org; <= a href=3D"mailto:rfc-dist@rfc-editor.org">rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.or= g; v6ops@ietf.org; rfc-editor@rfc-editor.org
Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Rout= ers

A new Request for Comments is now available in online RFC libraries.


=A0 =A0 =A0 =A0 RFC 7084

=A0 =A0 =A0 =A0 Title: =A0 =A0 =A0Basic Requirements for IPv6 Customer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Edge Routers
=A0 =A0 =A0 =A0 Author: =A0 =A0 H. Singh, W. Beebee,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 C. Donley, B. Stark
=A0 =A0 =A0 =A0 Status: =A0 =A0 Informational
=A0 =A0 =A0 =A0 Stream: =A0 =A0 IETF
=A0 =A0 =A0 =A0 Date: =A0 =A0 =A0 November 2013
=A0 =A0 =A0 =A0 Mailbox: =A0 =A0sheman= t@cisco.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wbeebee@cisco.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 c.donley@cablelabs.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 barbara.stark@att.com
=A0 =A0 =A0 =A0 Pages: =A0 =A0 =A021
=A0 =A0 =A0 =A0 Characters: 46569
=A0 =A0 =A0 =A0 Obsoletes: =A0RFC 6204

=A0 =A0 =A0 =A0 I-D Tag: =A0 =A0draft-ietf-v6ops-6204bis-12.txt

=A0 =A0 =A0 =A0 URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc7084.txt<= /a>

This document specifies requirements for an IPv6 Customer Edge (CE) router.= =A0Specifically, the current version of this document focuses on the basic= provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attac= hed to it. =A0The document also covers IP transition technologies. =A0Two t= ransition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infr= astructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered = in the document. =A0The document obsoletes RFC 6204.

This document is a product of the IPv6 Operations Working Group of the IETF= .


INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this = memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=A0 http://www.ietf.org/mailman/listinfo/ietf-announce
=A0 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<= br>
For searching the RFC series, see http://www.rfc-editor.org/search/rfc_s= earch.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the author = of the RFC in question, or to = rfc-editor@rfc-editor.org. =A0Unless specifically noted otherwise on th= e RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

--001a11c350da5b17c104ec007114-- From Carl.Wuyts@technicolor.com Mon Nov 25 05:43:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67071AD69E; Mon, 25 Nov 2013 05:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFA36XASJWof; Mon, 25 Nov 2013 05:43:49 -0800 (PST) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 082B51ACCE3; Mon, 25 Nov 2013 05:43:46 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKUpNT+0Owgh/QX+ogaNa0yybGEQ1Ml2x0@postini.com; Mon, 25 Nov 2013 05:43:49 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Nov 2013 14:39:16 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 25 Nov 2013 14:39:17 +0100 From: Wuyts Carl To: Victor Kuarsingh Date: Mon, 25 Nov 2013 14:39:16 +0100 Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers Thread-Index: Ac7p406OXByR0Sn2S4i0S7kayo08eQAAC6lg Message-ID: <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3135C2851EB6764BACEF35D8B495596806FB9EEDEDMOPESMBX01eut_" MIME-Version: 1.0 Cc: "drafts-update-ref@iana.org" , "v6ops@ietf.org" , "rfc-dist@rfc-editor.org" , "ietf-announce@ietf.org" , "rfc-editor@rfc-editor.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 13:43:53 -0000 --_000_3135C2851EB6764BACEF35D8B495596806FB9EEDEDMOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Victor, Indeed, this will not be always known upfront. Besides that, if you purely= want to look at all active interfaces, I believe you will be (for resident= ial market at least) push for a /64 for all deployments, and I don't believ= e this should be the goal. After all, many residential scenario's at our c= ustomer base are a single LAN from defs.... regs From: Victor Kuarsingh [mailto:victor@jvknet.com] Sent: maandag 25 november 2013 14:36 To: Wuyts Carl Cc: rfc-editor@rfc-editor.org; ietf-announce@ietf.org; rfc-dist@rfc-editor.= org; drafts-update-ref@iana.org; v6ops@ietf.org Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge = Routers Carl, Are you saying that vendors will be unable to determine the number of [loca= l] interfaces during this initialization step? As for "what is too small",= is WPD-2 not sufficient in determining that? WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. As for changes after initial IA_PD, are you concerned about new interfaces = coming up on the box after IPv6 initialization? If so, should those not be= part of the PD size request upfront? E.g. Ask for /64 for all active and i= nactive interfaces. regards, Victor K On Mon, Nov 25, 2013 at 7:54 AM, Wuyts Carl > wrote: All, I can still see it is impossible today to fully comply to this as, IMHO, t= he following requirement is impossible to meet (the SHOULD part): "" WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. [RFC6177] covers the recommendations for service providers for prefix allocation sizes. "" Checking if a ia_Pd is "too small" is impossible, i.e., what is "too small"= ? What if certain changes are done after initial ia_pd ? What .... ? Regs Carl -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] = On Behalf Of rfc-editor@rfc-editor.org Sent: vrijdag 22 november 2013 19:33 To: ietf-announce@ietf.org; rfc-dist@rfc-edi= tor.org Cc: drafts-update-ref@iana.org; v6ops@ie= tf.org; rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Rout= ers A new Request for Comments is now available in online RFC libraries. RFC 7084 Title: Basic Requirements for IPv6 Customer Edge Routers Author: H. Singh, W. Beebee, C. Donley, B. Stark Status: Informational Stream: IETF Date: November 2013 Mailbox: shemant@cisco.com, wbeebee@cisco.com, c.donley@cablelabs.com, barbara.stark@att.com Pages: 21 Characters: 46569 Obsoletes: RFC 6204 I-D Tag: draft-ietf-v6ops-6204bis-12.txt URL: http://www.rfc-editor.org/rfc/rfc7084.txt This document specifies requirements for an IPv6 Customer Edge (CE) router.= Specifically, the current version of this document focuses on the basic p= rovisioning of an IPv6 CE router and the provisioning of IPv6 hosts attache= d to it. The document also covers IP transition technologies. Two transit= ion technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructure= s (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the documen= t. The document obsoletes RFC 6204. This document is a product of the IPv6 Operations Working Group of the IETF= . INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this = memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_sear= ch.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all= RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ 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 --_000_3135C2851EB6764BACEF35D8B495596806FB9EEDEDMOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI Victor= ,

 =

Indeed, this will not be alway= s known upfront.  Besides that, if you purely want to look at all acti= ve interfaces, I believe you will be (for residential market at least) push= for a /64 for all deployments, and I don’t believe this should be th= e goal.  After all, many residential scenario’s at our customer = base are a single LAN from defs….

 

regs

 

From:= Victor Kuarsingh [mailto:victor@jvknet.com]
Sent: maandag 25 november 2013 14:36
To: Wuyts Carl
Cc: rf= c-editor@rfc-editor.org; ietf-announce@ietf.org; rfc-dist@rfc-editor.org; d= rafts-update-ref@iana.org; v6ops@ietf.org
Subject: Re: [v6ops] RF= C 7084 on Basic Requirements for IPv6 Customer Edge Routers

 

C= arl,

 

Are you saying that vendors will be unable to determ= ine the number of [local] interfaces during this initialization step?  = ;As for "what is too small", is WPD-2 not sufficient in determini= ng that?

 

   =
WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
&nbs=
p;          router the size of=
 the prefix it requires.  If so, it MUST
<=
span style=3D'font-size:12.0pt;color:black'>     &=
nbsp;     ask for a prefix large enough to assign one /=
64 for each of
           i=
ts interfaces, rounded up to the nearest nibble, and SHOULD
   =
;        be configurable to ask for more=
.

 <= /p>

As for changes after initial IA_PD, are = you concerned about new interfaces coming up on the box after IPv6 initiali= zation?  If so, should those not be part of the PD size request upfron= t? E.g. Ask for /64 for all active and inactive interfaces.

<= /div>

 

regards,

 =

Victor K

 

<= div>

On Mon, Nov 25, 2013 at 7:54 AM, Wuyts Carl <Carl.Wuyts@te= chnicolor.com> wrote:

All,
I c= an still see it is impossible today to fully comply to this as, IMHO,  = ;the following requirement is impossible to meet (the SHOULD part):
&quo= t;"
WPD-3:  The IPv6 CE router MUST be prepared to accept a de= legated
           prefix size different f= rom what is given in the hint.  If the
        =    delegated prefix is too small to address all of its
  =          interfaces, the IPv6 CE router SHOULD log= a system management
           error. &nb= sp;[RFC6177] covers the recommendations for service
     =      providers for prefix allocation sizes.
""=
Checking if a ia_Pd is "too small" is impossible, i.e., what = is "too small" ?  What if certain changes are done after ini= tial ia_pd ?  What .... ?

Regs
Carl


-----Original= Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org
Sent: vrijdag 22 november 2= 013 19:33
To: ietf-announce@ie= tf.org; rfc-dist@rfc-editor.= org
Cc: drafts-update-= ref@iana.org; v6ops@ietf.org; rfc-editor@rfc-editor.org
= Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Rout= ers

A new Request for Comments is now available in online RFC librar= ies.


        RFC 7084

    &= nbsp;   Title:      Basic Requirements for IPv6 Custome= r
                    = Edge Routers
        Author:     H. Singh,= W. Beebee,
                &nbs= p;   C. Donley, B. Stark
        Status:  =   Informational
        Stream:     = IETF
        Date:       November 201= 3
        Mailbox:    shemant@cisco.com,
        &nbs= p;           = wbeebee@cisco.com,
              =       c.donley@cab= lelabs.com,
                =     barbara.stark@att.co= m
        Pages:      21
 = ;       Characters: 46569
        Obs= oletes:  RFC 6204

        I-D Tag:   &= nbsp;draft-ietf-v6ops-6204bis-12.txt

        URL= :        http://www.rfc-editor.org/rfc/rfc7084.txt
=
This document specifies requirements for an IPv6 Customer Edge (CE) rou= ter.  Specifically, the current version of this document focuses on th= e basic provisioning of an IPv6 CE router and the provisioning of IPv6 host= s attached to it.  The document also covers IP transition technologies= .  Two transition technologies in RFC 5969's IPv6 Rapid Deployment on = IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are cov= ered in the document.  The document obsoletes RFC 6204.

This do= cument is a product of the IPv6 Operations Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet commun= ity.
It does not specify an Internet standard of any kind. Distribution = of this memo is unlimited.

This announcement is sent to the IETF-Ann= ounce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For = searching the RFC series, see http://www.rfc-editor.org/search/rfc_searc= h.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

= Requests for special distribution should be addressed to either the author = of the RFC in question, or to = rfc-editor@rfc-editor.org.  Unless specifically noted otherwise on= the RFC itself, all RFCs are for unlimited distribution.


The RF= C Editor Team
Association Management Solutions, LLC


_________= ______________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/li= stinfo/v6ops
_______________________________________________
v6op= s mailing list
v6ops@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/v6ops

 

= --_000_3135C2851EB6764BACEF35D8B495596806FB9EEDEDMOPESMBX01eut_-- From Jean-Francois.TremblayING@videotron.com Mon Nov 25 06:27:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90201ADD9A for ; Mon, 25 Nov 2013 06:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0EQNldizUIT for ; Mon, 25 Nov 2013 06:27:14 -0800 (PST) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 86D731ADD9D for ; Mon, 25 Nov 2013 06:27:14 -0800 (PST) In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> To: Carl.Wuyts@technicolor.com MIME-Version: 1.0 X-KeepSent: 1909BE08:00E4773F-85257C2E:004E2BAB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP1 March 08, 2012 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Mon, 25 Nov 2013 09:27:13 -0500 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP3|November 15, 2012) at 11/25/2013 09:27:13, Serialize complete at 11/25/2013 09:27:13 Content-Type: multipart/alternative; boundary="=_alternative 004F660185257C2E_=" Received-SPF: none Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:27:17 -0000 Message en plusieurs parties au format MIME --=_alternative 004F660185257C2E_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > De : Wuyts Carl > Indeed, this will not be always known upfront.=20 Carl, could you please give an example where a router doesn't know=20 upfront the number of interfaces? Even if some of them could be=20 off at some point (Wifi for example), the router usually knows=20 the maximum number of local interfaces it can support.=20 > Besides that, if you > purely want to look at all active interfaces, I believe you will be=20 > (for residential market at least) push for a /64 for all=20 > deployments, and I don?t believe this should be the goal. After=20 > all, many residential scenario?s at our customer base are a single=20 > LAN from defs?. I don't see why this would push /64 in the residential market.=20 Most recent routers are expected to have a few interfaces (one=20 for public wifi and another for the private lan for example) and=20 therefore should hint for a /60 at least. If DHCPv6-PD is supported=20 on the LAN side, a hint for /56 or /48 would be expected.=20 And a hint is just that, a hint. The operator is free to hand out larger prefixes. Some operators will hand out a /64 in the=20 absence of a hint because of a number of broken old implementations unable to carve out /64s out of larger prefixes. But beside these,=20 /56 or larger is expected to become the standard for residential.=20 As a data point, we hand out /56s by default as a cable=20 operator and it works fairly well so far.=20 /JF --=_alternative 004F660185257C2E_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <snip>

> De : Wuyts Carl <Carl.Wuyts@technicolor.com&= gt;
> Indeed, this will not be always known upfront.  

Carl, could you please give an example where a router doesn't know
upfront the number of interfaces? Even if some of them could be
off at some point (Wifi for example), the router usu= ally knows
the maximum number of local interfaces it can suppor= t.

> Besides that, if you
> purely want to look at all active interfaces, I believe you will be
> (for residential market at least) push for a /64 for all
> deployments, and I don’t believe this should be the goal.  = After
> all, many residential scenario’s at our customer base are a sing= le
> LAN from defs….

I don't see why this would push /64 in the residenti= al market.
Most recent routers are expected to have a few inter= faces (one
for public wifi and another for the private lan for example) and
therefore should hint for a /60 at least. If DHCPv6-= PD is supported
on the LAN side, a hint for /56 or /48 would be expe= cted.

And a hint is just that, a hint. The operator is free to hand out
larger prefixes. Some operators will hand out a /64 in the
absence of a hint because of a number of broken old implementations
unable to carve out /64s out of larger prefixes. But beside these,
/56 or larger is expected to become the standard for residential.

As a data point, we hand out /56s by default as a cable
operator and it works fairly well so far.

/JF

--=_alternative 004F660185257C2E_=-- From Carl.Wuyts@technicolor.com Mon Nov 25 06:40:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F541ADDD3 for ; Mon, 25 Nov 2013 06:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABVlo7qbRy7L for ; Mon, 25 Nov 2013 06:40:12 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0FB1AD8DC for ; Mon, 25 Nov 2013 06:40:08 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUpNhQYgIXE1YL2+fXplB5So7YqhxOhcX@postini.com; Mon, 25 Nov 2013 06:40:11 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Nov 2013 15:39:21 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 25 Nov 2013 15:39:22 +0100 From: Wuyts Carl To: "Jean-Francois.TremblayING@videotron.com" Date: Mon, 25 Nov 2013 15:39:21 +0100 Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers Thread-Index: Ac7p6oQCUsnc8NwZQSuNDdCq8VZB9AAADKgQ Message-ID: <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3135C2851EB6764BACEF35D8B495596806FB9EEF39MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:40:16 -0000 --_000_3135C2851EB6764BACEF35D8B495596806FB9EEF39MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A typical CPE has 4 eth ports and wifi, all joined together as ... the LAN = intf, hence 1 interface it is. You do not hand out different prefixes to w= ired and wireless. In fact, you can of course, but this would lead to rout= ed traffic between wired and wireless, which cannot be the target I'd say. Potentially, you could have a separate hotspot/public wifi, even more than = one potentially, although for sure not always used, and very often v4-only= , hence no real need today for ipv6 prefix today. We're deploying in managed CPE, so the hint will for sure not change anythi= ng. I agree it is also "just" a hint, but the req in the RFC says you SHOU= LD flag "too small" and it's exactly that part which is not ok, not the fac= t that you should sent a hint or anything. Today, our customers hand out anything between 48 and 64, and size NOT depe= nding on "too big or too small". And I do get a /56 @ home, so works smooth here too, but the choice of /56 = is not depending small/big number of physical intfs. Regs Carl From: Jean-Francois.TremblayING@videotron.com [mailto:Jean-Francois.Trembla= yING@videotron.com] Sent: maandag 25 november 2013 15:27 To: Wuyts Carl Cc: v6ops@ietf.org; Victor Kuarsingh Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge = Routers > De : Wuyts Carl > > Indeed, this will not be always known upfront. Carl, could you please give an example where a router doesn't know upfront the number of interfaces? Even if some of them could be off at some point (Wifi for example), the router usually knows the maximum number of local interfaces it can support. > Besides that, if you > purely want to look at all active interfaces, I believe you will be > (for residential market at least) push for a /64 for all > deployments, and I don't believe this should be the goal. After > all, many residential scenario's at our customer base are a single > LAN from defs.... I don't see why this would push /64 in the residential market. Most recent routers are expected to have a few interfaces (one for public wifi and another for the private lan for example) and therefore should hint for a /60 at least. If DHCPv6-PD is supported on the LAN side, a hint for /56 or /48 would be expected. And a hint is just that, a hint. The operator is free to hand out larger prefixes. Some operators will hand out a /64 in the absence of a hint because of a number of broken old implementations unable to carve out /64s out of larger prefixes. But beside these, /56 or larger is expected to become the standard for residential. As a data point, we hand out /56s by default as a cable operator and it works fairly well so far. /JF --_000_3135C2851EB6764BACEF35D8B495596806FB9EEF39MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A typical = CPE has 4 eth ports and wifi, all joined together as … the LAN intf, = hence 1 interface it is.  You do not hand out different = prefixes to wired and wireless.  In fact, you can of course, but this = would lead to routed traffic between wired and wireless, which cannot be th= e target I’d say.

Potentially, you could have a separate hotspot/public wifi, even= more than one potentially,  although for sure not always used, and ve= ry often v4-only, hence no real need today for ipv6 prefix today.

 

We’re deploying in man= aged CPE, so the hint will for sure not change anything.  I agree it i= s also “just” a hint, but the req in the RFC says you SHOULD fl= ag “too small” and it’s exactly that part which is not ok= , not the fact that you should sent a hint or anything. 

 <= /p>

Today, our customers hand out a= nything between 48 and 64, and size NOT depending on “too big or too = small”. 

 

And I do get a /56 @ home, so works smooth here too, but the choice of = /56 is not depending small/big number of physical intfs.<= /p>

 

 

Regs

Carl

 

F= rom: Jean-Francois.TremblayING@videotron.com [mailto:Jean-F= rancois.TremblayING@videotron.com]
Sent: maandag 25 november 201= 3 15:27
To: Wuyts Carl
Cc: v6ops@ietf.org; Victor Kuars= ingh
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6= Customer Edge Routers

 = ;

<snip>

> De : Wuyts Carl <Carl.Wuyts@technicolor.com>
> Indeed, this will not be always known u= pfront.  

Car= l, could you please give an example where a router doesn't know
upfront the number of interfaces?= Even if some of them could be
off at some point (Wifi for example), the router usually knows
the maximum number of loc= al interfaces it can support.

> Besides that, if you
> purely want to look at all ac= tive interfaces, I believe you will be
> (for residential m= arket at least) push for a /64 for all
> deployments, and I= don’t believe this should be the goal.  After
>= all, many residential scenario’s at our customer base are a single <= /tt>
> LAN from defs….

I don't see why this would push /64 in the residentia= l market.
Most recent = routers are expected to have a few interfaces (one
for public wifi and another for the private la= n for example) and
the= refore should hint for a /60 at least. If DHCPv6-PD is supported
on the LAN side, a hint for /56 = or /48 would be expected.

And a hint is just that, a hint. The operator is free to hand out
larger prefixes. Some o= perators will hand out a /64 in the
absence of a hint because of a number of broken old implement= ations
unable to carve= out /64s out of larger prefixes. But beside these,
/56 or larger is expected to become the stand= ard for residential.

As a data point, we hand out /56s by default as a cable
= operator and it works fairly well so f= ar.

/JF

=

= --_000_3135C2851EB6764BACEF35D8B495596806FB9EEF39MOPESMBX01eut_-- From otroan@employees.org Mon Nov 25 06:48:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A761ADC03 for ; Mon, 25 Nov 2013 06:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExEMYBMFJv0E for ; Mon, 25 Nov 2013 06:48:26 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0D51ADBCF for ; Mon, 25 Nov 2013 06:48:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFADBik1KQ/khM/2dsb2JhbABZgwe9MoEqFnSCJQEBBAF5BQsLRlcGiA4GvU0XjlQzB4MggRMDqiaDKTs X-IronPort-AV: E=Sophos;i="4.93,768,1378857600"; d="scan'208";a="1204910" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 25 Nov 2013 14:48:25 +0000 Received: from dhcp-10-61-109-79.cisco.com (dhcp-10-61-109-79.cisco.com [10.61.109.79]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAPEmLj1002843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Nov 2013 14:48:21 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> Date: Mon, 25 Nov 2013 15:48:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <31151BBD-CE4F-42FA-B1CB-32849ACA8B2C@employees.org> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:48:27 -0000 Carl, > A typical CPE has 4 eth ports and wifi, all joined together as =85 the = LAN intf, hence 1 interface it is. You do not hand out different = prefixes to wired and wireless. In fact, you can of course, but this = would lead to routed traffic between wired and wireless, which cannot be = the target I=92d say. > Potentially, you could have a separate hotspot/public wifi, even more = than one potentially, although for sure not always used, and very often = v4-only, hence no real need today for ipv6 prefix today. >=20 > We=92re deploying in managed CPE, so the hint will for sure not change = anything. I agree it is also =93just=94 a hint, but the req in the RFC = says you SHOULD flag =93too small=94 and it=92s exactly that part which = is not ok, not the fact that you should sent a hint or anything.=20 >=20 > Today, our customers hand out anything between 48 and 64, and size NOT = depending on =93too big or too small=94.=20 >=20 > And I do get a /56 @ home, so works smooth here too, but the choice of = /56 is not depending small/big number of physical intfs. the hint is a MAY. you'd be perfectly fine not including it. the hint is largely there to give an indication to the server to give = the same prefix back as it delegated in a previous session. cheers, Ole From victor@jvknet.com Mon Nov 25 06:57:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC951ADE88 for ; Mon, 25 Nov 2013 06:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4GErRbycAFl for ; Mon, 25 Nov 2013 06:57:11 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 56E801AD947 for ; Mon, 25 Nov 2013 06:57:11 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so3896044wes.38 for ; Mon, 25 Nov 2013 06:57:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wnjpZerQbj6z/DcjM5hbp01RSbidaw7S4rsAUkbU8A0=; b=ma2ynsvmVRpENiHjQbEVBiasORZ8ctUUaOr+HTBJXTaUtPG383GNn0x+MudD4AKWN6 wCBeOXsaxJR/dqrViQqLigPiPlLnxTv8MkeVtAWRDokI3iy+JKvnZtioe/NbIHouyWkV 4ocYMrQEoYGbNX3ETkhyMOPXd0gji5ti6cMvcbz8W0FMOcAbQuI1SL1Z5zX1A3HLG02z +MUOtzV5HnI5mHKoQMUR4YYu6TayZXcYdyY4PqtvRj1eTW9J3dxGn9p6htSw9WcrObyG epnVtcng02FDOH+w377pqJYR49wWDvAkfB+VFiIc2yNYAeE3n8ae8PuD/75AxC/7/tbg Tjig== X-Gm-Message-State: ALoCoQkgeTPEXEobH6OGxhH2bn1XfSBPgUjQBv41bs6oaTGff5M9A37YmdLy/cv8ddAoVEX6UeRd MIME-Version: 1.0 X-Received: by 10.194.175.202 with SMTP id cc10mr1988533wjc.48.1385391430976; Mon, 25 Nov 2013 06:57:10 -0800 (PST) Received: by 10.216.35.4 with HTTP; Mon, 25 Nov 2013 06:57:10 -0800 (PST) In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> Date: Mon, 25 Nov 2013 09:57:10 -0500 Message-ID: From: Victor Kuarsingh To: Wuyts Carl Content-Type: multipart/alternative; boundary=089e013d0f481e5b5904ec019482 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:57:14 -0000 --089e013d0f481e5b5904ec019482 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 9:39 AM, Wuyts Carl wro= te: > Hi, > > > > A typical CPE has 4 eth ports and wifi, all joined together as =85 the LA= N > intf, hence *1 interface* it is. You do not hand out different prefixes > to wired and wireless. In fact, you can of course, but this would lead t= o > routed traffic > Carl, In your case above, I am not sure if the Eth ports you are referring to are separate logical interfaces which are just bridged together or if they are just switch ports that connect back to a single logical interface. Notwithstanding this, could you not consider all logical interfaces (regardless if they are bridged day-1) as separate for the purposes of asking for IPv6 PD space? Lets assume that you have 4 eth ports, and standard WiFi interface and a Guest WiFi. This sounds like 6x [potential] interfaces, of which you may only be using 1-2 for now [say LAN/WiFi is one, and Guest WiFi is two). If you ask for IPv6 PD space for all of the potential interfaces, rounded up to the nearest nibble, you would grab a ::/60. So in the beginning, you only configure 2 ::/64s for the interfaces you fire up. If you expand this and/or break out the function later, then you use more (out of the ::/60). If you only got a ::/62 or ::/64 from the operator, then you log an error (right)? If you get a ::/60 or ::/56 you are ok (right)? regards, Victor K > > > > > Regs > > Carl > > > > *From:* Jean-Francois.TremblayING@videotron.com [mailto: > Jean-Francois.TremblayING@videotron.com] > *Sent:* maandag 25 november 2013 15:27 > *To:* Wuyts Carl > *Cc:* v6ops@ietf.org; Victor Kuarsingh > *Subject:* Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer > Edge Routers > > > > > > > De : Wuyts Carl > > Indeed, this will not be always known upfront. > > Carl, could you please give an example where a router doesn't know > upfront the number of interfaces? Even if some of them could be > off at some point (Wifi for example), the router usually knows > the maximum number of local interfaces it can support. > > > Besides that, if you > > purely want to look at all active interfaces, I believe you will be > > (for residential market at least) push for a /64 for all > > deployments, and I don=92t believe this should be the goal. After > > all, many residential scenario=92s at our customer base are a single > > LAN from defs=85. > > I don't see why this would push /64 in the residential market. > Most recent routers are expected to have a few interfaces (one > for public wifi and another for the private lan for example) and > therefore should hint for a /60 at least. If DHCPv6-PD is supported > on the LAN side, a hint for /56 or /48 would be expected. > > And a hint is just that, a hint. The operator is free to hand out > larger prefixes. Some operators will hand out a /64 in the > absence of a hint because of a number of broken old implementations > unable to carve out /64s out of larger prefixes. But beside these, > /56 or larger is expected to become the standard for residential. > > As a data point, we hand out /56s by default as a cable > operator and it works fairly well so far. > > /JF > > --089e013d0f481e5b5904ec019482 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 25, 2013 at 9:39 AM, Wuyts Carl <<= a href=3D"mailto:Carl.Wuyts@technicolor.com" target=3D"_blank">Carl.Wuyts@t= echnicolor.com> wrote:

=A0=

A typical CPE has 4 eth ports and wifi, all joined together as =85 = the LAN intf, hence 1 interface it is.=A0 You do not hand out= different prefixes to wired and wireless.=A0 In fact, you can of course, b= ut this would lead to routed traffic=A0


Carl,

In your case above, I am not sure if the Eth ports you are referring to ar= e separate logical interfaces which are just bridged together or if they ar= e just switch ports that connect back to a single logical interface. =A0Not= withstanding this, could you not consider all logical interfaces (regardles= s if they are bridged day-1) as separate for the purposes of asking for IPv= 6 PD space?

Lets assume that you have 4 eth ports, and standard WiF= i interface and a Guest WiFi. =A0This sounds like 6x [potential] interfaces= , of which you may only be using 1-2 for now [say LAN/WiFi is one, and Gues= t WiFi is two). =A0If you ask for IPv6 PD space for all of the potential in= terfaces, rounded up to the nearest nibble, you would grab a ::/60.

So in the beginning, you only configure 2 ::/64s for th= e interfaces you fire up. =A0If you expand this and/or break out the functi= on later, then you use more (out of the ::/60). =A0If you only got a ::/62 = or ::/64 from the operator, then you log an error (right)? =A0If you get a = ::/60 or ::/56 you are ok (right)?

regards,

Victor K


=A0

=A0

<= p class=3D"MsoNormal"> =A0

Regs<= /u>

Carl

=A0

From: Jean-Francois.TremblayING@videotron.com [mailto= :Jean-Francois.TremblayING@videotron.com]
Sent: maandag 25 november 2013 15:27
To: Wuyts Carl
= Cc: v6ops@ietf.org<= /a>; Victor Kuarsingh
Subject: Re: [v6ops] RFC 7084 on Basic Requ= irements for IPv6 Customer Edge Routers

=A0

<snip>

> De : Wuyts Carl= <Carl.W= uyts@technicolor.com>
> Indeed, this will not be always k= nown upfront. =A0

= Carl, could you please give an example where a router doesn't know
upfront the number of interfaces? Even= if some of them could be
off at some point (Wifi for example), the router usually knows <= /tt>
the maximum number of local interfaces= it can support.

&= gt; Besides that, if you
> purely want to look at all active interfaces, I believe you will b= e
> (for residential market at least) push for a /64 for al= l
> deployments, and I don=92t believe this should be the g= oal. =A0After
> all, many residential scenario=92s at our customer base are a sing= le
> LAN from defs=85.

I don't see why this would push /64 in the reside= ntial market.
Most recent routers are expected to ha= ve a few interfaces (one
for public wifi and another for the private lan for example) and =
therefore should hint for a /60 at lea= st. If DHCPv6-PD is supported
on the LAN side, a hint for /56 or /48 would be expected.

And a hint is just that, a hint. T= he operator is free to hand out
larger prefixes. Some operators will hand out a /64 in the
absence of a hint because of a number = of broken old implementations
unable to carve out /64s out of larger prefixes. But beside these, =
/56 or larger is expected to become th= e standard for residential.

As a data point, we hand out /56s by default as a cable
operator and it works fairly well so f= ar.

/JF
<= br>


--089e013d0f481e5b5904ec019482-- From Carl.Wuyts@technicolor.com Mon Nov 25 06:57:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEF61AD947 for ; Mon, 25 Nov 2013 06:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzcHmrRn8Rb9 for ; Mon, 25 Nov 2013 06:57:40 -0800 (PST) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0879D1AD83F for ; Mon, 25 Nov 2013 06:56:40 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKUpNlI8Yu/13Fm74kpXycRu2CZbhc8HJA@postini.com; Mon, 25 Nov 2013 06:57:37 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Nov 2013 15:53:41 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 25 Nov 2013 15:53:42 +0100 From: Wuyts Carl To: Ole Troan Date: Mon, 25 Nov 2013 15:53:40 +0100 Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers Thread-Index: Ac7p7WmffajmvP9eT5qJJO2fcLbB7QAACoyA Message-ID: <3135C2851EB6764BACEF35D8B495596806FB9EEF8B@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> <31151BBD-CE4F-42FA-B1CB-32849ACA8B2C@employees.org> In-Reply-To: <31151BBD-CE4F-42FA-B1CB-32849ACA8B2C@employees.org> 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: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:57:42 -0000 Hi Ole, I've seen the MAY and SHOULD etc, I just think it is a silly requirement, h= ence should better not be present, so just leave it out (hint can stay in p= erfectly) It in fact leads to customers asking us "too small-checking" in tenders/rfp= /..., so as of that moment, you have to start explaining that this is not p= ossible, there is AND should be NO link between them. You should not put u= p these reqs to the CPEs at all as they make no sense. Everyone will trans= late this their own way. I've talked to someone not too long ago, claiming= that /60 is too small for him/his network, although I would highly doubt h= e has a CPE with 16 physical intfs... Regs Carl -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: maandag 25 november 2013 15:48 To: Wuyts Carl Cc: Jean-Francois.TremblayING@videotron.com; v6ops@ietf.org Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge = Routers Carl, > A typical CPE has 4 eth ports and wifi, all joined together as ... the LA= N intf, hence 1 interface it is. You do not hand out different prefixes to= wired and wireless. In fact, you can of course, but this would lead to ro= uted traffic between wired and wireless, which cannot be the target I'd say= . > Potentially, you could have a separate hotspot/public wifi, even more tha= n one potentially, although for sure not always used, and very often v4-on= ly, hence no real need today for ipv6 prefix today. >=20 > We're deploying in managed CPE, so the hint will for sure not change anyt= hing. I agree it is also "just" a hint, but the req in the RFC says you SH= OULD flag "too small" and it's exactly that part which is not ok, not the f= act that you should sent a hint or anything.=20 >=20 > Today, our customers hand out anything between 48 and 64, and size NOT de= pending on "too big or too small".=20 >=20 > And I do get a /56 @ home, so works smooth here too, but the choice of /5= 6 is not depending small/big number of physical intfs. the hint is a MAY. you'd be perfectly fine not including it. the hint is largely there to give an indication to the server to give the s= ame prefix back as it delegated in a previous session. cheers, Ole From Carl.Wuyts@technicolor.com Mon Nov 25 07:08:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B86D1ADBCF for ; Mon, 25 Nov 2013 07:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm9GTR0kJ0JG for ; Mon, 25 Nov 2013 07:08:15 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAE01ADEDC for ; Mon, 25 Nov 2013 07:08:10 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUpNn2jE48NccFCJb0FA6hbQaV+U/t0cK@postini.com; Mon, 25 Nov 2013 07:08:13 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Nov 2013 16:03:33 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 25 Nov 2013 16:03:34 +0100 From: Wuyts Carl To: Victor Kuarsingh Date: Mon, 25 Nov 2013 16:03:32 +0100 Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers Thread-Index: Ac7p7qw0nWbqFfI/TGef3yGBONZuTgAAC8RA Message-ID: <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3135C2851EB6764BACEF35D8B495596806FB9EEFC9MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 15:08:19 -0000 --_000_3135C2851EB6764BACEF35D8B495596806FB9EEFC9MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, Agree. I do always recommend our customers to assign /56. This doesn't me= an it is always being deployed like this of course, we have single /64s as = well. But this is better for the sake of future proof and leaves some room= for expansion without having to fiddle in the back-end to aggregation etc. The point I want to make is that the req of checking "too small" serves no = goal, as nearly all CPE devices have a similar set of interfaces, of which = some are used separately, mostly not, some have public wifi, mostly not, et= c. It just makes customers asking questions on it, as they base themselves= upon this RFC to send their reqs to CPE vendors. Moreover, too small (too= big too ??) is too much subject of interpretation. Regs Carl From: Victor Kuarsingh [mailto:victor@jvknet.com] Sent: maandag 25 november 2013 15:57 To: Wuyts Carl Cc: Jean-Francois.TremblayING@videotron.com; v6ops@ietf.org Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge = Routers On Mon, Nov 25, 2013 at 9:39 AM, Wuyts Carl > wrote: Hi, A typical CPE has 4 eth ports and wifi, all joined together as ... the LAN = intf, hence 1 interface it is. You do not hand out different prefixes to w= ired and wireless. In fact, you can of course, but this would lead to rout= ed traffic Carl, In your case above, I am not sure if the Eth ports you are referring to are= separate logical interfaces which are just bridged together or if they are= just switch ports that connect back to a single logical interface. Notwit= hstanding this, could you not consider all logical interfaces (regardless i= f they are bridged day-1) as separate for the purposes of asking for IPv6 P= D space? Lets assume that you have 4 eth ports, and standard WiFi interface and a Gu= est WiFi. This sounds like 6x [potential] interfaces, of which you may onl= y be using 1-2 for now [say LAN/WiFi is one, and Guest WiFi is two). If yo= u ask for IPv6 PD space for all of the potential interfaces, rounded up to = the nearest nibble, you would grab a ::/60. So in the beginning, you only configure 2 ::/64s for the interfaces you fir= e up. If you expand this and/or break out the function later, then you use= more (out of the ::/60). If you only got a ::/62 or ::/64 from the operat= or, then you log an error (right)? If you get a ::/60 or ::/56 you are ok = (right)? regards, Victor K Regs Carl From: Jean-Francois.TremblayING@videotron.com [mailto:Jean-Francois.TremblayING@videotron.com] Sent: maandag 25 november 2013 15:27 To: Wuyts Carl Cc: v6ops@ietf.org; Victor Kuarsingh Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge = Routers > De : Wuyts Carl > > Indeed, this will not be always known upfront. Carl, could you please give an example where a router doesn't know upfront the number of interfaces? Even if some of them could be off at some point (Wifi for example), the router usually knows the maximum number of local interfaces it can support. > Besides that, if you > purely want to look at all active interfaces, I believe you will be > (for residential market at least) push for a /64 for all > deployments, and I don't believe this should be the goal. After > all, many residential scenario's at our customer base are a single > LAN from defs.... I don't see why this would push /64 in the residential market. Most recent routers are expected to have a few interfaces (one for public wifi and another for the private lan for example) and therefore should hint for a /60 at least. If DHCPv6-PD is supported on the LAN side, a hint for /56 or /48 would be expected. And a hint is just that, a hint. The operator is free to hand out larger prefixes. Some operators will hand out a /64 in the absence of a hint because of a number of broken old implementations unable to carve out /64s out of larger prefixes. But beside these, /56 or larger is expected to become the standard for residential. As a data point, we hand out /56s by default as a cable operator and it works fairly well so far. /JF --_000_3135C2851EB6764BACEF35D8B495596806FB9EEFC9MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Victor,

 

Agr= ee.  I do always recommend our customers to assign /56.  This doe= sn’t mean it is always being deployed like this of course, we have si= ngle /64s as well.  But this is better for the sake of future proof an= d leaves some room for expansion without having to fiddle in the back-end t= o aggregation etc.

The point I want to make is that the req of checking “too small= ” serves no goal, as nearly all CPE devices have a similar set of int= erfaces, of which some are used separately, mostly not, some have public wi= fi, mostly not, etc.  It just makes customers asking questions on it, = as they base themselves upon this RFC to send their reqs to CPE vendors.&nb= sp; Moreover, too small (too big too ??) is too much subject of interpretat= ion.

&nb= sp;

Regs

Carl=

 

 

From: Victor Kuarsingh [mailto:victor@= jvknet.com]
Sent: maandag 25 november 2013 15:57
To: W= uyts Carl
Cc: Jean-Francois.TremblayING@videotron.com; v6ops@ietf= .org
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6= Customer Edge Routers

 = ;

 

 

On Mon, Nov 25, 2013 at 9:39 AM, Wuyts Carl <Carl.Wuyts@technicolor.co= m> wrote:

Hi,

 

A typical CPE has 4 eth ports and wifi, all joined= together as … the LAN intf, hence 1 interface it is.&n= bsp; You do not hand out different prefixes to wired and wireless.  In= fact, you can of course, but this would lead to routed traffic 

 

=

Carl,

 

In your case = above, I am not sure if the Eth ports you are referring to are separate log= ical interfaces which are just bridged together or if they are just switch = ports that connect back to a single logical interface.  Notwithstandin= g this, could you not consider all logical interfaces (regardless if they a= re bridged day-1) as separate for the purposes of asking for IPv6 PD space?=

 

<= div>

Lets assume that you have 4 eth ports, and standar= d WiFi interface and a Guest WiFi.  This sounds like 6x [potential] in= terfaces, of which you may only be using 1-2 for now [say LAN/WiFi is one, = and Guest WiFi is two).  If you ask for IPv6 PD space for all of the p= otential interfaces, rounded up to the nearest nibble, you would grab a ::/= 60.

 

So in the beginning, you only configure 2 ::/64= s for the interfaces you fire up.  If you expand this and/or break out= the function later, then you use more (out of the ::/60).  If you onl= y got a ::/62 or ::/64 from the operator, then you log an error (right)? &n= bsp;If you get a ::/60 or ::/56 you are ok (right)?

 

regards,

 

Victor K

 

&nb= sp;

 

 

 

 

Regs

Carl

 

From: Jean-Francois.TremblayING@vi= deotron.com [mailto:Jean-Francois.TremblayING@videotron.com]
= Sent: maandag 25 november 2013 15:27
To: Wuyts Carl
= Cc: v6ops@ietf.org<= /a>; Victor Kuarsingh
Subject: Re: [v6ops] RFC 7084 on Basic Requ= irements for IPv6 Customer Edge Routers

 <= o:p>

<snip>

> De : Wuyts Carl <Carl.Wuyts@tec= hnicolor.com>
&= gt; Indeed, this will not be always known upfront.  
<= br>Carl, could you please give an exam= ple where a router doesn't know
upfront the number of interfaces? Even if some of them could be <= /span>
off at some point (Wifi= for example), the router usually knows
the maximum number of local interfaces it can support.

> Besides that, i= f you
> purely want to look at all active interfaces, I believe you w= ill be
> (for residential market at least) push for a /64 f= or all
> deployments, and I don’t believe this should= be the goal.  After
> all, many residential scenario&= #8217;s at our customer base are a single
> LAN from defs&#= 8230;.

I don't see= why this would push /64 in the residential market.
Most recent routers are expected to have a fe= w interfaces (one
for = public wifi and another for the private lan for example) and therefore should hint for a /60 at l= east. If DHCPv6-PD is supported
on the LAN side, a hint for /56 or /48 would be expected. =

And a hint is just that, = a hint. The operator is free to hand out
larger prefixes. Some operators will hand out a /64 in t= he
absence of a hint b= ecause of a number of broken old implementations
unable to carve out /64s out of larger prefixes.= But beside these,
/56= or larger is expected to become the standard for residential. =

As a data point, we hand out /= 56s by default as a cable
operator and it works fairly well so far.

/JF

 

<= /body>= --_000_3135C2851EB6764BACEF35D8B495596806FB9EEFC9MOPESMBX01eut_-- From gert@space.net Mon Nov 25 09:51:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2AD1ADF80 for ; Mon, 25 Nov 2013 09:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NklccTZComYJ for ; Mon, 25 Nov 2013 09:51:42 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 87A271AD8D5 for ; Mon, 25 Nov 2013 09:51:42 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 715EF6099D for ; Mon, 25 Nov 2013 18:51:41 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5179660932 for ; Mon, 25 Nov 2013 18:51:41 +0100 (CET) Received: (qmail 62140 invoked by uid 1007); 25 Nov 2013 18:51:41 +0100 Date: Mon, 25 Nov 2013 18:51:41 +0100 From: Gert Doering To: Wuyts Carl Message-ID: <20131125175141.GI81676@Space.Net> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:51:44 -0000 Hi, On Mon, Nov 25, 2013 at 03:39:21PM +0100, Wuyts Carl wrote: > We're deploying in managed CPE, so the hint will for sure not change anything. I agree it is also "just" a hint, but the req in the RFC says you SHOULD flag "too small" and it's exactly that part which is not ok, not the fact that you should sent a hint or anything. I really can't see the point of this. Your CPE is configured to have 2 different LAN zones, and 1 WiFi zone. IETF says "a /64 per routed interface". So you count 1..2..3 and request a /62 or /60. The ISP gives you a /63. You count again "1..2...oops". You log "to number all (3) interfaces a /62 has been requested by DHCP-PD and only a /63 has been delegated. Interface 3 (WiFi) will not receive an IPv6 address, we're sorry". Now which is the step that you are unable to do? (Maybe I'm daft, or it's because I've never worked for a mass marked CPE producer, but this really seems straightforward and easy to implement to me...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From brian.e.carpenter@gmail.com Mon Nov 25 11:31:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9011ADF8F for ; Mon, 25 Nov 2013 11:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob-Q_FBmUeAG for ; Mon, 25 Nov 2013 11:31:37 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4973D1ADBCB for ; Mon, 25 Nov 2013 11:31:37 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rr13so6436469pbb.9 for ; Mon, 25 Nov 2013 11:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QG8DjpKxBc4SJycG9ZBm1paRlAxYOqqlvS0L6FgqDYw=; b=KaMI1rBvOQMMpZP6m371jWUbe1lo/Onkfk2NVyyByYi+jR6Qa+LYiWciGIaFWkpk+D fNKOTQB5NYn8853ec0vV+6sxWUy9QRuhaWlMAkgF0ieCddQU76+5sZVBT5wJfDKH04Qs gXsg2/lyfgYSzxK0UIkicrB1u1qJW4BcVKgh3N+Z2/Gtjds+K58JRHvlBgrAItHfQZ7K /2xgiAq+xqUi7EDh3huqK63FNGV5/L99b8PB1hQqGKeaibdJjds9lMOoUedPiEo7hiym RIKZB70fvBFdO6uVJpKCEusy9rvXDiHFgt8lXLf3g2aWPZ4FS84XpyM4GGQNzLFGEszk gv1g== X-Received: by 10.68.251.133 with SMTP id zk5mr19610973pbc.69.1385407897405; Mon, 25 Nov 2013 11:31:37 -0800 (PST) Received: from [192.168.178.20] (34.192.69.111.dynamic.snap.net.nz. [111.69.192.34]) by mx.google.com with ESMTPSA id gv10sm69279667pbd.0.2013.11.25.11.31.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 11:31:36 -0800 (PST) Message-ID: <5293A596.2000304@gmail.com> Date: Tue, 26 Nov 2013 08:31:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Wuyts Carl References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:31:38 -0000 On 26/11/2013 04:03, Wuyts Carl wrote: > Hi Victor, > > Agree. I do always recommend our customers to assign /56. This doesn't mean it is always being deployed like this of course, we have single /64s as well. But this is better for the sake of future proof and leaves some room for expansion without having to fiddle in the back-end to aggregation etc. > The point I want to make is that the req of checking "too small" serves no goal, as nearly all CPE devices have a similar set of interfaces, of which some are used separately, mostly not, some have public wifi, mostly not, etc. It just makes customers asking questions on it, as they base themselves upon this RFC to send their reqs to CPE vendors. Moreover, too small (too big too ??) is too much subject of interpretation. If I'm implementing a device and the spec includes a SHOULD, I will read the definition of SHOULD: "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." In the case in point, if I am unable to determine whether the delegated prefix is too "small" to address all interfaces, that is clearly a valid reason to ignore the requirement. Therefore, I don't see this as a formal defect in WPD-3. I think it's true that in many cases, the CPE will be unable to determine whether the prefix is too "small". Also, if there happens to be a subsidiary router hanging off one of the interfaces, it might want a whole bunch of prefixes, and the CPE router can't possibly know that in advance. Also, "small" in this case turns out to mean "long". WPD-3 could have been better phrased, but since product development managers have never met a SHOULD that they couldn't ignore, I doubt that it really matters. Brian From Carl.Wuyts@technicolor.com Mon Nov 25 22:52:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0BB1AE186 for ; Mon, 25 Nov 2013 22:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfiUKF5xFG5x for ; Mon, 25 Nov 2013 22:52:00 -0800 (PST) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 965681AE183 for ; Mon, 25 Nov 2013 22:51:56 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUpRFDK5nmcegZOqD8yyxqOb3UXZOszem@postini.com; Mon, 25 Nov 2013 22:52:00 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 26 Nov 2013 07:51:52 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 26 Nov 2013 07:51:54 +0100 From: Wuyts Carl To: Brian E Carpenter Date: Tue, 26 Nov 2013 07:51:53 +0100 Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers Thread-Index: Ac7qFQwhNuHQNdGOTe+KWtjkg1DV0gAXpNtQ Message-ID: <3135C2851EB6764BACEF35D8B495596806FB9EF25E@MOPESMBX01.eu.thmulti.com> References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com> <5293A596.2000304@gmail.com> In-Reply-To: <5293A596.2000304@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 06:52:04 -0000 SGkgQnJpYW4sDQoNCkkgQWdyZWUgb24gdGhlIFNIT1VMRCBzdGF0ZW1lbnQsIG5vIGlzc3VlIG9m ICJub3QgY29tcGx5aW5nIiB3aXRoIHRoZSBSRkMgZHVlIHRvIHRoaXMuICBIb3dldmVyLCBhcyBm YXIgYXMgSSBrbm93LCBTSE9VTEQgbWVhbnMgInN1cHBvcnQgaXQgdW5sZXNzIGEgZ29vZCByZWFz b24gZXhpc3RzIHRvIG5vdCBkbyB0aGlzIi4gIEFzIHlvdSBzdGF0ZSBiZWxvdywgdGhlIGdvb2Qg cmVhc29uIGlzIHRoZXJlICJ5b3UgZG9uJ3Qga25vdyIsIGJ1dCBpdCdzIG5vdCBhIHBsZWFzYW50 IHRoaW5nIGhhdmluZyB0byBjb252aW5jZSBjdXN0b21lcnMgb2YgdGhpcyBvdmVyIGFuZCBvdmVy LiAgQXMgSSd2ZSBzYWlkOiB0aGlzIHBhcnQgb2YgdGhhdCByZXEgaGFzIG5vIGFkZGVkIHZhbHVl IGF0IGFsbCwgaGVuY2Ugc2hvdWxkIG5vdCBiZSBwcmVzZW50Lg0KDQpSZWdzDQpDYXJsDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRv OmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0gDQpTZW50OiBtYWFuZGFnIDI1IG5vdmVtYmVy IDIwMTMgMjA6MzINClRvOiBXdXl0cyBDYXJsDQpDYzogVmljdG9yIEt1YXJzaW5naDsgdjZvcHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIFJGQyA3MDg0IG9uIEJhc2ljIFJlcXVpcmVt ZW50cyBmb3IgSVB2NiBDdXN0b21lciBFZGdlIFJvdXRlcnMNCg0KT24gMjYvMTEvMjAxMyAwNDow MywgV3V5dHMgQ2FybCB3cm90ZToNCj4gSGkgVmljdG9yLA0KPiANCj4gQWdyZWUuICBJIGRvIGFs d2F5cyByZWNvbW1lbmQgb3VyIGN1c3RvbWVycyB0byBhc3NpZ24gLzU2LiAgVGhpcyBkb2Vzbid0 IG1lYW4gaXQgaXMgYWx3YXlzIGJlaW5nIGRlcGxveWVkIGxpa2UgdGhpcyBvZiBjb3Vyc2UsIHdl IGhhdmUgc2luZ2xlIC82NHMgYXMgd2VsbC4gIEJ1dCB0aGlzIGlzIGJldHRlciBmb3IgdGhlIHNh a2Ugb2YgZnV0dXJlIHByb29mIGFuZCBsZWF2ZXMgc29tZSByb29tIGZvciBleHBhbnNpb24gd2l0 aG91dCBoYXZpbmcgdG8gZmlkZGxlIGluIHRoZSBiYWNrLWVuZCB0byBhZ2dyZWdhdGlvbiBldGMu DQo+IFRoZSBwb2ludCBJIHdhbnQgdG8gbWFrZSBpcyB0aGF0IHRoZSByZXEgb2YgY2hlY2tpbmcg InRvbyBzbWFsbCIgc2VydmVzIG5vIGdvYWwsIGFzIG5lYXJseSBhbGwgQ1BFIGRldmljZXMgaGF2 ZSBhIHNpbWlsYXIgc2V0IG9mIGludGVyZmFjZXMsIG9mIHdoaWNoIHNvbWUgYXJlIHVzZWQgc2Vw YXJhdGVseSwgbW9zdGx5IG5vdCwgc29tZSBoYXZlIHB1YmxpYyB3aWZpLCBtb3N0bHkgbm90LCBl dGMuICBJdCBqdXN0IG1ha2VzIGN1c3RvbWVycyBhc2tpbmcgcXVlc3Rpb25zIG9uIGl0LCBhcyB0 aGV5IGJhc2UgdGhlbXNlbHZlcyB1cG9uIHRoaXMgUkZDIHRvIHNlbmQgdGhlaXIgcmVxcyB0byBD UEUgdmVuZG9ycy4gIE1vcmVvdmVyLCB0b28gc21hbGwgKHRvbyBiaWcgdG9vID8/KSBpcyB0b28g bXVjaCBzdWJqZWN0IG9mIGludGVycHJldGF0aW9uLg0KDQpJZiBJJ20gaW1wbGVtZW50aW5nIGEg ZGV2aWNlIGFuZCB0aGUgc3BlYyBpbmNsdWRlcyBhIFNIT1VMRCwgSSB3aWxsIHJlYWQgdGhlIGRl ZmluaXRpb24gb2YgU0hPVUxEOg0KDQoiU0hPVUxEICAgVGhpcyB3b3JkLCBvciB0aGUgYWRqZWN0 aXZlICJSRUNPTU1FTkRFRCIsIG1lYW4gdGhhdCB0aGVyZQ0KICAgbWF5IGV4aXN0IHZhbGlkIHJl YXNvbnMgaW4gcGFydGljdWxhciBjaXJjdW1zdGFuY2VzIHRvIGlnbm9yZSBhDQogICBwYXJ0aWN1 bGFyIGl0ZW0sIGJ1dCB0aGUgZnVsbCBpbXBsaWNhdGlvbnMgbXVzdCBiZSB1bmRlcnN0b29kIGFu ZA0KICAgY2FyZWZ1bGx5IHdlaWdoZWQgYmVmb3JlIGNob29zaW5nIGEgZGlmZmVyZW50IGNvdXJz ZS4iDQoNCkluIHRoZSBjYXNlIGluIHBvaW50LCBpZiBJIGFtIHVuYWJsZSB0byBkZXRlcm1pbmUg d2hldGhlciB0aGUgZGVsZWdhdGVkIHByZWZpeCBpcyB0b28gInNtYWxsIiB0byBhZGRyZXNzIGFs bCBpbnRlcmZhY2VzLCB0aGF0IGlzIGNsZWFybHkgYSB2YWxpZCByZWFzb24gdG8gaWdub3JlIHRo ZSByZXF1aXJlbWVudC4NClRoZXJlZm9yZSwgSSBkb24ndCBzZWUgdGhpcyBhcyBhIGZvcm1hbCBk ZWZlY3QgaW4gV1BELTMuDQoNCkkgdGhpbmsgaXQncyB0cnVlIHRoYXQgaW4gbWFueSBjYXNlcywg dGhlIENQRSB3aWxsIGJlIHVuYWJsZSB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgcHJlZml4IGlz IHRvbyAic21hbGwiLiBBbHNvLCBpZiB0aGVyZSBoYXBwZW5zIHRvIGJlIGEgc3Vic2lkaWFyeSBy b3V0ZXIgaGFuZ2luZyBvZmYgb25lIG9mIHRoZSBpbnRlcmZhY2VzLCBpdCBtaWdodCB3YW50IGEg d2hvbGUgYnVuY2ggb2YgcHJlZml4ZXMsIGFuZCB0aGUgQ1BFIHJvdXRlciBjYW4ndCBwb3NzaWJs eSBrbm93IHRoYXQgaW4gYWR2YW5jZS4NCg0KQWxzbywgInNtYWxsIiBpbiB0aGlzIGNhc2UgdHVy bnMgb3V0IHRvIG1lYW4gImxvbmciLg0KDQpXUEQtMyBjb3VsZCBoYXZlIGJlZW4gYmV0dGVyIHBo cmFzZWQsIGJ1dCBzaW5jZSBwcm9kdWN0IGRldmVsb3BtZW50IG1hbmFnZXJzIGhhdmUgbmV2ZXIg bWV0IGEgU0hPVUxEIHRoYXQgdGhleSBjb3VsZG4ndCBpZ25vcmUsIEkgZG91YnQgdGhhdCBpdCBy ZWFsbHkgbWF0dGVycy4NCg0KICAgIEJyaWFuDQo= From internet-drafts@ietf.org Tue Nov 26 00:10:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD481AC421; Tue, 26 Nov 2013 00:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHVV5RoFKpob; Tue, 26 Nov 2013 00:10:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 013531A1F5D; Tue, 26 Nov 2013 00:10:12 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126081011.9754.84462.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 00:10:11 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 08:10:13 -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 : DHCPv6/SLAAC Address Configuration Interaction Problem S= tatement Author(s) : Bing Liu Ron Bonica Sheng Jiang Xiangyang Gong Wendong Wang Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-00.txt Pages : 12 Date : 2013-11-26 Abstract: This document analyzes the DHCPv6/SLAAC interaction issue on host. More specifically, the interaction is regarding with the A, M, and O flags defined in ND protocol. Test results identify that current implementations in operating systems have varied on interpreting these flags. The variation might cause some operational issues as described in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Tue Nov 26 02:36:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC01ADFDA for ; Tue, 26 Nov 2013 02:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr5wc45hwOaa for ; Tue, 26 Nov 2013 02:36:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 794E41ADFA0 for ; Tue, 26 Nov 2013 02:36:14 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFJ5lFKQ/khM/2dsb2JhbABZgwe9IYEqFnSCJQEBBAF5BQsLRlcGiA4GvzYXjnYHgyCBEwOQMZl0gyk7 X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="asc'?scan'208";a="643124" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 26 Nov 2013 10:36:13 +0000 Received: from dhcp-10-61-103-120.cisco.com (dhcp-10-61-103-120.cisco.com [10.61.103.120]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAQAa9xk021365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Nov 2013 10:36:10 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_49375346-9DFF-4A2D-B880-5A27243F124D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EF25E@MOPESMBX01.eu.thmulti.com> Date: Tue, 26 Nov 2013 11:36:08 +0100 Message-Id: References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com> <5293A596.2000304@gmail.com> <3135C2851EB6764BACEF35D8B495596806FB9EF25E@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 10:36:15 -0000 --Apple-Mail=_49375346-9DFF-4A2D-B880-5A27243F124D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Carl, > I Agree on the SHOULD statement, no issue of "not complying" with the = RFC due to this. However, as far as I know, SHOULD means "support it = unless a good reason exists to not do this". As you state below, the = good reason is there "you don't know", but it's not a pleasant thing = having to convince customers of this over and over. As I've said: this = part of that req has no added value at all, hence should not be present. at some point in time you can detect when you've run out of prefixes to = assign. be that to local interfaces or via a homenet control protocol. is the confusion about timing? WPD-3 clearly allows the logging to = happen at any point in time, independent of the prefix delegation state = machine. there is no expectation that the CPE indicates this to the = delegating router in anyhow. cheers, Ole --Apple-Mail=_49375346-9DFF-4A2D-B880-5A27243F124D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSlHmZAAoJEFuJXizso86gU5QIANDp19dmb8A31CIw6RAhDXkj R5Gxtjt1/PRnmD7CTVo7qKq+e/Tgb/MpTuhEoRra3l+TOGokuZjbHdWodFhMMbq0 md4itdfMf4RExCbjipRZsVTMFp9HqWggGNsq1GLGtBX1FV2bACAmCzTBEEYqiPmD D4jc9jqKEq0nMMoZ7wDOjpL/KbwccM7Q4oiT+2L0MJFUDPDqcbKWSffa1S/tapG8 5uWbZuvlgOg9YZL9UITljG4ll/rT/fBNOg0s37eqFJh3ZgsR+dqrfdXJbApxLkVg Cx+yhQGjjQ/fV90K3fiSCdRK1G6gadYHu17Yuvom9EStKOPTLeXTfVoh+1X1yzI= =HLDe -----END PGP SIGNATURE----- --Apple-Mail=_49375346-9DFF-4A2D-B880-5A27243F124D-- From wbeebee@cisco.com Tue Nov 26 07:58:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49FD1ACCE7; Tue, 26 Nov 2013 07:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzmCZUK08wtS; Tue, 26 Nov 2013 07:58:22 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4C51AC85E; Tue, 26 Nov 2013 07:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4121; q=dns/txt; s=iport; t=1385481502; x=1386691102; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RoVaCTinWIBwygGiCfb8S5F+JGRJJo2YUT/KAITlU7E=; b=IW4oxPUM1bUknEXEBXHaH3LtCW2Swp8a6+ruIaZUhMpednH8Dj9dl6Op +3k3IyZy8GC68CmUmKbeEOnP8nhPYnpwNPKwgGf8dz1N/XL0vCGzcleBa dePZv7h8Ja/GSujqv1uYwn4QOjQNdLWPSn9HcaanF1J0vLfwfH1DcjZke w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJ3ElFKtJXG9/2dsb2JhbAA/GoMHOFO6Z4ErFnSCJQEBAQQBAQE3FCALDAQCAQgRAwEBAQ0SCQcnCgEUCQgCBAENBQkLBwIEh2ANNr8IF44pKCsCBQIEhC0DmBSBMIsjhT+DKIFxOQ X-IronPort-AV: E=Sophos;i="4.93,775,1378857600"; d="scan'208";a="2359450" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 26 Nov 2013 15:58:21 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAQFwLdW022820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 15:58:21 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.25]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 09:58:21 -0600 From: "Wes Beebee (wbeebee)" To: Wuyts Carl , "rfc-editor@rfc-editor.org" , "ietf-announce@ietf.org" , "rfc-dist@rfc-editor.org" Thread-Topic: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers Thread-Index: AQHO6sBUqXBPY2V55Ei1MRCboS6kUw== Date: Tue, 26 Nov 2013 15:58:20 +0000 Message-ID: References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.131.77.158] Content-Type: text/plain; charset="us-ascii" Content-ID: <92D2889368E8B546AB6B44AB7902E077@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drafts-update-ref@iana.org" , "v6ops@ietf.org" Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 15:58:25 -0000 The idea is that a unique /64 is given to each of the LAN interfaces. If there's not enough delegated address space, a system management error SHOULD be logged (the reason it's a SHOULD is that some boxes may not have a web-interface/console to log to). The document doesn't cover the case where you add LAN interfaces to the box - but you could, in principle, follow the same logic there as well - and log an error message. - Wes On 11/25/13 7:54 AM, "Wuyts Carl" wrote: >All, >I can still see it is impossible today to fully comply to this as, IMHO, >the following requirement is impossible to meet (the SHOULD part): >"" >WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > prefix size different from what is given in the hint. If the > delegated prefix is too small to address all of its > interfaces, the IPv6 CE router SHOULD log a system management > error. [RFC6177] covers the recommendations for service > providers for prefix allocation sizes. >"" >Checking if a ia_Pd is "too small" is impossible, i.e., what is "too >small" ? What if certain changes are done after initial ia_pd ? What >.... ? > >Regs >Carl > > >-----Original Message----- >From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of >rfc-editor@rfc-editor.org >Sent: vrijdag 22 november 2013 19:33 >To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org >Cc: drafts-update-ref@iana.org; v6ops@ietf.org; rfc-editor@rfc-editor.org >Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge >Routers > >A new Request for Comments is now available in online RFC libraries. > > =20 > RFC 7084 > > Title: Basic Requirements for IPv6 Customer > Edge Routers > Author: H. Singh, W. Beebee, > C. Donley, B. Stark > Status: Informational > Stream: IETF > Date: November 2013 > Mailbox: shemant@cisco.com, > wbeebee@cisco.com, > c.donley@cablelabs.com, > barbara.stark@att.com > Pages: 21 > Characters: 46569 > Obsoletes: RFC 6204 > > I-D Tag: draft-ietf-v6ops-6204bis-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc7084.txt > >This document specifies requirements for an IPv6 Customer Edge (CE) >router. Specifically, the current version of this document focuses on >the basic provisioning of an IPv6 CE router and the provisioning of IPv6 >hosts attached to it. The document also covers IP transition >technologies. Two transition technologies in RFC 5969's IPv6 Rapid >Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite >(DS-Lite) are covered in the document. The document obsoletes RFC 6204. > >This document is a product of the IPv6 Operations Working Group of the >IETF. > > >INFORMATIONAL: This memo provides information for the Internet community. >It does not specify an Internet standard of any kind. Distribution of >this memo is unlimited. > >This announcement is sent to the IETF-Announce and rfc-dist lists. >To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > >For searching the RFC series, see >http://www.rfc-editor.org/search/rfc_search.php >For downloading RFCs, see http://www.rfc-editor.org/rfc.html > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > > >The RFC Editor Team >Association Management Solutions, LLC > > >_______________________________________________ >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 ayourtch@cisco.com Wed Nov 27 05:06:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407861AE004 for ; Wed, 27 Nov 2013 05:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o9yRBBeoCGl for ; Wed, 27 Nov 2013 05:06:56 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A08BB1AD943 for ; Wed, 27 Nov 2013 05:06:55 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rARD6sgk027580 for ; Wed, 27 Nov 2013 14:06:54 +0100 (CET) Received: from ams3-vpn-dhcp4383.cisco.com (ams3-vpn-dhcp4383.cisco.com [10.61.81.30]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rARD6rjv013685 for ; Wed, 27 Nov 2013 14:06:54 +0100 (CET) Date: Wed, 27 Nov 2013 14:06:03 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:06:58 -0000 Hello all, Finally I managed to comb a little bit and finally submit the doc that aims to compare RAs with DHCPv6 which emerged from the discussion on this list a few weeks ago. I'll be very happy to hear any comments, suggestions, flames, etc. --a p.s. The "realtime changes" repository is at: https://github.com/ayourtch/ra-dhcpv6, in case you want to send the feedback via a pull request :) ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko Subject: New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt has been successfully submitted by Andrew Yourtchenko and posted to the IETF repository. Filename: draft-yourtchenko-ra-dhcpv6-comparison Revision: 00 Title: A comparison between the DHCPv6 and RA based host configuration Creation date: 2013-11-27 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt Status: http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison Htmlized: http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 Abstract: This document attempts to make a balanced comparison between the RA- based and DHCPv6-based host configuration mechanisms. It compares the two on different aspects, e.g: underlying media assumptions, coordination, locality, etc. and highlights the strong and weak sides of both protocols for each scenario. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From holger.metschulat@telekom.de Sat Nov 30 14:54:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057371AE4A1 for ; Sat, 30 Nov 2013 14:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rErnXlOU_Lm for ; Sat, 30 Nov 2013 14:54:07 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6571AE4A0 for ; Sat, 30 Nov 2013 14:54:06 -0800 (PST) From: Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 30 Nov 2013 23:54:04 +0100 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Sat, 30 Nov 2013 23:54:03 +0100 To: Date: Sat, 30 Nov 2013 23:54:03 +0100 Thread-Topic: AW: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt Thread-Index: Ac7lx8czE5p1+Ck6TcO9MHrmE3WUVgHVeF+w Message-ID: References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131111145452.GF81676@Space.Net> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 22:54:10 -0000 Hi Mikael, sorry for the late reply.=20 What I am thinking: Should the network be set up to offer an unabiguous acc= ess method to the end device , or should the end device be able to detect t= he "Internet Access toolset" (public IPv4, private IPv4 with NAT, NAT64, na= tive IPv6) that the network it is connected to offers and pick the most app= ropriate methods by itself? I am fearing that we get into a similar trouble as with SIP when using NAT/= PAT, which failed because the client, NAT gateway and/or SIP server tried t= o fix the NAT/PAT translation in SIP signalling sometimes by only by "guess= ing"? Holger -----Urspr=FCngliche Nachricht----- Von: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Gesendet: Mittwoch, 20. November 2013 09:09 An: Metschulat, Holger Cc: v6ops@ietf.org Betreff: Re: AW: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.t= xt On Wed, 20 Nov 2013, holger.metschulat@telekom.de wrote: > I agree, but are there any other choices? We could provide the problem case and have "someone" develop standards to f= ix it? I think it's a pretty common case going forward that the network sup= ports a combination of IPv4, DS and IPv6 devices being connected even to a = wifi network or LAN (not necessarily mobile). Then one doesn't have the cho= ice to have different APNs. One way would be to have a recommendation to detect NAT64 and then detect N= AT44, and in the case of both being present, prefer one of them consistentl= y? Hardest case to handle would be GUA IPv4 and IPv6 with NAT64, then there wo= uld have to be heuristics to actively detect the DNS64 doing A->AAAA and no= t use the AAAA pointing to the NAT64 prefix, but instead use A records for = those.... if that's what we want. --=20 Mikael Abrahamsson email: swmike@swm.pp.se