From nobody Mon Sep 1 06:27:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0320D1A0411; Mon, 1 Sep 2014 06:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlxvkFTELGq2; Mon, 1 Sep 2014 06:27:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0434A1A0413; Mon, 1 Sep 2014 06:27:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140901132712.22671.61466.idtracker@ietfa.amsl.com> Date: Mon, 01 Sep 2014 06:27:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Y_WmlYjZsoq9F4f_NM74ON321BM Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 13:27:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Roaming Behavior Analysis Authors : Gang Chen Hui Deng Dave Michaud Jouni Korhonen Mohamed Boucadair Vizdal Ales Filename : draft-ietf-v6ops-ipv6-roaming-analysis-05.txt Pages : 19 Date : 2014-09-01 Abstract: This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 1 09:35:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D621A041C for ; Mon, 1 Sep 2014 09:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRLS9c4TEosf for ; Mon, 1 Sep 2014 09:35:29 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CF11A035E for ; Mon, 1 Sep 2014 09:35:29 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s81GZHrs004907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Sep 2014 16:35:17 GMT (envelope-from joelja@bogus.com) Message-ID: <5404A041.4070203@bogus.com> Date: Mon, 01 Sep 2014 09:35:13 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: =?UTF-8?Q?Andrew_=f0=9f=91=bd_Yourtchenko?= References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w5gHftNF9d1nINQprPO12pNb35CKUIpI0" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 01 Sep 2014 16:35:17 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bVyX-PBeENUINCWxsrwC7NXWA8s Cc: IPv6 Ops WG Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 16:35:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w5gHftNF9d1nINQprPO12pNb35CKUIpI0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think this is worthwhile and I will work to incorporate the observation= =2E On 8/26/14 2:50 AM, Andrew =F0=9F=91=BD Yourtchenko wrote: > Joel, >=20 > On 8/25/14, joel jaeggli wrote: >> On 8/25/14 1:49 PM, Joe Touch wrote: >>> Hi, all, >>> >>> Speaking from TCPM-land, I would observe the following: >>> >>> - PMTUD already has many known problems, which is why PLMTUD is >>> recommended instead >> >> I agree, operationally however I'm trying not to break existing device= s >> attempting to connect to me, is the motivation for the note. >> >=20 > During the presentation in the v6ops session I made a comment about > sysctl net.ipv4.tcp_mtu_probing. Since then I had a chance to test it > - and indeed, it affects the behavior of TCP over IPv6 as well. >=20 > However, the value of 1 causes a large value of MSS to be used, > resulting in about 1.5 second hiccup. So, yeah it "works" but for > barely acceptable values of "works" >=20 > Setting the value to 2 causes the initial MSS to be 512, which > "mitigates" the problem and avoided the hiccups on a 100kb file I was > testing with - at the expense of almost 3x more packets of course. >=20 > I think it would be useful to see the discussion of this measure and > its applicability/tradeoffs in the draft. >=20 > --a >=20 --w5gHftNF9d1nINQprPO12pNb35CKUIpI0 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 iEYEARECAAYFAlQEoEEACgkQ8AA1q7Z/VrIZSgCeKGLrPT+e8Seps3KlPw1uLIvY C+UAn2MdcQNPkLp8AhxCPQjCv97T1pZS =jnSj -----END PGP SIGNATURE----- --w5gHftNF9d1nINQprPO12pNb35CKUIpI0-- From nobody Mon Sep 1 09:58:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AA91A0494 for ; Mon, 1 Sep 2014 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0g4vHnSads5 for ; Mon, 1 Sep 2014 09:58:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A9D1A048F for ; Mon, 1 Sep 2014 09:58:01 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s81Gvv9Q004993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Sep 2014 16:57:57 GMT (envelope-from joelja@bogus.com) Message-ID: <5404A590.8040104@bogus.com> Date: Mon, 01 Sep 2014 09:57:52 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Ray Hunter , Matthew Petach References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> In-Reply-To: <5402C26A.8060304@globis.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xbL5NGg8VdWcSE47UJuo6mdqxOcPgN6uS" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 01 Sep 2014 16:57:57 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6CDBKn1Iq7OmGLL9O0vnfU4Pmh0 Cc: IPv6 Ops WG Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 16:58:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xbL5NGg8VdWcSE47UJuo6mdqxOcPgN6uS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/30/14 11:36 PM, Ray Hunter wrote: >> Matthew Petach =2E.. > Not necessarily. >=20 > What might help is a realistic and early estimate of the minimum MTU=20 > we're likely going to encounter on the path,. even if this is just > used as a hint for the PLMTUD learning process that is communicated > from the local router to local hosts. The case where we would see this occur typically involved encapsulation, It would be the tunnel ingress on the way to the client that sends the PTB message. The client is practically speaking unaware that the MTU is constrained (even if the immediate upstream device is aware (because it terminates the tunnel). in that sense it may be a lot simpler to inform the client that the mtu is constrained e.g. by setting it in the RA even though the lan segment can in fact support something larger (e.g. rfc 4861s observation about heterogeneous networks). You as the client could be several hops from your end of the tunnel I suppose. > MTU is configured on routers. Routers determine the path (based on=20 > routes). Routes are based on prefixes. So there is certainly a > relationship between MTU and prefixes. >=20 > Your concern seems to be how good that correlation is. >=20 > IMVHO I believe we could generate a single minimum MTU per path > (based on prefixes) that is a pretty good first approximation (whilst > avoiding blowing up the routing table). So In my specific case I actually do have a full table on servers so that I can do outbound path selection, per prefix/as statistics for the application and so on, that's maybe an unnecessary set of information for most "servers" e.g. devices that receive incoming connections. > In EIGRP, a lot of AS'es don't even use summary routes. So in this > case there's a very good correlation between MTU, path, and prefix, > at least for traffic within the AS. So I could see this working quite > well within an individual AS, like a corporate network. >=20 > In BGP4, the path is a set of AS'es to be traversed. >=20 > The minimum MTU of an individual AS would be the minimum MTU of all=20 > individual paths encountered when traversing that AS. e.g. the > minimum of all MTUs learned in the IGP, or a static manually=20 > configured number in the AS border router. >=20 > The minimum MTU of a BGP path would be the minimum of the individual > AS MTUs. >=20 > I can see this being potentially problematic, but is it meaningfully=20 > better than a single global constant (based on a minimum of the > whole Internet)? >=20 > Or is a search for the path MTU for every host for every session > already a good enough solution? connections are frequently pretty short-lived I personally like to minimize the number of times that we need to engage in negotiation when setting up a tcp connection. fortunately as I noted this case is actually kind of infrequent and hopefully even less common as the network matures. --xbL5NGg8VdWcSE47UJuo6mdqxOcPgN6uS 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 iEYEARECAAYFAlQEpZAACgkQ8AA1q7Z/VrKeSACff9PmHlsDSz1cb6NZhCjov4ea 6koAni4r6GSxEMpiXH9AjuKNw1mujq50 =vv7Z -----END PGP SIGNATURE----- --xbL5NGg8VdWcSE47UJuo6mdqxOcPgN6uS-- From nobody Mon Sep 1 11:56:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB921A0697 for ; Mon, 1 Sep 2014 11:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdJsbEVtdHpt for ; Mon, 1 Sep 2014 11:56:09 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92611A0694 for ; Mon, 1 Sep 2014 11:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1411; q=dns/txt; s=iport; t=1409597770; x=1410807370; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KIJQgcKrmb5sP2MCCteFltFgcosVMvbRkedvxp78OXQ=; b=P8KzP1IlIoWHDWzrxzZP75jXoazsZiXWEWf9yg/cYxzMaWo6ZQXh2Nmz 8lmMgA8LFp9cM+Z9vBF0fW/sVN1pFvrr42mumM5bPdj+VVGuIamTV6xbL ug8+nOK7+2oZLiIR8y1fjUTWvBBZS9puBnmoqUst4V3VraFKOAP0mJGCp c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFACHABFStJV2P/2dsb2JhbABZgw1TVwTHf4dPAYEZFneEBAEBAwF5BQsCAQhGMiUCBA4FDogsCA25bAEXj00Hgy+BHQWRMYIGgUpehn2BW5NDg2FsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,444,1406592000"; d="asc'?scan'208";a="74029731" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 01 Sep 2014 18:56:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s81Iu8XR027338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Sep 2014 18:56:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 13:56:08 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem Thread-Index: AQHPxhZjjYSa+m6Hk0O0iy/DA4fRwg== Date: Mon, 1 Sep 2014 18:56:08 +0000 Message-ID: <301104B4-78F7-4B55-86EB-0712FFB7D4DD@cisco.com> References: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> In-Reply-To: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_12354E6C-75B4-40E4-8182-CEFF82815DA7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tcEsravPfyxOWnxJBy3ob9_w80U Cc: "draft-v6ops-pmtud-ecmp-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 18:56:11 -0000 --Apple-Mail=_12354E6C-75B4-40E4-8182-CEFF82815DA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 25, 2014, at 4:47 AM, fred@cisco.com wrote: > A new draft has been posted, at = http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem/. Please = take a look at it and comment. As noted, there=92s a draft. We have, for the past week or so, had a = discussion in the thread =93PMTUD problem=94. Question for the masses: what do we want to do with this draft? At IETF = 90, we discussed adopting an updated version as a working group draft. = Do we want to do that?=20 More importantly, what outcome do we want. Does it need to become an RFC = as operational viewpoint or procedure? Do we want to make = recommendations to tcpm, 6man, or someone else, and specifically what = recommendations? --Apple-Mail=_12354E6C-75B4-40E4-8182-CEFF82815DA7 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 iD8DBQFUBMFGbjEdbHIsm0MRAtMKAKCpVzdoB1VjwEsTCjs5zXfdhErxgwCgygSQ jRYPYTudui96QLeZJ+RGpjQ= =zQ3x -----END PGP SIGNATURE----- --Apple-Mail=_12354E6C-75B4-40E4-8182-CEFF82815DA7-- From nobody Tue Sep 2 01:55:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3401A0145 for ; Tue, 2 Sep 2014 01:55:05 -0700 (PDT) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 VRqFexMMwzml for ; Tue, 2 Sep 2014 01:55:03 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 193371A0141 for ; Tue, 2 Sep 2014 01:55:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3BD42871612; Tue, 2 Sep 2014 10:55:02 +0200 (CEST) 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 1ZXEOYQlGSMP; Tue, 2 Sep 2014 10:55:02 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:1e6:1250:5da2:96bc]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id EB09C870042; Tue, 2 Sep 2014 10:55:01 +0200 (CEST) Message-ID: <540585CE.8020701@globis.net> Date: Tue, 02 Sep 2014 10:54:38 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> <301104B4-78F7-4B55-86EB-0712FFB7D4DD@cisco.com> In-Reply-To: <301104B4-78F7-4B55-86EB-0712FFB7D4DD@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pAm5OnGigUPGenpCWkXgqSlO1t8 Cc: "draft-v6ops-pmtud-ecmp-problem@tools.ietf.org" , IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Sep 2014 08:55:05 -0000 Fred Baker (fred) wrote: > On Aug 25, 2014, at 4:47 AM, fred@cisco.com wrote: > >> A new draft has been posted, at http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem/. Please take a look at it and comment. > > As noted, there’s a draft. We have, for the past week or so, had a discussion in the thread “PMTUD problem”. > > Question for the masses: what do we want to do with this draft? At IETF 90, we discussed adopting an updated version as a working group draft. Do we want to do that? > > More importantly, what outcome do we want. Does it need to become an RFC as operational viewpoint or procedure? Do we want to make recommendations to tcpm, 6man, or someone else, and specifically what recommendations? I've read the draft. I think the more generic problem statement is "Using ICMPv6 PTB signaling for path MTU discovery is currently unreliable" together with the related problem "fragmentation doesn't work even if the IPv6 stack knows the path MTU " Whether that be due to: -bad implementations -ECMP -filters -tunnels ..... The result is a global clamp of 1280 octets. And individual applications that have to perform their own application layer message fragmentation. Would a draft summarizing the ICMP PTB problem, investigating potential alternative sources of path MTU information, and alternative signaling mechanisms for path MTU, fit within v6ops remit? The (lack of) support for fragmentation already seems to be well known. -- Regards, RayH From nobody Tue Sep 2 08:19:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1871A0435 for ; Tue, 2 Sep 2014 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoMn8eqHgqMZ for ; Tue, 2 Sep 2014 08:19:39 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1321A0424 for ; Tue, 2 Sep 2014 08:19:38 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id i17so6883708qcy.40 for ; Tue, 02 Sep 2014 08:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u02SSYfTZsvPMKYMeQV4Y2IaXPsnJVrS9O/fcjhorKU=; b=R5hgZ4xOSWIfWBFW/JKua6kwlTcjBU21N/Vz86hbW5ByzetR/GlR4Mh2AseSfKvaqj YLNChrYOdfAregkeJsDY4jcDSNQw1PVYrpRkrJKloF4Au9nc9uwU5OXz6/iLZVP4RSqs ESncFHUj7C7/rI2K0IPnDd22/WUKGZX97074vi9ahPrOgu4A54are7W/jSjWBSVFJbpy fgKT6dfKX61p653NRgFLGAKAvvB4efJYm3UohJMNNJh8OfUNJm7hUcIbp8sh3KfcmxLR jVk9hNDZpWrEJTGS+I0c1klmOyulzEm9ckHXHss0hLAEvzdZOTvWPO2a6zXSVq+Yj/JV btdA== X-Received: by 10.224.163.138 with SMTP id a10mr56051391qay.72.1409671178034; Tue, 02 Sep 2014 08:19:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.104.135 with HTTP; Tue, 2 Sep 2014 08:19:17 -0700 (PDT) In-Reply-To: <53E90FBA.8030701@si6networks.com> References: <53E5382E.3010302@si6networks.com> <53E90FBA.8030701@si6networks.com> From: Jen Linkova Date: Tue, 2 Sep 2014 17:19:17 +0200 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-tC59U_lKuvq518BOp5ZVLrg_D0 Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] comments on draft-gont-v6ops-ipv6-ehs-in-real-world-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Sep 2014 15:19:39 -0000 On Mon, Aug 11, 2014 at 8:47 PM, Fernando Gont wrote: >> This explanation was also hard to understand to me: >> >> Since there is some ambiguity when identifying the autonomous system >> to which a specific router belongs (see Appendix A.2), our >> measurements result in a percentage *range*: the lowest percentage >> value represents the "best case scenario" (where, when in doubt, we >> assume the packet drops occur in the same AS as the destination AS), >> and the highest percentage value represents the "worst case scenario" >> (where, when in doubt, we assume the packet drops occur at different >> AS than the destination AS). >> >> (added a missing closing parenthesis for readability). One possible >> reason for this is that the explanation of the best/worst scenarios is >> too technical and a reader could easily get lost. Maybe we can just >> give a higher level semantics here: >> >> Since there is some ambiguity when identifying the autonomous system >> to which a specific router belongs, our measurements result in a >> percentage *range* (see Appendix A.2). In the following tables, >> the values shown in the parentheses represent the estimated range >> of possibility that when a packet is dropped it happens in a >> different AS. >> >> and leave all other details to the Appendix. > > OK, I will keep this option in mind, and also discuss this with my > co-authors such that we find a way to improve the readabiily of this part. Sorry, your co-author is being late to the party...;) I like the idea of dropping 'best/worst case' terminology and just explain (probably by providing an example of '1000 packets sent, 1180 dropped etc' what those number mean. -- SY, Jen Linkova aka Furry From nobody Tue Sep 2 13:22:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DB41A88B2 for ; Tue, 2 Sep 2014 13:22:28 -0700 (PDT) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 7PFloETcZ9M3 for ; Tue, 2 Sep 2014 13:22:24 -0700 (PDT) Received: from ironport03a.scea.com (ironport03a.scea.com [160.33.44.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD071A88C9 for ; Tue, 2 Sep 2014 13:22:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,451,1406617200"; d="scan'208";a="12076163" Received: from inbetweener02.scea.com ([160.33.45.196]) by ironport03a.scea.com with ESMTP; 02 Sep 2014 13:22:14 -0700 Received: from toms-mac-pro.am.sony.com (toms-mac-pro.am.sony.com [10.56.5.244]) by inbetweener02.scea.com (Postfix) with ESMTP id 2648CB830B for ; Tue, 2 Sep 2014 13:22:14 -0700 (PDT) Message-ID: <540626F6.1020103@scea.com> Date: Tue, 02 Sep 2014 13:22:14 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> In-Reply-To: <5402C26A.8060304@globis.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/d9G_ziTlSfZTASl1BTjuzSV-Ep0 Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:22:29 -0000 What MTUs are actually (commonly) seen in the wild? I can only think of less than a dozen that I would expect to see, assuming that the actual MTU is based solely on the underlying network technology. Is planning and assuming that we'll see each and every possible MTU actually necessary? I agree that we wouldn't want to artificially limit MTUs to only a few common ones, I mean look how /64s became embedded in silicon... From nobody Tue Sep 2 13:27:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D0E1A88DA for ; Tue, 2 Sep 2014 13:27:02 -0700 (PDT) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 zAQSqwc4Uz0X for ; Tue, 2 Sep 2014 13:27:01 -0700 (PDT) Received: from ironport03a.scea.com (ironport03a.scea.com [160.33.44.91]) by ietfa.amsl.com (Postfix) with ESMTP id DBB531A88D4 for ; Tue, 2 Sep 2014 13:27:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,451,1406617200"; d="scan'208";a="12076220" Received: from inbetweener01.scea.com ([160.33.45.195]) by ironport03a.scea.com with ESMTP; 02 Sep 2014 13:27:01 -0700 Received: from toms-mac-pro.am.sony.com (toms-mac-pro.am.sony.com [10.56.5.244]) by inbetweener01.scea.com (Postfix) with ESMTP id BFEF9F0566 for ; Tue, 2 Sep 2014 13:27:01 -0700 (PDT) Message-ID: <54062815.2090500@scea.com> Date: Tue, 02 Sep 2014 13:27:01 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> In-Reply-To: <540626F6.1020103@scea.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/p4lSsI8MNOMiXTlSzyvUazWBS8k Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:27:03 -0000 Sorry, total brain fart. Encapsulation and all the other cases. Ignore me, I do :-) On 9/2/14 1:22 PM, Tom Perrine wrote: > What MTUs are actually (commonly) seen in the wild? > > I can only think of less than a dozen that I would expect to see, > assuming that the actual MTU is based solely on the underlying network > technology. > > Is planning and assuming that we'll see each and every possible MTU > actually necessary? > > I agree that we wouldn't want to artificially limit MTUs to only a few > common ones, I mean look how /64s became embedded in silicon... > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 2 13:31:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4941A88C3 for ; Tue, 2 Sep 2014 13:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 394VJ6pLfHcK for ; Tue, 2 Sep 2014 13:30:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCD51A88DA for ; Tue, 2 Sep 2014 13:30:55 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s82KUL7a012285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Sep 2014 13:30:21 -0700 (PDT) Message-ID: <540628DC.3000804@isi.edu> Date: Tue, 02 Sep 2014 13:30:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ray Hunter , "Fred Baker (fred)" References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> In-Reply-To: <54020ECC.4000000@globis.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eUGpyTc0Lvy4E1QH4oo8sQ0kLqw Cc: IPv6 Ops WG Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:31:01 -0000 On 8/30/2014 10:50 AM, Ray Hunter wrote: > Paths are learned via routing. What if Path MTU was also learned via > routing, rather than being probed for by individual end hosts? Not all devices that forward packets participate in routing protocols. Using this as a hint may or may not be worthwhile, but it's at most just a hint. Joe From nobody Tue Sep 2 16:55:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515641A2119 for ; Tue, 2 Sep 2014 16:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJp_ReOpRh18 for ; Tue, 2 Sep 2014 16:55:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDAE1A0BEB for ; Tue, 2 Sep 2014 16:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1296; q=dns/txt; s=iport; t=1409702101; x=1410911701; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xty1JZEmdntIgNr6ng5xc9Ns4Ei8KUhDu1LiOEOHYOM=; b=ezzh2Jvvx8TxVQ2SJTnp+SekTEs2h1synbqPjLCL8j13BAIDyO+9f5lh Kqml61qy+a9Snn6jJ9QKuxEvl7MJR6ODLZ0zXolpduEX9PijhpVXraL+1 B3ZXSJDhxHYnEIvXSuCMesugxMotAkOiMgXdFdFHKNcn1gRpLahfk0uNe U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAIRYBlStJA2I/2dsb2JhbABagw2BKgTPcwGBDxZ3hAQBAQMBeQULAgEIDjgyJQIEDgUOiCwIvSIBF49NB4MvgR0BBJExggaBSodblR6DYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,452,1406592000"; d="asc'?scan'208";a="74398393" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 02 Sep 2014 23:55:01 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s82Nt1oQ031499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 23:55:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 18:55:01 -0500 From: "Fred Baker (fred)" To: Ray Hunter Thread-Topic: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem Thread-Index: AQHPxwlOcD8eKfElLkGO/GIcD7swRA== Date: Tue, 2 Sep 2014 23:55:00 +0000 Message-ID: References: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> <301104B4-78F7-4B55-86EB-0712FFB7D4DD@cisco.com> <540585CE.8020701@globis.net> In-Reply-To: <540585CE.8020701@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.127.128] Content-Type: multipart/signed; boundary="Apple-Mail=_F68506C6-388A-49B2-961C-E78ED667D859"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kOPSYUOcYoyn8wMT3aoJh-TwP84 Cc: "draft-v6ops-pmtud-ecmp-problem@tools.ietf.org" , IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Sep 2014 23:55:03 -0000 --Apple-Mail=_F68506C6-388A-49B2-961C-E78ED667D859 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 2, 2014, at 6:54 PM, Ray Hunter wrote: > Would a draft summarizing the ICMP PTB problem, investigating = potential alternative sources of path MTU information, and alternative = signaling mechanisms for path MTU, fit within v6ops remit? I think this draft is trying to be that. What would definitely be within = our remit would be operational advice, as in "advice from operators to = operators", and advice to other working groups of the form "X needs to = be improved, we like Y, but it has problems {Z}". What would be outside = our remit would be changes to protocols. --Apple-Mail=_F68506C6-388A-49B2-961C-E78ED667D859 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 iD8DBQFUBld7bjEdbHIsm0MRAiRRAKDwEbqTRr8sOXVRL2g6pMqCSeiQWQCfUyOv scsE8vbARYrOEp+ELzqLifs= =4bnm -----END PGP SIGNATURE----- --Apple-Mail=_F68506C6-388A-49B2-961C-E78ED667D859-- From nobody Tue Sep 2 18:15:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3FE1A892F for ; Tue, 2 Sep 2014 18:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL8MQ-DFIhYh for ; Tue, 2 Sep 2014 18:15:49 -0700 (PDT) Received: from mail-oa0-x243.google.com (mail-oa0-x243.google.com [IPv6:2607:f8b0:4003:c02::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76FE1A0072 for ; Tue, 2 Sep 2014 18:15:48 -0700 (PDT) Received: by mail-oa0-f67.google.com with SMTP id m1so1760189oag.2 for ; Tue, 02 Sep 2014 18:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j3ysaTESvhzqmbHYjptbD2dx77Z3kCJ5gmLHJGi59/o=; b=pblfzlrPDvfcI2OO9YC6ObM6JAgHbbOFGvplrBEoz7BHKFXKyCzTioc8mW05J4bVJ2 obzNYWAb21uAGff9LAygWTcqsQJ6RH+IaL7cg7+oiSEe0lLRZbOeTH8MkbcbK5dSs9ax aIYhFwHToUAgUktYWT66BZjJ4pevrZcswore/el7BSqfRK0dph/fkqoTFQ/ZD00Bf4ki IBLBH6qhOKetGmXaWAqJPhrJHRvYHxlz4iI5rf1eIOilQsSRzezPnRrcwF7uUa9L0Vc4 4G3jEaSTE+gnWfvPzgkcAr6XzSAga6kYnLWUX/zDWLNAqoGElXes90ihVHGjyJWWnMlT QsSA== X-Received: by 10.182.236.65 with SMTP id us1mr35494936obc.38.1409706948267; Tue, 02 Sep 2014 18:15:48 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id wa1sm7337048oeb.1.2014.09.02.18.15.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 18:15:47 -0700 (PDT) Message-ID: <54066BD7.4010000@gmail.com> Date: Wed, 03 Sep 2014 13:16:07 +1200 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: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> <301104B4-78F7-4B55-86EB-0712FFB7D4DD@cisco.com> <540585CE.8020701@globis.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i6-dxkJqKNlTphZ6YghvB8fumys Cc: Ray Hunter , IPv6 Ops WG , "draft-v6ops-pmtud-ecmp-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Sep 2014 01:15:50 -0000 BTW the draft name is a bit schlonky. Isn't there supposed to be an -ietf in there? Brian On 03/09/2014 11:55, Fred Baker (fred) wrote: > On Sep 2, 2014, at 6:54 PM, Ray Hunter wrote: > >> Would a draft summarizing the ICMP PTB problem, investigating potential alternative sources of path MTU information, and alternative signaling mechanisms for path MTU, fit within v6ops remit? > > I think this draft is trying to be that. What would definitely be within our remit would be operational advice, as in "advice from operators to operators", and advice to other working groups of the form "X needs to be improved, we like Y, but it has problems {Z}". What would be outside our remit would be changes to protocols. > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 2 18:39:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6771A8939 for ; Tue, 2 Sep 2014 18:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRGBX_CbyhZU for ; Tue, 2 Sep 2014 18:39:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96561A8935 for ; Tue, 2 Sep 2014 18:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1615; q=dns/txt; s=iport; t=1409708371; x=1410917971; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Kq1cYPe684NKP2mVsdFL09bkIV6UlM9eztH3idn/DtU=; b=F+khgrraiE4gUaR0r2HjgaffCcRHaxpHheNOqkEoaAbLCXOwqWW1jVW7 /NsSNWO1PgKyob+ix2KTjfeh9I6LMzMfLH5AoDUqus6m0c7yT3YX0z/pP jtQLzc0eJdJ9VzyCDLi/COsP1tIJyc8oacjLewFCHRI3lZaF/YUFniSJR c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAIxwBlStJV2S/2dsb2JhbABagw2BKgTQEwGBERZ3g3wIAQEDAXkFCwIBCEYhESUCBA4FDoU7B4JeAwkItw4NhhABF40ggi0Hgy+BHQEEhU2LZIIGgUqFS4IQjmeGN4NhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,453,1406592000"; d="asc'?scan'208";a="352079601" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 03 Sep 2014 01:39:31 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s831dV8S026902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 01:39:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 20:39:30 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem Thread-Index: AQHPxxfnpDMiF36dxEahVYRJNw+WqQ== Date: Wed, 3 Sep 2014 01:39:30 +0000 Message-ID: <2238531E-F0A1-40C3-BC9D-FFB4A0AF3436@cisco.com> References: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> <301104B4-78F7-4B55-86EB-0712FFB7D4DD@cisco.com> <540585CE.8020701@globis.net> <54066BD7.4010000@gmail.com> In-Reply-To: <54066BD7.4010000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.48] Content-Type: multipart/signed; boundary="Apple-Mail=_5C7B413F-8D5E-474D-B3D5-BF4B8C53D650"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lIkGqi1bQJVokm3GiaGO6Px5zA4 Cc: Ray Hunter , IPv6 Ops WG , "draft-v6ops-pmtud-ecmp-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Sep 2014 01:39:33 -0000 --Apple-Mail=_5C7B413F-8D5E-474D-B3D5-BF4B8C53D650 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 3, 2014, at 11:16 AM, Brian E Carpenter = wrote: > BTW the draft name is a bit schlonky. Isn't there supposed to be an = -ietf in there? Well, only after we have seen fit to make it a working group draft; I = would expect a =91-jaeggli=92 in the corresponding position. Our beloved = AD seems to have difficulties reproducing names that IETF tools = recognize, and in counting. The history of its name is: -rw-r--r-- 1 fred admin 11001 Feb 15 2014 = draft-v6ops-jaeggli-pmtud-ecmp-problem-00.txt -rw-r--r-- 1 fred admin 13661 Mar 5 2014 = draft-v6ops-jaeggli-pmtud-ecmp-problem-01.txt -rw-r--r-- 1 fred admin 13590 Jun 2 17:26 = draft-jaeggli-v6ops-pmtud-ecmp-problem-00.txt -rw-rw-r-- 1 fred admin 14643 Jul 4 02:51 = draft-jaeggli-v6ops-pmtud-ecmp-problem-01.txt -rw-r--r-- 1 fred admin 15293 Aug 25 09:22 = draft-v6ops-pmtud-ecmp-problem-00.txt --Apple-Mail=_5C7B413F-8D5E-474D-B3D5-BF4B8C53D650 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 iD8DBQFUBnFQbjEdbHIsm0MRAgONAKCE+oXT+bAeITrYvW4OYXPzLaJdaACg+qn2 Zk0gbDpndfujnlA3YzkeMYs= =WS8n -----END PGP SIGNATURE----- --Apple-Mail=_5C7B413F-8D5E-474D-B3D5-BF4B8C53D650-- From nobody Tue Sep 2 18:45:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20821A8942 for ; Tue, 2 Sep 2014 18:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2pS472fYP3c for ; Tue, 2 Sep 2014 18:45:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780A01A6F2A for ; Tue, 2 Sep 2014 18:45:41 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s831jWs4017825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 Sep 2014 01:45:33 GMT (envelope-from joelja@bogus.com) Message-ID: <540672B9.2000005@bogus.com> Date: Tue, 02 Sep 2014 18:45:29 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Brian E Carpenter References: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> <301104B4-78F7-4B55-86EB-0712FFB7D4DD@cisco.com> <540585CE.8020701@globis.net> <54066BD7.4010000@gmail.com> <2238531E-F0A1-40C3-BC9D-FFB4A0AF3436@cisco.com> In-Reply-To: <2238531E-F0A1-40C3-BC9D-FFB4A0AF3436@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Mn82eRrjcUiLOQvl77gsdBgETxffoaWOC" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 03 Sep 2014 01:45:33 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aVyoVsocFr7uLyBhuJ0tGOovWgQ Cc: Ray Hunter , IPv6 Ops WG , "draft-v6ops-pmtud-ecmp-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Sep 2014 01:45:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mn82eRrjcUiLOQvl77gsdBgETxffoaWOC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/2/14 6:39 PM, Fred Baker (fred) wrote: >=20 > On Sep 3, 2014, at 11:16 AM, Brian E Carpenter wrote: >=20 >> BTW the draft name is a bit schlonky. Isn't there supposed to be an -i= etf in there? I was asked to change the name after the presentation so I interpreted that a inv9tationtion to do so. in practice I tend to be guided by the metadata in the tracker and not by the unstructured string that is the filename. that said at some point I was bit sloppy. > Well, only after we have seen fit to make it a working group draft; I w= ould expect a =91-jaeggli=92 in the corresponding position. Our beloved A= D seems to have difficulties reproducing names that IETF tools recognize,= and in counting. The history of its name is: >=20 > -rw-r--r-- 1 fred admin 11001 Feb 15 2014 draft-v6ops-jaeggli-pmtud= -ecmp-problem-00.txt > -rw-r--r-- 1 fred admin 13661 Mar 5 2014 draft-v6ops-jaeggli-pmtud= -ecmp-problem-01.txt > -rw-r--r-- 1 fred admin 13590 Jun 2 17:26 draft-jaeggli-v6ops-pmtud= -ecmp-problem-00.txt > -rw-rw-r-- 1 fred admin 14643 Jul 4 02:51 draft-jaeggli-v6ops-pmtud= -ecmp-problem-01.txt > -rw-r--r-- 1 fred admin 15293 Aug 25 09:22 draft-v6ops-pmtud-ecmp-pr= oblem-00.txt >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Mn82eRrjcUiLOQvl77gsdBgETxffoaWOC 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 iEYEARECAAYFAlQGcrkACgkQ8AA1q7Z/VrJ7ugCffprcBswkySJ8S0wPcxhPB1O8 XSkAnj47sjWmlT9Xzirz+dcbEGCybG7f =K2a0 -----END PGP SIGNATURE----- --Mn82eRrjcUiLOQvl77gsdBgETxffoaWOC-- From nobody Wed Sep 3 10:24:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6D1A0361 for ; Wed, 3 Sep 2014 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MKcm9xLqpl8 for ; Wed, 3 Sep 2014 10:23:51 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2D61A0235 for ; Wed, 3 Sep 2014 10:23:50 -0700 (PDT) Received: from [2001:5c0:1000:a::d3d] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XPEHZ-0003cG-9d; Wed, 03 Sep 2014 19:23:45 +0200 Message-ID: <54074E9B.5030007@si6networks.com> Date: Wed, 03 Sep 2014 14:23:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/a85U3dGB1Mp-uRxysvluVMOQTyg Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org Subject: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Sep 2014 17:23:55 -0000 Folks, Based on the recent discussions, we're planning to update Section 5.2 (which contains all the discussion about the ICMP-based attack vector) of the aforementioned I-D as follows. Please let us know if you have any comments: ---- cut here ---- 5.2. A possible attack vector The widespread filtering of IPv6 packets employing IPv6 Extension Headers can, in some scenarios, be exploited for malicious purposes: if packets employing IPv6 EHs are known to be filtered on the path from one system (say, "A") to another (say, "B"), an attacker could cause packets sent from A to B to be dropped by sending a forged ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a Next-Hop MTU smaller than 1280), such that subsequent packets from A to B include a fragment header (i.e., they result in atomic fragments [RFC6946]). Possible scenarios where this attack vector could be exploited include (but are not limited to): o Communication between any two systems through to public network (e.g., client from/to server or server from/to server), where packets with IPv6 extension headers are filtered by some intermediate router o Communication between two BGP peers employing IPv6 transport, where these BGP peers implement ACLs to drop IPv6 fragments (to avoid control-plane attacks) The aforementioned attack vector is exacerbated by the following factors: o The attacker does not need to forge the IPv6 Source Address of his attack packets. Hence, deployment of simple BCP38 filters will not help as a counter-measure. o Only the IPv6 addresses of the IPv6 packet embedded in the ICMPv6 payload need to be forged. While one could envision filtering devices enforcing BCP38-style filters on the ICMPv6 payload, the use of extension (by the attacker) could make this difficult, if at all possible. o Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and documented in [RFC5927]. It should be noted that in some cases, such as when an ICMPv6 error message has (supposedly) been elicited by a connection-less transport protocol (or some other connection-less protocol being encapsulated in IPv6), it may be virtually impossible to perform validation checks on the received ICMPv6 error messages. And, because of IPv6 extension headers, the ICMPv6 payload might not even contain any useful information on which to perform validation checks. o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" error messages, the Destination Cache [RFC4861] is usually updated to reflect that any subsequent packets to such destination should include a Fragment Header. This means that a single ICMPv6 "Packet Too Big" error message might affect multiple communication instances (e.g., TCP connections) with such destination. o A node cannot simply "just filter/drop all incoming ICMPv6 Packet Too Big error messages", or else it would create a PMTUD blackhole. Possible mitigations for this issue include: o Filtering incoming ICMPv6 Packet Too Big error messages that advertise a Next-Hop MTU smaller than 1280 bytes. o Artificially reducing the MTU to 1280 bytes and filter incoming ICMPv6 PTB error messages. Both of these mitigations come at the expense of possibly preventing communication through SIIT [RFC6145] that rely on IPv6 aomic fragments (see [I-D.gont-6man-deprecate-atomfrag-generation]), and also implies that the filtering device has the ability to filter ICMP PTB messages based on the contents of the MTU field. [I-D.gont-6man-deprecate-atomfrag-generation] has recently proposed to deprecate the generation of IPv6 atomic fragments, and update the SIIT [RFC6145] such that it does not rely on ICMPv6 atomic fragments. Thus, any of the above mitigations would eliminate the attack vector without any interoperability implications. ---- cut here ---- Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Sep 3 16:55:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D2C1A0710 for ; Wed, 3 Sep 2014 16:55:35 -0700 (PDT) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 UTLWWzwYGzaP for ; Wed, 3 Sep 2014 16:55:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8C01A06FC for ; Wed, 3 Sep 2014 16:55:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id EB0833493B0; Wed, 3 Sep 2014 23:55:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DAF4F160068; Wed, 3 Sep 2014 23:58:13 +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 ACD55160064; Wed, 3 Sep 2014 23:58:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C08031E5282B; Thu, 4 Sep 2014 09:55:29 +1000 (EST) To: Fernando Gont From: Mark Andrews References: <54074E9B.5030007@si6networks.com> In-reply-to: Your message of "Wed, 03 Sep 2014 14:23:39 -0300." <54074E9B.5030007@si6networks.com> Date: Thu, 04 Sep 2014 09:55:29 +1000 Message-Id: <20140903235529.C08031E5282B@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pdZOaipR47lltbBFnfuxFsN56xM Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Sep 2014 23:55:36 -0000 In message <54074E9B.5030007@si6networks.com>, Fernando Gont writes: > Folks, > > Based on the recent discussions, we're planning to update Section 5.2 > (which contains all the discussion about the ICMP-based attack vector) > of the aforementioned I-D as follows. Please let us know if you have any > comments: > > ---- cut here ---- > 5.2. A possible attack vector > > The widespread filtering of IPv6 packets with Extension Headers by enterprise firewalls > employing IPv6 Extension > Headers can, in some scenarios, be exploited for malicious purposes: > if packets employing IPv6 EHs are known to be filtered on the path > from one system (say, "A") to another (say, "B"), an attacker could > cause packets sent from A to B to be dropped by sending a forged > ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a > Next-Hop MTU smaller than 1280), such that subsequent packets from A > to B include a fragment header (i.e., they result in atomic fragments > [RFC6946]). IPv6 packets with fragmentation headers get through if you don't stuff a device with deliberately blocks them in the path. This is self inflicted pain. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 3 17:41:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0821A8774 for ; Wed, 3 Sep 2014 17:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E274gbMyGHiv for ; Wed, 3 Sep 2014 17:41:50 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797821A8775 for ; Wed, 3 Sep 2014 17:41:50 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fb1so18660785pad.27 for ; Wed, 03 Sep 2014 17:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HY5oynRkWaR1t6mMlDZqMrHwDpvm7bU3np45NbKbanQ=; b=p2b4FPxhkBN0yZFOkHbckEGIf6k9qSJZaEIIVf1v1HEToytgCP81AHpnnHSkvMZlm8 F0pBhBZAZGPxMykYrOcfc6XH7Y/X79nFKUsmQoNWSZ8lzxMIBPH3L7oT+n8CQOmtXGGi JOQswFexdduC8pHbjF+vE9dB1wJ/4gWuzq6QJdcFFsdCEcc3V4ERX7JRacTG5Rk72/EG 9wwz+cVyv+0PyEudjlHhErbdzCvfMCrf2jEDRAk9PBS+4JqK5+o8gYbSR6WJ2U4v7KOd m8YS4c8ntNaZJOoGwNtoXbsaiRyQuo4UQ3NMowv/D3flisd4ogLmnaSd5RpGxmNz8wcM u9zg== X-Received: by 10.66.192.195 with SMTP id hi3mr1662316pac.117.1409791310259; Wed, 03 Sep 2014 17:41:50 -0700 (PDT) Received: from [192.168.178.23] (71.193.69.111.dynamic.snap.net.nz. [111.69.193.71]) by mx.google.com with ESMTPSA id pm1sm81381pdb.58.2014.09.03.17.41.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 17:41:49 -0700 (PDT) Message-ID: <5407B564.7060003@gmail.com> Date: Thu, 04 Sep 2014 12:42:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews References: <54074E9B.5030007@si6networks.com> <20140903235529.C08031E5282B@rock.dv.isc.org> In-Reply-To: <20140903235529.C08031E5282B@rock.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Mctut0rlIMnWff4rcbc376pP00I Cc: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org Subject: Re: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Sep 2014 00:41:52 -0000 On 04/09/2014 11:55, Mark Andrews wrote: > In message <54074E9B.5030007@si6networks.com>, Fernando Gont writes: >> Folks, >> >> Based on the recent discussions, we're planning to update Section 5.2 >> (which contains all the discussion about the ICMP-based attack vector) >> of the aforementioned I-D as follows. Please let us know if you have any >> comments: >> >> ---- cut here ---- >> 5.2. A possible attack vector >> >> The widespread filtering of IPv6 packets > > with Extension Headers by enterprise firewalls > >> employing IPv6 Extension >> Headers can, in some scenarios, be exploited for malicious purposes: >> if packets employing IPv6 EHs are known to be filtered on the path >> from one system (say, "A") to another (say, "B"), an attacker could >> cause packets sent from A to B to be dropped by sending a forged >> ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a >> Next-Hop MTU smaller than 1280), such that subsequent packets from A >> to B include a fragment header (i.e., they result in atomic fragments >> [RFC6946]). > > IPv6 packets with fragmentation headers get through if you don't > stuff a device with deliberately blocks them in the path. This is > self inflicted pain. I think the problem is that isn't painful at all to the people who configure the blocking device. It's only painful to actual users. Brian > From nobody Wed Sep 3 17:59:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6F81A8788 for ; Wed, 3 Sep 2014 17:59:47 -0700 (PDT) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 XJZ2xRijMdfY for ; Wed, 3 Sep 2014 17:59:45 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFE41A8785 for ; Wed, 3 Sep 2014 17:59:45 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 123851FCB39; Thu, 4 Sep 2014 00:59:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7005E160068; Thu, 4 Sep 2014 01:02:22 +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 38C8F160064; Thu, 4 Sep 2014 01:02:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 397471E53E95; Thu, 4 Sep 2014 10:59:37 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <54074E9B.5030007@si6networks.com> <20140903235529.C08031E5282B@rock.dv.isc.org> <5407B564.7060003@gmail.com> In-reply-to: Your message of "Thu, 04 Sep 2014 12:42:12 +1200." <5407B564.7060003@gmail.com> Date: Thu, 04 Sep 2014 10:59:37 +1000 Message-Id: <20140904005937.397471E53E95@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oO5d5h66Z42X-Cp-UjLuvDYa71M Cc: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org Subject: Re: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Sep 2014 00:59:48 -0000 In message <5407B564.7060003@gmail.com>, Brian E Carpenter writes: > On 04/09/2014 11:55, Mark Andrews wrote: > > In message <54074E9B.5030007@si6networks.com>, Fernando Gont writes: > >> Folks, > >> > >> Based on the recent discussions, we're planning to update Section 5.2 > >> (which contains all the discussion about the ICMP-based attack vector) > >> of the aforementioned I-D as follows. Please let us know if you have any > >> comments: > >> > >> ---- cut here ---- > >> 5.2. A possible attack vector > >> > >> The widespread filtering of IPv6 packets > > > > with Extension Headers by enterprise firewalls > > > >> employing IPv6 Extension > >> Headers can, in some scenarios, be exploited for malicious purposes: > >> if packets employing IPv6 EHs are known to be filtered on the path > >> from one system (say, "A") to another (say, "B"), an attacker could > >> cause packets sent from A to B to be dropped by sending a forged > >> ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a > >> Next-Hop MTU smaller than 1280), such that subsequent packets from A > >> to B include a fragment header (i.e., they result in atomic fragments > >> [RFC6946]). > > > > IPv6 packets with fragmentation headers get through if you don't > > stuff a device with deliberately blocks them in the path. This is > > self inflicted pain. > > I think the problem is that isn't painful at all to the people who > configure the blocking device. It's only painful to actual users. Which in 99% of case work for the same people that orded the firewall to be installed. If fragments aren't getting to your device take the issue up with your management. It's almost always a problem at the receiving end. If you are a home user with a broken firewall that does this replace it. Mark > Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 3 20:02:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383B61A6EDC for ; Wed, 3 Sep 2014 20:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACgfaHcvHbk8 for ; Wed, 3 Sep 2014 20:02:04 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2A31A0473 for ; Wed, 3 Sep 2014 20:02:04 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so12469931pdb.13 for ; Wed, 03 Sep 2014 20:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zz/AlGSWlYbpVBeigaP1hy+FA6mQgWCQTbYrb4xRqd0=; b=phQOY0zbi2xlfFPrwK6gAabVAOW1r9cioMzWGbJw69CqiyT98j5MiRNu2Nb2c0Fwgx 8NunkRDMkDQ5Q40QgV/GrTi5AO44It3A/QsxSKFW/gs6QHpwBx5tbpxOtmO1gz05hn/H iaY6G7HSm5MZfXea0xg+/R6NwsZVUQQmtqRWLKAm4dvrwBYRaMkYBlKW8x+fCK5vznuI HffEbspRwb9mREm3xv7jcAbn+Javgq0B95ihQsL0phpBLyjfCi4l1qlrIrT0ikf7AEhL hinb6P3/9UAyc5TeebsRoTKzp8yVk/d+oab8/UIaY1KbcoX3yeihIGitug30KqvdmRcn 5fOw== X-Received: by 10.70.131.70 with SMTP id ok6mr2898453pdb.133.1409799723693; Wed, 03 Sep 2014 20:02:03 -0700 (PDT) Received: from [192.168.178.23] (71.193.69.111.dynamic.snap.net.nz. [111.69.193.71]) by mx.google.com with ESMTPSA id fh10sm241865pdb.71.2014.09.03.20.02.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 20:02:02 -0700 (PDT) Message-ID: <5407D639.8090101@gmail.com> Date: Thu, 04 Sep 2014 15:02:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews References: <54074E9B.5030007@si6networks.com> <20140903235529.C08031E5282B@rock.dv.isc.org> <5407B564.7060003@gmail.com> <20140904005937.397471E53E95@rock.dv.isc.org> In-Reply-To: <20140904005937.397471E53E95@rock.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uH3JMu8x_gl_oYc4MseDStNd5iU Cc: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org Subject: Re: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Sep 2014 03:02:06 -0000 On 04/09/2014 12:59, Mark Andrews wrote: > In message <5407B564.7060003@gmail.com>, Brian E Carpenter writes: >> On 04/09/2014 11:55, Mark Andrews wrote: >>> In message <54074E9B.5030007@si6networks.com>, Fernando Gont writes: >>>> Folks, >>>> >>>> Based on the recent discussions, we're planning to update Section 5.2 >>>> (which contains all the discussion about the ICMP-based attack vector) >>>> of the aforementioned I-D as follows. Please let us know if you have any >>>> comments: >>>> >>>> ---- cut here ---- >>>> 5.2. A possible attack vector >>>> >>>> The widespread filtering of IPv6 packets >>> with Extension Headers by enterprise firewalls >>> >>>> employing IPv6 Extension >>>> Headers can, in some scenarios, be exploited for malicious purposes: >>>> if packets employing IPv6 EHs are known to be filtered on the path >>>> from one system (say, "A") to another (say, "B"), an attacker could >>>> cause packets sent from A to B to be dropped by sending a forged >>>> ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a >>>> Next-Hop MTU smaller than 1280), such that subsequent packets from A >>>> to B include a fragment header (i.e., they result in atomic fragments >>>> [RFC6946]). >>> IPv6 packets with fragmentation headers get through if you don't >>> stuff a device with deliberately blocks them in the path. This is >>> self inflicted pain. >> I think the problem is that isn't painful at all to the people who >> configure the blocking device. It's only painful to actual users. > > Which in 99% of case work for the same people that orded the firewall > to be installed. If fragments aren't getting to your device take > the issue up with your management. It's almost always a problem > at the receiving end. Yes, but in my experience, the ordinary corporate user has zero influence on the security edicts of the corporate IT department, even if the user is knowledgeable enough to identify that his or her problem is a failure due to dropped PTBs or fragments. I'm not just saying this. In fact, personal experience of the corporate firewall where I work dropping extension headers is exactly why I initiated RFC 7045 and have taken so much interest in Fernando's various drafts. I think it's very important to get the analysis and the best possible advice out there before the concrete sets on IPv6 "best" practices. > If you are a home user with a broken firewall that does this replace > it. If you know that's the case, sure, but it means spending $99 that you might prefer to spend elsewhere. And Joe Random Citizen won't know that it's the case anyway. RFC 7084 is silent on this issue. RFC 6092 covers ICMPv6 but is incomplete in its coverage of extension headers and options, and doesn't mention fragments at all. Once Fernando's various drafts have stabilised, it may be useful to review 6092 carefully, and make sure that Homenet is aware of the issues too. Brian From nobody Thu Sep 4 13:22:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884851A003A for ; Thu, 4 Sep 2014 13:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giTkc8vAvm0w for ; Thu, 4 Sep 2014 13:22:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F881A004C for ; Thu, 4 Sep 2014 13:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1441; q=dns/txt; s=iport; t=1409862165; x=1411071765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+TVhCP1W0fXXzVeQx+5IV5JpZij/9LuY7MqQHycOafo=; b=igKStDM3evUZjVmtfg2o226/NGFiihTV18A0CGMiJnmkR27ek3/GCs4Z Cxt3SlCLdGPFGhYmgVlI7rU4hAO1simol66f6RRRIUjXx9pFgKn846ldh 8YbtB42Duf1gfUxPeae36WBL5RFPuUCzKiJJOoQjAhsPmt1x3U6Je7c56 g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFANbICFStJV2R/2dsb2JhbABZgw2BKgTPdAGBCBZ3hAQBAQMBeQULAgEIDjgyJQIEDgUOiCwIvTABF49NB4MvgR0BBJE+ggaBSodelSKDYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,468,1406592000"; d="asc'?scan'208";a="352665465" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP; 04 Sep 2014 20:22:44 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s84KMiFA030394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 20:22:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 15:22:44 -0500 From: "Fred Baker (fred)" To: Tom Perrine Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPyH37SIyg8NeK/UmyBJjeYCzFwg== Date: Thu, 4 Sep 2014 20:22:43 +0000 Message-ID: <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> In-Reply-To: <540626F6.1020103@scea.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.48] Content-Type: multipart/signed; boundary="Apple-Mail=_881B6FD4-D0BC-4559-9C01-5811DD699139"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-bacg_09rQo-mcyMXq2GjbY-TQQ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 20:22:52 -0000 --Apple-Mail=_881B6FD4-D0BC-4559-9C01-5811DD699139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 3, 2014, at 6:22 AM, Tom Perrine wrote: > What MTUs are actually (commonly) seen in the wild? >=20 > I can only think of less than a dozen that I would expect to see, = assuming that the actual MTU is based solely on the underlying network = technology. There are a number of magic numbers in the literature, notably the = values in RFC 2470, which is for IEEE 802.5 Token Ring. As a practical = matter today, I think the magic numbers are 1500 and 9000, and those = numbers reduced by the sizes of various encapsulations. I=92m not quite = sure of the math that led us to select the number 1280, but I=92ll = certainly agree that any encapsulation I can readily think of would work = with a packet of that size. --Apple-Mail=_881B6FD4-D0BC-4559-9C01-5811DD699139 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 iD8DBQFUCMoIbjEdbHIsm0MRAr+5AKDH14nxsD+gOeOcMdhmuTa4D1qGHQCdF4im O5H5pygjOjgAfKi0VFbby/o= =N2Ga -----END PGP SIGNATURE----- --Apple-Mail=_881B6FD4-D0BC-4559-9C01-5811DD699139-- From nobody Thu Sep 4 15:10:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2C11A00A3 for ; Thu, 4 Sep 2014 15:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 4CFPRW5s-xv3 for ; Thu, 4 Sep 2014 15:10:03 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCAE1A005F for ; Thu, 4 Sep 2014 15:10:03 -0700 (PDT) Received: from [172.22.208.164] ([162.210.130.4]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s84MA0iq001441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2014 18:10:00 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1974.6\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <540626F6.1020103@scea.com> Date: Thu, 4 Sep 2014 18:09:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28F170C9-1E44-42CB-B11A-4A7173511D22@puck.nether.net> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> To: Tom Perrine X-Mailer: Apple Mail (2.1974.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Thu, 04 Sep 2014 18:10:01 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hYZhACK6jUfoRCLPuTjLzLmGL-I Cc: v6ops@ietf.org Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 22:10:05 -0000 We configure customer links at 1500 (default), 4470 and 9000. - Jared > On Sep 2, 2014, at 4:22 PM, Tom Perrine wrote: >=20 > What MTUs are actually (commonly) seen in the wild? >=20 > I can only think of less than a dozen that I would expect to see, = assuming that the actual MTU is based solely on the underlying network = technology. >=20 > Is planning and assuming that we'll see each and every possible MTU = actually necessary? >=20 > I agree that we wouldn't want to artificially limit MTUs to only a few = common ones, I mean look how /64s became embedded in silicon... >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Sep 4 16:17:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA751A0298 for ; Thu, 4 Sep 2014 16:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pzdmpdwjuOaO for ; Thu, 4 Sep 2014 16:17:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B58C1A02A0 for ; Thu, 4 Sep 2014 16:16:57 -0700 (PDT) Received: from [2001:5c0:1000:a::1201] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XPgGg-0004ua-JI; Fri, 05 Sep 2014 01:16:44 +0200 Message-ID: <5408F090.7030503@si6networks.com> Date: Thu, 04 Sep 2014 20:06:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mark Andrews References: <54074E9B.5030007@si6networks.com> <20140903235529.C08031E5282B@rock.dv.isc.org> In-Reply-To: <20140903235529.C08031E5282B@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aYu71u5UrUqBz0AhPRIZRV1U6Xw Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Sep 2014 23:17:09 -0000 Hi, Mark, On 09/03/2014 08:55 PM, Mark Andrews wrote: >> >> Based on the recent discussions, we're planning to update Section 5.2 >> (which contains all the discussion about the ICMP-based attack vector) >> of the aforementioned I-D as follows. Please let us know if you have any >> comments: >> >> ---- cut here ---- >> 5.2. A possible attack vector >> >> The widespread filtering of IPv6 packets > > with Extension Headers by enterprise firewalls EH filtering is simply widespread... not just by enterprise firewalls. For instance, please check the measurement results we have included in our I-D. > >> employing IPv6 Extension >> Headers can, in some scenarios, be exploited for malicious purposes: >> if packets employing IPv6 EHs are known to be filtered on the path >> from one system (say, "A") to another (say, "B"), an attacker could >> cause packets sent from A to B to be dropped by sending a forged >> ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a >> Next-Hop MTU smaller than 1280), such that subsequent packets from A >> to B include a fragment header (i.e., they result in atomic fragments >> [RFC6946]). > > IPv6 packets with fragmentation headers get through if you don't > stuff a device with deliberately blocks them in the path. This is > self inflicted pain. Again, not necessarily "self inflicted". Please check the percentage of packet drops by ASes other than the destination AS (in our I-D). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 4 16:23:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BE51A02A3 for ; Thu, 4 Sep 2014 16:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr62JSKycs70 for ; Thu, 4 Sep 2014 16:23:33 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EAE21A02A0 for ; Thu, 4 Sep 2014 16:23:33 -0700 (PDT) Received: from [181.46.190.53] (helo=[172.16.5.35]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XPgNF-0004zm-4C; Fri, 05 Sep 2014 01:23:29 +0200 Message-ID: <5408F464.6010705@si6networks.com> Date: Thu, 04 Sep 2014 20:23:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mark Andrews , Brian E Carpenter References: <54074E9B.5030007@si6networks.com> <20140903235529.C08031E5282B@rock.dv.isc.org> <5407B564.7060003@gmail.com> <20140904005937.397471E53E95@rock.dv.isc.org> In-Reply-To: <20140904005937.397471E53E95@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VU_EVfnwEoF-bv-gMBfXVRF2ZuI Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Sep 2014 23:23:35 -0000 On 09/03/2014 09:59 PM, Mark Andrews wrote: >> >> I think the problem is that isn't painful at all to the people who >> configure the blocking device. It's only painful to actual users. > > Which in 99% of case work for the same people that orded the firewall > to be installed. If fragments aren't getting to your device take > the issue up with your management. It's almost always a problem > at the receiving end. Brian already commented on this issue. That said, for the case we are describing, your assessment does not really apply: the filtering is happening in transit rather than at the edge. e.g., I was able to attack my own connection against www.kernel.org, and there wasn't any firewall on my access. Whether firewalls at the edge are predominant when it comes to filtering of IPv6 packets with Ehs between peers (i.e., peer to peer) is something worth exploring... but for the time being is rather orthogonal to our discussion (although it might help to exacerbate the problem when there's no filtering on the network, but the border firewall does filter IPv6 packets with EHs). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 4 16:29:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4F91A02E9 for ; Thu, 4 Sep 2014 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBES-n9GZgns for ; Thu, 4 Sep 2014 16:29:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB3D1A02D9 for ; Thu, 4 Sep 2014 16:29:39 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s84NTcsJ040298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Sep 2014 23:29:39 GMT (envelope-from joelja@bogus.com) Message-ID: <5408F5DB.6000906@bogus.com> Date: Thu, 04 Sep 2014 16:29:31 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Jared Mauch , Tom Perrine References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <28F170C9-1E44-42CB-B11A-4A7173511D22@puck.nether.net> In-Reply-To: <28F170C9-1E44-42CB-B11A-4A7173511D22@puck.nether.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KkiD2dd6cglU0ckaacbVvhfq6QfpKvCLO" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 04 Sep 2014 23:29:39 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xc3D_Ln-xD-AkBujE8zbvOLh-kY Cc: v6ops@ietf.org Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 23:29:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KkiD2dd6cglU0ckaacbVvhfq6QfpKvCLO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/4/14 3:09 PM, Jared Mauch wrote: > We configure customer links at 1500 (default), 4470 and 9000. in the cases that I experienced I have my mss set to 1440. So clients with a higher MTU than 1500 are no so much of an issue. almost all of the cases that I have have examined were due to encapsulation. > - Jared >=20 >> On Sep 2, 2014, at 4:22 PM, Tom Perrine wrote: >> >> What MTUs are actually (commonly) seen in the wild? >> >> I can only think of less than a dozen that I would expect to see, assu= ming that the actual MTU is based solely on the underlying network techno= logy. >> >> Is planning and assuming that we'll see each and every possible MTU ac= tually necessary? >> >> I agree that we wouldn't want to artificially limit MTUs to only a few= common ones, I mean look how /64s became embedded in silicon... >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --KkiD2dd6cglU0ckaacbVvhfq6QfpKvCLO 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 iEYEARECAAYFAlQI9dwACgkQ8AA1q7Z/VrJCfgCfR0YAnNQjUY/KNPiNmehmew8w 0XQAnjplQY3/C+uShAdzcelcwTAJrfgd =x+gr -----END PGP SIGNATURE----- --KkiD2dd6cglU0ckaacbVvhfq6QfpKvCLO-- From nobody Thu Sep 4 17:00:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD121A02C2 for ; Thu, 4 Sep 2014 17:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai2GBpznwa4n for ; Thu, 4 Sep 2014 17:00:14 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68FE1A02C1 for ; Thu, 4 Sep 2014 17:00:14 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so5294266pdj.28 for ; Thu, 04 Sep 2014 17:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DGlJvlCDgmSc/4BNke3xYuR67isTVYb6jMzlDnSeTII=; b=0+7oZyWj6f6yKB7qGwrmLSA7YRnYNsMWThHUxcUhM/FsP4H/lpxvJ7G9YVG6y9Ufv8 uVnMfcJjzBViWsCRf4iXLFtkjNNSyCnx7ZIoNLed2Xgk209MxZcfM9cYPyk23vcaJcoQ re1jOez09Hcz3A+OhPQQbTB6cpdokwCHvKuZBHRLX4PVUQ7FBPyQABqTsi2KtOh573Es KrtC4esmFrXw6FD22W9fHHajmxANeDWh2UmXxEm3HdcfHHnHG4Uyq09NbGJIpmJwIM6D oCGQgLb8IbHfzJcQdzbnjcIw0kfiGE3e9kuzg3Q47qkw9dGjf0HABBLB3N/YOEt6EL55 p8mw== X-Received: by 10.66.102.68 with SMTP id fm4mr14434197pab.46.1409875213360; Thu, 04 Sep 2014 17:00:13 -0700 (PDT) Received: from [192.168.178.23] (189.199.69.111.dynamic.snap.net.nz. [111.69.199.189]) by mx.google.com with ESMTPSA id oj13sm248951pdb.45.2014.09.04.17.00.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 17:00:12 -0700 (PDT) Message-ID: <5408FD25.4000505@gmail.com> Date: Fri, 05 Sep 2014 12:00:37 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <28F170C9-1E44-42CB-B11A-4A7173511D22@puck.nether.net> <5408F5DB.6000906@bogus.com> In-Reply-To: <5408F5DB.6000906@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/77-ylKlvdjRjVt-J0PcdyWsDnUw Cc: v6ops@ietf.org, Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:00:17 -0000 On 05/09/2014 11:29, joel jaeggli wrote: > On 9/4/14 3:09 PM, Jared Mauch wrote: >> We configure customer links at 1500 (default), 4470 and 9000. > > in the cases that I experienced I have my mss set to 1440. So clients > with a higher MTU than 1500 are no so much of an issue. almost all of > the cases that I have have examined were due to encapsulation. Yes, and MSS negotiation down to 1220 doesn't always work, so with 1280 tunnels still around, even 1440 can cause failures. Brian > >> - Jared >> >>> On Sep 2, 2014, at 4:22 PM, Tom Perrine wrote: >>> >>> What MTUs are actually (commonly) seen in the wild? >>> >>> I can only think of less than a dozen that I would expect to see, assuming that the actual MTU is based solely on the underlying network technology. >>> >>> Is planning and assuming that we'll see each and every possible MTU actually necessary? >>> >>> I agree that we wouldn't want to artificially limit MTUs to only a few common ones, I mean look how /64s became embedded in silicon... >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Sep 4 17:19:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DF01A02F9 for ; Thu, 4 Sep 2014 17:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyfNGRQroBCX for ; Thu, 4 Sep 2014 17:19:19 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3751A02E3 for ; Thu, 4 Sep 2014 17:19:18 -0700 (PDT) Received: from [181.46.190.53] (helo=[172.16.5.35]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XPhF5-0005Ly-3k; Fri, 05 Sep 2014 02:19:14 +0200 Message-ID: <5408F6C6.3030103@gont.com.ar> Date: Thu, 04 Sep 2014 20:33:26 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Tom Perrine References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> In-Reply-To: <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tsJsMJjcxxY49tLYtGQ4jdixRao Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:19:22 -0000 On 09/04/2014 05:22 PM, Fred Baker (fred) wrote: >> >> I can only think of less than a dozen that I would expect to see, >> assuming that the actual MTU is based solely on the underlying >> network technology. > > There are a number of magic numbers in the literature, notably the > values in RFC 2470, which is for IEEE 802.5 Token Ring. As a > practical matter today, I think the magic numbers are 1500 and 9000, > and those numbers reduced by the sizes of various encapsulations. I’m > not quite sure of the math that led us to select the number 1280, but > I’ll certainly agree that any encapsulation I can readily think of > would work with a packet of that size. FWIW, MTUs of around 296 bytes are reportedly quite usual in some radio networks. That's why some operating systems enforce that as the minimum acceptable reported MTU in ICMPv4 "frag needed but DF bit set". What happens when/if such lins employ v6 (whether they really offer a "virtual" MTU >=1280).. I just don't know. 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 nobody Thu Sep 4 17:24:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7351A02EF for ; Thu, 4 Sep 2014 17:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxig3bu54CGp for ; Thu, 4 Sep 2014 17:24:49 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A272A1A02E6 for ; Thu, 4 Sep 2014 17:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=879; q=dns/txt; s=iport; t=1409876689; x=1411086289; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UIe25eNXde/eZvhQVBBGKZdKqXscYR4RlE1Naff0Q5w=; b=a768lB/mJS71c4pgLHjIOkLUQO91NGbJvoR4G/HYIzSQ4gOLtim64dwO yG85ejx95w0+vs9fSOFCl9UwTIYjKxnRZyz9+7NFh90TsZ7hFSrLIwbCx sUhahFu3vnpf/5d5MwRW62/3KUOlP4UujN+5CogjLWr6D0rTY8vC5rH+S 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUGALgBCVStJA2G/2dsb2JhbABZgw2BKgSNPcI+AYEJFneEBAEBAwF5BQsCAQhGMiUCBA4FDogsCL1VARePTQeDL4EdAQSRPoIGgUqHXpUig2FsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,469,1406592000"; d="asc'?scan'208";a="75069381" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 05 Sep 2014 00:24:49 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s850OmmY024369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 00:24:48 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 19:24:48 -0500 From: "Fred Baker (fred)" To: Fernando Gont Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPyJ/NIHNbpHwo3U+scOVO1Hx99Q== Date: Fri, 5 Sep 2014 00:24:48 +0000 Message-ID: <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> In-Reply-To: <5408F6C6.3030103@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.48] Content-Type: multipart/signed; boundary="Apple-Mail=_375FCEFF-0989-4B40-8834-D532414BA7AD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GX9dVnGK51Bu2XOiA9uRtiVYrWw Cc: "v6ops@ietf.org" , Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:24:51 -0000 --Apple-Mail=_375FCEFF-0989-4B40-8834-D532414BA7AD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On Sep 5, 2014, at 9:33 AM, Fernando Gont wrote: > What happens when/if such lins employ v6 (whether they really offer a > "virtual" MTU >=1280).. I just don't know. 802.15.4? --Apple-Mail=_375FCEFF-0989-4B40-8834-D532414BA7AD 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 iD8DBQFUCQLPbjEdbHIsm0MRAuP1AKDwtoVoctXciEnIFZNhGl+DhjclAQCgt/vp Ib+TR0c7+P/Yo22+GNZzjqI= =rQUO -----END PGP SIGNATURE----- --Apple-Mail=_375FCEFF-0989-4B40-8834-D532414BA7AD-- From nobody Thu Sep 4 17:46:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B311A0328 for ; Thu, 4 Sep 2014 17:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 2MJBpmXFlZsq for ; Thu, 4 Sep 2014 17:46:36 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45861A0302 for ; Thu, 4 Sep 2014 17:46:36 -0700 (PDT) Received: from [172.22.208.164] ([162.210.130.4]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s850ioqb013263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2014 20:44:51 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1974.6\)) Content-Type: text/plain; charset=windows-1252 From: Jared Mauch In-Reply-To: <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> Date: Thu, 4 Sep 2014 20:46:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E0095E7-5384-4097-A66C-BB1FB3D6354C@puck.nether.net> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1974.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Thu, 04 Sep 2014 20:44:51 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VLP9m4IeAYO8XLd4-ZvS698NSVk Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:46:37 -0000 > On Sep 4, 2014, at 8:24 PM, Fred Baker (fred) wrote: >=20 >=20 > On Sep 5, 2014, at 9:33 AM, Fernando Gont = wrote: >=20 >> What happens when/if such lins employ v6 (whether they really offer a >> "virtual" MTU >=3D1280).. I just don't know. >=20 > 802.15.4? I really want to drag anyone who thinks breaking p-mtu by their improper = understanding of standards to do tech support for grandmas impacted by = their issues. The big problems we have is IETF wrote down 1280 when most links were = already 1500 to be =91safe=92 and allowed this broken behavior to drive = average packet sizes down. I have equipment from vendors that can=92t = do average packet sizes lower than 330 bytes, so I really need that = higher end packet size to bring the average up as a result. We need to make P-MTU mandatory and not enable those who build broken = networks any more. - Jared= From nobody Thu Sep 4 17:48:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA041A033C for ; Thu, 4 Sep 2014 17:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw1ou9_pxigK for ; Thu, 4 Sep 2014 17:47:57 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C201A02F7 for ; Thu, 4 Sep 2014 17:47:50 -0700 (PDT) Received: from [181.46.190.53] (helo=[172.16.5.35]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XPhgo-0005Qo-4I; Fri, 05 Sep 2014 02:47:46 +0200 Message-ID: <5409080E.7000200@si6networks.com> Date: Thu, 04 Sep 2014 21:47:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Fernando Gont References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> In-Reply-To: <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZMXJ_VUFfiIWMwFv6Ny-GmpqCYk Cc: "v6ops@ietf.org" , Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:48:05 -0000 On 09/04/2014 09:24 PM, Fred Baker (fred) wrote: > > On Sep 5, 2014, at 9:33 AM, Fernando Gont > wrote: > >> What happens when/if such lins employ v6 (whether they really >> offer a "virtual" MTU >=1280).. I just don't know. > > 802.15.4? No. I seem to recall that it was more of a packet radio sort of thing (something predating 802.15.4). I could ask some folks if interested in more details... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 4 17:52:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C4A1A02E0 for ; Thu, 4 Sep 2014 17:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shpQqGTF384V for ; Thu, 4 Sep 2014 17:52:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597E61A02F0 for ; Thu, 4 Sep 2014 17:52:42 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s850qeof040721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Sep 2014 00:52:40 GMT (envelope-from joelja@bogus.com) Message-ID: <54090953.7010709@bogus.com> Date: Thu, 04 Sep 2014 17:52:35 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Brian E Carpenter References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <28F170C9-1E44-42CB-B11A-4A7173511D22@puck.nether.net> <5408F5DB.6000906@bogus.com> <5408FD25.4000505@gmail.com> In-Reply-To: <5408FD25.4000505@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vw6dOCg1F2SHDu7PPDbbiA9he8TjChJCt" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 05 Sep 2014 00:52:40 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iXrrSgFSYieIWoDUHVWa4dgOYAU Cc: v6ops@ietf.org, Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:52:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vw6dOCg1F2SHDu7PPDbbiA9he8TjChJCt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/4/14 5:00 PM, Brian E Carpenter wrote: > On 05/09/2014 11:29, joel jaeggli wrote: >> On 9/4/14 3:09 PM, Jared Mauch wrote: >>> We configure customer links at 1500 (default), 4470 and 9000. >> >> in the cases that I experienced I have my mss set to 1440. So clients >> with a higher MTU than 1500 are no so much of an issue. almost all of >> the cases that I have have examined were due to encapsulation. >=20 > Yes, and MSS negotiation down to 1220 doesn't always work, so > with 1280 tunnels still around, even 1440 can cause failures. sure that's kinda I find it necessary make sure the packet makes it when i get one. I suspect even 1220 can hose you in some corner case... I'd rather have my extra 220 bytes of pdu in any event. > Brian >=20 >> >>> - Jared >>> >>>> On Sep 2, 2014, at 4:22 PM, Tom Perrine wrote: >>>> >>>> What MTUs are actually (commonly) seen in the wild? >>>> >>>> I can only think of less than a dozen that I would expect to see, as= suming that the actual MTU is based solely on the underlying network tech= nology. >>>> >>>> Is planning and assuming that we'll see each and every possible MTU = actually necessary? >>>> >>>> I agree that we wouldn't want to artificially limit MTUs to only a f= ew common ones, I mean look how /64s became embedded in silicon... >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --vw6dOCg1F2SHDu7PPDbbiA9he8TjChJCt 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 iEYEARECAAYFAlQJCVMACgkQ8AA1q7Z/VrJwDQCdG5vjIdwx2N5HcFgTUH8mcB/N X+MAnjqqPxeu76mRb8AD7q5RUC3B9yrt =G66p -----END PGP SIGNATURE----- --vw6dOCg1F2SHDu7PPDbbiA9he8TjChJCt-- From nobody Thu Sep 4 17:58:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1111A0302 for ; Thu, 4 Sep 2014 17:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 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.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKa6T4RpaDX4 for ; Thu, 4 Sep 2014 17:58:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABC51A0328 for ; Thu, 4 Sep 2014 17:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1459; q=dns/txt; s=iport; t=1409878698; x=1411088298; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UBjSJY7GXttV3iL70IKQCtw0OMKrwgmi26WjzqpgGiU=; b=fWPrKng1/irnZN3z62Amlbr/ooAbNKBbI4dl2m9bnCAOaNEutUxGqnOw lqP2f9LoRJzJXiejF4Zzw0qTUrcjlreolRwWMzWtgR/rTLqace8IWqzCA BSgSeMrDVAmKcer6w2sM4E8mG1I4MZrBNsCzCfAZjz3bpV7K2Uu79s0O/ o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAHoJCVStJV2U/2dsb2JhbABZgw2BKgTPewGBCRZ3hAMBAQEDAXkFCwIBCA4KLjIlAgQOBQ6ILAi9WwEXj00Hgy+BHQEEkT6CBoFKh16VIoFnHoFcbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,470,1406592000"; d="asc'?scan'208";a="352748443" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP; 05 Sep 2014 00:58:17 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s850wHc3017008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 00:58:17 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 19:58:17 -0500 From: "Fred Baker (fred)" To: Fernando Gont Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPyKR6fvzqDo/bZ0KWIfCuh10udg== Date: Fri, 5 Sep 2014 00:58:16 +0000 Message-ID: <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> In-Reply-To: <5409080E.7000200@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.48] Content-Type: multipart/signed; boundary="Apple-Mail=_71178CF5-3054-45AC-A196-A3651E5D8D43"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qiHaQtmhbDmxV8ZfO28AYqpkuVI Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:58:30 -0000 --Apple-Mail=_71178CF5-3054-45AC-A196-A3651E5D8D43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 5, 2014, at 10:47 AM, Fernando Gont = wrote: > On 09/04/2014 09:24 PM, Fred Baker (fred) wrote: >>=20 >> On Sep 5, 2014, at 9:33 AM, Fernando Gont >> wrote: >>=20 >>> What happens when/if such lins employ v6 (whether they really >>> offer a "virtual" MTU >=3D1280).. I just don't know. >>=20 >> 802.15.4? >=20 > No. I seem to recall that it was more of a packet radio sort of thing > (something predating 802.15.4). I could ask some folks if interested > in more details=85 I think you missed my point. We have a case in point today, which is = IPv6 in an IPv6 tunnel encapsulation running on a packet network whose = MTU is 127 bytes. We call it =936lowpan=94, and it runs on IEEE = 802.15.4. --Apple-Mail=_71178CF5-3054-45AC-A196-A3651E5D8D43 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 iD8DBQFUCQqpbjEdbHIsm0MRAsSHAJwLQuQ5hcWbHVq0Afw7p8/D3EO55QCgr1Tx NDgPs3fLzpVu3fwnV4VKyx4= =m6OZ -----END PGP SIGNATURE----- --Apple-Mail=_71178CF5-3054-45AC-A196-A3651E5D8D43-- From nobody Thu Sep 4 18:51:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5980F1A0334; Thu, 4 Sep 2014 18:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lE4tS6X0GzE; Thu, 4 Sep 2014 18:51:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 388DC1A0344; Thu, 4 Sep 2014 18:50:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> Date: Thu, 04 Sep 2014 18:50:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KLRXgwqHB6M8OyE8ITWiMw1haTM Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 01:51:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-02.txt Pages : 16 Date : 2014-09-04 Abstract: This document presents advice on the design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 4 19:06:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAD81A033C for ; Thu, 4 Sep 2014 19:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziaZCuxHw4Sr for ; Thu, 4 Sep 2014 19:06:20 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B672F1A0334 for ; Thu, 4 Sep 2014 19:06:20 -0700 (PDT) Received: from [186.134.41.131] (helo=[192.168.123.128]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XPiui-0006kL-Nw; Fri, 05 Sep 2014 04:06:13 +0200 Message-ID: <540916FC.6030507@si6networks.com> Date: Thu, 04 Sep 2014 22:50:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> In-Reply-To: <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bKIBs4j7Tr9N2fL2dFAyg1XkmBM Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 02:06:23 -0000 On 09/04/2014 09:58 PM, Fred Baker (fred) wrote: >>> 802.15.4? >> >> No. I seem to recall that it was more of a packet radio sort of >> thing (something predating 802.15.4). I could ask some folks if >> interested in more details… > > I think you missed my point. We have a case in point today, which is > IPv6 in an IPv6 tunnel encapsulation running on a packet network > whose MTU is 127 bytes. We call it “6lowpan”, and it runs on IEEE > 802.15.4. I expected 6lowpan to offer a virtual MTU >= 1280 (don't they), but older stuff to not take care of that -- hence my comment. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 4 19:09:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603BF1A0343 for ; Thu, 4 Sep 2014 19:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9Q249Qgk4Ff for ; Thu, 4 Sep 2014 19:09:03 -0700 (PDT) Received: from mail-08.primus.ca (smtp1.primus.ca [209.216.129.80]) by ietfa.amsl.com (Postfix) with ESMTP id 912CB1A0334 for ; Thu, 4 Sep 2014 19:09:03 -0700 (PDT) Received: from bas2-kanata16-2925498180.dsl.bell.ca ([174.95.143.68] helo=[192.168.3.4]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XPixQ-0005VX-2W; Thu, 04 Sep 2014 22:09:03 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> Date: Thu, 4 Sep 2014 22:07:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> To: v6ops list , Owen DeLong X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas2-kanata16-2925498180.dsl.bell.ca ([192.168.3.4]) [174.95.143.68] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mt0JYMxn-oshoB3Qs99tRZ5lv9E Cc: Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 02:09:05 -0000 Folks: As you can see, Victor and I have just submitted an update to the Design = Choices draft. This is a significant update, with completely re-written text around IGP = choice and BGP. The IGP choice section looks more completely at the = various options, while the BGP section now considers iBGP as well as = eBGP. This update also addresses comments sent to us by Owen DeLong = (thanks, Owen, and sorry that we took so long to address them!). In terms of draft status, we are thinking that we are getting close to a = final version. There are surely problems with the draft that need = correcting, but we don't have any plans to add significant new content. = So please read this version with that in mind. Thanks in advance for any comments, and sorry that we have been a bit = slow in updating the draft. Philip On 2014-09-04, at 21:50 , Internet-Drafts@ietf.org wrote: >=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 : Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-02.txt > Pages : 16 > Date : 2014-09-04 >=20 > Abstract: > This document presents advice on the design choices that arise when > designing IPv6 networks (both dual-stack and IPv6-only). The > intended audience is someone designing an IPv6 network who is > knowledgeable about best current practices around IPv4 network > design, and wishes to learn the corresponding practices for IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-02 >=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 >=20 From nobody Fri Sep 5 01:08:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64AB1A0574 for ; Fri, 5 Sep 2014 01:07:56 -0700 (PDT) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 44jpPlLrN4UF for ; Fri, 5 Sep 2014 01:07:55 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 32DB21A04C2 for ; Fri, 5 Sep 2014 01:07:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 35410871611; Fri, 5 Sep 2014 10:07:54 +0200 (CEST) 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 Jyrmd7p6uEuR; Fri, 5 Sep 2014 10:07:54 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:c1e3:8d3:4688:836d]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id DA24387005E; Fri, 5 Sep 2014 10:07:53 +0200 (CEST) Message-ID: <54096F3A.5090401@globis.net> Date: Fri, 05 Sep 2014 10:07:22 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: joel jaeggli References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <28F170C9-1E44-42CB-B11A-4A7173511D22@puck.nether.net> <5408F5DB.6000906@bogus.com> In-Reply-To: <5408F5DB.6000906@bogus.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4NL97AR9TTQPr2fV62nWUUz_5x8 Cc: v6ops@ietf.org, Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 08:07:57 -0000 joel jaeggli wrote: > On 9/4/14 3:09 PM, Jared Mauch wrote: >> We configure customer links at 1500 (default), 4470 and 9000. > > in the cases that I experienced I have my mss set to 1440. So clients > with a higher MTU than 1500 are no so much of an issue. almost all of > the cases that I have have examined were due to encapsulation. Which would seem to assume that everyone is happy with "eyeball reachability". In which case 1280 will almost certainly become de facto hard(ware) coded, and anything longer is only going to be used for encapsulation mechanisms. I'm also interested in the people who could significantly benefit from larger MTU's all the way to the end device (for performance reasons) e.g. FCIP. >> - Jared >> >>> On Sep 2, 2014, at 4:22 PM, Tom Perrine wrote: >>> >>> What MTUs are actually (commonly) seen in the wild? >>> >>> I can only think of less than a dozen that I would expect to see, assuming that the actual MTU is based solely on the underlying network technology. >>> >>> Is planning and assuming that we'll see each and every possible MTU actually necessary? >>> >>> I agree that we wouldn't want to artificially limit MTUs to only a few common ones, I mean look how /64s became embedded in silicon... >>> >>> >>> _______________________________________________ >>> 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 >> > > -- Regards, RayH From nobody Fri Sep 5 07:00:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D10F1A06E4 for ; Fri, 5 Sep 2014 07:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrlN68zZWjRx for ; Fri, 5 Sep 2014 07:00:13 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C9A1A06ED for ; Fri, 5 Sep 2014 07:00:13 -0700 (PDT) Received: from [192.168.1.13] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s85Dxgoe027461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Sep 2014 06:59:45 -0700 (PDT) Message-ID: <5409C1D2.60604@isi.edu> Date: Fri, 05 Sep 2014 06:59:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Fernando Gont References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> In-Reply-To: <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BvyGxjXWgC14iQghJ37Dsw3_Q1g Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:00:15 -0000 On 9/4/2014 5:58 PM, Fred Baker (fred) wrote: > > On Sep 5, 2014, at 10:47 AM, Fernando Gont wrote: > >> On 09/04/2014 09:24 PM, Fred Baker (fred) wrote: >>> >>> On Sep 5, 2014, at 9:33 AM, Fernando Gont >>> wrote: >>> >>>> What happens when/if such lins employ v6 (whether they really >>>> offer a "virtual" MTU >=1280).. I just don't know. >>> >>> 802.15.4? >> >> No. I seem to recall that it was more of a packet radio sort of thing >> (something predating 802.15.4). I could ask some folks if interested >> in more details… > > I think you missed my point. We have a case in point today, which is > IPv6 in an IPv6 tunnel encapsulation running on a packet network whose > MTU is 127 bytes. We call it “6lowpan”, and it runs on IEEE 802.15.4. That's not IPv6. I don't know what it is, but RFC2460 is clear on the minimum MTU for IPv6. Anyone who pays money for such a thing should return it. Joe From nobody Fri Sep 5 07:34:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8B91A06F6 for ; Fri, 5 Sep 2014 07:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAo5OKdroABd for ; Fri, 5 Sep 2014 07:34:23 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id E330B1A06EF for ; Fri, 5 Sep 2014 07:34:22 -0700 (PDT) Received: from [85.158.137.67:34017] by server-5.bemta-3.messagelabs.com id D5/DE-30889-DE9C9045; Fri, 05 Sep 2014 14:34:21 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-139.messagelabs.com!1409927658!37875135!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5499 invoked from network); 5 Sep 2014 14:34:19 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-8.tower-139.messagelabs.com with SMTP; 5 Sep 2014 14:34:19 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Fri, 05 Sep 2014 15:36:40 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([::1]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 15:34:07 +0100 From: "Heatley, Nick" To: Philip Matthews , v6ops list , Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt Thread-Index: AQHPyKvnC/ECCZEXn02t3INu8wz3Rpvxuk2AgADeB3A= Date: Fri, 5 Sep 2014 14:34:07 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303B8A15A@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> In-Reply-To: <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fpnral_4NUl6T5JGlhxye3nPKEw Cc: Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:34:24 -0000 Hi, I am assuming these functional elements often found in various broadband = networks are out of scope: NAT, DNS, AAA, Address Assignment, Load balanc= er, Multi-homing? What of Security enforcement such as (but not limited) = to IP firewall?=20 So if the intention is to leave contents as shown (ok with me) perhaps th= e title and abstract could be clearer? Is "IP Transport Design" a common term for the subject matter, or perhaps= =20"IP Router Design"? Regards, Nick -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Matthews Sent: 05 September 2014 03:08 To: v6ops list; Owen DeLong Cc: Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt Folks: As you can see, Victor and I have just submitted an update to the Design = Choices draft. This is a significant update, with completely re-written text around IGP = choice and BGP. The IGP choice section looks more completely at the vario= us options, while the BGP section now considers iBGP as well as eBGP. Thi= s update also addresses comments sent to us by Owen DeLong (thanks, Owen= , and sorry that we took so long to address them!). In terms of draft status, we are thinking that we are getting close to a = final version. There are surely problems with the draft that need correct= ing, but we don't have any plans to add significant new content. So pleas= e read this version with that in mind. Thanks in advance for any comments, and sorry that we have been a bit slo= w in updating the draft. Philip On 2014-09-04, at 21:50 , Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the IPv6 Operations Working Group of the I= ETF. >=20 > Title : Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-02.txt > Pages : 16 > Date : 2014-09-04 >=20 > Abstract: > This document presents advice on the design choices that arise when > designing IPv6 networks (both dual-stack and IPv6-only). The > intended audience is someone designing an IPv6 network who is > knowledgeable about best current practices around IPv4 network > design, and wishes to learn the corresponding practices for IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-02 >=20 >=20 > 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 tools.i= etf.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 >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW From nobody Fri Sep 5 07:48:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11291A02FC for ; Fri, 5 Sep 2014 07:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 CBp2oeVktlej for ; Fri, 5 Sep 2014 07:48:12 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B3F1A02D0 for ; Fri, 5 Sep 2014 07:48:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s85EmBGW013662; Fri, 5 Sep 2014 07:48:11 -0700 Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s85Em76o013564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Sep 2014 07:48:07 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.177]) with mapi id 14.03.0181.006; Fri, 5 Sep 2014 07:48:06 -0700 From: "Templin, Fred L" To: Joe Touch , "Fred Baker (fred)" , "Fernando Gont" Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPyJifs1qEEvpydkaz7jvT8FP9mpvyI8EAgAAGQACAAAMaAIAA2lkA//+XRyA= Date: Fri, 5 Sep 2014 14:48:06 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D0F3EE@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> In-Reply-To: <5409C1D2.60604@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QTbgMlHbTA7QV2m8cuAwnE7u72w Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:48:14 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Friday, September 05, 2014 7:00 AM > To: Fred Baker (fred); Fernando Gont > Cc: v6ops@ietf.org; Tom Perrine; Fernando Gont > Subject: Re: [v6ops] PMTUD issue discussion >=20 >=20 >=20 > On 9/4/2014 5:58 PM, Fred Baker (fred) wrote: > > > > On Sep 5, 2014, at 10:47 AM, Fernando Gont wrot= e: > > > >> On 09/04/2014 09:24 PM, Fred Baker (fred) wrote: > >>> > >>> On Sep 5, 2014, at 9:33 AM, Fernando Gont > >>> wrote: > >>> > >>>> What happens when/if such lins employ v6 (whether they really > >>>> offer a "virtual" MTU >=3D1280).. I just don't know. > >>> > >>> 802.15.4? > >> > >> No. I seem to recall that it was more of a packet radio sort of thing > >> (something predating 802.15.4). I could ask some folks if interested > >> in more details... > > > > I think you missed my point. We have a case in point today, which is > > IPv6 in an IPv6 tunnel encapsulation running on a packet network whose > > MTU is 127 bytes. We call it "6lowpan", and it runs on IEEE 802.15.4. >=20 > That's not IPv6. I don't know what it is, but RFC2460 is clear on the > minimum MTU for IPv6. Joe is right - for IPv6 there is only one magic number (1280). Beyond that, any size up to and including jumbograms must be accommodated, subject to path MTU limitations. Thanks - Fred fred.l.templin@boeing.com > Anyone who pays money for such a thing should return it. >=20 > Joe >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 5 08:38:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8FD1A08BE for ; Fri, 5 Sep 2014 08:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFm51x0s5J8C for ; Fri, 5 Sep 2014 08:38:27 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0016.outbound.protection.outlook.com [213.199.154.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F6F1A0739 for ; Fri, 5 Sep 2014 08:38:27 -0700 (PDT) Received: from DBXPR07CA001.eurprd07.prod.outlook.com (10.255.191.159) by AMSPR07MB470.eurprd07.prod.outlook.com (10.242.106.141) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 5 Sep 2014 15:38:25 +0000 Received: from AM1FFO11FD051.protection.gbl (2a01:111:f400:7e00::121) by DBXPR07CA001.outlook.office365.com (2a01:111:e400:9800::31) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Fri, 5 Sep 2014 15:38:24 +0000 Received: from CHIXEDG01.BSKYB.COM (80.238.1.152) by AM1FFO11FD051.mail.protection.outlook.com (10.174.65.214) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Fri, 5 Sep 2014 15:38:24 +0000 From: "Chettle, Nick" To: Philip Matthews , v6ops list , Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt Thread-Index: AQHPyKvi+JIp7a6Fsk6A4ZTqboez95vxuk2AgADzMIA= Date: Fri, 5 Sep 2014 15:38:22 +0000 Message-ID: References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> In-Reply-To: <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.20.32.127] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:80.238.1.152; CTRY:GB; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(24454002)(377424004)(51874003)(51704005)(479174003)(505014003)(189002)(199003)(95666004)(118246001)(90102001)(74662001)(25786005)(74502001)(26826002)(230783001)(31966008)(4396001)(53416004)(2656002)(77096002)(87936001)(21056001)(85852003)(83072002)(15975445006)(83506001)(107046002)(36756003)(15202345003)(106116001)(105586002)(92566001)(106466001)(86362001)(92726001)(47776003)(20776003)(64706001)(101416001)(46102001)(81342001)(77982001)(85306004)(81542001)(80022001)(19580395003)(6806004)(44976005)(83322001)(19580405001)(23756003)(79102001)(99396002)(76482001)(54356999)(50466002)(76176999)(50986999); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB470; H:CHIXEDG01.BSKYB.COM; FPR:; MLV:ovrnspm; PTR:ip-80-238-1-152.bskyb.com; MX:1; A:0; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0325F6C77B Received-SPF: None (protection.outlook.com: bskyb.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 80.238.1.152) smtp.mailfrom=Nick.Chettle@bskyb.com; X-OriginatorOrg: bskyb.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9uUHifXjasHkzzVhS5v67sj0IIc Cc: Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:38:34 -0000 Hi Phillip, I think this is document pulls a lot of useful best practices together. A couple of minor points. o It is not often not possible to identify the interface or link (in a database, email, etc) by giving just its address without also specifying the link in some manner. I think this should read "often not possible=B2 ? Additionally, in section 2.1.2 you talk about link-local vs. GUA/ULA for point-to-point links, it might be useful to reference something on address assignment here (/64, /126, /127, etc.). I see you=B9ve already referenced RFC5375 in the introduction however it may be worth a second mention here? Cheers, Nick On 05/09/2014 03:07, "Philip Matthews" wrote: >Folks: > >As you can see, Victor and I have just submitted an update to the Design >Choices draft. > >This is a significant update, with completely re-written text around IGP >choice and BGP. The IGP choice section looks more completely at the >various options, while the BGP section now considers iBGP as well as >eBGP. This update also addresses comments sent to us by Owen DeLong >(thanks, Owen, and sorry that we took so long to address them!). > >In terms of draft status, we are thinking that we are getting close to a >final version. There are surely problems with the draft that need >correcting, but we don't have any plans to add significant new content. >So please read this version with that in mind. > >Thanks in advance for any comments, and sorry that we have been a bit >slow in updating the draft. > >Philip > > >On 2014-09-04, at 21:50 , Internet-Drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the IPv6 Operations Working Group of the >>IETF. >> >> Title : Design Choices for IPv6 Networks >> Authors : Philip Matthews >> Victor Kuarsingh >> Filename : draft-ietf-v6ops-design-choices-02.txt >> Pages : 16 >> Date : 2014-09-04 >> >> Abstract: >> This document presents advice on the design choices that arise when >> designing IPv6 networks (both dual-stack and IPv6-only). The >> intended audience is someone designing an IPv6 network who is >> knowledgeable about best current practices around IPv4 network >> design, and wishes to learn the corresponding practices for IPv6. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-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/ >> >> _______________________________________________ >> 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 Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trademarks of British Sky Broadcast= ing Group plc and Sky International AG and are used under licence. British = Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Li= mited (Registration No. 2067075) and Sky Subscribers Services Limited (Regi= stration No. 2340150) are direct or indirect subsidiaries of British Sky Br= oadcasting Group plc (Registration No. 2247735). All of the companies menti= oned in this paragraph are incorporated in England and Wales and share the = same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From nobody Fri Sep 5 11:55:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049C81A6F51 for ; Fri, 5 Sep 2014 11:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcZnOG8ceTw1 for ; Fri, 5 Sep 2014 11:55:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15E1A014E for ; Fri, 5 Sep 2014 11:55:51 -0700 (PDT) Received: from [10.20.0.186] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s85IoNx6030154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Sep 2014 11:50:34 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s85IoNx6030154 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1409943036; bh=U74iFoaLNvSJdXh9wThg/4BQV+w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LbT0Tt9xLISRyRw5RUtngs6QTpDZXkDhTG+0LuOedhlmOU5XOxDovvQf0kwj6YpdC x/TtdAh0DCgjALf9NtAtHMBtHHQmvOD6ph46NSjtzNDcvnoyVBSQp2hcDD9kUXa5jr 2qRjIiigV7B2dFXfmubqaCpgEjxVsngBagWxMYGg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <5409C1D2.60604@isi.edu> Date: Fri, 5 Sep 2014 11:50:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <19AC0386-C63B-4B41-B303-FAA6C1B1C9D9@delong.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r0RuNG31HoyqJIwW-XbEYM130CQ Cc: Fernando Gont , "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 18:55:53 -0000 On Sep 5, 2014, at 6:59 AM, Joe Touch wrote: >=20 >=20 > On 9/4/2014 5:58 PM, Fred Baker (fred) wrote: >>=20 >> On Sep 5, 2014, at 10:47 AM, Fernando Gont = wrote: >>=20 >>> On 09/04/2014 09:24 PM, Fred Baker (fred) wrote: >>>>=20 >>>> On Sep 5, 2014, at 9:33 AM, Fernando Gont >>>> wrote: >>>>=20 >>>>> What happens when/if such lins employ v6 (whether they really >>>>> offer a "virtual" MTU >=3D1280).. I just don't know. >>>>=20 >>>> 802.15.4? >>>=20 >>> No. I seem to recall that it was more of a packet radio sort of = thing >>> (something predating 802.15.4). I could ask some folks if interested >>> in more details=85 >>=20 >> I think you missed my point. We have a case in point today, which is >> IPv6 in an IPv6 tunnel encapsulation running on a packet network = whose >> MTU is 127 bytes. We call it =936lowpan=94, and it runs on IEEE = 802.15.4. >=20 > That's not IPv6. I don't know what it is, but RFC2460 is clear on the = minimum MTU for IPv6. >=20 > Anyone who pays money for such a thing should return it. It is, actually, IPv6 for Low Power Area Networks and it does provide a = =93virtual MTU=94 of 1280 or better at layer 2 in order to facilitate = moving IPv6 data over those networks. It does, however, provide = additional optimizations to support the low power applications where = these networks are common. I recommend reading the RFC before saying that 6lowpan isn=92t IPv6. Owen From nobody Fri Sep 5 12:08:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECC21A01A9 for ; Fri, 5 Sep 2014 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7FHzT31Ofhy for ; Fri, 5 Sep 2014 12:08:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3B51A00CA for ; Fri, 5 Sep 2014 12:08:18 -0700 (PDT) Received: from [128.9.184.123] ([128.9.184.123]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s85J6wYF012685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Sep 2014 12:07:01 -0700 (PDT) Message-ID: <540A09D6.6040408@isi.edu> Date: Fri, 05 Sep 2014 12:07:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Owen DeLong References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> <19AC0386-C63B-4B41-B303-FAA6C1B1C9D9@delong.com> In-Reply-To: <19AC0386-C63B-4B41-B303-FAA6C1B1C9D9@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7TMMJMUyUVsB1kjZCFf1yTxrEyc Cc: Fernando Gont , "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 19:08:19 -0000 Let me be more clear: On 9/5/2014 11:50 AM, Owen DeLong wrote: > I recommend reading the RFC before saying that 6lowpan isn’t IPv6. Anything that doesn't support an IPv6 MTU of at least 1280 isn't IPv6. That requirement has no impact on the L2 MTU, but the L2 must never return an ICMP error of "too big" for IPv6 MTUs that are valid. Joe From nobody Fri Sep 5 14:20:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399B81A0309 for ; Fri, 5 Sep 2014 14:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJx0s4HXskYJ for ; Fri, 5 Sep 2014 14:20:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 520161A0307 for ; Fri, 5 Sep 2014 14:20:29 -0700 (PDT) Received: from [10.20.0.186] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s85LGs9M004380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Sep 2014 14:16:55 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s85LGs9M004380 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1409951819; bh=qBrMeDN2RYS/TvHJGK4O2xPnO/I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=D0N48Q+kr3c25lm/UsKi16U7gBsMteyDhc1OhEDRyD/EooBcRTAms94xh/L8alyBX fZGzk5y07/WIAgGY6ry8mi9MrgNxdWnYh0FI/yl9EOaXGWNA7KJRkS4TGzy30jyUgA GLSVnUraryjfbiNqaCrhMaPdOgSAZXwXwGHwSRtg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <540A09D6.6040408@isi.edu> Date: Fri, 5 Sep 2014 14:16:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DC02C77-FAEE-4D92-9A3B-B803F798DE58@delong.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> <19AC0386-C63B-4B41-B303-FAA6C1B1C9D9@delong.com> <540A09D6.6040408@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sj8_DYhL1vDnXIsZTQ6wyNi7zZ4 Cc: Fernando Gont , "v6ops@ietf.org" , Tom Perrine , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:20:32 -0000 On Sep 5, 2014, at 12:07 PM, Joe Touch wrote: > Let me be more clear: >=20 > On 9/5/2014 11:50 AM, Owen DeLong wrote: >> I recommend reading the RFC before saying that 6lowpan isn=E2=80=99t = IPv6. >=20 > Anything that doesn't support an IPv6 MTU of at least 1280 isn't IPv6. Correct. 6lowpan is IPv6 with an IPv6 MTU of 1280 or better over radio = links that have a 127 octet MTU. > That requirement has no impact on the L2 MTU, but the L2 must never = return an ICMP error of "too big" for IPv6 MTUs that are valid. Also correct, sort of. The requirement does have impact on L2 = devices/media/etc. that have an MTU that doesn=E2=80=99t allow a =E2=89=A5= 1280 octet L3 payload in that it requires L2 SAR or an L2 adaptation = layer that provides SAR. The 6lowpan specification provides such SAR and = is also being adapted to allow 6lowpan over BLE. Owen From nobody Fri Sep 5 17:56:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742781A06F2 for ; Fri, 5 Sep 2014 17:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUxH_igjZzXa for ; Fri, 5 Sep 2014 17:56:47 -0700 (PDT) Received: from mail-08.primus.ca (smtp1.primus.ca [209.216.129.80]) by ietfa.amsl.com (Postfix) with ESMTP id 78D861A031F for ; Fri, 5 Sep 2014 17:56:46 -0700 (PDT) Received: from [65.92.199.80] (helo=[192.168.3.4]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XQ4J3-0003fa-2L; Fri, 05 Sep 2014 20:56:46 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <6536E263028723489CCD5B6821D4B21303B8A15A@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Fri, 5 Sep 2014 20:56:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <716DB361-6280-4825-9A3D-E739DFF37E9F@magma.ca> References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> <6536E263028723489CCD5B6821D4B21303B8A15A@UK30S005EXS06.EEAD.EEINT.CO.UK> To: "Heatley, Nick" X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([192.168.3.4]) [65.92.199.80] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BpBsmemqwONciguwDqj8bLohE50 Cc: v6ops list , Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.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, 06 Sep 2014 00:56:49 -0000 Hi Nick: There are lots of additional topics that could go into this document, = but the authors feel that it would be best to leave these to follow-on = documents because (a) otherwise the document would get very large, and = (b) both authors have had difficulty finding the time to work on this = more-limited scope document.=20 So the authors feel it would be best to polish up this document and = publish it as an RFC. After that, if the WG is interested, other = documents could address other areas. - Philip On 2014-09-05, at 10:34 , Heatley, Nick wrote: > Hi, > I am assuming these functional elements often found in various = broadband networks are out of scope: NAT, DNS, AAA, Address Assignment, = Load balancer, Multi-homing? What of Security enforcement such as (but = not limited) to IP firewall?=20 > So if the intention is to leave contents as shown (ok with me) perhaps = the title and abstract could be clearer? > Is "IP Transport Design" a common term for the subject matter, or = perhaps "IP Router Design"? > Regards, > Nick >=20 >=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip = Matthews > Sent: 05 September 2014 03:08 > To: v6ops list; Owen DeLong > Cc: Victor Kuarsingh > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-02.txt >=20 > Folks: >=20 > As you can see, Victor and I have just submitted an update to the = Design Choices draft. >=20 > This is a significant update, with completely re-written text around = IGP choice and BGP. The IGP choice section looks more completely at the = various options, while the BGP section now considers iBGP as well as = eBGP. This update also addresses comments sent to us by Owen DeLong = (thanks, Owen, and sorry that we took so long to address them!). >=20 > In terms of draft status, we are thinking that we are getting close to = a final version. There are surely problems with the draft that need = correcting, but we don't have any plans to add significant new content. = So please read this version with that in mind. >=20 > Thanks in advance for any comments, and sorry that we have been a bit = slow in updating the draft. >=20 > Philip >=20 >=20 > On 2014-09-04, at 21:50 , Internet-Drafts@ietf.org wrote: >=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 : Design Choices for IPv6 Networks >> Authors : Philip Matthews >> Victor Kuarsingh >> Filename : draft-ietf-v6ops-design-choices-02.txt >> Pages : 16 >> Date : 2014-09-04 >>=20 >> Abstract: >> This document presents advice on the design choices that arise when >> designing IPv6 networks (both dual-stack and IPv6-only). The >> intended audience is someone designing an IPv6 network who is >> knowledgeable about best current practices around IPv4 network >> design, and wishes to learn the corresponding practices for IPv6. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-02 >>=20 >>=20 >> 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 = 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 >>=20 >=20 > _______________________________________________ > 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. =20 >=20 > 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.=20 >=20 > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW >=20 From nobody Fri Sep 5 18:07:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8EE1A02F4 for ; Fri, 5 Sep 2014 18:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcBb4kgSDOe8 for ; Fri, 5 Sep 2014 18:07:40 -0700 (PDT) Received: from mail-02.primus.ca (smtp1.primus.ca [209.216.129.80]) by ietfa.amsl.com (Postfix) with ESMTP id BF0521A0709 for ; Fri, 5 Sep 2014 18:07:39 -0700 (PDT) Received: from [65.92.199.80] (helo=[192.168.3.4]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XQ4Ta-00005p-29; Fri, 05 Sep 2014 21:07:39 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Philip Matthews In-Reply-To: Date: Fri, 5 Sep 2014 21:07:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F9D01A1-ED49-43B3-B7DB-3EE602AAE38A@magma.ca> References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> To: "Chettle, Nick" X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([192.168.3.4]) [65.92.199.80] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rpju7tsjMdh3hWvW8tFUk574jIU Cc: v6ops list , Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.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, 06 Sep 2014 01:07:43 -0000 Nick: Thanks for the comments. In my working copy, I have corrected the grammatical error and added the = sentence "See also [RFC5375] for IPv6 unicast address assignment = considerations." to the end of the section. Philip On 2014-09-05, at 11:38 , Chettle, Nick wrote: > Hi Phillip, >=20 >=20 > I think this is document pulls a lot of useful best practices = together. A > couple of minor points. >=20 > o It is not often not possible to identify the interface or link = (in > a database, email, etc) by giving just its address without also > specifying the link in some manner. >=20 >=20 > I think this should read "often not possible=B2 ? >=20 >=20 > Additionally, in section 2.1.2 you talk about link-local vs. GUA/ULA = for > point-to-point links, it might be useful to reference something on = address > assignment here (/64, /126, /127, etc.). I see you=B9ve already = referenced > RFC5375 in the introduction however it may be worth a second mention = here? >=20 > Cheers, Nick >=20 >=20 > On 05/09/2014 03:07, "Philip Matthews" = wrote: >=20 >> Folks: >>=20 >> As you can see, Victor and I have just submitted an update to the = Design >> Choices draft. >>=20 >> This is a significant update, with completely re-written text around = IGP >> choice and BGP. The IGP choice section looks more completely at the >> various options, while the BGP section now considers iBGP as well as >> eBGP. This update also addresses comments sent to us by Owen DeLong >> (thanks, Owen, and sorry that we took so long to address them!). >>=20 >> In terms of draft status, we are thinking that we are getting close = to a >> final version. There are surely problems with the draft that need >> correcting, but we don't have any plans to add significant new = content. >> So please read this version with that in mind. >>=20 >> Thanks in advance for any comments, and sorry that we have been a bit >> slow in updating the draft. >>=20 >> Philip >>=20 >>=20 >> On 2014-09-04, at 21:50 , Internet-Drafts@ietf.org wrote: >>=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 : Design Choices for IPv6 Networks >>> Authors : Philip Matthews >>> Victor Kuarsingh >>> Filename : draft-ietf-v6ops-design-choices-02.txt >>> Pages : 16 >>> Date : 2014-09-04 >>>=20 >>> Abstract: >>> This document presents advice on the design choices that arise when >>> designing IPv6 networks (both dual-stack and IPv6-only). The >>> intended audience is someone designing an IPv6 network who is >>> knowledgeable about best current practices around IPv4 network >>> design, and wishes to learn the corresponding practices for IPv6. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-02 >>>=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 >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > Information in this email including any attachments may be privileged, = confidential and is intended exclusively for the addressee. The views = expressed may not be official policy, but the personal views of the = originator. If you have received it in error, please notify the sender = by return e-mail and delete it from your system. You should not = reproduce, distribute, store, retransmit, use or disclose its contents = to anyone. Please note we reserve the right to monitor all e-mail = communication through our internal and external networks. SKY and the = SKY marks are trademarks of British Sky Broadcasting Group plc and Sky = International AG and are used under licence. British Sky Broadcasting = Limited (Registration No. 2906991), Sky-In-Home Service Limited = (Registration No. 2067075) and Sky Subscribers Services Limited = (Registration No. 2340150) are direct or indirect subsidiaries of = British Sky Broadcasting Group plc (Registration No. 2247735). All of = the companies mentioned in this paragraph are incorporated in England = and Wales and share the same registered office at Grant Way, Isleworth, = Middlesex TW7 5QD. >=20 From nobody Fri Sep 5 18:15:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39FA1A0706 for ; Fri, 5 Sep 2014 18:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGj-2zOZp46j for ; Fri, 5 Sep 2014 18:15:30 -0700 (PDT) Received: from mail-08.primus.ca (smtp3.primus.ca [209.216.129.203]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBD81A0704 for ; Fri, 5 Sep 2014 18:15:29 -0700 (PDT) Received: from [65.92.199.80] (helo=[192.168.3.4]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XQ4bA-0007gz-2Q; Fri, 05 Sep 2014 21:15:29 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <716DB361-6280-4825-9A3D-E739DFF37E9F@magma.ca> Date: Fri, 5 Sep 2014 21:15:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F064DC3-3F24-450A-B8F1-795252336736@magma.ca> References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> <6536E263028723489CCD5B6821D4B21303B8A15A@UK30S005EXS06.EEAD.EEINT.CO.UK> <716DB361-6280-4825-9A3D-E739DFF37E9F@magma.ca> To: Nick Heatley X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([192.168.3.4]) [65.92.199.80] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7kBf-RJY1EYBkIWB5_vC8CvWsSk Cc: v6ops list , Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.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, 06 Sep 2014 01:15:33 -0000 Hi Nick: Just re-read your email and realized that I missed your comments on = title and abstract. But yes, my personal feeling is that the title and = abstract describe reasonably well the contents of the document. Philip On 2014-09-05, at 20:56 , Philip Matthews wrote: > Hi Nick: >=20 > There are lots of additional topics that could go into this document, = but the authors feel that it would be best to leave these to follow-on = documents because (a) otherwise the document would get very large, and = (b) both authors have had difficulty finding the time to work on this = more-limited scope document.=20 >=20 > So the authors feel it would be best to polish up this document and = publish it as an RFC. After that, if the WG is interested, other = documents could address other areas. >=20 > - Philip >=20 > On 2014-09-05, at 10:34 , Heatley, Nick wrote: >=20 >> Hi, >> I am assuming these functional elements often found in various = broadband networks are out of scope: NAT, DNS, AAA, Address Assignment, = Load balancer, Multi-homing? What of Security enforcement such as (but = not limited) to IP firewall?=20 >> So if the intention is to leave contents as shown (ok with me) = perhaps the title and abstract could be clearer? >> Is "IP Transport Design" a common term for the subject matter, or = perhaps "IP Router Design"? >> Regards, >> Nick >>=20 >>=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip = Matthews >> Sent: 05 September 2014 03:08 >> To: v6ops list; Owen DeLong >> Cc: Victor Kuarsingh >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-02.txt >>=20 >> Folks: >>=20 >> As you can see, Victor and I have just submitted an update to the = Design Choices draft. >>=20 >> This is a significant update, with completely re-written text around = IGP choice and BGP. The IGP choice section looks more completely at the = various options, while the BGP section now considers iBGP as well as = eBGP. This update also addresses comments sent to us by Owen DeLong = (thanks, Owen, and sorry that we took so long to address them!). >>=20 >> In terms of draft status, we are thinking that we are getting close = to a final version. There are surely problems with the draft that need = correcting, but we don't have any plans to add significant new content. = So please read this version with that in mind. >>=20 >> Thanks in advance for any comments, and sorry that we have been a bit = slow in updating the draft. >>=20 >> Philip >>=20 >>=20 >> On 2014-09-04, at 21:50 , Internet-Drafts@ietf.org wrote: >>=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 : Design Choices for IPv6 Networks >>> Authors : Philip Matthews >>> Victor Kuarsingh >>> Filename : draft-ietf-v6ops-design-choices-02.txt >>> Pages : 16 >>> Date : 2014-09-04 >>>=20 >>> Abstract: >>> This document presents advice on the design choices that arise when >>> designing IPv6 networks (both dual-stack and IPv6-only). The >>> intended audience is someone designing an IPv6 network who is >>> knowledgeable about best current practices around IPv4 network >>> design, and wishes to learn the corresponding practices for IPv6. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-02 >>>=20 >>>=20 >>> 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 = 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 >>>=20 >>=20 >> _______________________________________________ >> 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. =20 >>=20 >> 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.=20 >>=20 >> EE Limited >> Registered in England and Wales >> Company Registered Number: 02382161 >> Registered Office Address: Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Sep 5 18:41:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59221A08A7 for ; Fri, 5 Sep 2014 18:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HRYhsZCBE82 for ; Fri, 5 Sep 2014 18:41:00 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F6D1A0719 for ; Fri, 5 Sep 2014 18:41:00 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id p10so212157pdj.37 for ; Fri, 05 Sep 2014 18:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2uG6A8RmGolcElYoaINC6bmx2Sri/L02C8eQ4lAfEoQ=; b=K2OIZyt2AuyMZ0dLqq8IAmJpejAIQCuG5CKPhGTZihbMVf4Z2YRLcp64HqCyRvEOR5 1nskVuGPn1StVVcsQ5LqFSQ+vg5LU/6nyLJGqLJ92p2DDlpcO+trvtcX7edwgFw5B4Xq hD4qdfldvXj7u8vlB1s7tBVhL1aWvq/HgLS6I7vsTdowXpuG2qkJtimmcRuUzXJWQCFa nJEDIPwuTfr4q9iDB8/gNIBmBg5PfAgyXQ3+4i4S3EKUo548jRYe7k5lKEE9DQCZmAyP QZov0KiH2ANGrVHZdX3zzEFexQgtqc809ImyJdo6g0v7BjzzvLf46OkELMCX09+kcqcX q0lA== X-Received: by 10.68.139.99 with SMTP id qx3mr840839pbb.75.1409967660144; Fri, 05 Sep 2014 18:41:00 -0700 (PDT) Received: from [192.168.178.23] (234.192.69.111.dynamic.snap.net.nz. [111.69.192.234]) by mx.google.com with ESMTPSA id k1sm2811158pdl.44.2014.09.05.18.40.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 18:40:59 -0700 (PDT) Message-ID: <540A6645.7020408@gmail.com> Date: Sat, 06 Sep 2014 13:41:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> <2134F8430051B64F815C691A62D9831832D0F3EE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D0F3EE@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7r2mIpxGvbyn63qhC2EmDl2-fC4 Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 01:41:03 -0000 On 06/09/2014 02:48, Templin, Fred L wrote: > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Friday, September 05, 2014 7:00 AM >> To: Fred Baker (fred); Fernando Gont >> Cc: v6ops@ietf.org; Tom Perrine; Fernando Gont >> Subject: Re: [v6ops] PMTUD issue discussion >> >> >> >> On 9/4/2014 5:58 PM, Fred Baker (fred) wrote: >>> On Sep 5, 2014, at 10:47 AM, Fernando Gont wrote: >>> >>>> On 09/04/2014 09:24 PM, Fred Baker (fred) wrote: >>>>> On Sep 5, 2014, at 9:33 AM, Fernando Gont >>>>> wrote: >>>>> >>>>>> What happens when/if such lins employ v6 (whether they really >>>>>> offer a "virtual" MTU >=1280).. I just don't know. >>>>> 802.15.4? >>>> No. I seem to recall that it was more of a packet radio sort of thing >>>> (something predating 802.15.4). I could ask some folks if interested >>>> in more details... >>> I think you missed my point. We have a case in point today, which is >>> IPv6 in an IPv6 tunnel encapsulation running on a packet network whose >>> MTU is 127 bytes. We call it "6lowpan", and it runs on IEEE 802.15.4. >> That's not IPv6. I don't know what it is, but RFC2460 is clear on the >> minimum MTU for IPv6. > > Joe is right - for IPv6 there is only one magic number (1280). Beyond > that, any size up to and including jumbograms must be accommodated, > subject to path MTU limitations. Actually jumbograms, according to RFC 2675, are only available when the *link* MTU is big enough: " The Jumbo Payload option is relevant only for IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets (that is, 65,535 + 40, where 40 octets is the size of the IPv6 header). The Jumbo Payload option need not be implemented or understood by IPv6 nodes that do not support attachment to links with MTU greater than 65,575." Note that it says "nodes", so it applies to routers as well as hosts. My recollection is that efficent use of HIPPI within data centres was the main motivation for jumbograms, and there is no expectation that they will work on the Internet in general. Running jumbograms over an adaptation layer would be craziness. Also " The Jumbo Payload option must not be used in a packet that carries a Fragment header." So I think it's "any size up to 65,575 octets" that must be accomodated. Jumbograms are optional. Brian > > Thanks - Fred > fred.l.templin@boeing.com > >> Anyone who pays money for such a thing should return it. >> >> Joe >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 8 11:47:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB0A1A02F7 for ; Mon, 8 Sep 2014 11:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 TjXtqxgPRHaD for ; Mon, 8 Sep 2014 11:47:54 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95CF1A02C2 for ; Mon, 8 Sep 2014 11:47:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s88IlsmB012306; Mon, 8 Sep 2014 11:47:54 -0700 Received: from XCH-BLV-208.nw.nos.boeing.com (xch-blv-208.nw.nos.boeing.com [10.57.37.5]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s88IlkXG012136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 8 Sep 2014 11:47:46 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.109]) with mapi id 14.03.0181.006; Mon, 8 Sep 2014 11:47:46 -0700 From: "Templin, Fred L" To: Brian E Carpenter Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPyJifs1qEEvpydkaz7jvT8FP9mpvyI8EAgAAGQACAAAMaAIAA2lkA//+XRyCAASzDgIADzG7g Date: Mon, 8 Sep 2014 18:47:45 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D122BB@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> <2134F8430051B64F815C691A62D9831832D0F3EE@XCH-BLV-504.nw.nos.boeing.com> <540A6645.7020408@gmail.com> In-Reply-To: <540A6645.7020408@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZlouQDuMhTgpW09EYo_vDhRZx8k Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 18:47:56 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IEZyaWRheSwgU2VwdGVtYmVyIDA1LCAyMDE0IDY6NDEgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQg TA0KPiBDYzogSm9lIFRvdWNoOyBGcmVkIEJha2VyIChmcmVkKTsgRmVybmFuZG8gR29udDsgdjZv cHNAaWV0Zi5vcmc7IFRvbSBQZXJyaW5lOyBGZXJuYW5kbyBHb250DQo+IFN1YmplY3Q6IFJlOiBb djZvcHNdIFBNVFVEIGlzc3VlIGRpc2N1c3Npb24NCj4gDQo+IE9uIDA2LzA5LzIwMTQgMDI6NDgs IFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKb2UgVG91Y2gNCj4gPj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDUsIDIw MTQgNzowMCBBTQ0KPiA+PiBUbzogRnJlZCBCYWtlciAoZnJlZCk7IEZlcm5hbmRvIEdvbnQNCj4g Pj4gQ2M6IHY2b3BzQGlldGYub3JnOyBUb20gUGVycmluZTsgRmVybmFuZG8gR29udA0KPiA+PiBT dWJqZWN0OiBSZTogW3Y2b3BzXSBQTVRVRCBpc3N1ZSBkaXNjdXNzaW9uDQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+IE9uIDkvNC8yMDE0IDU6NTggUE0sIEZyZWQgQmFrZXIgKGZyZWQpIHdyb3RlOg0K PiA+Pj4gT24gU2VwIDUsIDIwMTQsIGF0IDEwOjQ3IEFNLCBGZXJuYW5kbyBHb250IDxmZ29udEBz aTZuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBPbiAwOS8wNC8yMDE0IDA5OjI0 IFBNLCBGcmVkIEJha2VyIChmcmVkKSB3cm90ZToNCj4gPj4+Pj4gT24gU2VwIDUsIDIwMTQsIGF0 IDk6MzMgQU0sIEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPg0KPiA+Pj4+PiB3 cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4+IFdoYXQgaGFwcGVucyB3aGVuL2lmIHN1Y2ggbGlucyBl bXBsb3kgdjYgKHdoZXRoZXIgdGhleSByZWFsbHkNCj4gPj4+Pj4+IG9mZmVyIGEgInZpcnR1YWwi IE1UVSA+PTEyODApLi4gSSBqdXN0IGRvbid0IGtub3cuDQo+ID4+Pj4+IDgwMi4xNS40Pw0KPiA+ Pj4+IE5vLiBJIHNlZW0gdG8gcmVjYWxsIHRoYXQgaXQgd2FzIG1vcmUgb2YgYSBwYWNrZXQgcmFk aW8gc29ydCBvZiB0aGluZw0KPiA+Pj4+IChzb21ldGhpbmcgcHJlZGF0aW5nIDgwMi4xNS40KS4g SSBjb3VsZCBhc2sgc29tZSBmb2xrcyBpZiBpbnRlcmVzdGVkDQo+ID4+Pj4gaW4gbW9yZSBkZXRh aWxzLi4uDQo+ID4+PiBJIHRoaW5rIHlvdSBtaXNzZWQgbXkgcG9pbnQuIFdlIGhhdmUgYSBjYXNl IGluIHBvaW50IHRvZGF5LCB3aGljaCBpcw0KPiA+Pj4gSVB2NiBpbiBhbiBJUHY2IHR1bm5lbCBl bmNhcHN1bGF0aW9uIHJ1bm5pbmcgb24gYSBwYWNrZXQgbmV0d29yayB3aG9zZQ0KPiA+Pj4gTVRV IGlzIDEyNyBieXRlcy4gV2UgY2FsbCBpdCAiNmxvd3BhbiIsIGFuZCBpdCBydW5zIG9uIElFRUUg ODAyLjE1LjQuDQo+ID4+IFRoYXQncyBub3QgSVB2Ni4gSSBkb24ndCBrbm93IHdoYXQgaXQgaXMs IGJ1dCBSRkMyNDYwIGlzIGNsZWFyIG9uIHRoZQ0KPiA+PiBtaW5pbXVtIE1UVSBmb3IgSVB2Ni4N Cj4gPg0KPiA+IEpvZSBpcyByaWdodCAtIGZvciBJUHY2IHRoZXJlIGlzIG9ubHkgb25lIG1hZ2lj IG51bWJlciAoMTI4MCkuIEJleW9uZA0KPiA+IHRoYXQsIGFueSBzaXplIHVwIHRvIGFuZCBpbmNs dWRpbmcganVtYm9ncmFtcyBtdXN0IGJlIGFjY29tbW9kYXRlZCwNCj4gPiBzdWJqZWN0IHRvIHBh dGggTVRVIGxpbWl0YXRpb25zLg0KPiANCj4gQWN0dWFsbHkganVtYm9ncmFtcywgYWNjb3JkaW5n IHRvIFJGQyAyNjc1LCBhcmUgb25seSBhdmFpbGFibGUNCj4gd2hlbiB0aGUgKmxpbmsqIE1UVSBp cyBiaWcgZW5vdWdoOg0KPiANCj4gIiAgVGhlIEp1bWJvIFBheWxvYWQgb3B0aW9uIGlzIHJlbGV2 YW50IG9ubHkgZm9yIElQdjYgbm9kZXMgdGhhdCBtYXkgYmUNCj4gICAgYXR0YWNoZWQgdG8gbGlu a3Mgd2l0aCBhIGxpbmsgTVRVIGdyZWF0ZXIgdGhhbiA2NSw1NzUgb2N0ZXRzICh0aGF0DQo+ICAg IGlzLCA2NSw1MzUgKyA0MCwgd2hlcmUgNDAgb2N0ZXRzIGlzIHRoZSBzaXplIG9mIHRoZSBJUHY2 IGhlYWRlcikuDQo+ICAgIFRoZSBKdW1ibyBQYXlsb2FkIG9wdGlvbiBuZWVkIG5vdCBiZSBpbXBs ZW1lbnRlZCBvciB1bmRlcnN0b29kIGJ5DQo+ICAgIElQdjYgbm9kZXMgdGhhdCBkbyBub3Qgc3Vw cG9ydCBhdHRhY2htZW50IHRvIGxpbmtzIHdpdGggTVRVIGdyZWF0ZXINCj4gICAgdGhhbiA2NSw1 NzUuIg0KPiANCj4gTm90ZSB0aGF0IGl0IHNheXMgIm5vZGVzIiwgc28gaXQgYXBwbGllcyB0byBy b3V0ZXJzIGFzIHdlbGwgYXMgaG9zdHMuDQo+IE15IHJlY29sbGVjdGlvbiBpcyB0aGF0IGVmZmlj ZW50IHVzZSBvZiBISVBQSSB3aXRoaW4gZGF0YSBjZW50cmVzDQo+IHdhcyB0aGUgbWFpbiBtb3Rp dmF0aW9uIGZvciBqdW1ib2dyYW1zLCBhbmQgdGhlcmUgaXMgbm8gZXhwZWN0YXRpb24NCj4gdGhh dCB0aGV5IHdpbGwgd29yayBvbiB0aGUgSW50ZXJuZXQgaW4gZ2VuZXJhbC4gUnVubmluZyBqdW1i b2dyYW1zDQo+IG92ZXIgYW4gYWRhcHRhdGlvbiBsYXllciB3b3VsZCBiZSBjcmF6aW5lc3MuDQo+ IA0KPiBBbHNvDQo+ICIgIFRoZSBKdW1ibyBQYXlsb2FkIG9wdGlvbiBtdXN0IG5vdCBiZSB1c2Vk IGluIGEgcGFja2V0IHRoYXQgY2FycmllcyBhDQo+ICAgIEZyYWdtZW50IGhlYWRlci4iDQo+IA0K PiBTbyBJIHRoaW5rIGl0J3MgImFueSBzaXplIHVwIHRvIDY1LDU3NSBvY3RldHMiIHRoYXQgbXVz dCBiZQ0KPiBhY2NvbW9kYXRlZC4gSnVtYm9ncmFtcyBhcmUgb3B0aW9uYWwuDQoNClRoZSBrZXkg cGhyYXNlIGluIG15IHRleHQgdGhhdCB5b3UgcXVvdGVkIHdhcyAic3ViamVjdCB0byBwYXRoIE1U VQ0KbGltaXRhdGlvbnMiLiBGb3IgZXhhbXBsZSwgaWYgdGhlIHNvdXJjZSdzIElQdjYgbGF5ZXIg cHJlc2VudHMgYSA0TUINCnBhY2tldCwgYW5kIGlmIGFsbCBsaW5rcyBpbiB0aGUgcGF0aCBzdXBw b3J0IGFuIE1UVSB0aGF0IGlzIGF0IGxlYXN0DQp0aGF0IGxhcmdlLCB0aGVuIHRoZSBwYWNrZXQg d2lsbCBiZSBmb3J3YXJkZWQgdG8gdGhlIGRlc3RpbmF0aW9uIGp1c3QNCmZpbmUuIElmIHRoZSBw YXRoIE1UVSBpcyBkZWZpY2llbnQgYXQgYW55IGhvcCBhbG9uZyB0aGUgcGF0aCwgaG93ZXZlciwN CnRoZSBwYWNrZXQgaXMgZHJvcHBlZCBhbmQgYSBQVEIgbWVzc2FnZSByZXR1cm5lZC4NCg0KV2Ug bWF5IGJlIGEgbG9uZyB3YXkgb2ZmIGZyb20gaGF2aW5nIHBhdGhzIGluIHRoZSBJbnRlcm5ldCAo b3IgZXZlbg0KaW4gcHJpdmF0ZSBuZXR3b3JrcykgdGhhdCBzdXBwb3J0cyBzdWNoIGxhcmdlIHNp emVzLCBidXQgdGhlIHByb3RvY29scw0Kd2lsbCBiZSByZWFkeSB3aGVuIGFuZCBpZiBzdWNoIGxp bmtzIGNvbWUgb25saW5lLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2Vpbmcu Y29tIA0KDQo+ICAgQnJpYW4NCj4gDQo+IA0KPiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZy ZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0KPiA+PiBBbnlvbmUgd2hvIHBheXMgbW9uZXkg Zm9yIHN1Y2ggYSB0aGluZyBzaG91bGQgcmV0dXJuIGl0Lg0KPiA+Pg0KPiA+PiBKb2UNCj4gPj4N Cj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+IHY2b3BzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBs aXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo+ID4NCg== From nobody Mon Sep 8 15:00:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18E11A040D for ; Mon, 8 Sep 2014 14:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oqjG66xxqSs for ; Mon, 8 Sep 2014 14:59:53 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174421A0408 for ; Mon, 8 Sep 2014 14:59:53 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id r10so21921874pdi.1 for ; Mon, 08 Sep 2014 14:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5mLqvr7hK1d2O9gCdymtRUtVEQZDX6ZIDsuB7kgD6Xc=; b=wFn9m1sLibumJZhWJBjH4sywI/VRRvbTOsRDnDfCbA6Q5yePng0lfGBulH+5u50YR3 vZWektqdvbTjmQhaLPUcoS7gI22RNkwYvgJRzdlHfQodp4Z1eoyloN0rx4bDxHIDyJiY soZ9ReaajNiNrVL3A9WRqgCE8KAxt5dd7nxzLtNJeSU8uUvECVbFEXLSMtdK0YAMb8xO UT8VCaPkFF0aydveGho+QxaTTv7AgXPsZwPOnzAyD9PokOqB5E5Sx5oHUXAE5KqkLopc +4y2hO3bM3xSJBBnu7B03M9/HYgMsAYruPtTdJ32VoLptTgY3j9YKAzJfGrNlBZ/VusM s2nw== X-Received: by 10.70.38.135 with SMTP id g7mr35608672pdk.100.1410213592669; Mon, 08 Sep 2014 14:59:52 -0700 (PDT) Received: from [192.168.178.23] (21.196.69.111.dynamic.snap.net.nz. [111.69.196.21]) by mx.google.com with ESMTPSA id k1sm9906535pdj.8.2014.09.08.14.59.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 14:59:52 -0700 (PDT) Message-ID: <540E26D9.3070907@gmail.com> Date: Tue, 09 Sep 2014 09:59:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Dale W. Carder" References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> In-Reply-To: <20140908183339.GB98785@ricotta.doit.wisc.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Y9mX1X4dbLIfHSS_Q7d_xhxsyns Cc: IPv6 Operations , l.wood@surrey.ac.uk Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Sep 2014 21:59:57 -0000 I switched to the relevant list. On 09/09/2014 06:33, Dale W. Carder wrote: > Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Mon, Sep 08, 2014 at 07:50:26AM +1200: >> If they really are interesting problems, it might be more to the >> point to analyse them over on v6ops. Given the number of large >> IPv6 deployments that don't have such problems, it seems like >> this particular deployment hit an unfortunate combination of >> implementation issues. That is worth understanding (for example, >> how large is the layer 2 network that leads to the MLD listener >> report overload?). > > Implementing MLD snooping for Solicited-Node multicast addresses > is probably a bad idea. > > See: draft-pashby-magma-simplify-mld-snooping-01 OK, but I would also like to understand why we require MLD messages for a Solicited-Node multicast address to set Router Alert. Brian From nobody Mon Sep 8 15:11:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634DA1A03F5 for ; Mon, 8 Sep 2014 15:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fTGYDYQNMGn for ; Mon, 8 Sep 2014 15:11:34 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFD71A035F for ; Mon, 8 Sep 2014 15:11:34 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id fp1so2091389pdb.14 for ; Mon, 08 Sep 2014 15:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4OIG8iZETxn7ZoW3huxKsC8mLV8y7tJD8KHRn98JjhY=; b=zvkG3qwD3IQZGcBrbbYPpuNBXRCrhfG2bTYWR+H1M+9E55MHMLGf0Pla7Dwyp4hd61 /iEKUaf+AQvaPxPfex4xSiydsp0a3pw23xYhKxuAKCUzYiBiLpdsDDj3ho5nZekQzZqd oIrhBnpweUXs66dEuCWU3Dnjw8gu7KKBdydblsRa0jlrx2PVdAyXJUSNV8IUdE4IwxZD 6Ct6+CEptormxvMEbB0vN2Vi8qRfTFbZ477bGF4/93hw0+CQDeb76kIchTsH1Orv05DD rXkw2WDi4oZq7MbXk+gY+5DzyuOGQSrkRzDbzoRhduZNFEAwo+fZ31ylyHwVq1GqBH97 30dA== X-Received: by 10.70.96.74 with SMTP id dq10mr51968430pdb.112.1410214294261; Mon, 08 Sep 2014 15:11:34 -0700 (PDT) Received: from [192.168.178.23] (21.196.69.111.dynamic.snap.net.nz. [111.69.196.21]) by mx.google.com with ESMTPSA id na4sm9867279pdb.96.2014.09.08.15.11.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 15:11:33 -0700 (PDT) Message-ID: <540E2995.1020208@gmail.com> Date: Tue, 09 Sep 2014 10:11:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> <2134F8430051B64F815C691A62D9831832D0F3EE@XCH-BLV-504.nw.nos.boeing.com> <540A6645.7020408@gmail.com> <2134F8430051B64F815C691A62D9831832D122BB@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D122BB@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r_ENbrEnK2KOHnFXcDKAVY0Vxuk Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 22:11:36 -0000 Fred, On 09/09/2014 06:47, Templin, Fred L wrote: > Hi Brian, > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Friday, September 05, 2014 6:41 PM >> To: Templin, Fred L >> Cc: Joe Touch; Fred Baker (fred); Fernando Gont; v6ops@ietf.org; Tom Perrine; Fernando Gont >> Subject: Re: [v6ops] PMTUD issue discussion >> >> On 06/09/2014 02:48, Templin, Fred L wrote: >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch >>>> Sent: Friday, September 05, 2014 7:00 AM >>>> To: Fred Baker (fred); Fernando Gont >>>> Cc: v6ops@ietf.org; Tom Perrine; Fernando Gont >>>> Subject: Re: [v6ops] PMTUD issue discussion >>>> >>>> >>>> >>>> On 9/4/2014 5:58 PM, Fred Baker (fred) wrote: >>>>> On Sep 5, 2014, at 10:47 AM, Fernando Gont wrote: >>>>> >>>>>> On 09/04/2014 09:24 PM, Fred Baker (fred) wrote: >>>>>>> On Sep 5, 2014, at 9:33 AM, Fernando Gont >>>>>>> wrote: >>>>>>> >>>>>>>> What happens when/if such lins employ v6 (whether they really >>>>>>>> offer a "virtual" MTU >=1280).. I just don't know. >>>>>>> 802.15.4? >>>>>> No. I seem to recall that it was more of a packet radio sort of thing >>>>>> (something predating 802.15.4). I could ask some folks if interested >>>>>> in more details... >>>>> I think you missed my point. We have a case in point today, which is >>>>> IPv6 in an IPv6 tunnel encapsulation running on a packet network whose >>>>> MTU is 127 bytes. We call it "6lowpan", and it runs on IEEE 802.15.4. >>>> That's not IPv6. I don't know what it is, but RFC2460 is clear on the >>>> minimum MTU for IPv6. >>> Joe is right - for IPv6 there is only one magic number (1280). Beyond >>> that, any size up to and including jumbograms must be accommodated, >>> subject to path MTU limitations. >> Actually jumbograms, according to RFC 2675, are only available >> when the *link* MTU is big enough: >> >> " The Jumbo Payload option is relevant only for IPv6 nodes that may be >> attached to links with a link MTU greater than 65,575 octets (that >> is, 65,535 + 40, where 40 octets is the size of the IPv6 header). >> The Jumbo Payload option need not be implemented or understood by >> IPv6 nodes that do not support attachment to links with MTU greater >> than 65,575." >> >> Note that it says "nodes", so it applies to routers as well as hosts. >> My recollection is that efficent use of HIPPI within data centres >> was the main motivation for jumbograms, and there is no expectation >> that they will work on the Internet in general. Running jumbograms >> over an adaptation layer would be craziness. >> >> Also >> " The Jumbo Payload option must not be used in a packet that carries a >> Fragment header." >> >> So I think it's "any size up to 65,575 octets" that must be >> accomodated. Jumbograms are optional. > > The key phrase in my text that you quoted was "subject to path MTU > limitations". For example, if the source's IPv6 layer presents a 4MB > packet, and if all links in the path support an MTU that is at least > that large, then the packet will be forwarded to the destination just > fine. If the path MTU is deficient at any hop along the path, however, > the packet is dropped and a PTB message returned. > > We may be a long way off from having paths in the Internet (or even > in private networks) that supports such large sizes, but the protocols > will be ready when and if such links come online. The key phrase in my comment was "Jumbograms are optional" (which is explicit in RFC 6434). So the only Internet-wide expectation is a maximum of 65,575, and that is the largest size that can ever be fragmented. Brian From nobody Mon Sep 8 15:45:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781731A0538 for ; Mon, 8 Sep 2014 15:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 m9wL5brpAc8f for ; Mon, 8 Sep 2014 15:45:49 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04651A0515 for ; Mon, 8 Sep 2014 15:45:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s88MjnMm028218; Mon, 8 Sep 2014 15:45:49 -0700 Received: from XCH-BLV-208.nw.nos.boeing.com (xch-blv-208.nw.nos.boeing.com [10.57.37.5]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s88Mjeic028191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 8 Sep 2014 15:45:41 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.109]) with mapi id 14.03.0181.006; Mon, 8 Sep 2014 15:45:40 -0700 From: "Templin, Fred L" To: Brian E Carpenter Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPyJifs1qEEvpydkaz7jvT8FP9mpvyI8EAgAAGQACAAAMaAIAA2lkA//+XRyCAASzDgIADzG7ggACv7YD//5LeAA== Date: Mon, 8 Sep 2014 22:45:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D1284F@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <60533790-9A16-44C8-8239-89AE2C6BD783@cisco.com> <5408F6C6.3030103@gont.com.ar> <080303C1-D09F-4987-B114-F0F5C8B44863@cisco.com> <5409080E.7000200@si6networks.com> <9F0F552B-B465-40C4-8206-82A289294787@cisco.com> <5409C1D2.60604@isi.edu> <2134F8430051B64F815C691A62D9831832D0F3EE@XCH-BLV-504.nw.nos.boeing.com> <540A6645.7020408@gmail.com> <2134F8430051B64F815C691A62D9831832D122BB@XCH-BLV-504.nw.nos.boeing.com> <540E2995.1020208@gmail.com> In-Reply-To: <540E2995.1020208@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JTk4h4MnyxOR53SZeeu3miRiqTM Cc: "v6ops@ietf.org" , Tom Perrine , Fernando Gont , Fernando Gont Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 22:45:51 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgU2VwdGVtYmVyIDA4LCAyMDE0IDM6MTIgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQg TA0KPiBDYzogSm9lIFRvdWNoOyBGcmVkIEJha2VyIChmcmVkKTsgRmVybmFuZG8gR29udDsgdjZv cHNAaWV0Zi5vcmc7IFRvbSBQZXJyaW5lOyBGZXJuYW5kbyBHb250DQo+IFN1YmplY3Q6IFJlOiBb djZvcHNdIFBNVFVEIGlzc3VlIGRpc2N1c3Npb24NCj4gDQo+IEZyZWQsDQo+IA0KPiBPbiAwOS8w OS8yMDE0IDA2OjQ3LCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4gSGkgQnJpYW4sDQo+ID4N Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQnJpYW4gRSBDYXJw ZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IEZy aWRheSwgU2VwdGVtYmVyIDA1LCAyMDE0IDY6NDEgUE0NCj4gPj4gVG86IFRlbXBsaW4sIEZyZWQg TA0KPiA+PiBDYzogSm9lIFRvdWNoOyBGcmVkIEJha2VyIChmcmVkKTsgRmVybmFuZG8gR29udDsg djZvcHNAaWV0Zi5vcmc7IFRvbSBQZXJyaW5lOyBGZXJuYW5kbyBHb250DQo+ID4+IFN1YmplY3Q6 IFJlOiBbdjZvcHNdIFBNVFVEIGlzc3VlIGRpc2N1c3Npb24NCj4gPj4NCj4gPj4gT24gMDYvMDkv MjAxNCAwMjo0OCwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lIFRvdWNoDQo+ID4+Pj4gU2VudDogRnJpZGF5LCBTZXB0 ZW1iZXIgMDUsIDIwMTQgNzowMCBBTQ0KPiA+Pj4+IFRvOiBGcmVkIEJha2VyIChmcmVkKTsgRmVy bmFuZG8gR29udA0KPiA+Pj4+IENjOiB2Nm9wc0BpZXRmLm9yZzsgVG9tIFBlcnJpbmU7IEZlcm5h bmRvIEdvbnQNCj4gPj4+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQTVRVRCBpc3N1ZSBkaXNjdXNz aW9uDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24gOS80LzIwMTQgNTo1OCBQTSwg RnJlZCBCYWtlciAoZnJlZCkgd3JvdGU6DQo+ID4+Pj4+IE9uIFNlcCA1LCAyMDE0LCBhdCAxMDo0 NyBBTSwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPiB3cm90ZToNCj4gPj4+ Pj4NCj4gPj4+Pj4+IE9uIDA5LzA0LzIwMTQgMDk6MjQgUE0sIEZyZWQgQmFrZXIgKGZyZWQpIHdy b3RlOg0KPiA+Pj4+Pj4+IE9uIFNlcCA1LCAyMDE0LCBhdCA5OjMzIEFNLCBGZXJuYW5kbyBHb250 IDxmZXJuYW5kb0Bnb250LmNvbS5hcj4NCj4gPj4+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+PiBXaGF0IGhhcHBlbnMgd2hlbi9pZiBzdWNoIGxpbnMgZW1wbG95IHY2ICh3aGV0aGVy IHRoZXkgcmVhbGx5DQo+ID4+Pj4+Pj4+IG9mZmVyIGEgInZpcnR1YWwiIE1UVSA+PTEyODApLi4g SSBqdXN0IGRvbid0IGtub3cuDQo+ID4+Pj4+Pj4gODAyLjE1LjQ/DQo+ID4+Pj4+PiBOby4gSSBz ZWVtIHRvIHJlY2FsbCB0aGF0IGl0IHdhcyBtb3JlIG9mIGEgcGFja2V0IHJhZGlvIHNvcnQgb2Yg dGhpbmcNCj4gPj4+Pj4+IChzb21ldGhpbmcgcHJlZGF0aW5nIDgwMi4xNS40KS4gSSBjb3VsZCBh c2sgc29tZSBmb2xrcyBpZiBpbnRlcmVzdGVkDQo+ID4+Pj4+PiBpbiBtb3JlIGRldGFpbHMuLi4N Cj4gPj4+Pj4gSSB0aGluayB5b3UgbWlzc2VkIG15IHBvaW50LiBXZSBoYXZlIGEgY2FzZSBpbiBw b2ludCB0b2RheSwgd2hpY2ggaXMNCj4gPj4+Pj4gSVB2NiBpbiBhbiBJUHY2IHR1bm5lbCBlbmNh cHN1bGF0aW9uIHJ1bm5pbmcgb24gYSBwYWNrZXQgbmV0d29yayB3aG9zZQ0KPiA+Pj4+PiBNVFUg aXMgMTI3IGJ5dGVzLiBXZSBjYWxsIGl0ICI2bG93cGFuIiwgYW5kIGl0IHJ1bnMgb24gSUVFRSA4 MDIuMTUuNC4NCj4gPj4+PiBUaGF0J3Mgbm90IElQdjYuIEkgZG9uJ3Qga25vdyB3aGF0IGl0IGlz LCBidXQgUkZDMjQ2MCBpcyBjbGVhciBvbiB0aGUNCj4gPj4+PiBtaW5pbXVtIE1UVSBmb3IgSVB2 Ni4NCj4gPj4+IEpvZSBpcyByaWdodCAtIGZvciBJUHY2IHRoZXJlIGlzIG9ubHkgb25lIG1hZ2lj IG51bWJlciAoMTI4MCkuIEJleW9uZA0KPiA+Pj4gdGhhdCwgYW55IHNpemUgdXAgdG8gYW5kIGlu Y2x1ZGluZyBqdW1ib2dyYW1zIG11c3QgYmUgYWNjb21tb2RhdGVkLA0KPiA+Pj4gc3ViamVjdCB0 byBwYXRoIE1UVSBsaW1pdGF0aW9ucy4NCj4gPj4gQWN0dWFsbHkganVtYm9ncmFtcywgYWNjb3Jk aW5nIHRvIFJGQyAyNjc1LCBhcmUgb25seSBhdmFpbGFibGUNCj4gPj4gd2hlbiB0aGUgKmxpbmsq IE1UVSBpcyBiaWcgZW5vdWdoOg0KPiA+Pg0KPiA+PiAiICBUaGUgSnVtYm8gUGF5bG9hZCBvcHRp b24gaXMgcmVsZXZhbnQgb25seSBmb3IgSVB2NiBub2RlcyB0aGF0IG1heSBiZQ0KPiA+PiAgICBh dHRhY2hlZCB0byBsaW5rcyB3aXRoIGEgbGluayBNVFUgZ3JlYXRlciB0aGFuIDY1LDU3NSBvY3Rl dHMgKHRoYXQNCj4gPj4gICAgaXMsIDY1LDUzNSArIDQwLCB3aGVyZSA0MCBvY3RldHMgaXMgdGhl IHNpemUgb2YgdGhlIElQdjYgaGVhZGVyKS4NCj4gPj4gICAgVGhlIEp1bWJvIFBheWxvYWQgb3B0 aW9uIG5lZWQgbm90IGJlIGltcGxlbWVudGVkIG9yIHVuZGVyc3Rvb2QgYnkNCj4gPj4gICAgSVB2 NiBub2RlcyB0aGF0IGRvIG5vdCBzdXBwb3J0IGF0dGFjaG1lbnQgdG8gbGlua3Mgd2l0aCBNVFUg Z3JlYXRlcg0KPiA+PiAgICB0aGFuIDY1LDU3NS4iDQo+ID4+DQo+ID4+IE5vdGUgdGhhdCBpdCBz YXlzICJub2RlcyIsIHNvIGl0IGFwcGxpZXMgdG8gcm91dGVycyBhcyB3ZWxsIGFzIGhvc3RzLg0K PiA+PiBNeSByZWNvbGxlY3Rpb24gaXMgdGhhdCBlZmZpY2VudCB1c2Ugb2YgSElQUEkgd2l0aGlu IGRhdGEgY2VudHJlcw0KPiA+PiB3YXMgdGhlIG1haW4gbW90aXZhdGlvbiBmb3IganVtYm9ncmFt cywgYW5kIHRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uDQo+ID4+IHRoYXQgdGhleSB3aWxsIHdvcmsg b24gdGhlIEludGVybmV0IGluIGdlbmVyYWwuIFJ1bm5pbmcganVtYm9ncmFtcw0KPiA+PiBvdmVy IGFuIGFkYXB0YXRpb24gbGF5ZXIgd291bGQgYmUgY3JhemluZXNzLg0KPiA+Pg0KPiA+PiBBbHNv DQo+ID4+ICIgIFRoZSBKdW1ibyBQYXlsb2FkIG9wdGlvbiBtdXN0IG5vdCBiZSB1c2VkIGluIGEg cGFja2V0IHRoYXQgY2FycmllcyBhDQo+ID4+ICAgIEZyYWdtZW50IGhlYWRlci4iDQo+ID4+DQo+ ID4+IFNvIEkgdGhpbmsgaXQncyAiYW55IHNpemUgdXAgdG8gNjUsNTc1IG9jdGV0cyIgdGhhdCBt dXN0IGJlDQo+ID4+IGFjY29tb2RhdGVkLiBKdW1ib2dyYW1zIGFyZSBvcHRpb25hbC4NCj4gPg0K PiA+IFRoZSBrZXkgcGhyYXNlIGluIG15IHRleHQgdGhhdCB5b3UgcXVvdGVkIHdhcyAic3ViamVj dCB0byBwYXRoIE1UVQ0KPiA+IGxpbWl0YXRpb25zIi4gRm9yIGV4YW1wbGUsIGlmIHRoZSBzb3Vy Y2UncyBJUHY2IGxheWVyIHByZXNlbnRzIGEgNE1CDQo+ID4gcGFja2V0LCBhbmQgaWYgYWxsIGxp bmtzIGluIHRoZSBwYXRoIHN1cHBvcnQgYW4gTVRVIHRoYXQgaXMgYXQgbGVhc3QNCj4gPiB0aGF0 IGxhcmdlLCB0aGVuIHRoZSBwYWNrZXQgd2lsbCBiZSBmb3J3YXJkZWQgdG8gdGhlIGRlc3RpbmF0 aW9uIGp1c3QNCj4gPiBmaW5lLiBJZiB0aGUgcGF0aCBNVFUgaXMgZGVmaWNpZW50IGF0IGFueSBo b3AgYWxvbmcgdGhlIHBhdGgsIGhvd2V2ZXIsDQo+ID4gdGhlIHBhY2tldCBpcyBkcm9wcGVkIGFu ZCBhIFBUQiBtZXNzYWdlIHJldHVybmVkLg0KPiA+DQo+ID4gV2UgbWF5IGJlIGEgbG9uZyB3YXkg b2ZmIGZyb20gaGF2aW5nIHBhdGhzIGluIHRoZSBJbnRlcm5ldCAob3IgZXZlbg0KPiA+IGluIHBy aXZhdGUgbmV0d29ya3MpIHRoYXQgc3VwcG9ydHMgc3VjaCBsYXJnZSBzaXplcywgYnV0IHRoZSBw cm90b2NvbHMNCj4gPiB3aWxsIGJlIHJlYWR5IHdoZW4gYW5kIGlmIHN1Y2ggbGlua3MgY29tZSBv bmxpbmUuDQo+IA0KPiBUaGUga2V5IHBocmFzZSBpbiBteSBjb21tZW50IHdhcyAiSnVtYm9ncmFt cyBhcmUgb3B0aW9uYWwiICh3aGljaA0KPiBpcyBleHBsaWNpdCBpbiBSRkMgNjQzNCkuDQoNCk9L LCB0aGFua3MgZm9yIHRoYXQgcmVmZXJlbmNlIC0gbXVjaCBhcHByZWNpYXRlZC4NCg0KPiBTbyB0 aGUgb25seSBJbnRlcm5ldC13aWRlIGV4cGVjdGF0aW9uDQo+IGlzIGEgbWF4aW11bSBvZiA2NSw1 NzUsIGFuZCB0aGF0IGlzIHRoZSBsYXJnZXN0IHNpemUgdGhhdCBjYW4gZXZlcg0KPiBiZSBmcmFn bWVudGVkLg0KDQpPZiB0aGF0LCB0aGUgc3BlY3MgbGVhdmUgbm8gZG91YnQuDQoNClRoYW5rcyAt IEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAgICBCcmlhbg0K From nobody Mon Sep 8 18:55:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E431A0382 for ; Mon, 8 Sep 2014 18:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=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 qGFjWZH52JVf for ; Mon, 8 Sep 2014 18:55:36 -0700 (PDT) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368881A0376 for ; Mon, 8 Sep 2014 18:55:36 -0700 (PDT) Received: from [66.196.81.172] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 09 Sep 2014 01:55:35 -0000 Received: from [98.139.212.214] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 09 Sep 2014 01:55:35 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 09 Sep 2014 01:55:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 368883.66802.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 39991 invoked by uid 60001); 9 Sep 2014 01:55:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1410227735; bh=/0kMzqD7smAox7fWh4C+boGYc5Nak7NRVRDJufprglQ=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sJahk/tS1I2OpUOmD0PTve5/ln6S2j2i4qmu46YPS0m8XXiE7cPhOwBf36sDf0R7161wUcpkBSyHrT9SDUvM0Mo4DPla/u/SvKq6DKJDZU00ZArQJTLA3pQPJ+AFdv1ubSDXOzNz9QXzXXe6jUZGcGIfRiCWNNcA9l/R13nd6qA= X-YMail-OSG: jzPB.4kVM1lvO3o3ld77gO_MrPtCAPeb7U8wFKX.jinYWvl TtAhQWs3LtpOwVlru4.xkJmtVWhwp5aLLrks9BP5_1rbB5kVdE9O4ZzSS56t NnesOIszqu0duD94J.5gCGRODV9Ool4tpfbJfXhFc2kJ0zuQkbSr4kZAm1V0 5vl1uwYIWyihvgoG2yRXRqf2KCM09p4cRhM0DYw6gUr_dQYDhT3AZ81aWbU7 3L5decKi0d1XV5tOxZSGyc0pZuYMaUH7jbN_70eyz8g6V.6_p6NQ57bRWnPy JBFf16uttXxEJ2I5KW3nTFbXKpY6O43isQxRtXOdxPl0xMXwtKgZ1ph67e1t QPowqPj5.F9LDTsoQb69uUhAySjrQUQ9mzvK9KQLR7PseOonPBfWzKgdLxsq kcict_5fc8IOxIfzOzU9WDSaMa9llQHD0gt7hLy3X6t2Pk_hUszHpb1jwO3z JwF0GEWQ831dIYbSLUZ55nxR51eWbIbtaMJn43IqKZUQXZ72YWTYzwfHXBdE YqcSM_hYZkzD3edbB8QQUaD7ex29Qlt7akRYug_6gAkTIE1vp8HWyg4oE_gl nAVsk8m6_CT2D6xXvh3LuS7dFFNViFCcCGF.Crri3GqurVQOtIkXt6htKxp0 moBnCD1J_jJ14hbtQYI1.Oq2.oanPTOT5b4NJzZ4pmPQUiJMsR_S6RSEMay7 N32CU Received: from [58.6.205.2] by web162204.mail.bf1.yahoo.com via HTTP; Mon, 08 Sep 2014 18:55:35 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBEYWxlIFcuIENhcmRlciA8ZHdjYXJkZXJAd2lzYy5lZHU.Cj4gQ2M6IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc.OyBsLndvb2RAc3VycmV5LmFjLnVrCj4gU2VudDogVHVlc2RheSwgOSBTZXB0ZW1iZXIgMjAxNCwgNzo1OQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEludGVyZXN0aW5nIHByb2JsZW1zIHdpdGggdXNpbmcgSVB2NgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> Message-ID: <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Mon, 8 Sep 2014 18:55:35 -0700 From: Mark ZZZ Smith To: Brian E Carpenter , "Dale W. Carder" In-Reply-To: <540E26D9.3070907@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Eju1pGxpIIncec5NTtY2kv0gzx4 Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 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, 09 Sep 2014 01:55:37 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Dale W. Carder =0A> Cc: = IPv6 Operations ; l.wood@surrey.ac.uk=0A> Sent: Tuesday, 9 = September 2014, 7:59=0A> Subject: Re: [v6ops] Interesting problems with usi= ng IPv6=0A> =0A> I switched to the relevant list.=0A> =0A> On 09/09/2014 06= :33, Dale W. Carder wrote:=0A>> Thus spake Brian E Carpenter (brian.e.carp= enter@gmail.com) on Mon, Sep 08, =0A> 2014 at 07:50:26AM +1200:=0A>>> If t= hey really are interesting problems, it might be more to the=0A>>> point t= o analyse them over on v6ops. Given the number of large=0A>>> IPv6 deploym= ents that don't have such problems, it seems like=0A>>> this particular de= ployment hit an unfortunate combination of=0A>>> implementation issues.=0A= =0A=0AIf this email is referring to this blog post:=0A=0Ahttp://blog.bimajo= rity.org/2014/09/05/the-network-nightmare-that-ate-my-week/=0A=0A=0Athen I = think this particular network was already on the verge of catastrophic fail= ure, and some of IPv6's ND differences were just the trigger to push it ove= r that threshold.=0A=0A=0AAccording to the blog post, they might have:=0A= =0A- hardware errors=0A- software errors=0A- 'bridge loops' causing the con= trol plane to overload=0A=0AIn some of these cases they've taken actions to= try to resolve them, however the actions taken seem to be based on specula= ting what is happening rather than finding evidence to support the hypothes= ised cause before taking action.=0A=0AFor example, there isn't any evidence= that they've actually determined that 'bridge loops' are occurring, found = out what is causing them, and then taking measures to prevent them or at le= ast reduce the chances of them occurring. If a 'bridge loop' can cause the = control plane to overload, then adding anything to this network like IPv6 i= s likely to only make the problem worse.=0A=0AI'd like to see them get to t= he bottom of and then fix these 'bridge loop' and other problems first befo= re any value is placed on addressing their criticisms of IPv6. Other people= have deployed IPv6 without these problems, so what is different between th= is network and everybody else's that doesn't have these sorts of problems?= =0A=0A=0A=0A That is worth understanding (for example,=0A>>> how large is = the layer 2 network that leads to the MLD listener=0A>>> report overload?)= .=0A>> =0A>> Implementing MLD snooping for Solicited-Node multicast addres= ses =0A>> is probably a bad idea.=0A>> =0A=0A>> See: draft-pashby-magma-s= implify-mld-snooping-01=0A> =0A> OK, but I would also like to understand wh= y we require=0A> MLD messages for a Solicited-Node multicast address to=0A>= set Router Alert.=0A> =0A> Brian=0A> =0A> ____________________________= ___________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://w= ww.ietf.org/mailman/listinfo/v6ops=0A> From nobody Mon Sep 8 19:14:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934D91A03B4 for ; Mon, 8 Sep 2014 19:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14sIiuJLrtuB for ; Mon, 8 Sep 2014 19:14:49 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985B61A03B1 for ; Mon, 8 Sep 2014 19:14:49 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id v10so7894654pde.5 for ; Mon, 08 Sep 2014 19:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KHfBZbaammF6LU7YwaXvjkt5DL6EnbHyvqptgTk4I7M=; b=tET6P7U8vEagwVMoqI51yy4SPgQKV4p6F6XR8vSabjLlI7MxF1thoYVu+yApp0gKgZ i1fhX0Q0A3zEZ7Md/72SjDng82/QLvIY4dtYlwD13oroJowVp2Fsdo3dHGbmIl5fVJRS dzc9Tw1acEhi8ShEoWhwNTYVnqsavETjEFJxPtsGYQ+QH4NP4f2LjQaz0WoKRin4toxl rWxIvObQvgQsptHVcTcpSJWQus0j0lt+RI+//qt/MhROzk2m+i44Z333FuqQOGqS8dw7 y53fwsaPUFvVp42SisKzZGozA1RkaPZO+qAqEYS4/eJoqfzbyPHHbKrcqal3JlMeRcmb D+Vg== X-Received: by 10.68.68.134 with SMTP id w6mr24055838pbt.110.1410228889143; Mon, 08 Sep 2014 19:14:49 -0700 (PDT) Received: from [192.168.178.23] (21.196.69.111.dynamic.snap.net.nz. [111.69.196.21]) by mx.google.com with ESMTPSA id pg2sm9995719pbb.43.2014.09.08.19.14.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 19:14:48 -0700 (PDT) Message-ID: <540E6299.2050003@gmail.com> Date: Tue, 09 Sep 2014 14:14:49 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/a1FpP-bfq8dRaXoz2s5dTWF3df8 Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 02:14:51 -0000 Mark, My point is that it's worth *understanding* such problems and then perhaps writing up operational or implementation recommendations. Exactly what the v6ops charter says we should do, in fact. "1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts." Or recommend protocol changes if they might help, which is why I want to understand the value of Router Alert in MLD messages for Solicited-Node multicast addresses. Or should we revive draft-pashby-magma-simplify-mld-snooping-01? Brian On 09/09/2014 13:55, Mark ZZZ Smith wrote: > > > > ----- Original Message ----- >> From: Brian E Carpenter >> To: Dale W. Carder >> Cc: IPv6 Operations ; l.wood@surrey.ac.uk >> Sent: Tuesday, 9 September 2014, 7:59 >> Subject: Re: [v6ops] Interesting problems with using IPv6 >> >> I switched to the relevant list. >> >> On 09/09/2014 06:33, Dale W. Carder wrote: >>> Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Mon, Sep 08, >> 2014 at 07:50:26AM +1200: >>>> If they really are interesting problems, it might be more to the >>>> point to analyse them over on v6ops. Given the number of large >>>> IPv6 deployments that don't have such problems, it seems like >>>> this particular deployment hit an unfortunate combination of >>>> implementation issues. > > > If this email is referring to this blog post: > > http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ > > > then I think this particular network was already on the verge of catastrophic failure, and some of IPv6's ND differences were just the trigger to push it over that threshold. > > > According to the blog post, they might have: > > - hardware errors > - software errors > - 'bridge loops' causing the control plane to overload > > In some of these cases they've taken actions to try to resolve them, however the actions taken seem to be based on speculating what is happening rather than finding evidence to support the hypothesised cause before taking action. > > For example, there isn't any evidence that they've actually determined that 'bridge loops' are occurring, found out what is causing them, and then taking measures to prevent them or at least reduce the chances of them occurring. If a 'bridge loop' can cause the control plane to overload, then adding anything to this network like IPv6 is likely to only make the problem worse. > > I'd like to see them get to the bottom of and then fix these 'bridge loop' and other problems first before any value is placed on addressing their criticisms of IPv6. Other people have deployed IPv6 without these problems, so what is different between this network and everybody else's that doesn't have these sorts of problems? > > > > That is worth understanding (for example, >>>> how large is the layer 2 network that leads to the MLD listener >>>> report overload?). >>> Implementing MLD snooping for Solicited-Node multicast addresses >>> is probably a bad idea. >>> > >>> See: draft-pashby-magma-simplify-mld-snooping-01 >> OK, but I would also like to understand why we require >> MLD messages for a Solicited-Node multicast address to >> set Router Alert. >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Mon Sep 8 21:12:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C62B1A06F6 for ; Mon, 8 Sep 2014 21:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQqd625hgrhe for ; Mon, 8 Sep 2014 21:11:58 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B531A06ED for ; Mon, 8 Sep 2014 21:11:57 -0700 (PDT) Received: from [2001:5c0:1000:a::16d] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XRCmU-00035S-80; Tue, 09 Sep 2014 06:11:50 +0200 Message-ID: <540E7DC3.8060408@gont.com.ar> Date: Tue, 09 Sep 2014 01:10:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Brian E Carpenter , "Dale W. Carder" References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> In-Reply-To: <540E26D9.3070907@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ACG_y2yRsMaxcs866g1oWgBIeIs Cc: IPv6 Operations , l.wood@surrey.ac.uk Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 04:12:05 -0000 On 09/08/2014 06:59 PM, Brian E Carpenter wrote: >> >> See: draft-pashby-magma-simplify-mld-snooping-01 > > OK, but I would also like to understand why we require > MLD messages for a Solicited-Node multicast address to > set Router Alert. Because in theory the multicast router needs to process the MLD message to build its forwarding table.... -- or are you arguing that since the Dst Addr "includes" the router, the router should process the MLD message anyway? 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 nobody Tue Sep 9 00:20:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E871A0B72 for ; Tue, 9 Sep 2014 00:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOUFd-EyahOm for ; Tue, 9 Sep 2014 00:20:51 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18E31A0B14 for ; Tue, 9 Sep 2014 00:20:50 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id w10so3530908pde.13 for ; Tue, 09 Sep 2014 00:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NPAh2cSSqwYuHenlq1UyEoJI6mW5+NSCT6lCvL5xM3k=; b=aSQhjGSfEwNEowKCAifud0puK4wSwFQeBE96Qb73t5F6qA/JdnAsTjYH7Bb9y29PCs U44kREuMRpg76L4Iw/nt1zKu9i4c+nDMdKS7zIQEuP+z6Y2v6AQY38kz0VZDnGXaiUUm C57e/Gbww5DqxwZX1i8CDTDRLsETWngIStBeZ5wgmdpRaz1qEQvnnRLNGQaxB8p5QaL2 yMRV9lJITSb3hk05T8llyewtbauF9VgzUVpS3MZEtYLKpDt+NBYL6UcyjJser4CEwFRa Yss9TcxyHLE3l5YjmyGJTQ8bvzzAULEJOfzh+jBmA9t8tZlcTR0p3/KqGZT68RF8K/Vt HbBw== X-Received: by 10.66.249.34 with SMTP id yr2mr11885740pac.149.1410247250681; Tue, 09 Sep 2014 00:20:50 -0700 (PDT) Received: from [192.168.178.23] (21.196.69.111.dynamic.snap.net.nz. [111.69.196.21]) by mx.google.com with ESMTPSA id td4sm10676220pbc.36.2014.09.09.00.20.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 00:20:50 -0700 (PDT) Message-ID: <540EAA55.7000207@gmail.com> Date: Tue, 09 Sep 2014 19:20:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> In-Reply-To: <540E7DC3.8060408@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UpH2gUtrnu4667Axj7UxSV_HKsw Cc: IPv6 Operations , l.wood@surrey.ac.uk Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 07:20:52 -0000 On 09/09/2014 16:10, Fernando Gont wrote: > On 09/08/2014 06:59 PM, Brian E Carpenter wrote: >>> See: draft-pashby-magma-simplify-mld-snooping-01 >> OK, but I would also like to understand why we require >> MLD messages for a Solicited-Node multicast address to >> set Router Alert. > > Because in theory the multicast router needs to process the MLD message > to build its forwarding table.... Why, for the Solicited-Node group, which is only meaningful on the link from which the MLD message arrives? (NBMA is different of course, but that is not the scenario in the blog.) -- or are you arguing that since the > Dst Addr "includes" the router, the router should process the MLD > message anyway? In its role as a node on the same link, participating in ND on that link, yes. In its role as a forwarding device, surely it should ignore traffic to the Solicited-Node address? So Router Alert is not needed. Or am I missing something? Brian From nobody Tue Sep 9 00:36:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BE61A0B72 for ; Tue, 9 Sep 2014 00:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 CwghKlyqQ4pf for ; Tue, 9 Sep 2014 00:36:03 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AEF1A0B75 for ; Tue, 9 Sep 2014 00:36:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9155CA2; Tue, 9 Sep 2014 09:36:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1410248161; bh=kdF31uL6AP5Yf+zJylguSLMb0mq2aY8OruCr1dYyV7E=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XaK0cL9TrdAMXsKAC+qzXFXcnkGMhI5LYMh386Bs3+2Z0Knbo3iTpskohLeiAxs5H HCj2HEqJWp+CN8bVNSCaBavk12E7FCSM0Tr6cjBJu06blUTYR1a7lxS+w6e43262O2 9NHo+gEawJYmFQT7ihHpWZRHIMggTzLdEJbFL4tw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DA3C9F; Tue, 9 Sep 2014 09:36:01 +0200 (CEST) Date: Tue, 9 Sep 2014 09:36:01 +0200 (CEST) From: Mikael Abrahamsson To: Philip Matthews In-Reply-To: <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> Message-ID: References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Lfi4eKbEBivxahuRsJctLes16b0 Cc: v6ops list , Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.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, 09 Sep 2014 07:36:05 -0000 On Thu, 4 Sep 2014, Philip Matthews wrote: > Thanks in advance for any comments, and sorry that we have been a bit > slow in updating the draft. Hi, In 2.1.1, I'd like to see some text talking about methods where IPv4 and IPv6 can be separated by means of protocol based vlans, so end system complexity isn't increased, it's only a network change. This way IPv4 and IPv6 can have different topology, so that IPv4 choices don't have to affect IPv6 choices. In light of recent talk about IPv6 multicast and privacy addressing causing problems in networks, we should give guidance pointing to the problems of having very large L2 domains. One article: http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 9 00:56:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06E21A0B83 for ; Tue, 9 Sep 2014 00:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-1.652, 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 BetyY93VlLhb for ; Tue, 9 Sep 2014 00:56:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD92B1A0B7D for ; Tue, 9 Sep 2014 00:56:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 14D17A2; Tue, 9 Sep 2014 09:56:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1410249407; bh=UM6/EFCQEnLy38XemPmoxKmrRSeSGq3lun8z1LVFLZo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=znH9QIeGw6LjPDp7/1oechvXvxz9jdsSCXzZsP1+TPoGHAIB74RrWMmDel8hLWbsN Kdkh7/QY5qzCqYWZG4RokUaXXghWhF8lobN7gOrUFBQDykCzqdN295FoBuz4LxC1+r rsxrc2dLyULSIwklRlGNlrs+IbAJVnlZgiBcJe30= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 109229F; Tue, 9 Sep 2014 09:56:47 +0200 (CEST) Date: Tue, 9 Sep 2014 09:56:47 +0200 (CEST) From: Mikael Abrahamsson To: Tom Perrine In-Reply-To: <540626F6.1020103@scea.com> Message-ID: References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/E9UGSQy1PG3h5YIh20Q2nkJPSXA Cc: v6ops@ietf.org Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:56:51 -0000 On Tue, 2 Sep 2014, Tom Perrine wrote: > What MTUs are actually (commonly) seen in the wild? My reply is late, but let me write some of my experience as I did some investigation into what's possible. All values presented here are IP MTU, not L2 MTU. Most people mix these values and I've seen a lot of broken deployments due to this. The major end system IP MTU seen in the world is 1500 (huge majority). The path MTUs seen might be slightly under due to PPPoE, GRE, GTP etc encapsulations on the access layer. Going larger than this (speaking both of path MTU and end system MTUs), most opt for 4470, 9000 or 9180 due to older protocols such as AAL5 ATM, SMDS, FDDI, POS etc. Unfortunately Juniper MX doesn't support 9180, but instead one has to choose one value of 9178, 9174 or 9170 depending on number of vlan tags (or MPLS labels I guess) one wants to support, so these are also seen. Personally I think the balanced approach would be to make your core support something around the 9180 figure, and give 9000 to end users. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 9 02:27:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69FA1A86E0 for ; Tue, 9 Sep 2014 02:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adaKl8mOolFA for ; Tue, 9 Sep 2014 02:27:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A17B11A89A8 for ; Tue, 9 Sep 2014 02:27:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XRHiD-0000COC; Tue, 9 Sep 2014 11:27:45 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> In-reply-to: Your message of "Tue, 09 Sep 2014 19:20:53 +1200 ." <540EAA55.7000207@gmail.com> Date: Tue, 09 Sep 2014 11:27:44 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1cXddYPn614CugwA_6hQ6jgbIu8 Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 09:27:51 -0000 In your letter dated Tue, 09 Sep 2014 19:20:53 +1200 you wrote: >In its role as a node on the same link, participating in ND on that >link, yes. In its role as a forwarding device, surely it should ignore >traffic to the Solicited-Node address? So Router Alert is not >needed. Or am I missing something? Something else is weird as well. MLD-snooping involves a trade-off. The benefits of MLD-snooping are reduced multicast traffic. The costs are the extra hardware needed to do the filtering and increased complexity. In most networks, increased complexity causes headaches and downtime, so the savings better be significant. Though ND is quite chatty, even in big networks it is not going to overload a 100 Mbit/s ethernet link or a host that is less than a decade old and not significantly under powered. One type of link that is certainly not going to be affected is backbone links between switches. So where does MLD-snooping make sense? On links from a switch to either a rather slow network technology, like 2.4 GHz wifi, or particularly low-end devices, like small ARM boards. So the weird thing in the story is that core switches get overloaded processing MLD even though they can just as well just forward multicast over a spanning tree. Somehow the network architecture at CSAIL ended up with central processing of MLD and a centralized TCAM for filtering instead of just filtering at the edges where it makes sense. From nobody Tue Sep 9 02:43:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FF71A89AE for ; Tue, 9 Sep 2014 02:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6] 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 SCRdeWnjcnH4 for ; Tue, 9 Sep 2014 02:43:24 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EBD71A06B6 for ; Tue, 9 Sep 2014 02:43:24 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s899grMx054645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Sep 2014 10:43:13 +0100 (IST) (envelope-from nick@foobar.org) Message-ID: <540ECB9E.9000102@foobar.org> Date: Tue, 09 Sep 2014 10:42:54 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Brian E Carpenter , "Dale W. Carder" References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PtOrJUIZUkCPQrPgC1KCl7SCjJI Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 09:43:26 -0000 On 09/09/2014 02:55, Mark ZZZ Smith wrote: > I'd like to see them get to the bottom of and then fix these 'bridge > loop' and other problems first before any value is placed on addressing > their criticisms of IPv6. Other people have deployed IPv6 without these > problems, so what is different between this network and everybody else's > that doesn't have these sorts of problems? from my reading of the post, the author+vendor determined that the bridge loops happened because the STP process was starved of resources on the switch CPUs. This happened because the switch CPUs were overloaded with mld report packets due to end hosts on the extended L2 network replying to MLD all-groups queries every 150 seconds. There were large numbers of MLD reports because there was a large number of ipv6 privacy addresses on the network. The network operators did not have admin control of the end hosts and could therefore not stop them from using privacy addresses. Nick From nobody Tue Sep 9 02:54:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF001A034D for ; Tue, 9 Sep 2014 02:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg62Z8T3WFeE for ; Tue, 9 Sep 2014 02:54:08 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA721A030A for ; Tue, 9 Sep 2014 02:54:08 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=35218 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XRI7Z-0006F9-7J; Tue, 09 Sep 2014 11:53:57 +0200 Message-ID: <540ECDD8.9040901@fud.no> Date: Tue, 09 Sep 2014 11:52:24 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Nick Hilliard , Mark ZZZ Smith , Brian E Carpenter , "Dale W. Carder" References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> In-Reply-To: <540ECB9E.9000102@foobar.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ajYInuyZpumQjdVYGysC_cXvvS8 Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 09:54:09 -0000 * Nick Hilliard > The network operators did not have admin control of the end hosts and > could therefore not stop them from using privacy addresses. That's easily accomplished by setting Autonomous=0 in RA and using something else for address assignment (like DHCPv6). No SLAAC => no privacy extensions. Tore From nobody Tue Sep 9 03:13:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878A41A02BE for ; Tue, 9 Sep 2014 03:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6ZGJXu5tB9H for ; Tue, 9 Sep 2014 03:13:12 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41BD1A00C5 for ; Tue, 9 Sep 2014 03:13:11 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s89ACeaI054854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Sep 2014 11:13:01 +0100 (IST) (envelope-from nick@foobar.org) Message-ID: <540ED29A.8050005@foobar.org> Date: Tue, 09 Sep 2014 11:12:42 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Tore Anderson , Mark ZZZ Smith , Brian E Carpenter , "Dale W. Carder" References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <540ECDD8.9040901@fud.no> In-Reply-To: <540ECDD8.9040901@fud.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6S3ZLHuvi-V4KckmaUONbZhksKs Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 10:13:13 -0000 On 09/09/2014 10:52, Tore Anderson wrote: > That's easily accomplished by setting Autonomous=0 in RA and using > something else for address assignment (like DHCPv6). > > No SLAAC => no privacy extensions. yes, this was what they decided: that SLAAC would not work on their configuration and that if they were going to enable ipv6 in the future, it would probably be on the basis of dhcpv6, with no autoconfiguration. Nick From nobody Tue Sep 9 03:29:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C531A6FA9 for ; Tue, 9 Sep 2014 03:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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=-1.652, 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 eQBFm8fEiKiP for ; Tue, 9 Sep 2014 03:29:34 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5C31A0AE9 for ; Tue, 9 Sep 2014 03:29:34 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id l13so174612iga.3 for ; Tue, 09 Sep 2014 03:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JUqflFJAIk9SudFD6SgcrsofGdwLw8qJ8g1gs6wcaxo=; b=d5Jyrw+A14ZjTvt3WNS0WLYhFIZRQImpl0fGv/3k0mw9IsXOHrjKZkA1Q1SHwi84p5 mIOjl3psZa/bsQyIY9Z3OimIrqSlyvAiAytSrl4raBO/lWP2n2yXDQxJWmAOpcHiGPu4 zeNAw6eabgSIYuhaRcFKABHS1nO3QZJGy0Q7FRLC2hSI3ZiBPbEAMWeTBUDYJsNEJQiO C4CLQmqC7QPUcchFdXh6fAtwUtshFkUHwmkgbwQ7ofKowydaV8DuPcory79jjByK7OiX zCXxfPXQGwrhegVlIgwyHXYn7C2A2i3sJZVuraHd8YhOVYgkg4h1Yn7ocio8vP7Mtg2Z X1lg== 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=JUqflFJAIk9SudFD6SgcrsofGdwLw8qJ8g1gs6wcaxo=; b=KS/PftfxuOr3O0UvAaCGfWcicIxaORrn7dNBgIDb55KQJ7M8NUmVbdfPYPKBQBA1hU duRzaIR4ZXmq/f+SmSO+5Y/Dx84nKT4IxRmkEsa9TisgJMrAnB9N7ECTVzFOnRfAbNiS gRnAW0bpl4qCaSdBIkAEBHY/iO/ADuobEGJN6IzoUm69ERV7dGs+pOPqjeMYbFVLp7Gh lApLuQuQFaCNObi5M2+ISt+Cqe0an76et4/ZLDnjKO9UQN2Iy0sT3SQmBkyM5aKGoBtZ BmIlJmdBOcNxs3PC2pUlggHtr/hWkW9M+0ACLSsgz76ssGBtpVPFqImVqj46sJaxp17c hgpA== X-Gm-Message-State: ALoCoQnFZLUeadnWIFA6af4ov9cVjVJoc1tieFXoF33fsmQaPvRxamGKugqkduJwYf31pMclx3Ts X-Received: by 10.50.85.74 with SMTP id f10mr30999149igz.4.1410258573768; Tue, 09 Sep 2014 03:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Tue, 9 Sep 2014 03:29:13 -0700 (PDT) In-Reply-To: <540ECB9E.9000102@foobar.org> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> From: Lorenzo Colitti Date: Tue, 9 Sep 2014 19:29:13 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=089e0149bfa654ed4205029f697b Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AL2aN97Fd8GFsSezVBgnr5RDgGA Cc: "l.wood@surrey.ac.uk" , IPv6 Operations Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 10:29:36 -0000 --089e0149bfa654ed4205029f697b Content-Type: text/plain; charset=UTF-8 On Tue, Sep 9, 2014 at 6:42 PM, Nick Hilliard wrote: > This happened because the switch CPUs were overloaded with mld report > packets due to end hosts on the extended L2 network replying to MLD > all-groups queries every 150 seconds. > So the switch was configured to send all-groups queries to all hosts, but did not have the CPU power to process them, and could not, or was not configured, to rate-limit them. News at 11: building a network beyond the capabilities of the gear that runs it will result in failure. That does not mean the protocol is flawed. ARP could have done the same thing, and in fact that was a common problem many years ago... except that these days ARP is usually processed on the fast path and it doesn't matter. --089e0149bfa654ed4205029f697b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 9, 2014 at 6:42 PM, Nick Hilliard <nick@foobar.org> wr= ote:
This happened because the switch CPU= s were overloaded with mld report packets due to end hosts on the extended = L2 network replying to MLD all-groups queries every 150 seconds.

So the switch was configured to send all-groups q= ueries to all hosts, but did not have the CPU power to process them, and co= uld not, or was not configured, to rate-limit them.

News at 11: building a network beyond the capabilities of the gear that r= uns it will result in failure.

That does not mean = the protocol is flawed. ARP could have done the same thing, and in fact tha= t was a common problem many years ago... except that these days ARP is usua= lly processed on the fast path and it doesn't matter.
= --089e0149bfa654ed4205029f697b-- From nobody Tue Sep 9 03:43:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976681A6FBA for ; Tue, 9 Sep 2014 03:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 aDJ9lPsGPijK for ; Tue, 9 Sep 2014 03:43:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F731A6FB4 for ; Tue, 9 Sep 2014 03:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7628; q=dns/txt; s=iport; t=1410259390; x=1411468990; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=43fWF6dQgh5QeKy7fxGA22lnMQCjO/eC0tXMr/GqZNE=; b=LI3F2i0mAjkS4two/ID/hm46Jkqk21fQcGme7uDvrTY2j0jVT/dMixUA OgLaCHV0PC34uiievzW9N7kdHLxjjTLLUN0MNmIjyTuxanIXgMDfomBwr s7A6ndlH0PbSN19EDMc9TldazFoQ09Pe3mgmTa76mwn/zqed5XxAc5yfK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAJTYDlStJV2b/2dsb2JhbABZgkdGU1cEgnjOcgEZeRZ4hAMBAQEEIwpMEAIBCBEEAQELHQMCAgIwFAkIAgQBDQUIEogopjuVZgEXjnYJHTEGAYJ5NoEdBZFBoGCDYWyBB0GBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,491,1406592000"; d="scan'208,217";a="353738345" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 09 Sep 2014 10:43:09 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s89Ah8ZM002678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 10:43:08 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 05:43:08 -0500 From: "Hemant Singh (shemant)" To: Lorenzo Colitti , Nick Hilliard Thread-Topic: [v6ops] Interesting problems with using IPv6 Thread-Index: AQHPy7BYcufcLcCSE0CP+QdxqYnKUZv4XruAgACCkQCAAAzxgP//rUdQ Date: Tue, 9 Sep 2014 10:43:07 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.123] Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B89155AF364xmbrcdx06ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xiw4ga_xJDedI-4LWRSJw7b8dg4 Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 10:43:11 -0000 --_000_75B6FA9F576969419E42BECB86CB1B89155AF364xmbrcdx06ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkLiAgSnVzdCBiZWNhdXNlIG9uZSB2ZW5kb3LigJlzIHN3aXRjaCBtZWx0ZWQgYW4gaXB2 NiBuZXR3b3JrIGlzIG5vdCBlbm91Z2gganVzdGlmaWNhdGlvbiB0byBjaGFuZ2UgcHJvdG9jb2xz Lg0KDQpIZW1hbnQNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xpdHRpDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIg MDksIDIwMTQgNjoyOSBBTQ0KVG86IE5pY2sgSGlsbGlhcmQNCkNjOiBsLndvb2RAc3VycmV5LmFj LnVrOyBJUHY2IE9wZXJhdGlvbnMNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEludGVyZXN0aW5nIHBy b2JsZW1zIHdpdGggdXNpbmcgSVB2Ng0KDQpPbiBUdWUsIFNlcCA5LCAyMDE0IGF0IDY6NDIgUE0s IE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9yZzxtYWlsdG86bmlja0Bmb29iYXIub3JnPj4g d3JvdGU6DQpUaGlzIGhhcHBlbmVkIGJlY2F1c2UgdGhlIHN3aXRjaCBDUFVzIHdlcmUgb3Zlcmxv YWRlZCB3aXRoIG1sZCByZXBvcnQgcGFja2V0cyBkdWUgdG8gZW5kIGhvc3RzIG9uIHRoZSBleHRl bmRlZCBMMiBuZXR3b3JrIHJlcGx5aW5nIHRvIE1MRCBhbGwtZ3JvdXBzIHF1ZXJpZXMgZXZlcnkg MTUwIHNlY29uZHMuDQoNClNvIHRoZSBzd2l0Y2ggd2FzIGNvbmZpZ3VyZWQgdG8gc2VuZCBhbGwt Z3JvdXBzIHF1ZXJpZXMgdG8gYWxsIGhvc3RzLCBidXQgZGlkIG5vdCBoYXZlIHRoZSBDUFUgcG93 ZXIgdG8gcHJvY2VzcyB0aGVtLCBhbmQgY291bGQgbm90LCBvciB3YXMgbm90IGNvbmZpZ3VyZWQs IHRvIHJhdGUtbGltaXQgdGhlbS4NCg0KTmV3cyBhdCAxMTogYnVpbGRpbmcgYSBuZXR3b3JrIGJl eW9uZCB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBnZWFyIHRoYXQgcnVucyBpdCB3aWxsIHJlc3Vs dCBpbiBmYWlsdXJlLg0KDQpUaGF0IGRvZXMgbm90IG1lYW4gdGhlIHByb3RvY29sIGlzIGZsYXdl ZC4gQVJQIGNvdWxkIGhhdmUgZG9uZSB0aGUgc2FtZSB0aGluZywgYW5kIGluIGZhY3QgdGhhdCB3 YXMgYSBjb21tb24gcHJvYmxlbSBtYW55IHllYXJzIGFnby4uLiBleGNlcHQgdGhhdCB0aGVzZSBk YXlzIEFSUCBpcyB1c3VhbGx5IHByb2Nlc3NlZCBvbiB0aGUgZmFzdCBwYXRoIGFuZCBpdCBkb2Vz bid0IG1hdHRlci4NCg== --_000_75B6FA9F576969419E42BECB86CB1B89155AF364xmbrcdx06ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdyZWVkLiZuYnNwOyBK dXN0IGJlY2F1c2Ugb25lIHZlbmRvcuKAmXMgc3dpdGNoIG1lbHRlZCBhbiBpcHY2IG5ldHdvcmsg aXMgbm90IGVub3VnaCBqdXN0aWZpY2F0aW9uIHRvIGNoYW5nZSBwcm90b2NvbHMuJm5ic3A7Jm5i c3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhlbWFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgU2Vw dGVtYmVyIDA5LCAyMDE0IDY6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IE5pY2sgSGlsbGlhcmQ8YnI+ DQo8Yj5DYzo8L2I+IGwud29vZEBzdXJyZXkuYWMudWs7IElQdjYgT3BlcmF0aW9uczxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBJbnRlcmVzdGluZyBwcm9ibGVtcyB3aXRoIHVzaW5n IElQdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFR1ZSwgU2VwIDksIDIwMTQgYXQgNjo0MiBQTSwgTmljayBIaWxsaWFyZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5pY2tAZm9vYmFyLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5pY2tAZm9vYmFyLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBoYXBwZW5lZCBiZWNhdXNlIHRoZSBzd2l0Y2ggQ1BVcyB3ZXJlIG92ZXJsb2FkZWQgd2l0aCBt bGQgcmVwb3J0IHBhY2tldHMgZHVlIHRvIGVuZCBob3N0cyBvbiB0aGUgZXh0ZW5kZWQgTDIgbmV0 d29yayByZXBseWluZyB0byBNTEQgYWxsLWdyb3VwcyBxdWVyaWVzIGV2ZXJ5IDE1MCBzZWNvbmRz LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdGhlIHN3 aXRjaCB3YXMgY29uZmlndXJlZCB0byBzZW5kIGFsbC1ncm91cHMgcXVlcmllcyB0byBhbGwgaG9z dHMsIGJ1dCBkaWQgbm90IGhhdmUgdGhlIENQVSBwb3dlciB0byBwcm9jZXNzIHRoZW0sIGFuZCBj b3VsZCBub3QsIG9yIHdhcyBub3QgY29uZmlndXJlZCwgdG8gcmF0ZS1saW1pdCB0aGVtLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZXdzIGF0 IDExOiBidWlsZGluZyBhIG5ldHdvcmsgYmV5b25kIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIGdl YXIgdGhhdCBydW5zIGl0IHdpbGwgcmVzdWx0IGluIGZhaWx1cmUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgZG9lcyBub3QgbWVhbiB0 aGUgcHJvdG9jb2wgaXMgZmxhd2VkLiBBUlAgY291bGQgaGF2ZSBkb25lIHRoZSBzYW1lIHRoaW5n LCBhbmQgaW4gZmFjdCB0aGF0IHdhcyBhIGNvbW1vbiBwcm9ibGVtIG1hbnkgeWVhcnMgYWdvLi4u IGV4Y2VwdCB0aGF0IHRoZXNlIGRheXMgQVJQIGlzIHVzdWFsbHkgcHJvY2Vzc2VkIG9uIHRoZSBm YXN0IHBhdGggYW5kIGl0IGRvZXNuJ3QgbWF0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_75B6FA9F576969419E42BECB86CB1B89155AF364xmbrcdx06ciscoc_-- From nobody Tue Sep 9 05:54:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2B1A00D5 for ; Tue, 9 Sep 2014 05:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuPAFB02lfKX for ; Tue, 9 Sep 2014 05:54:33 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BAF1A0178 for ; Tue, 9 Sep 2014 05:54:33 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id w8so15371168qac.19 for ; Tue, 09 Sep 2014 05:54:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JNonOn9hRw/CCWD6PhDfIb/63QKXzsnf3PqAlw8s1PU=; b=QEunlQNR3CyVC7hOCjyK1liRTTd4JmarapFIfkiNZPmrYw2pt+c8gBDP7SW990nRRh JUm7JAqROgDoNi22NPlypkOs6qXk/uPjcmLeYlVaZ2dwY7vhvWB72YYSoLymre8635B8 N86KuLTqsgCtHzPrdNMpA14VQApeJpbR92mOFWK43k9697EBsE4rguBk4XMiisHYwfEa rBYziUGsnUG2hcqMsnaFv4NUp3++fNVlx4Es44NEm4I3Y3nPLIK20vqaozTGA+6UgjQR MsmarFRhjWYTuyvUpNTFcQTPEqH6M89tg6UTFavwB2hD5G/yz/NKQVReYaoQM9NF3rgC P7/w== X-Gm-Message-State: ALoCoQknvZtDR0V5rVO5fj73rJuuFdl0yFiZ2j3DHBKtXqF9c9fFiQ35qWcy2Pot4KAHZfM3yFQq X-Received: by 10.229.137.131 with SMTP id w3mr50373533qct.23.1410267272238; Tue, 09 Sep 2014 05:54:32 -0700 (PDT) Received: from Victors-MacBook-Pro.local ([2601:6:1f80:5b6:49f:6c34:e5ed:3254]) by mx.google.com with ESMTPSA id s4sm10225995qay.36.2014.09.09.05.54.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 05:54:31 -0700 (PDT) Message-ID: <540EF884.6000000@jvknet.com> Date: Tue, 09 Sep 2014 08:54:28 -0400 From: Victor Kuarsingh User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Philip Matthews References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7qzSe7eJpo81hf2Jo5j428ZRUFc Cc: v6ops list , Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.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, 09 Sep 2014 12:54:35 -0000 Mikael, The top portion of the text (in section 2.1.1) describes the concept of using two links or two Vlans to separate traffic. The option of separating IPv4 and IPv6 on links (logical or physical) is set as option (b). We have a brief discussion on the last paragraph on some reasons to choose this. Now before we action any changes, there is discussion in the last paragraph which talks about limitations on network equipment and device-specific limitations. If you don't feel that this text is sufficient, then which of the following approaches do you think would best get the point across. (1). Have a new paragraph(s) which highlight option (b) more and then provide a listing of pros/cons (where the pros can then point to items you wanted addressed) (2). Extend the last paragraph to list the issues you highlighted On that point, these issues will be arguably temporary and resolve over time, so if we did highlight issues as noted in the article you listed, we should also note that these problems are part of the maturing process (no?). regards, Victor K On 2014-09-09, 3:36 AM, Mikael Abrahamsson wrote: > On Thu, 4 Sep 2014, Philip Matthews wrote: > >> Thanks in advance for any comments, and sorry that we have been a bit >> slow in updating the draft. > > Hi, > > In 2.1.1, I'd like to see some text talking about methods where IPv4 > and IPv6 can be separated by means of protocol based vlans, so end > system complexity isn't increased, it's only a network change. This > way IPv4 and IPv6 can have different topology, so that IPv4 choices > don't have to affect IPv6 choices. In light of recent talk about IPv6 > multicast and privacy addressing causing problems in networks, we > should give guidance pointing to the problems of having very large L2 > domains. > > One article: > > http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ > > From nobody Tue Sep 9 05:55:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869D11A02D8 for ; Tue, 9 Sep 2014 05:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.166 X-Spam-Level: * X-Spam-Status: No, score=1.166 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_220=2.118, RP_MATCHES_RCVD=-1.652, 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 7GWCEEuuAlGA for ; Tue, 9 Sep 2014 05:55:14 -0700 (PDT) Received: from m15-10.126.com (m15-10.126.com [220.181.15.10]) by ietfa.amsl.com (Postfix) with ESMTP id 387DE1A0175 for ; Tue, 9 Sep 2014 05:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=yEjBY qGwsP9W/dtgqFR8EjQesbzR8pPrpmKFIsnDPnc=; b=Bi59CR7p22BE+Yup0ZPOd v9ogiQreG0V2W4U8dHuQdim1Iq1g/Xcx/BW0AX/+tuSmf9el3pc8rZPGbkal6S6H V6tFuNQD9+UGwwo+VorCZEKDhrA0iNARAch93oW3ocZs+Rxw6VnjedS1pl077WIe zLj75CaYiaQVi/p9bKmZjI= Received: from lilishan48$126.com ( [166.111.68.231] ) by ajax-webmail-wmsvr10 (Coremail) ; Tue, 9 Sep 2014 20:55:10 +0800 (CST) X-Originating-IP: [166.111.68.231] Date: Tue, 9 Sep 2014 20:55:10 +0800 (CST) From: lilishan48 To: fgont@si6networks.com X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140725(28226.6623) Copyright (c) 2002-2014 www.mailtech.cn 126com X-CM-CTRLDATA: ONHxy2Zvb3Rlcl9odG09MTQ2MDo4MQ== Content-Type: multipart/alternative; boundary="----=_Part_170192_1562405820.1410267310672" MIME-Version: 1.0 Message-ID: <5f55ee89.aada.1485a7b6a51.Coremail.lilishan48@126.com> X-CM-TRANSID: CsqowGCpi0Kv+A5UubgoAA--.19142W X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbi6xsCwU0vV+Y+8gACsu X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7w1MBIdXZdv64drQTnvwbZrze7Y Cc: v6ops@ietf.org Subject: Re: [v6ops] New I-D: IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 12:55:15 -0000 ------=_Part_170192_1562405820.1410267310672 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgIERlYXIgYWxsLApJJ3ZlIHJlYWQgdGhpcyBkb2N1bWVudCBhbmQg dGhpbmsgaXQgcHJvdmlkZXMgYSBnb29kIG92ZXJ2aWV3IG9mIHRoZQppbXBsaWNhdGlvbnMgb2Yg ZXh0ZW5zaW9uIGhlYWRlcnMsIGFuZCB0aGVpciBzaXR1YXRpb24gaW4gdGhlIEludGVybmV0LgpJ IGFncmVlIHdpdGggb3RoZXIgY29tbWVudHMgYWJvdXQgdGhlIGxhY2sgb2YgY2xhcml0eSBvZiB0 aGUgdGFibGVzIGluClNlY3Rpb24gNC4gWW91IG11c3QgY2xhcmlmeSB3aGF0IHRoZSBudW1iZXJz IGluIHRoaXMgdGFibGVzIG1lYW4uCgpTZWN0aW9uIDUuMiBtdXN0IGJlIGV4cGFuZGVkIHRvIGxp c3QgaW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbmFsCm1pdGlnYXRpb25zLgoKU2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyB0byBzaG9ydC4gUGxlYXNlIGV4cGFuZCBpdCBvciBt b3ZlCnRleHQgZnJvbSBvdGhlciBzZWN0aW9ucyBoZXJlLgpCZXN0IFJlZ2FyZHMsTGlzaGFuIExp Cgo= ------=_Part_170192_1562405820.1410267310672 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNztjb2xvcjojMDAw MDAwO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkFyaWFsIj48ZGl2PiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Rl YXIgYWxsLDwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhLCAnTWljcm9zb2Z0IFlhaGVpJywgdmVyZGFuYTsgbGluZS1oZWlnaHQ6IDIzLjMy NDAwMTMxMjI1NTg2cHg7Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JJ3ZlIHJlYWQgdGhpcyBk b2N1bWVudCBhbmQgdGhpbmsgaXQgcHJvdmlkZXMgYSBnb29kIG92ZXJ2aWV3IG9mIHRoZTxicj48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+aW1wbGljYXRpb25zIG9mIGV4dGVu c2lvbiBoZWFkZXJzLCBhbmQgdGhlaXIgc2l0dWF0aW9uIGluIHRoZSBJbnRlcm5ldC48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5JIGFncmVlIHdpdGggb3RoZXIgY29tbWVudHMgYWJvdXQgdGhlIGxhY2sg b2YgY2xhcml0eSBvZiB0aGUgdGFibGVzIGluPGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj5TZWN0aW9uIDQuIFlvdSBtdXN0IGNsYXJpZnkgd2hhdCB0aGUgbnVtYmVycyBp biB0aGlzIHRhYmxlcyBtZWFuLjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5TZWN0aW9uIDUuMiBt dXN0IGJlIGV4cGFuZGVkIHRvIGxpc3QgaW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbmFsPGJy PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5taXRpZ2F0aW9ucy48YnI+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+U2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyB0byBz aG9ydC4gUGxlYXNlIGV4cGFuZCBpdCBvciBtb3ZlPGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj50ZXh0IGZyb20gb3RoZXIgc2VjdGlvbnMgaGVyZS48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj5CZXN0IFJlZ2FyZHMsPC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pkxpc2hhbiBMaTwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PHByZSBzdHlsZT0ibGluZS1oZWln aHQ6IG5vcm1hbDsiPjxicj48L3ByZT48L2Rpdj48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJu ZXRlYXNlZm9vdGVyIj48c3BhbiBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bh bj4= ------=_Part_170192_1562405820.1410267310672-- From nobody Tue Sep 9 06:12:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138211A02E6 for ; Tue, 9 Sep 2014 06:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-1.652, 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 ZnzWde-iCpm2 for ; Tue, 9 Sep 2014 06:12:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F881A02E5 for ; Tue, 9 Sep 2014 06:12:23 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B3BECA3; Tue, 9 Sep 2014 15:12:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1410268340; bh=mUwhE5dMjxpPelt6XKUocUPVOjWRKFGtnrDgqvV91gg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VVusR0jMtJp/9Qmkd7yOvgrET1rU+bppD8L98Hi39OTpgyuXJnqFssVqDefukK1fE WoE3XvlSHTeivzPHPLvYRtAMf21nUWX7JLEY7WQhPkOn96265vGD9+yxwjj8v3Fk9Q 5Fv0c+5JAls8V/iGj1xvi/Y5cRxSjuuuLUdvRk+o= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AF12EA2; Tue, 9 Sep 2014 15:12:20 +0200 (CEST) Date: Tue, 9 Sep 2014 15:12:20 +0200 (CEST) From: Mikael Abrahamsson To: Victor Kuarsingh In-Reply-To: <540EF884.6000000@jvknet.com> Message-ID: References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> <540EF884.6000000@jvknet.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kvG_ahVJsXWq8qJWgUIlyFbOYFA Cc: v6ops list , Victor Kuarsingh , Philip Matthews Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.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, 09 Sep 2014 13:12:27 -0000 On Tue, 9 Sep 2014, Victor Kuarsingh wrote: > Mikael, > > The top portion of the text (in section 2.1.1) describes the concept of using > two links or two Vlans to separate traffic. Well, from end system point of view, it's a single vlan, it doesn't need to understand the two vlans. So this is somewhat of in-between. > The option of separating IPv4 and IPv6 on links (logical or physical) is set > as option (b). We have a brief discussion on the last paragraph on some > reasons to choose this. Now before we action any changes, there is > discussion in the last paragraph which talks about limitations on network > equipment and device-specific limitations. > > If you don't feel that this text is sufficient, then which of the following > approaches do you think would best get the point across. > > (1). Have a new paragraph(s) which highlight option (b) more and then > provide a listing of pros/cons (where the pros can then point to items you > wanted addressed) I think this is the approach I would prefer. Try to give examples how it can be done and pros and cons so the implementor can make an informed choice. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 9 06:42:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFDB1A02F4 for ; Tue, 9 Sep 2014 06:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcPHbQaHfAww for ; Tue, 9 Sep 2014 06:42:03 -0700 (PDT) Received: from mail-05.primus.ca (smtp3.primus.ca [209.216.129.203]) by ietfa.amsl.com (Postfix) with ESMTP id A60AB1A02ED for ; Tue, 9 Sep 2014 06:42:03 -0700 (PDT) Received: from [24.114.79.95] (helo=[172.20.10.4]) by mail-05.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1XRLgG-0002FC-1u; Tue, 09 Sep 2014 09:42:01 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Tue, 9 Sep 2014 09:41:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E1FE8BF-8187-4655-8BE8-160348A49635@magma.ca> References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> <540EF884.6000000@jvknet.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.79.95] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9bQS2MX248uYX7uhHGCPF6SHsBo Cc: v6ops list , Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.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, 09 Sep 2014 13:42:05 -0000 Mikael: I agree that the discussion of option (b) in section 2.1.1 could be = improved. It would be helpful if you could send some points that you would like = included. We can then draft something and sent it out. Philip On 2014-09-09, at 9:12 , Mikael Abrahamsson wrote: > On Tue, 9 Sep 2014, Victor Kuarsingh wrote: >=20 >> Mikael, >>=20 >> The top portion of the text (in section 2.1.1) describes the concept = of using two links or two Vlans to separate traffic. >=20 > Well, from end system point of view, it's a single vlan, it doesn't = need to understand the two vlans. So this is somewhat of in-between. >=20 >> The option of separating IPv4 and IPv6 on links (logical or physical) = is set as option (b). We have a brief discussion on the last paragraph = on some reasons to choose this. Now before we action any changes, there = is discussion in the last paragraph which talks about limitations on = network equipment and device-specific limitations. >>=20 >> If you don't feel that this text is sufficient, then which of the = following approaches do you think would best get the point across. >>=20 >> (1). Have a new paragraph(s) which highlight option (b) more and = then provide a listing of pros/cons (where the pros can then point to = items you wanted addressed) >=20 > I think this is the approach I would prefer. Try to give examples how = it can be done and pros and cons so the implementor can make an informed = choice. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 From nobody Tue Sep 9 07:22:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5A1A0B77 for ; Tue, 9 Sep 2014 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.553 X-Spam-Level: X-Spam-Status: No, score=-4.553 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvEtyoJ_G4ct for ; Tue, 9 Sep 2014 07:22:31 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id F07B61A0BEA for ; Tue, 9 Sep 2014 07:22:30 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.9/8.14.9) with ESMTP id s89EMTvU021188 for ; Tue, 9 Sep 2014 10:22:29 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU s89EMTvU021188 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1410272549; bh=KytXWspYOE1CVyGGr6xSUpTch9ZhzIW+auG/fQEpJbo=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=Bo4R6JknPNOIglb1Gz+xJyr1g4XAwXBWvRXPOmpPhxpDq2ZrdxBOiITz8C4cackAc K69xUd0WsGGZUAEgqfSf+3x/fqqUZQcYAKtl5VL5T9zGoPbv0QKMvVzApmsuQcuctQ Owcu/3DkOa6alwacPL4TQ5UW5fP0JUZ9TWCqnrag= Received: from MX3.WPI.EDU (mx3.wpi.edu [130.215.36.147]) by MAIL1.WPI.EDU (8.14.9/8.14.9) with ESMTP id s89EMTWK021184 for ; Tue, 9 Sep 2014 10:22:29 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by MX3.WPI.EDU (8.14.4/8.14.4) with ESMTP id s89EMSJQ021753 for ; Tue, 9 Sep 2014 10:22:29 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id s89EMSdG014418 for ; Tue, 9 Sep 2014 10:22:28 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id s89EMR8Q014416 for v6ops@ietf.org; Tue, 9 Sep 2014 10:22:27 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Tue, 9 Sep 2014 10:22:27 -0400 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20140909142226.GP15839@angus.ind.WPI.EDU> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> User-Agent: Mutt/1.5.20 (2009-12-10) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vTcPkf0z0q8pqJPFhxpVZvhmOrU Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 14:22:33 -0000 Disagree. In common practice, ARP doesn't need to scale to hundreds of IPv4 addresses per host. Unforutnately, IPv6 SLAAC with Privacy Addressing means that ND and hence MLD does need to scale much larger than ARP ever did. The cure of using Solicited Node multicast for ND is worse than the disease of using broadcast for ARP. It is not reasonable to expect a switch to scale to maintaining state for 300 * (# of hosts connected) Solicited-Node multicast groups. 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable. 90,000 MLD groups for a 300 port switch stack is also unreasonable. Most switches cannot handle that many IPv4 multicast groups--expecting them to handle that many IPv6 multicast groups is unreasonable. How many MLD reports per second have to be processed by the switch CPU given reports every 150 seconds by each of the many Solicited Node multicast groups on every connected host? 100 pps? 600 pps? What are the scaling numbers for IGMP groups and MLD groups and how many IGMP/MLD reports can be processed per second on commonly available access-layer switches? Having designed a ubiquitous protocol 16 years ago that can't be implemented reasonably cheaply on current hardware is an operational problem that can and should be dealt with by tweaking the protocol in some cases. I think the protocol change proposals put forward in the article are a quite reasonable starting point for discussing how to mitigate this issue and shouldn't be dismissed out of hand. On Tue, Sep 09, 2014 at 10:43:07AM +0000, Hemant Singh (shemant) wrote: > Agreed. Just because one vendor’s switch melted an ipv6 network is not enough justification to change protocols. > > Hemant > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti > Sent: Tuesday, September 09, 2014 6:29 AM > To: Nick Hilliard > Cc: l.wood@surrey.ac.uk; IPv6 Operations > Subject: Re: [v6ops] Interesting problems with using IPv6 > > On Tue, Sep 9, 2014 at 6:42 PM, Nick Hilliard > wrote: > This happened because the switch CPUs were overloaded with mld report packets due to end hosts on the extended L2 network replying to MLD all-groups queries every 150 seconds. > > So the switch was configured to send all-groups queries to all hosts, but did not have the CPU power to process them, and could not, or was not configured, to rate-limit them. > > News at 11: building a network beyond the capabilities of the gear that runs it will result in failure. > > That does not mean the protocol is flawed. ARP could have done the same thing, and in fact that was a common problem many years ago... except that these days ARP is usually processed on the fast path and it doesn't matter. From nobody Tue Sep 9 07:29:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FF21A03F5 for ; Tue, 9 Sep 2014 07:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Woj5FRd88J7l for ; Tue, 9 Sep 2014 07:29:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2681A02EC for ; Tue, 9 Sep 2014 07:29:28 -0700 (PDT) Received: from [2001:5c0:1000:a::1423] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XRMQ5-0004yp-W0; Tue, 09 Sep 2014 16:29:22 +0200 Message-ID: <540F0BCF.1060905@gont.com.ar> Date: Tue, 09 Sep 2014 11:16:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Brian E Carpenter References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> In-Reply-To: <540EAA55.7000207@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0rlYo8Y70KBWg2E_L8X1SOzljno Cc: IPv6 Operations , l.wood@surrey.ac.uk Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 14:29:30 -0000 On 09/09/2014 04:20 AM, Brian E Carpenter wrote: >>> OK, but I would also like to understand why we require >>> MLD messages for a Solicited-Node multicast address to >>> set Router Alert. >> >> Because in theory the multicast router needs to process the MLD message >> to build its forwarding table.... > > Why, for the Solicited-Node group, which is only meaningful on the link > from which the MLD message arrives? Then, let me change the question: Why do I need MLD for *this*? We probably use MLD because "If you use multicast, you use MLD". Truth is that, *unless your switch does MLD snooping* (and hence you *need* MLD, or else your packets will not flow around), you could completely kill MLD, and ND would still work just fine. Not to mention that there are nodes that default t running MLDv2 *for this* (way overkill, IMO) 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 nobody Tue Sep 9 07:38:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086ED1A6F9D for ; Tue, 9 Sep 2014 07:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 5B_4VsKQX6-I for ; Tue, 9 Sep 2014 07:38:42 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8701A0AE9 for ; Tue, 9 Sep 2014 07:38:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s89EcfkN031677; Tue, 9 Sep 2014 09:38:41 -0500 Received: from XCH-BLV-202.nw.nos.boeing.com (xch-blv-202.nw.nos.boeing.com [10.57.37.69]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s89EcVJx031427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 9 Sep 2014 09:38:32 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-202.nw.nos.boeing.com ([169.254.2.206]) with mapi id 14.03.0181.006; Tue, 9 Sep 2014 07:38:30 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson , Tom Perrine Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPzAOas1qEEvpydkaz7jvT8FP9mpv43h1Q Date: Tue, 9 Sep 2014 14:38:29 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D12EED@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6Tq_jvWg6o3UP43mSm0ynMOz074 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 14:38:45 -0000 Hi Mikael, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamss= on > Sent: Tuesday, September 09, 2014 12:57 AM > To: Tom Perrine > Cc: v6ops@ietf.org > Subject: Re: [v6ops] PMTUD issue discussion >=20 > On Tue, 2 Sep 2014, Tom Perrine wrote: >=20 > > What MTUs are actually (commonly) seen in the wild? >=20 > My reply is late, but let me write some of my experience as I did some > investigation into what's possible. All values presented here are IP MTU, > not L2 MTU. Most people mix these values and I've seen a lot of broken > deployments due to this. >=20 > The major end system IP MTU seen in the world is 1500 (huge majority). Right; the vast majority of end systems currently see 1500. > The path MTUs seen might be slightly under due to PPPoE, GRE, GTP etc > encapsulations on the access layer. Which can be problematic when PMTUD is not functioning correctly.=20 > Going larger than this (speaking both of path MTU and end system MTUs), > most opt for 4470, 9000 or 9180 due to older protocols such as AAL5 ATM, > SMDS, FDDI, POS etc. Unfortunately Juniper MX doesn't support 9180, but > instead one has to choose one value of 9178, 9174 or 9170 depending on > number of vlan tags (or MPLS labels I guess) one wants to support, so > these are also seen. >=20 > Personally I think the balanced approach would be to make your core > support something around the 9180 figure, Fully support the core going to larger MTUs. > and give 9000 to end users. This could be problematic when PMTUD is not functioning correctly. As a result, IMHO any end system that wants to try for packet sizes larger than 1500 really should be using RFC4821 (maybe even MUST?). Thanks - Fred fred.l.templin@boeing.com > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 9 08:07:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5442D1A6FE9 for ; Tue, 9 Sep 2014 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 7BHnxlicSZ80 for ; Tue, 9 Sep 2014 08:07:46 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D8B1A6FD0 for ; Tue, 9 Sep 2014 08:07:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F091EA3; Tue, 9 Sep 2014 17:07:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1410275263; bh=BpvkCeCsBXQPKCDnjlwoZ7pKi+r1uyD8hr8xLTjhUUQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=o3l17jSLq9PVoif6f6zvKeM8RONlM/XtXFoVb2m4Y4ExZdie5kZhUNUi4vt7rsJDV 6v4tBN1fAbI9iKqAm5/Epy/IM051EhRk5UGkZtOa5pbgRN5Yn0yQoO405ut3nM5r1h cqffGbNfgovTGDD0FCEoe6cY6HqjfsMMCuO4gVCg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id ED9F9A2; Tue, 9 Sep 2014 17:07:43 +0200 (CEST) Date: Tue, 9 Sep 2014 17:07:43 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D9831832D12EED@XCH-BLV-504.nw.nos.boeing.com> Message-ID: References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <2134F8430051B64F815C691A62D9831832D12EED@XCH-BLV-504.nw.nos.boeing.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bpdh7-mpaf1JMpcPP2sR1qSramc Cc: "v6ops@ietf.org" , Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 15:07:50 -0000 On Tue, 9 Sep 2014, Templin, Fred L wrote: > This could be problematic when PMTUD is not functioning correctly. As a > result, IMHO any end system that wants to try for packet sizes larger > than 1500 really should be using RFC4821 (maybe even MUST?). Well, even that might not solve it as there might be devices along the path that re-assemble the packets (if they're fragmented) and then fragment them again, which will break things anyway. But yes, supporting 4821 or PMTUD blackhole detection should definitely be a requirement. One problem is that a lot of people don't even know that sending a 16k UDP packet fragmented into a bunch of smaller fragments, is a perfectly valid use of IP. They're so used to TCP and its MSS that this is all they've seen. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 9 08:17:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF31A6FEC for ; Tue, 9 Sep 2014 08:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 C6YNdOX4Kckh for ; Tue, 9 Sep 2014 08:17:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B17F1A6FEE for ; Tue, 9 Sep 2014 08:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5314; q=dns/txt; s=iport; t=1410275844; x=1411485444; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ssnmWaPbNn1a8XSsuxKJyzUK/YWBrxYqkHM5cabCwVw=; b=P+v/Vkl6kAJthrNdVNtKr9hEBbtY/8LoN8o8BW3qnIRC8P4E1JKuQxff Yr/sasnPoZsgmTPTikgJSo5JW7UxADpPMoW0YLdUHuXZXjBSnlYS93EVm VzupW+QEZi4u0ejMZDfDTWR1jEtDjTf95TSeHicTYOD3rqju3vA8p9+GL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAAYZD1StJV2Q/2dsb2JhbABZDoJ/U1cEgnjHJQqHTAEZdBZ4hAMBAQEEAQEBIBE6FwQCAQgOAwQBAQECAgYdAwICAiULFAEICAIEARIIEogoDaZ6lWoBEwSBLI1KCR0WIgaCczaBHQWRQaBggx9CbIEHQYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,491,1406592000"; d="scan'208";a="76321072" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 09 Sep 2014 15:17:23 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s89FHMOt003567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 15:17:22 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 10:17:22 -0500 From: "Hemant Singh (shemant)" To: Chuck Anderson , "v6ops@ietf.org" Thread-Topic: [v6ops] Interesting problems with using IPv6 Thread-Index: AQHPy7BYcufcLcCSE0CP+QdxqYnKUZv4XruAgACCkQCAAAzxgP//rUdQgACT44D//7fXgA== Date: Tue, 9 Sep 2014 15:17:22 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89155AF75A@xmb-rcd-x06.cisco.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> In-Reply-To: <20140909142226.GP15839@angus.ind.WPI.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/msU6CoiwlEI3GrqY-PMGbE1KP_o Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 15:17:33 -0000 VGhlcmUgYXJlIHNldmVyYWwgbWl0aWdhdGlvbnMgdGhhdCBleGlzdC4gIA0KDQphLiBUaGUgc3dp dGNoIHNob3VsZCBoYXZlIGJlZW4gZGVzaWduZWQgZm9yIHJhdGUtbGltaXRpbmcgYmV5b25kIGEg Y2VydGFpbiBudW1iZXIgb2YgTUxEIHJlcG9ydHMvc2VjLiAgDQpiLiBVc2UgREhDUHY2IGluIHRo ZSBuZXR3b3JrIHRvIGRpc3BlbnNlIHdpdGggcHJpdmFjeSBhZGRyZXNzZXMgYW5kIFNMQUFDLiAg DQpjLiBBUlAgY291bGQgYmUgcHJvY2Vzc2VkIGluIHRoZSBmYXN0cGF0aCBiZWNhdXNlIEFSUCB1 c2VzIGEgZGlmZmVyZW50IGV0aGVydHlwZSB0aGFuIHRoZSBJUCBwYWNrZXQuICBUaGUgZGlmZmVy ZW50IGV0aGVydHlwZSBtYWRlIHRoZSBmYXN0cGF0aCBmaWx0ZXIgQVJQIHBrdHMgd2l0aCByZWxh dGl2ZSBlYXNlLiAgT25lIGNvdWxkIGNvbnNpZGVyIGRlZmluaW5nIGEgbmV3IGV0aGVydHlwZSBm b3IgSVB2NiBORCBhbmQgb3IgTUxEIGFuZCBsb29rIGludG8gbW92aW5nIGNlcnRhaW4gSVB2NiBw cm9jZXNzaW5nIHRvIHRoZSBmYXN0cGF0aC4NCg0KSSBkbyBhZ3JlZSB0aGF0IGEgNDgtcG9ydCBz d2l0Y2ggc2hvdWxkIG5vdCBoYXZlIHRvIGRlYWwgd2l0aCAxNWsgTUxEIGdyb3Vwcy4gIE5EIHVz ZXMgbXVsdGljYXN0IGFuZCBtdWx0aWNhc3QgdXNlcyBNTEQuICBDaGFuZ2luZyBtdWx0aWNhc3Qg YW5kL29yIE5EIG5lZWRzIG1vcmUgZGlzY3Vzc2lvbi4gIA0KDQpIZW1hbnQNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIENodWNrIEFuZGVyc29uDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1i ZXIgMDksIDIwMTQgMTA6MjIgQU0NClRvOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2 Nm9wc10gSW50ZXJlc3RpbmcgcHJvYmxlbXMgd2l0aCB1c2luZyBJUHY2DQoNCkRpc2FncmVlLiAg DQoNCkluIGNvbW1vbiBwcmFjdGljZSwgQVJQIGRvZXNuJ3QgbmVlZCB0byBzY2FsZSB0byBodW5k cmVkcyBvZiBJUHY0IGFkZHJlc3NlcyBwZXIgaG9zdC4gIFVuZm9ydXRuYXRlbHksIElQdjYgU0xB QUMgd2l0aCBQcml2YWN5IEFkZHJlc3NpbmcgbWVhbnMgdGhhdCBORCBhbmQgaGVuY2UgTUxEIGRv ZXMgbmVlZCB0byBzY2FsZSBtdWNoIGxhcmdlciB0aGFuIEFSUCBldmVyIGRpZC4gIFRoZSBjdXJl IG9mIHVzaW5nIFNvbGljaXRlZCBOb2RlIG11bHRpY2FzdCBmb3IgTkQgaXMgd29yc2UgdGhhbiB0 aGUgZGlzZWFzZSBvZiB1c2luZyBicm9hZGNhc3QgZm9yIEFSUC4NCg0KSXQgaXMgbm90IHJlYXNv bmFibGUgdG8gZXhwZWN0IGEgc3dpdGNoIHRvIHNjYWxlIHRvIG1haW50YWluaW5nIHN0YXRlIGZv ciAzMDAgKiAoIyBvZiBob3N0cyBjb25uZWN0ZWQpIFNvbGljaXRlZC1Ob2RlIG11bHRpY2FzdCBn cm91cHMuDQoxNSwwMDAgTUxEIGdyb3VwcyBmb3IgNDggaG9zdHMgb24gYSA0OCBwb3J0IHN3aXRj aCBpcyB1bnJlYXNvbmFibGUuDQo5MCwwMDAgTUxEIGdyb3VwcyBmb3IgYSAzMDAgcG9ydCBzd2l0 Y2ggc3RhY2sgaXMgYWxzbyB1bnJlYXNvbmFibGUuDQpNb3N0IHN3aXRjaGVzIGNhbm5vdCBoYW5k bGUgdGhhdCBtYW55IElQdjQgbXVsdGljYXN0IGdyb3Vwcy0tZXhwZWN0aW5nIHRoZW0gdG8gaGFu ZGxlIHRoYXQgbWFueSBJUHY2IG11bHRpY2FzdCBncm91cHMgaXMgdW5yZWFzb25hYmxlLg0KDQpI b3cgbWFueSBNTEQgcmVwb3J0cyBwZXIgc2Vjb25kIGhhdmUgdG8gYmUgcHJvY2Vzc2VkIGJ5IHRo ZSBzd2l0Y2ggQ1BVIGdpdmVuIHJlcG9ydHMgZXZlcnkgMTUwIHNlY29uZHMgYnkgZWFjaCBvZiB0 aGUgbWFueSBTb2xpY2l0ZWQgTm9kZSBtdWx0aWNhc3QgZ3JvdXBzIG9uIGV2ZXJ5IGNvbm5lY3Rl ZCBob3N0PyAgMTAwIHBwcz8gIDYwMCBwcHM/DQoNCldoYXQgYXJlIHRoZSBzY2FsaW5nIG51bWJl cnMgZm9yIElHTVAgZ3JvdXBzIGFuZCBNTEQgZ3JvdXBzIGFuZCBob3cgbWFueSBJR01QL01MRCBy ZXBvcnRzIGNhbiBiZSBwcm9jZXNzZWQgcGVyIHNlY29uZCBvbiBjb21tb25seSBhdmFpbGFibGUg YWNjZXNzLWxheWVyIHN3aXRjaGVzPw0KDQpIYXZpbmcgZGVzaWduZWQgYSB1YmlxdWl0b3VzIHBy b3RvY29sIDE2IHllYXJzIGFnbyB0aGF0IGNhbid0IGJlIGltcGxlbWVudGVkIHJlYXNvbmFibHkg Y2hlYXBseSBvbiBjdXJyZW50IGhhcmR3YXJlIGlzIGFuIG9wZXJhdGlvbmFsIHByb2JsZW0gdGhh dCBjYW4gYW5kIHNob3VsZCBiZSBkZWFsdCB3aXRoIGJ5IHR3ZWFraW5nIHRoZSBwcm90b2NvbCBp biBzb21lIGNhc2VzLiAgSSB0aGluayB0aGUgcHJvdG9jb2wgY2hhbmdlIHByb3Bvc2FscyBwdXQg Zm9yd2FyZCBpbiB0aGUgYXJ0aWNsZSBhcmUgYSBxdWl0ZSByZWFzb25hYmxlIHN0YXJ0aW5nIHBv aW50IGZvciBkaXNjdXNzaW5nIGhvdyB0byBtaXRpZ2F0ZSB0aGlzIGlzc3VlIGFuZCBzaG91bGRu J3QgYmUgZGlzbWlzc2VkIG91dCBvZiBoYW5kLg0KDQpPbiBUdWUsIFNlcCAwOSwgMjAxNCBhdCAx MDo0MzowN0FNICswMDAwLCBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpIHdyb3RlOg0KPiBBZ3JlZWQu ICBKdXN0IGJlY2F1c2Ugb25lIHZlbmRvcuKAmXMgc3dpdGNoIG1lbHRlZCBhbiBpcHY2IG5ldHdv cmsgaXMgbm90IGVub3VnaCBqdXN0aWZpY2F0aW9uIHRvIGNoYW5nZSBwcm90b2NvbHMuDQo+IA0K PiBIZW1hbnQNCj4gDQo+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIExvcmVuem8gDQo+IENvbGl0dGkNCj4gU2VudDogVHVlc2RheSwgU2Vw dGVtYmVyIDA5LCAyMDE0IDY6MjkgQU0NCj4gVG86IE5pY2sgSGlsbGlhcmQNCj4gQ2M6IGwud29v ZEBzdXJyZXkuYWMudWs7IElQdjYgT3BlcmF0aW9ucw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJ bnRlcmVzdGluZyBwcm9ibGVtcyB3aXRoIHVzaW5nIElQdjYNCj4gDQo+IE9uIFR1ZSwgU2VwIDks IDIwMTQgYXQgNjo0MiBQTSwgTmljayBIaWxsaWFyZCA8bmlja0Bmb29iYXIub3JnPG1haWx0bzpu aWNrQGZvb2Jhci5vcmc+PiB3cm90ZToNCj4gVGhpcyBoYXBwZW5lZCBiZWNhdXNlIHRoZSBzd2l0 Y2ggQ1BVcyB3ZXJlIG92ZXJsb2FkZWQgd2l0aCBtbGQgcmVwb3J0IHBhY2tldHMgZHVlIHRvIGVu ZCBob3N0cyBvbiB0aGUgZXh0ZW5kZWQgTDIgbmV0d29yayByZXBseWluZyB0byBNTEQgYWxsLWdy b3VwcyBxdWVyaWVzIGV2ZXJ5IDE1MCBzZWNvbmRzLg0KPiANCj4gU28gdGhlIHN3aXRjaCB3YXMg Y29uZmlndXJlZCB0byBzZW5kIGFsbC1ncm91cHMgcXVlcmllcyB0byBhbGwgaG9zdHMsIGJ1dCBk aWQgbm90IGhhdmUgdGhlIENQVSBwb3dlciB0byBwcm9jZXNzIHRoZW0sIGFuZCBjb3VsZCBub3Qs IG9yIHdhcyBub3QgY29uZmlndXJlZCwgdG8gcmF0ZS1saW1pdCB0aGVtLg0KPiANCj4gTmV3cyBh dCAxMTogYnVpbGRpbmcgYSBuZXR3b3JrIGJleW9uZCB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBn ZWFyIHRoYXQgcnVucyBpdCB3aWxsIHJlc3VsdCBpbiBmYWlsdXJlLg0KPiANCj4gVGhhdCBkb2Vz IG5vdCBtZWFuIHRoZSBwcm90b2NvbCBpcyBmbGF3ZWQuIEFSUCBjb3VsZCBoYXZlIGRvbmUgdGhl IHNhbWUgdGhpbmcsIGFuZCBpbiBmYWN0IHRoYXQgd2FzIGEgY29tbW9uIHByb2JsZW0gbWFueSB5 ZWFycyBhZ28uLi4gZXhjZXB0IHRoYXQgdGhlc2UgZGF5cyBBUlAgaXMgdXN1YWxseSBwcm9jZXNz ZWQgb24gdGhlIGZhc3QgcGF0aCBhbmQgaXQgZG9lc24ndCBtYXR0ZXIuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QN CnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo= From nobody Tue Sep 9 08:41:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC5F1A6FE3 for ; Tue, 9 Sep 2014 08:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tarL8cofSaHa for ; Tue, 9 Sep 2014 08:41:40 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12AD1A6FD8 for ; Tue, 9 Sep 2014 08:41:40 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id hn18so4757886igb.5 for ; Tue, 09 Sep 2014 08:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T1KIjXAkOhyTcC3C/Mx4Qa9o3JWQjOV5YX54ecR7gdo=; b=Sl40mHXJf9oWNisS5DUAenfivIzqgd+sLZmTf7KTn06eeKr+JB/GcPgw2EZFYRCOMr Q4tLPhfkV9MPXPSLS+lFduX9Ezt6dvM333615RQy65AMgsdZnvjD0xH7zjkRMN0bfjDb J8XdjTrLJMjDy+r1L39XH9zYOVytIpR1rYVJ1NAFH/+tV36dOj1Jzm402fJjm5hDb1D3 kxMWmONy+qamb0EOG6+/Hocq9OvXcbBye6CfxKgbCBw2vdtFinw8ouApv3dsZ4LIL3Kx bEjDS28Q4dekfeFLqnDdbQxOmfzxRbl8ZKhvNGW3Gs7NENiL281yXu9rud474qesox1Z NlYg== MIME-Version: 1.0 X-Received: by 10.50.56.38 with SMTP id x6mr32679729igp.30.1410277299832; Tue, 09 Sep 2014 08:41:39 -0700 (PDT) Received: by 10.107.137.39 with HTTP; Tue, 9 Sep 2014 08:41:39 -0700 (PDT) In-Reply-To: <20140909142226.GP15839@angus.ind.WPI.EDU> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> Date: Tue, 9 Sep 2014 17:41:39 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Chuck Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/smxo8VKMg-HfN3hNiOW9xUZAZPM Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 15:41:42 -0000 On 9/9/14, Chuck Anderson wrote: > Disagree. > > In common practice, ARP doesn't need to scale to hundreds of IPv4 > addresses per host. Unforutnately, IPv6 SLAAC with Privacy Addressing > means that ND and hence MLD does need to scale much larger than ARP > ever did. The cure of using Solicited Node multicast for ND is worse > than the disease of using broadcast for ARP. > > It is not reasonable to expect a switch to scale to maintaining state > for 300 * (# of hosts connected) Solicited-Node multicast groups. > 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable. > 90,000 MLD groups for a 300 port switch stack is also unreasonable. Not delving into the whole "why in today-scale network we need to maintain separate groups per each solicited multicast" argument, let's just assume there are some noticeable gains there and focus on the number of groups. 1) http://tools.ietf.org/html/rfc4941#section-3.3 says: 1. Process the Prefix Information Option as defined in [ADDRCONF], either creating a new public address or adjusting the lifetimes of existing addresses, both public and temporary. If a received option will extend the lifetime of a public address, the lifetimes of temporary addresses should be extended, subject to the overall constraint that no temporary addresses should ever remain "valid" or "preferred" for a time longer than (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), respectively. The configuration variables TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to approximate target lifetimes for temporary addresses. One way to interpret this text is that with the defaults, a host with SLAAC and temporary addresses will have: 1 LL + 1 SLAAC + 7 temp addresses = 9. This gives 1.5 order of magnitude less groups than in the example you cite - a not terribly unreasonable number, though it's still a 9x amount. The TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME are host-coded, the network (for better or worse) appears to have not much say about them. 2) The "300 addresses" situation might look like either the defaults were changed, or the stack is being "helpful" as described in http://tools.ietf.org/html/rfc4941#section-6: An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). This is in contrast to current approaches where addresses are removed from an interface when they become invalid [ADDRCONF], independent of whether or not upper layer protocols are still using them. For TCP connections, such information is available in control blocks. For UDP-based applications, it may be the case that only the applications have knowledge about what addresses are actually in use. Consequently, an implementation generally will need to use heuristics in deciding when an address is no longer in use. Would this mean the host has a connection that is lasting 300 days and is using the same temporary address ? This does not look too temporary, so arguably that application should not be using temporary addresses (Also: interesting that e.g. Linux limits the default # to 16 - cf.: http://oss.sgi.com/archives/netdev/2004-01/msg01002.html which is still true in the Ubuntu 14.04.) BTW, talking about the applications, they should be able to select whether they need the temporary addresses or not: rfc5014. Do they intentionally select the temporary addresses on the long-lasting connections ? Now, let me argue with myself: 1) IPv6 requiring 9x time the IPv4 addresses is still quite a stretch. If someone needs a long-lasting session, they should use a stable address. 2) Does application have a way to say "I do not want temporary addresses" ? (cf: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756) Seems not today ? 3) Also, http://tools.ietf.org/html/rfc4941#section-3.6 clearly says: " In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions. Individual applications, which have specific knowledge about the normal duration of connections, MAY override this as appropriate." So, if the hosts were gentle with the number of addresses they try to use, apps with long-lasting connections were to disable the temporary addresses and the server fleet had the temporary addresses disabled altogether, SLAAC (and, where appropriate, temporary addresses) would not be so bad at all. Of course, the amount of manual work this requires today means that the A-bit is turned off and the DHCPv6 is being used. Which may be perfectly okay - but if it is not, and we do assert that "An RA with prefix having an A-bit set and default settings, should not cause the 10x expansion to the resource requirements compared to Legacy IP", seems like some sort of a correction in default stacks/apps behavior with respect to temporary addresses could be useful. --a From nobody Tue Sep 9 08:46:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298181A6FF2 for ; Tue, 9 Sep 2014 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 rYgC7tRsLJVJ for ; Tue, 9 Sep 2014 08:46:04 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA581A6FD8 for ; Tue, 9 Sep 2014 08:46:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s89Fk40J014054; Tue, 9 Sep 2014 08:46:04 -0700 Received: from XCH-BLV-403.nw.nos.boeing.com (xch-blv-403.nw.nos.boeing.com [130.247.25.62]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s89FjtZf013452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 9 Sep 2014 08:45:56 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.144]) with mapi id 14.03.0181.006; Tue, 9 Sep 2014 08:45:55 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPzAOas1qEEvpydkaz7jvT8FP9mpv43h1QgAB+0ID//5L4IA== Date: Tue, 9 Sep 2014 15:45:55 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D13130@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <2134F8430051B64F815C691A62D9831832D12EED@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MhpSqwo7rH4LUSrvQ_NnqK5qwyc Cc: "v6ops@ietf.org" , Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 15:46:11 -0000 Hi Mikael, > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, September 09, 2014 8:08 AM > To: Templin, Fred L > Cc: Tom Perrine; v6ops@ietf.org > Subject: RE: [v6ops] PMTUD issue discussion >=20 > On Tue, 9 Sep 2014, Templin, Fred L wrote: >=20 > > This could be problematic when PMTUD is not functioning correctly. As a > > result, IMHO any end system that wants to try for packet sizes larger > > than 1500 really should be using RFC4821 (maybe even MUST?). >=20 > Well, even that might not solve it as there might be devices along the > path that re-assemble the packets (if they're fragmented) and then > fragment them again, which will break things anyway. I think RFC4821 only applies to whole packets with DF=3D1 (i.e., where all IPv6 packets implicitly have DF=3D1), but I get your point.=20 > But yes, supporting 4821 or PMTUD blackhole detection should definitely b= e > a requirement. OK. =20 > One problem is that a lot of people don't even know that sending a 16k UD= P > packet fragmented into a bunch of smaller fragments, is a perfectly valid > use of IP. They're so used to TCP and its MSS that this is all they've > seen. Yes, isolated large UDP packets with DF=3D0 must be dealt with. Thanks - Fred fred.l.templin@boeing.com =20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 9 08:59:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64771A7001 for ; Tue, 9 Sep 2014 08:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.853 X-Spam-Level: X-Spam-Status: No, score=-15.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 5gs5kBzluPTN for ; Tue, 9 Sep 2014 08:59:01 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700541A6FFF for ; Tue, 9 Sep 2014 08:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7596; q=dns/txt; s=iport; t=1410278341; x=1411487941; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=75dUCQqkNsNxnN2cNy86DnfVo3Oqooi2w29DHqjOga8=; b=VlWAq2sjmPfJyvdXeoMcyLmkKZlrl12iXmu+meDcvYdpt4oUlwZzAzfr CN/6kGyIaRiwJRY4ahJ1bH+oQU0/snUNDbXl2SQ98v7lkIcobhh4fz2LW dBsnrTFRKRvokRlPSVxlGIbhC2EMBHhHpHUX5oAgnEDrZeJVoTIm7nkQ9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAHcjD1StJV2c/2dsb2JhbABZDoJ/U1cEgnjHJQqHTAEZdBZ4hAMBAQEEAQEBIBE4AgsMBAIBCBEEAQEDAgYdAwICAiULFAEICAIEAQ0FCIg6DacXlWYBF4EsiFSEdiYWGwcGgnM2gR0FjxmCKIQwgjyGJYZrjGSDH0JsAYEFAR8EHoEHAQEB X-IronPort-AV: E=Sophos;i="5.04,492,1406592000"; d="scan'208";a="76330168" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 09 Sep 2014 15:58:43 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s89Fwh7b018588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 15:58:43 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 10:58:42 -0500 From: "Hemant Singh (shemant)" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= , "Chuck Anderson" Thread-Topic: [v6ops] Interesting problems with using IPv6 Thread-Index: AQHPy7BYcufcLcCSE0CP+QdxqYnKUZv4XruAgACCkQCAAAzxgP//rUdQgACT44CAABYhgP//ryjQ Date: Tue, 9 Sep 2014 15:58:42 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89155AF84D@xmb-rcd-x06.cisco.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aq5N2eGLKJZBNWSeCAQDZ1mBqjM Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 15:59:04 -0000 QW5kcmV3LA0KDQpHcmVhdCBpbnB1dCBmcm9tIHlvdS4gICBIb3dldmVyLCB0aGVyZSBpcyBvbmUg Y2F0Y2guICBBIGJhc2ljIHN3aXRjaCB3b3JrcyBhdCBsYXllci0yIGFuZCBtYXkgbm90IGhhdmUg aXRzIGltcGxlbWVudGF0aW9uIGNvbW11bmljYXRlIHdpdGggdXBwZXIgdHJhbnNwb3J0IGxheWVy cyBzdWNoIGFzIFRDUCBhbmQgVURQLiAgVGhlIHN3aXRjaCBpcyBtZXJlbHkgc25vb3BpbmcgTUxE LiAgVGhlbiB0aGUgc3dpdGNoIHNob3VsZCBqdXN0IHN1cHBvcnQgbmV2ZXIgbGV0dGluZyBpdHMg Y3B1IGdvIGhpZ2hlciB0aGFuIDQwJSBhbmQgcmF0ZSBsaW1pdCBwcm9jZXNzaW5nIGluIHRoZSBz d2l0Y2ggcHVudCBwYXRoLg0KDQpIZW1hbnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEFuZHJldyA/PyBZb3VydGNoZW5rbw0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDA5LCAyMDE0 IDExOjQyIEFNDQpUbzogQ2h1Y2sgQW5kZXJzb24NCkNjOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFt2Nm9wc10gSW50ZXJlc3RpbmcgcHJvYmxlbXMgd2l0aCB1c2luZyBJUHY2DQoNCg0K Tm90IGRlbHZpbmcgaW50byB0aGUgd2hvbGUgIndoeSBpbiB0b2RheS1zY2FsZSBuZXR3b3JrIHdl IG5lZWQgdG8gbWFpbnRhaW4gc2VwYXJhdGUgZ3JvdXBzIHBlciBlYWNoIHNvbGljaXRlZCBtdWx0 aWNhc3QiIGFyZ3VtZW50LCBsZXQncyBqdXN0IGFzc3VtZSB0aGVyZSBhcmUgc29tZSBub3RpY2Vh YmxlIGdhaW5zIHRoZXJlIGFuZCBmb2N1cyBvbiB0aGUgbnVtYmVyIG9mIGdyb3Vwcy4NCg0KMSkg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDk0MSNzZWN0aW9uLTMuMyBzYXlzOg0KDQog ICAxLiAgUHJvY2VzcyB0aGUgUHJlZml4IEluZm9ybWF0aW9uIE9wdGlvbiBhcyBkZWZpbmVkIGlu IFtBRERSQ09ORl0sDQogICAgICAgZWl0aGVyIGNyZWF0aW5nIGEgbmV3IHB1YmxpYyBhZGRyZXNz IG9yIGFkanVzdGluZyB0aGUgbGlmZXRpbWVzDQogICAgICAgb2YgZXhpc3RpbmcgYWRkcmVzc2Vz LCBib3RoIHB1YmxpYyBhbmQgdGVtcG9yYXJ5LiAgSWYgYSByZWNlaXZlZA0KICAgICAgIG9wdGlv biB3aWxsIGV4dGVuZCB0aGUgbGlmZXRpbWUgb2YgYSBwdWJsaWMgYWRkcmVzcywgdGhlDQogICAg ICAgbGlmZXRpbWVzIG9mIHRlbXBvcmFyeSBhZGRyZXNzZXMgc2hvdWxkIGJlIGV4dGVuZGVkLCBz dWJqZWN0IHRvDQogICAgICAgdGhlIG92ZXJhbGwgY29uc3RyYWludCB0aGF0IG5vIHRlbXBvcmFy eSBhZGRyZXNzZXMgc2hvdWxkIGV2ZXINCiAgICAgICByZW1haW4gInZhbGlkIiBvciAicHJlZmVy cmVkIiBmb3IgYSB0aW1lIGxvbmdlciB0aGFuDQogICAgICAgKFRFTVBfVkFMSURfTElGRVRJTUUp IG9yIChURU1QX1BSRUZFUlJFRF9MSUZFVElNRSAtDQogICAgICAgREVTWU5DX0ZBQ1RPUiksIHJl c3BlY3RpdmVseS4gIFRoZSBjb25maWd1cmF0aW9uIHZhcmlhYmxlcw0KICAgICAgIFRFTVBfVkFM SURfTElGRVRJTUUgYW5kIFRFTVBfUFJFRkVSUkVEX0xJRkVUSU1FIGNvcnJlc3BvbmQgdG8NCiAg ICAgICBhcHByb3hpbWF0ZSB0YXJnZXQgbGlmZXRpbWVzIGZvciB0ZW1wb3JhcnkgYWRkcmVzc2Vz Lg0KDQpPbmUgd2F5IHRvIGludGVycHJldCB0aGlzIHRleHQgaXMgdGhhdCB3aXRoIHRoZSBkZWZh dWx0cywgYSBob3N0IHdpdGggU0xBQUMgYW5kIHRlbXBvcmFyeSBhZGRyZXNzZXMgd2lsbCBoYXZl OiAxIExMICsgMSBTTEFBQyArIDcgdGVtcCBhZGRyZXNzZXMgPSA5Lg0KDQpUaGlzIGdpdmVzIDEu NSBvcmRlciBvZiBtYWduaXR1ZGUgbGVzcyBncm91cHMgdGhhbiBpbiB0aGUgZXhhbXBsZSB5b3Ug Y2l0ZSAtIGEgbm90IHRlcnJpYmx5IHVucmVhc29uYWJsZSBudW1iZXIsIHRob3VnaCBpdCdzIHN0 aWxsIGEgOXggYW1vdW50Lg0KDQpUaGUgVEVNUF9WQUxJRF9MSUZFVElNRSBhbmQgVEVNUF9QUkVG RVJSRURfTElGRVRJTUUgYXJlIGhvc3QtY29kZWQsIHRoZSBuZXR3b3JrIChmb3IgYmV0dGVyIG9y IHdvcnNlKSBhcHBlYXJzIHRvIGhhdmUgbm90IG11Y2ggc2F5IGFib3V0IHRoZW0uDQoNCjIpIFRo ZSAiMzAwIGFkZHJlc3NlcyIgc2l0dWF0aW9uIG1pZ2h0IGxvb2sgbGlrZSBlaXRoZXIgdGhlIGRl ZmF1bHRzIHdlcmUgY2hhbmdlZCwgb3IgdGhlIHN0YWNrIGlzIGJlaW5nICJoZWxwZnVsIiBhcyBk ZXNjcmliZWQgaW4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ5NDEjc2VjdGlvbi02 Og0KDQogICBBbiBpbXBsZW1lbnRhdGlvbiBtaWdodCB3YW50IHRvIGtlZXAgdHJhY2sgb2Ygd2hp Y2ggYWRkcmVzc2VzIGFyZQ0KICAgYmVpbmcgdXNlZCBieSB1cHBlciBsYXllcnMgc28gYXMgdG8g YmUgYWJsZSB0byByZW1vdmUgYSBkZXByZWNhdGVkDQogICB0ZW1wb3JhcnkgYWRkcmVzcyBmcm9t IGludGVybmFsIGRhdGEgc3RydWN0dXJlcyBvbmNlIG5vIHVwcGVyIGxheWVyDQogICBwcm90b2Nv bHMgYXJlIHVzaW5nIGl0IChidXQgbm90IGJlZm9yZSkuICBUaGlzIGlzIGluIGNvbnRyYXN0IHRv DQogICBjdXJyZW50IGFwcHJvYWNoZXMgd2hlcmUgYWRkcmVzc2VzIGFyZSByZW1vdmVkIGZyb20g YW4gaW50ZXJmYWNlIHdoZW4NCiAgIHRoZXkgYmVjb21lIGludmFsaWQgW0FERFJDT05GXSwgaW5k ZXBlbmRlbnQgb2Ygd2hldGhlciBvciBub3QgdXBwZXINCiAgIGxheWVyIHByb3RvY29scyBhcmUg c3RpbGwgdXNpbmcgdGhlbS4gIEZvciBUQ1AgY29ubmVjdGlvbnMsIHN1Y2gNCiAgIGluZm9ybWF0 aW9uIGlzIGF2YWlsYWJsZSBpbiBjb250cm9sIGJsb2Nrcy4gIEZvciBVRFAtYmFzZWQNCiAgIGFw cGxpY2F0aW9ucywgaXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgb25seSB0aGUgYXBwbGljYXRpb25z IGhhdmUNCiAgIGtub3dsZWRnZSBhYm91dCB3aGF0IGFkZHJlc3NlcyBhcmUgYWN0dWFsbHkgaW4g dXNlLiAgQ29uc2VxdWVudGx5LCBhbg0KICAgaW1wbGVtZW50YXRpb24gZ2VuZXJhbGx5IHdpbGwg bmVlZCB0byB1c2UgaGV1cmlzdGljcyBpbiBkZWNpZGluZyB3aGVuDQogICBhbiBhZGRyZXNzIGlz IG5vIGxvbmdlciBpbiB1c2UuDQoNCldvdWxkIHRoaXMgbWVhbiB0aGUgaG9zdCBoYXMgYSBjb25u ZWN0aW9uIHRoYXQgaXMgbGFzdGluZyAzMDAgZGF5cyBhbmQgaXMgdXNpbmcgdGhlIHNhbWUgdGVt cG9yYXJ5IGFkZHJlc3MgPyBUaGlzIGRvZXMgbm90IGxvb2sgdG9vIHRlbXBvcmFyeSwgc28gYXJn dWFibHkgdGhhdCBhcHBsaWNhdGlvbiBzaG91bGQgbm90IGJlIHVzaW5nIHRlbXBvcmFyeSBhZGRy ZXNzZXMgKEFsc286IGludGVyZXN0aW5nIHRoYXQgZS5nLiBMaW51eCBsaW1pdHMgdGhlIGRlZmF1 bHQgIyB0bw0KMTYgLSBjZi46IGh0dHA6Ly9vc3Muc2dpLmNvbS9hcmNoaXZlcy9uZXRkZXYvMjAw NC0wMS9tc2cwMTAwMi5odG1sDQp3aGljaCBpcyBzdGlsbCB0cnVlIGluIHRoZSBVYnVudHUgMTQu MDQuKQ0KDQpCVFcsIHRhbGtpbmcgYWJvdXQgdGhlIGFwcGxpY2F0aW9ucywgdGhleSBzaG91bGQg YmUgYWJsZSB0byBzZWxlY3Qgd2hldGhlciB0aGV5IG5lZWQgdGhlIHRlbXBvcmFyeSBhZGRyZXNz ZXMgb3Igbm90OiByZmM1MDE0LiBEbyB0aGV5IGludGVudGlvbmFsbHkgc2VsZWN0IHRoZSB0ZW1w b3JhcnkgYWRkcmVzc2VzIG9uIHRoZSBsb25nLWxhc3RpbmcgY29ubmVjdGlvbnMgPw0KDQpOb3cs IGxldCBtZSBhcmd1ZSB3aXRoIG15c2VsZjoNCg0KMSkgSVB2NiByZXF1aXJpbmcgOXggdGltZSB0 aGUgSVB2NCBhZGRyZXNzZXMgaXMgc3RpbGwgcXVpdGUgYSBzdHJldGNoLg0KSWYgc29tZW9uZSBu ZWVkcyBhIGxvbmctbGFzdGluZyBzZXNzaW9uLCB0aGV5IHNob3VsZCB1c2UgYSBzdGFibGUgYWRk cmVzcy4NCg0KMikgRG9lcyBhcHBsaWNhdGlvbiBoYXZlIGEgd2F5IHRvIHNheSAiSSBkbyBub3Qg d2FudCB0ZW1wb3JhcnkgYWRkcmVzc2VzIiA/DQooY2Y6IGh0dHBzOi8vYnVncy5sYXVuY2hwYWQu bmV0L3VidW50dS8rc291cmNlL3Byb2Nwcy8rYnVnLzEwNjg3NTYpDQpTZWVtcyBub3QgdG9kYXkg Pw0KDQozKSBBbHNvLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0OTQxI3NlY3Rpb24t My42IGNsZWFybHkgc2F5czoNCg0KIiBJbiBhZGRpdGlvbiwgc29tZSBhcHBsaWNhdGlvbnMgbWF5 IG5vdCBiZWhhdmUNCiAgIHJvYnVzdGx5IGlmIHRlbXBvcmFyeSBhZGRyZXNzZXMgYXJlIHVzZWQg YW5kIGFuIGFkZHJlc3MgZXhwaXJlcw0KICAgYmVmb3JlIHRoZSBhcHBsaWNhdGlvbiBoYXMgdGVy bWluYXRlZCwgb3IgaWYgaXQgb3BlbnMgbXVsdGlwbGUNCiAgIHNlc3Npb25zLCBidXQgZXhwZWN0 cyB0aGVtIHRvIGFsbCB1c2UgdGhlIHNhbWUgYWRkcmVzc2VzLg0KICAgQ29uc2VxdWVudGx5LCB0 aGUgdXNlIG9mIHRlbXBvcmFyeSBhZGRyZXNzZXMgU0hPVUxEIGJlIGRpc2FibGVkIGJ5DQogICBk ZWZhdWx0IGluIG9yZGVyIHRvIG1pbmltaXplIHBvdGVudGlhbCBkaXNydXB0aW9ucy4gIEluZGl2 aWR1YWwNCiAgIGFwcGxpY2F0aW9ucywgd2hpY2ggaGF2ZSBzcGVjaWZpYyBrbm93bGVkZ2UgYWJv dXQgdGhlIG5vcm1hbCBkdXJhdGlvbg0KICAgb2YgY29ubmVjdGlvbnMsIE1BWSBvdmVycmlkZSB0 aGlzIGFzIGFwcHJvcHJpYXRlLiINCg0KDQpTbywgaWYgdGhlIGhvc3RzIHdlcmUgZ2VudGxlIHdp dGggdGhlIG51bWJlciBvZiBhZGRyZXNzZXMgdGhleSB0cnkgdG8gdXNlLCBhcHBzIHdpdGggbG9u Zy1sYXN0aW5nIGNvbm5lY3Rpb25zIHdlcmUgdG8gZGlzYWJsZSB0aGUgdGVtcG9yYXJ5IGFkZHJl c3NlcyBhbmQgdGhlIHNlcnZlciBmbGVldCBoYWQgdGhlIHRlbXBvcmFyeSBhZGRyZXNzZXMgZGlz YWJsZWQgYWx0b2dldGhlciwgU0xBQUMgKGFuZCwgd2hlcmUgYXBwcm9wcmlhdGUsIHRlbXBvcmFy eSBhZGRyZXNzZXMpIHdvdWxkIG5vdCBiZSBzbyBiYWQgYXQgYWxsLg0KDQpPZiBjb3Vyc2UsIHRo ZSBhbW91bnQgb2YgbWFudWFsIHdvcmsgdGhpcyByZXF1aXJlcyB0b2RheSBtZWFucyB0aGF0IHRo ZSBBLWJpdCBpcyB0dXJuZWQgb2ZmIGFuZCB0aGUgREhDUHY2IGlzIGJlaW5nIHVzZWQuIFdoaWNo IG1heSBiZSBwZXJmZWN0bHkgb2theSAtIGJ1dCBpZiBpdCBpcyBub3QsIGFuZCB3ZSBkbyBhc3Nl cnQgdGhhdCAiQW4gUkEgd2l0aCBwcmVmaXggaGF2aW5nIGFuIEEtYml0IHNldCBhbmQgZGVmYXVs dCBzZXR0aW5ncywgc2hvdWxkIG5vdCBjYXVzZSB0aGUgMTB4IGV4cGFuc2lvbiB0byB0aGUgcmVz b3VyY2UgcmVxdWlyZW1lbnRzIGNvbXBhcmVkIHRvIExlZ2FjeSBJUCIsIHNlZW1zIGxpa2Ugc29t ZSBzb3J0IG9mIGEgY29ycmVjdGlvbiBpbiBkZWZhdWx0IHN0YWNrcy9hcHBzIGJlaGF2aW9yIHdp dGggcmVzcGVjdCB0byB0ZW1wb3JhcnkgYWRkcmVzc2VzIGNvdWxkIGJlIHVzZWZ1bC4NCg0KLS1h DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9w cyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Tue Sep 9 09:22:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C2E1A6FF6 for ; Tue, 9 Sep 2014 09:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LHPauKxo3oF for ; Tue, 9 Sep 2014 09:22:29 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AA81A04F6 for ; Tue, 9 Sep 2014 09:22:29 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id l13so669242iga.5 for ; Tue, 09 Sep 2014 09:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/S4AuGXyeRuTy6zxfPgYEw+qGv7sr+0UmEQPVQ/OdVI=; b=gEdVHk82mgIEYX0x3WdMmEl3k4wRbXptQThMt9bZnn6gBWdfUfAc76n5am4cffMblP XrpqvVeS4enRA6pbrKM4Fap/nx4ZpXYVRjus5TJbRjiGAHjOsY57H/3IRi8ZJyMF5euv tqkQS4HEDYBwpvQQ7AknbAiADvJKWzp6BdMGa2UwQHVybi4h3q4FQzRag1qwuRo/zZ+Q Y0aEz913GsQ+Hj5me8wKYMQ8SHjZgDYrEEzh4aDBlD8lgymnOZWbD3HRn2ZJbqO3/+2+ 5MPhlBrGtgWGr69jcc4gr/klsejpFwl4FrH+F2Q6V1PBPc5+kZJMijbHemHyDt+o5njr fnsg== MIME-Version: 1.0 X-Received: by 10.42.83.131 with SMTP id h3mr10875709icl.77.1410279748850; Tue, 09 Sep 2014 09:22:28 -0700 (PDT) Received: by 10.107.137.39 with HTTP; Tue, 9 Sep 2014 09:22:28 -0700 (PDT) In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89155AF84D@xmb-rcd-x06.cisco.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <75B6FA9F576969419E42BECB86CB1B89155AF84D@xmb-rcd-x06.cisco.com> Date: Tue, 9 Sep 2014 18:22:28 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BysR6-T4KDHucOW32ONUUzjkfgA Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 16:22:31 -0000 Hemant, On 9/9/14, Hemant Singh (shemant) wrote: > Andrew, > > Great input from you. However, there is one catch. A basic switch works > at layer-2 and may not have its implementation communicate with upper > transport layers such as TCP and UDP. The switch is merely snooping MLD. > Then the switch should just support never letting its cpu go higher than 40% > and rate limit processing in the switch punt path. "should", absolutely! But safeguarding by other means to avoid the fireworks and explosions if this "should" is violated due to human error (designer, programmer, operator, or user) seems like a prudent engineering choice. Besides, the multicast group explosion and MLD traffic is just one of the facets related to excessive temporary addresses that just happens to be in the spotlight today, but it is not the only one. --a > > Hemant > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Andrew ?? > Yourtchenko > Sent: Tuesday, September 09, 2014 11:42 AM > To: Chuck Anderson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Interesting problems with using IPv6 > > > Not delving into the whole "why in today-scale network we need to maintain > separate groups per each solicited multicast" argument, let's just assume > there are some noticeable gains there and focus on the number of groups. > > 1) http://tools.ietf.org/html/rfc4941#section-3.3 says: > > 1. Process the Prefix Information Option as defined in [ADDRCONF], > either creating a new public address or adjusting the lifetimes > of existing addresses, both public and temporary. If a received > option will extend the lifetime of a public address, the > lifetimes of temporary addresses should be extended, subject to > the overall constraint that no temporary addresses should ever > remain "valid" or "preferred" for a time longer than > (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - > DESYNC_FACTOR), respectively. The configuration variables > TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to > approximate target lifetimes for temporary addresses. > > One way to interpret this text is that with the defaults, a host with SLAAC > and temporary addresses will have: 1 LL + 1 SLAAC + 7 temp addresses = 9. > > This gives 1.5 order of magnitude less groups than in the example you cite - > a not terribly unreasonable number, though it's still a 9x amount. > > The TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME are host-coded, the > network (for better or worse) appears to have not much say about them. > > 2) The "300 addresses" situation might look like either the defaults were > changed, or the stack is being "helpful" as described in > http://tools.ietf.org/html/rfc4941#section-6: > > An implementation might want to keep track of which addresses are > being used by upper layers so as to be able to remove a deprecated > temporary address from internal data structures once no upper layer > protocols are using it (but not before). This is in contrast to > current approaches where addresses are removed from an interface when > they become invalid [ADDRCONF], independent of whether or not upper > layer protocols are still using them. For TCP connections, such > information is available in control blocks. For UDP-based > applications, it may be the case that only the applications have > knowledge about what addresses are actually in use. Consequently, an > implementation generally will need to use heuristics in deciding when > an address is no longer in use. > > Would this mean the host has a connection that is lasting 300 days and is > using the same temporary address ? This does not look too temporary, so > arguably that application should not be using temporary addresses (Also: > interesting that e.g. Linux limits the default # to > 16 - cf.: http://oss.sgi.com/archives/netdev/2004-01/msg01002.html > which is still true in the Ubuntu 14.04.) > > BTW, talking about the applications, they should be able to select whether > they need the temporary addresses or not: rfc5014. Do they intentionally > select the temporary addresses on the long-lasting connections ? > > Now, let me argue with myself: > > 1) IPv6 requiring 9x time the IPv4 addresses is still quite a stretch. > If someone needs a long-lasting session, they should use a stable address. > > 2) Does application have a way to say "I do not want temporary addresses" ? > (cf: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756) > Seems not today ? > > 3) Also, http://tools.ietf.org/html/rfc4941#section-3.6 clearly says: > > " In addition, some applications may not behave > robustly if temporary addresses are used and an address expires > before the application has terminated, or if it opens multiple > sessions, but expects them to all use the same addresses. > Consequently, the use of temporary addresses SHOULD be disabled by > default in order to minimize potential disruptions. Individual > applications, which have specific knowledge about the normal duration > of connections, MAY override this as appropriate." > > > So, if the hosts were gentle with the number of addresses they try to use, > apps with long-lasting connections were to disable the temporary addresses > and the server fleet had the temporary addresses disabled altogether, SLAAC > (and, where appropriate, temporary addresses) would not be so bad at all. > > Of course, the amount of manual work this requires today means that the > A-bit is turned off and the DHCPv6 is being used. Which may be perfectly > okay - but if it is not, and we do assert that "An RA with prefix having an > A-bit set and default settings, should not cause the 10x expansion to the > resource requirements compared to Legacy IP", seems like some sort of a > correction in default stacks/apps behavior with respect to temporary > addresses could be useful. > > --a > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 9 10:09:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95831A7009 for ; Tue, 9 Sep 2014 10:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuYauZ7FHcvv for ; Tue, 9 Sep 2014 10:08:55 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855341A802F for ; Tue, 9 Sep 2014 10:08:55 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6ADDC880F6 for ; Tue, 9 Sep 2014 10:08:55 -0700 (PDT) Received: from 1025210049.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 31C3871B0001 for ; Tue, 9 Sep 2014 10:08:55 -0700 (PDT) Message-ID: <540F3432.5030702@innovationslab.net> Date: Tue, 09 Sep 2014 13:09:06 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> In-Reply-To: <540F0BCF.1060905@gont.com.ar> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1Jpk1dQfOT6QJf5e9EAjLpejwCvDh14UU" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jRdLmkQKiPNeQRs9oSPq1Y1gqVI Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 17:08:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1Jpk1dQfOT6QJf5e9EAjLpejwCvDh14UU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9/9/14 10:16 AM, Fernando Gont wrote: > On 09/09/2014 04:20 AM, Brian E Carpenter wrote: >>>> OK, but I would also like to understand why we require >>>> MLD messages for a Solicited-Node multicast address to >>>> set Router Alert. >>> >>> Because in theory the multicast router needs to process the MLD messa= ge >>> to build its forwarding table.... >> >> Why, for the Solicited-Node group, which is only meaningful on the lin= k >> from which the MLD message arrives? >=20 > Then, let me change the question: Why do I need MLD for *this*? The MLD specs say that an MLD Report is sent for every multicast group joined except the All-Nodes multicast address. The use of MLD Reports for essentially all multicast addresses was done to facilitate this very type of snooping functionality. The use of Router Alerts in MLD messages is due to MLDv1 (and IGMPv2) using the group address as the IP destination rather than the All-Routers multicast address. >=20 > We probably use MLD because "If you use multicast, you use MLD". Truth > is that, *unless your switch does MLD snooping* (and hence you *need* > MLD, or else your packets will not flow around), you could completely > kill MLD, and ND would still work just fine. Sure, since NDP is link-local. The drawback is what happens if your network is using RFC 4541 snooping that relies on seeing those MLD messages to build forwarding/filtering tables? >=20 > Not to mention that there are nodes that default t running MLDv2 *for > this* (way overkill, IMO) >=20 Why is MLDv2 overkill? Brian --1Jpk1dQfOT6QJf5e9EAjLpejwCvDh14UU 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUDzQ4AAoJEBOZRqCi7goqBSYIAM+1ai0xZiCiKgQ7WzkB4MzM AEwi+GnfnMPiJO23t5a6LEljjUJmd//S0sa+67Cn5P8M15upkk8LTeEy9uSx+mOi /Exy8n3z/Ns3RQmxQ4vk40d2vlzxSn9Oxv8T8Qw4y5gEpeszMmT72LJCE2T8f7F1 v+ixPDW3f6n2nfSC//BFw9A+56OSbx5xzFerj2Bw9HmEOkUg24cSl/3zX0fGI7QU FbCAy3Qo14JPHsO8Ni2X2IwzuGKaLY6AVb0VKXEOzWcDOWCZNk2spt1Zj+tCuHUl bNgOFEY5FSOrqkkcoiPVFUZt2I0EAOHivujX9MaJFuIveeCDcFdmzxRggLkd5yk= =kWeu -----END PGP SIGNATURE----- --1Jpk1dQfOT6QJf5e9EAjLpejwCvDh14UU-- From nobody Tue Sep 9 11:58:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19861A0013 for ; Tue, 9 Sep 2014 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqZgucmp1tSN for ; Tue, 9 Sep 2014 11:57:54 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5411A00E0 for ; Tue, 9 Sep 2014 11:57:46 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u56so3440838wes.4 for ; Tue, 09 Sep 2014 11:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w7WxwDt4PW9xIDLY24noFLzJuRJEtkeKxXhdceCRddA=; b=G7GvvCVZoJd3RUfHKsAapuL4RnzCxV0kE2geK3GIGTftXKQ8CjMvcD6J5QjMD7ug/s q2XKvejicEUHPSOYM/05KME7cLmx+EMZH+MoQpNZC+gF0SkJ0Pqbfadpa9WEJX3FFcYn jMsHYXI78l+vuanqV7L9OzGAp++pZMC5AKeNn6ZXU/Bo8FCIxZ7AjO9vlWFiRQbrgPtp 8/+ehPNG0/2TWXE+Qnd1vyBSSO6Bev+lSc3R+advzcZjq4CGMmwVqoikQiPChGnZarMh L4J8o3+MjdcsNECjGEyg1lSabmK1AyrFTEA5Lkb1+vHbgH/0t2orP+UkntUwzYusssjM Vxbg== MIME-Version: 1.0 X-Received: by 10.194.172.137 with SMTP id bc9mr45812516wjc.72.1410289064886; Tue, 09 Sep 2014 11:57:44 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Tue, 9 Sep 2014 11:57:44 -0700 (PDT) In-Reply-To: <540E26D9.3070907@gmail.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> Date: Tue, 9 Sep 2014 11:57:44 -0700 X-Google-Sender-Auth: g4psTm-zyzBXVnU5dN5qTRHw14c Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sWXO9Z8ZajP1A6MNKPbAjrQ3BMQ Cc: IPv6 Operations , l.wood@surrey.ac.uk Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 18:57:55 -0000 At Tue, 09 Sep 2014 09:59:53 +1200, Brian E Carpenter wrote: > > Implementing MLD snooping for Solicited-Node multicast addresses > > is probably a bad idea. > > > > See: draft-pashby-magma-simplify-mld-snooping-01 > > OK, but I would also like to understand why we require > MLD messages for a Solicited-Node multicast address to > set Router Alert. I don't know the answer, but my guess is that when the original MLD was designed in RFC 2710 they simply didn't have that question. In fact, we were not aware of various implications with MLD messages for solicited-node multicast addresses for quite some time, which made us include some specific discussion on this topic in RFC 4862 (Section 5.4.2). -- JINMEI, Tatuya From nobody Tue Sep 9 13:40:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5391A0149 for ; Tue, 9 Sep 2014 13:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSDY37AME71u for ; Tue, 9 Sep 2014 13:40:36 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A70F1A010A for ; Tue, 9 Sep 2014 13:40:36 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so4977601pad.14 for ; Tue, 09 Sep 2014 13:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TTPfTc9HVrN99VdSiOginMERt+pb7r1c0HOmDCLURCI=; b=NUuQ7x5JNlvjjj9kST8OdBD32xU4q2U6/9TE7tLM28ddokt7K1isYqDzt+qzAnyrTr sEjIx4S/sH+W/Uf+v07SfmrcMM+kEmpCaeWvleA+7oG84lBBMOc/OeoRY4Cd4JofnVzo 8dKwNtkeP2VUEF9K0Joe9OeFTByf7593BviTlzl5hdVSqTkGNEoVOFS1AgMfAhrtomO/ m0NABGp/71Nz5bnFme/BkNbiYaUz1ma4oRtFpJaWiuJF1VjPvj0uhZwvveb04Lecri5S j9KgOnZsLWPyEfHkJS6Yc9xNtqgWqBaAtkalQnuICa6olRmP4TiM/Y8I7NLdFNH8hpRj BPBg== X-Received: by 10.66.142.166 with SMTP id rx6mr18278591pab.128.1410295236162; Tue, 09 Sep 2014 13:40:36 -0700 (PDT) Received: from [192.168.178.23] (221.199.69.111.dynamic.snap.net.nz. [111.69.199.221]) by mx.google.com with ESMTPSA id lx10sm12591713pdb.31.2014.09.09.13.40.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 13:40:35 -0700 (PDT) Message-ID: <540F65C4.7050503@gmail.com> Date: Wed, 10 Sep 2014 08:40:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> In-Reply-To: <540F3432.5030702@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EMoxNSwetwTutE_0fTtPHkOtZA4 Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Sep 2014 20:40:38 -0000 On 10/09/2014 05:09, Brian Haberman wrote: > > On 9/9/14 10:16 AM, Fernando Gont wrote: >> On 09/09/2014 04:20 AM, Brian E Carpenter wrote: >>>>> OK, but I would also like to understand why we require >>>>> MLD messages for a Solicited-Node multicast address to >>>>> set Router Alert. >>>> Because in theory the multicast router needs to process the MLD message >>>> to build its forwarding table.... >>> Why, for the Solicited-Node group, which is only meaningful on the link >>> from which the MLD message arrives? >> Then, let me change the question: Why do I need MLD for *this*? I think Brian Haberman's reply shows why that is the wrong question. You need MLD for every multicast group, including a solicited-node group, and if you insist on MLD snooping in the bridges (let's not obfuscate by calling them switches) then you need to snoop every solicited-node group. My question is orthogonal to MLD snooping: why do we require router-alert for MLD messages referring to a solicited-node group, since it by definition is limited to a single L2 link (even if that link is split up by bridges)? I tend to think this requirement is an error in the MLD spec. Brian C > The MLD specs say that an MLD Report is sent for every multicast group > joined except the All-Nodes multicast address. > > The use of MLD Reports for essentially all multicast addresses was done > to facilitate this very type of snooping functionality. The use of > Router Alerts in MLD messages is due to MLDv1 (and IGMPv2) using the > group address as the IP destination rather than the All-Routers > multicast address. > >> We probably use MLD because "If you use multicast, you use MLD". Truth >> is that, *unless your switch does MLD snooping* (and hence you *need* >> MLD, or else your packets will not flow around), you could completely >> kill MLD, and ND would still work just fine. > > Sure, since NDP is link-local. The drawback is what happens if your > network is using RFC 4541 snooping that relies on seeing those MLD > messages to build forwarding/filtering tables? > >> Not to mention that there are nodes that default t running MLDv2 *for >> this* (way overkill, IMO) >> > > Why is MLDv2 overkill? > > Brian > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 9 14:20:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87B21A8549 for ; Tue, 9 Sep 2014 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.553 X-Spam-Level: X-Spam-Status: No, score=-8.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 K_fkB37s2B7K for ; Tue, 9 Sep 2014 14:20:08 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CEA1A0299 for ; Tue, 9 Sep 2014 14:19:52 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 6E97C3493A2; Tue, 9 Sep 2014 21:19:50 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8612216005D; Tue, 9 Sep 2014 21:22:35 +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 1FFA016005A; Tue, 9 Sep 2014 21:22:35 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 69A5B1F2609A; Wed, 10 Sep 2014 07:19:47 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <2134F8430051B64F815C691A62D9831832D12EED@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D13130@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Tue, 09 Sep 2014 15:45:55 +0000." <2134F8430051B64F815C691A62D9831832D13130@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 10 Sep 2014 07:19:47 +1000 Message-Id: <20140909211947.69A5B1F2609A@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9LU2PMaxAaeQQUP1saittkXQe7I Cc: "v6ops@ietf.org" , Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 21:20:10 -0000 In message <2134F8430051B64F815C691A62D9831832D13130@XCH-BLV-504.nw.nos.boeing.com>, "Templin, Fred L" writes: > Hi Mikael, > > > -----Original Message----- > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > Sent: Tuesday, September 09, 2014 8:08 AM > > To: Templin, Fred L > > Cc: Tom Perrine; v6ops@ietf.org > > Subject: RE: [v6ops] PMTUD issue discussion > > > > On Tue, 9 Sep 2014, Templin, Fred L wrote: > > > > > This could be problematic when PMTUD is not functioning correctly. As a > > > result, IMHO any end system that wants to try for packet sizes larger > > > than 1500 really should be using RFC4821 (maybe even MUST?). > > > > Well, even that might not solve it as there might be devices along the > > path that re-assemble the packets (if they're fragmented) and then > > fragment them again, which will break things anyway. > > I think RFC4821 only applies to whole packets with DF=1 (i.e., where > all IPv6 packets implicitly have DF=1), but I get your point. > > > But yes, supporting 4821 or PMTUD blackhole detection should definitely be > > a requirement. > > OK. > > > One problem is that a lot of people don't even know that sending a 16k UDP > > packet fragmented into a bunch of smaller fragments, is a perfectly valid > > use of IP. They're so used to TCP and its MSS that this is all they've > > seen. > > Yes, isolated large UDP packets with DF=0 must be dealt with. Actually there is plenty of fragmented UDP traffic. Pick just about any IPv6 DNSSEC aware recursive nameserver and you will almost certainly see fragmented IPv6 UDP responses. This traffic is only increasing as more zones become signed pushing response size well over 1500. Below is from BIND 9.10 which tracks UDP response sizes. Find a busy resolver and you will find a lot more. The EDNS field shows timeouts at various EDNS UDP buffer sizes. A timeout at a small size is counted against larger sizes as well as named tries to workout the DNS/UDP mtu which can be as low as 512 as some firewalls "know" that DNS/UDP payloads "never" exceeded 512 bytes. This nameserver is behind a HE tunnel so it also has to deal with authorative nameservers that block PTB to them. Named also forces fragmentation at 1280 on all sockets if it can. The savings for a nameserver in sending bigger packets just aren't there. [edns success/4096 timeout/1432 timeout/1232 timeout/512 timeout] [rock:~/ports] marka% grep srtt /var/named/named_dump.db | grep udpsize | grep -v "udpsize 512" | grep : ; 2001:500:31::63 [srtt 119657] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 965] [ttl 1230] ; 2001:500:2c::254 [srtt 214672] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 1676] [ttl 1222] ; 2001:13c7:7002:3000::11 [srtt 242467] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 513] [ttl 1229] ; 2001:500:60::30 [srtt 229183] [flags 00806000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 1816] [ttl 1221] ; 2001:4f8:0:2::19 [srtt 82726] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 1626] [ttl 1221] ; 2001:500:13::108 [srtt 115528] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 1991] [ttl 1229] [rock:~/ports] marka% > Thanks - Fred > fred.l.templin@boeing.com > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Sep 9 18:13:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A7B1A0390 for ; Tue, 9 Sep 2014 18:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-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 D9iF_N8OV1qH for ; Tue, 9 Sep 2014 18:13:32 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4918F1A0380 for ; Tue, 9 Sep 2014 18:13:32 -0700 (PDT) Received: from [186.134.45.58] (helo=[192.168.123.128]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XRWTM-0008Lg-Ow; Wed, 10 Sep 2014 03:13:25 +0200 Message-ID: <540F9BE0.5060403@si6networks.com> Date: Tue, 09 Sep 2014 21:31:28 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= , Chuck Anderson References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ADrNEKIyJs1-qd_Dx34S1kHt-tE Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 01:13:34 -0000 On 09/09/2014 12:41 PM, Andrew 👽 Yourtchenko wrote: > > Of course, the amount of manual work this requires today means that > the A-bit is turned off and the DHCPv6 is being used. Which may be > perfectly okay - but if it is not, and we do assert that "An RA with > prefix having an A-bit set and default settings, should not cause the > 10x expansion to the resource requirements compared to Legacy IP", > seems like some sort of a correction in default stacks/apps behavior > with respect to temporary addresses could be useful. FWIW: Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Sep 9 18:13:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF98E1A03C5 for ; Tue, 9 Sep 2014 18:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHMv8XSWREJD for ; Tue, 9 Sep 2014 18:13:40 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708971A0390 for ; Tue, 9 Sep 2014 18:13:40 -0700 (PDT) Received: from [186.134.45.58] (helo=[192.168.123.128]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XRWTY-0008Lp-0d; Wed, 10 Sep 2014 03:13:36 +0200 Message-ID: <540F9DF1.50402@si6networks.com> Date: Tue, 09 Sep 2014 21:40:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Brian Haberman , v6ops@ietf.org References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> In-Reply-To: <540F3432.5030702@innovationslab.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/n3qbuXcQ3eKmJ2b5oeK2EflnaZc Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 01:13:43 -0000 Hi, Brian, On 09/09/2014 02:09 PM, Brian Haberman wrote: >> We probably use MLD because "If you use multicast, you use MLD". Truth >> is that, *unless your switch does MLD snooping* (and hence you *need* >> MLD, or else your packets will not flow around), you could completely >> kill MLD, and ND would still work just fine. > > Sure, since NDP is link-local. The drawback is what happens if your > network is using RFC 4541 snooping that relies on seeing those MLD > messages to build forwarding/filtering tables? Exactly. That's why I said "unless...". >> Not to mention that there are nodes that default t running MLDv2 *for >> this* (way overkill, IMO) > > Why is MLDv2 overkill? If you're just going to use MLD for ND, MLDv2 is unnecessarily complex -- whole different game if you're using non-link-local multicast, of course. That said, I seem to recall the node reqs RFC requires MLDv1, rather than MLDv2? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Sep 9 18:13:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213611A03F4 for ; Tue, 9 Sep 2014 18:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLOZKTJkf29J for ; Tue, 9 Sep 2014 18:13:45 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969331A0390 for ; Tue, 9 Sep 2014 18:13:45 -0700 (PDT) Received: from [186.134.45.58] (helo=[192.168.123.128]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XRWTe-0008M7-5K; Wed, 10 Sep 2014 03:13:42 +0200 Message-ID: <540F9FA9.3070300@si6networks.com> Date: Tue, 09 Sep 2014 21:47:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Brian E Carpenter , Brian Haberman References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> In-Reply-To: <540F65C4.7050503@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ErhqtbbMQhV2MkD-IJjhTVOCUd4 Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 01:13:50 -0000 On 09/09/2014 05:40 PM, Brian E Carpenter wrote: >>> Then, let me change the question: Why do I need MLD for *this*? > > I think Brian Haberman's reply shows why that is the wrong question. > You need MLD for every multicast group, including a solicited-node > group, and if you insist on MLD snooping in the bridges (let's not > obfuscate by calling them switches) then you need to snoop every > solicited-node group. > > My question is orthogonal to MLD snooping: why do we require router-alert > for MLD messages referring to a solicited-node group, since it by > definition is limited to a single L2 link (even if that link is > split up by bridges)? .. to avoid them being a special case? -- i.e., all MLD packets carry a Router Alert option. And, actually, an MLD report could potentially include groups other than solicited-node (so you probably wouldn't want to turn the "include a router-alert" on and off). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Sep 9 19:16:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EFC1A039A for ; Tue, 9 Sep 2014 19:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLB_QGAJWwKt for ; Tue, 9 Sep 2014 19:16:11 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0140A1A039B for ; Tue, 9 Sep 2014 19:16:10 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id w10so5128897pde.26 for ; Tue, 09 Sep 2014 19:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8yDNLKN8XEsiChZERhaFWr8CvQoBveZSPGd177zStbM=; b=D42Q52IBb9XFItCGFcpvewznroKZ96RN9+siQ2GwXLEHhy+TYlZH7bAuC6De3b627n YKZBO6Mv3bFIajjybcwzCirmwMEEBqcS/b264U4IgLutgC+R8blyrmNhIdTtnWLDps/H OQm4KeMNdlUHRyWjBDf8fHKFxYMGdlEn30KbmDEfqyQ3CPn/GlgsIUF5edXwB08PxEi0 2P+wImeyZmwelfIAeRVL7O6OZcgzchHOsAqs1Xd4DtD3NZlhDNKD9T5TuqMetsmFsx3V nJW0pR56jP6Hqgn6Z5XUmxy2DEhBaLSK/zRAoo6GGif6igDY11Q8R5nZ/IefrbCMBp7f vuGA== X-Received: by 10.68.103.4 with SMTP id fs4mr34784522pbb.58.1410315370621; Tue, 09 Sep 2014 19:16:10 -0700 (PDT) Received: from [192.168.178.23] (221.199.69.111.dynamic.snap.net.nz. [111.69.199.221]) by mx.google.com with ESMTPSA id v1sm12943916pdp.76.2014.09.09.19.16.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 19:16:10 -0700 (PDT) Message-ID: <540FB46F.2010200@gmail.com> Date: Wed, 10 Sep 2014 14:16:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> In-Reply-To: <540F9FA9.3070300@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kDZa0uOQ9vV3IMYl8Cs-O_aGW20 Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 02:16:13 -0000 On 10/09/2014 12:47, Fernando Gont wrote: > On 09/09/2014 05:40 PM, Brian E Carpenter wrote: >>>> Then, let me change the question: Why do I need MLD for *this*? >> I think Brian Haberman's reply shows why that is the wrong question. >> You need MLD for every multicast group, including a solicited-node >> group, and if you insist on MLD snooping in the bridges (let's not >> obfuscate by calling them switches) then you need to snoop every >> solicited-node group. >> >> My question is orthogonal to MLD snooping: why do we require router-alert >> for MLD messages referring to a solicited-node group, since it by >> definition is limited to a single L2 link (even if that link is >> split up by bridges)? > > .. to avoid them being a special case? -- i.e., all MLD packets carry a > Router Alert option. Yes, it would be an exception. But we know that HbH options in general and Router Alert in particular are a serious performance issue, and that all links carry this particular kind of MLD traffic, so an exception seems like something to be discussed. > And, actually, an MLD report could potentially > include groups other than solicited-node (so you probably wouldn't want > to turn the "include a router-alert" on and off). Sure, the exception would have to be for messages containing only solicited-nodes data. Brian From nobody Tue Sep 9 20:12:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C531A03C8 for ; Tue, 9 Sep 2014 20:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 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=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6rL2bTakPtx for ; Tue, 9 Sep 2014 20:11:57 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A211A041C for ; Tue, 9 Sep 2014 20:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1658; q=dns/txt; s=iport; t=1410318717; x=1411528317; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=szL2A8ijnHPcaFur/B1RRE+fOInjdTOCRHBahtX7E1A=; b=Sf6zhAUK6qjShvSGDl0mBMBhFwKdFBm3Dry66hLlbll+KlLZ7PIjKGHY hosVO6yt01tl1kvVQ0apL9XdCbe/GIt8r6poC/lU1Y3Y4zoGRJh5h/3Dr vDG2H/Kv7Tg1YNKzHsqGkJphlSb3qL2DNsvRPuTrr8V/ysJhIYEzeTMkH s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAB/BD1StJA2E/2dsb2JhbABZgw1TUwQEyhyHSgGBCRZ4hAQBAQMBdwIQAgEIRjIlAgQOBQkFiCwICAW8fwEXj00HCYMmgR0FkUGCBoFKYIcCgV+TT4NhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,495,1406592000"; d="asc'?scan'208";a="76498392" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 10 Sep 2014 03:11:56 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8A3Buae009432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 03:11:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 22:11:56 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: New Version Notification - draft-ietf-v6ops-mobile-device-profile-10.txt Thread-Index: AQHPzKT6lwrk+whw9km71DJCyhc6WA== Date: Wed, 10 Sep 2014 03:11:55 +0000 Message-ID: References: <20140829150134.28129.95250.idtracker@ietfa.amsl.com> In-Reply-To: <20140829150134.28129.95250.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.137.0.108] Content-Type: multipart/signed; boundary="Apple-Mail=_4A3B54F1-928B-494B-BF98-7D6B0B6B3FC0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r_8uYfGhvpC20nhVTNAn18rn5h8 Subject: Re: [v6ops] New Version Notification - draft-ietf-v6ops-mobile-device-profile-10.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, 10 Sep 2014 03:12:01 -0000 --Apple-Mail=_4A3B54F1-928B-494B-BF98-7D6B0B6B3FC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Do me a favor if you would. We have gotten through the comments on the = list and the comments made in the IETF LC a year ago. I=92d like to = believe that this document is done. Is it? I=92ll give people a week to make comments and then make a call. On Aug 30, 2014, at 1:01 AM, internet-drafts@ietf.org wrote: >=20 > A new version (-10) has been submitted for = draft-ietf-v6ops-mobile-device-profile: > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mobile-device-profile= -10.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ >=20 > Diff from previous version: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-= 10 >=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 > IETF Secretariat. >=20 --Apple-Mail=_4A3B54F1-928B-494B-BF98-7D6B0B6B3FC0 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 iD8DBQFUD8DlbjEdbHIsm0MRAh1DAKDzOQ1HyI5xiYV5r+47XVlttFWBrwCg4OCx 2Icqerpif+mnWTeByCIeFLg= =rfax -----END PGP SIGNATURE----- --Apple-Mail=_4A3B54F1-928B-494B-BF98-7D6B0B6B3FC0-- From nobody Tue Sep 9 22:37:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744021A04B8; Tue, 9 Sep 2014 22:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10aycWGkCBYl; Tue, 9 Sep 2014 22:37:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 463A31A04E7; Tue, 9 Sep 2014 22:37:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140910053701.15832.61677.idtracker@ietfa.amsl.com> Date: Tue, 09 Sep 2014 22:37:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6XXFLLnm-y-ODDP7DszbcEQDf60 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-11.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: Wed, 10 Sep 2014 05:37:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-11.txt Pages : 19 Date : 2014-09-09 Abstract: This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 10 01:09:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40381A0679 for ; Wed, 10 Sep 2014 01:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqhTKfxuTKhA for ; Wed, 10 Sep 2014 01:09:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC9F1A0677 for ; Wed, 10 Sep 2014 01:09:14 -0700 (PDT) Received: from [2001:5c0:1000:a::1439] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XRcxg-0002C2-6N; Wed, 10 Sep 2014 10:09:09 +0200 Message-ID: <540FF53E.50903@si6networks.com> Date: Wed, 10 Sep 2014 03:52:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Brian E Carpenter References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com> In-Reply-To: <540FB46F.2010200@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7ePOKbYaOHsaTump_qeK4SYnN4k Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 08:09:17 -0000 Hi, Brian, On 09/09/2014 11:16 PM, Brian E Carpenter wrote: > On 10/09/2014 12:47, Fernando Gont wrote: >> On 09/09/2014 05:40 PM, Brian E Carpenter wrote: >>>>> Then, let me change the question: Why do I need MLD for *this*? >>> I think Brian Haberman's reply shows why that is the wrong question. >>> You need MLD for every multicast group, including a solicited-node >>> group, and if you insist on MLD snooping in the bridges (let's not >>> obfuscate by calling them switches) then you need to snoop every >>> solicited-node group. >>> >>> My question is orthogonal to MLD snooping: why do we require router-alert >>> for MLD messages referring to a solicited-node group, since it by >>> definition is limited to a single L2 link (even if that link is >>> split up by bridges)? >> >> .. to avoid them being a special case? -- i.e., all MLD packets carry a >> Router Alert option. > > Yes, it would be an exception. But we know that HbH options in general > and Router Alert in particular are a serious performance issue, and > that all links carry this particular kind of MLD traffic, so an > exception seems like something to be discussed. Agreed. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Sep 10 03:18:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2CA1A06E6 for ; Wed, 10 Sep 2014 03:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wakHGB5tBtJA for ; Wed, 10 Sep 2014 03:18:30 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC5F1A06DA for ; Wed, 10 Sep 2014 03:18:30 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rl12so5785056iec.14 for ; Wed, 10 Sep 2014 03:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6wY3DWnzi88vMONWSVExh6SI9AwZeMoP50SfVQo8/3Y=; b=nEr8KMKf7eMTn7TppJVblGIyrtGNEXzqrw1LSZqYAwrcxTDurjeMKknIcC8P1XPaON BPoPnVg2bFHG+VFdsO4HIl2GxXrphpZQUn9TdYVkO0do2A5zEpqIoXbxob47D2N485sC 9i8NAO5aLs+9MWyjF9Y4bTQvv4ynJ+2NcHpkcWQHRMuGqeOw+N01kPv1Xzl2aNwiDBeZ 2F/w3tZaiQd52rGvqS+pySQ9nsr8cD3rUF2fzBtl7Yu2RkWYDSQ/d33F2sGJmNAN0wEx omjbEcu01T1P6SRJa+V91q0jUkJC7/39jI5jFGtAgqr5OYFdvJyhsfJaBNbRkpudFX8w 1LZg== MIME-Version: 1.0 X-Received: by 10.42.23.16 with SMTP id q16mr45913769icb.0.1410344309798; Wed, 10 Sep 2014 03:18:29 -0700 (PDT) Received: by 10.107.137.39 with HTTP; Wed, 10 Sep 2014 03:18:29 -0700 (PDT) In-Reply-To: <540FB46F.2010200@gmail.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com> Date: Wed, 10 Sep 2014 12:18:29 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_OW6mBlTqnaxddXf6_e1vHTift0 Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 10:18:31 -0000 On 9/10/14, Brian E Carpenter wrote: > On 10/09/2014 12:47, Fernando Gont wrote: >> On 09/09/2014 05:40 PM, Brian E Carpenter wrote: >>>>> Then, let me change the question: Why do I need MLD for *this*? >>> I think Brian Haberman's reply shows why that is the wrong question. >>> You need MLD for every multicast group, including a solicited-node >>> group, and if you insist on MLD snooping in the bridges (let's not >>> obfuscate by calling them switches) then you need to snoop every >>> solicited-node group. >>> >>> My question is orthogonal to MLD snooping: why do we require >>> router-alert >>> for MLD messages referring to a solicited-node group, since it by >>> definition is limited to a single L2 link (even if that link is >>> split up by bridges)? >> >> .. to avoid them being a special case? -- i.e., all MLD packets carry a >> Router Alert option. > > Yes, it would be an exception. But we know that HbH options in general > and Router Alert in particular are a serious performance issue, and > that all links carry this particular kind of MLD traffic, so an > exception seems like something to be discussed. How does this interact with the case where a "pure L2" switch within the link would want to snoop MLD ? Presumably, today the L2 switch would see the "router alert" and know that it needs to process this traffic. If this were to be removed, then it would be much trickier to direct the traffic to the slow path in that scenario, wouldn't it ? --a > >> And, actually, an MLD report could potentially >> include groups other than solicited-node (so you probably wouldn't want >> to turn the "include a router-alert" on and off). > > Sure, the exception would have to be for messages containing only > solicited-nodes data. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 10 05:15:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A991F1A002D for ; Wed, 10 Sep 2014 05:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQpJl1FzhhpN for ; Wed, 10 Sep 2014 05:15:29 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8303F1A0023 for ; Wed, 10 Sep 2014 05:15:29 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 66B8E880DB; Wed, 10 Sep 2014 05:15:29 -0700 (PDT) Received: from 102529956.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B1B471B0001; Wed, 10 Sep 2014 05:15:29 -0700 (PDT) Message-ID: <541040E1.1060701@innovationslab.net> Date: Wed, 10 Sep 2014 08:15:29 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> In-Reply-To: <540F65C4.7050503@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="95dxQm5qUwaAq2bV05e2OukqEa5nMeOpf" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/x8-xe9VDMnKm28m2GFiQEM2-qZ0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 12:15:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --95dxQm5qUwaAq2bV05e2OukqEa5nMeOpf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, On 9/9/14 4:40 PM, Brian E Carpenter wrote: > On 10/09/2014 05:09, Brian Haberman wrote: >> >> On 9/9/14 10:16 AM, Fernando Gont wrote: >>> On 09/09/2014 04:20 AM, Brian E Carpenter wrote: >>>>>> OK, but I would also like to understand why we require >>>>>> MLD messages for a Solicited-Node multicast address to >>>>>> set Router Alert. >>>>> Because in theory the multicast router needs to process the MLD mes= sage >>>>> to build its forwarding table.... >>>> Why, for the Solicited-Node group, which is only meaningful on the l= ink >>>> from which the MLD message arrives? >>> Then, let me change the question: Why do I need MLD for *this*? >=20 > I think Brian Haberman's reply shows why that is the wrong question. > You need MLD for every multicast group, including a solicited-node > group, and if you insist on MLD snooping in the bridges (let's not > obfuscate by calling them switches) then you need to snoop every > solicited-node group. >=20 > My question is orthogonal to MLD snooping: why do we require router-ale= rt > for MLD messages referring to a solicited-node group, since it by > definition is limited to a single L2 link (even if that link is > split up by bridges)? >=20 > I tend to think this requirement is an error in the MLD spec. This is an interesting point. The use of Router Alert was carried through the various versions of IGMP/MLD from the original IGMPv1 spec. Since IGMPv1, IGMPv2, and MLDv1 sent Reports to the group address, the Router Alert was meant to signal to routers that they needed to process the packet. There are two things that I think have changed. 1) Routers tend to trigger processing based on the Protocol or Next Header field. I think it would be worthwhile to verify with router vendors that they do not use the Router Alert to trigger processing. 2) IGMPv3 and MLDv2 now send Reports are sent to an all-multicast-routers multicast address. Regards, Brian H >=20 > Brian C >=20 >> The MLD specs say that an MLD Report is sent for every multicast group= >> joined except the All-Nodes multicast address. >> >> The use of MLD Reports for essentially all multicast addresses was don= e >> to facilitate this very type of snooping functionality. The use of >> Router Alerts in MLD messages is due to MLDv1 (and IGMPv2) using the >> group address as the IP destination rather than the All-Routers >> multicast address. >> >>> We probably use MLD because "If you use multicast, you use MLD". Trut= h >>> is that, *unless your switch does MLD snooping* (and hence you *need*= >>> MLD, or else your packets will not flow around), you could completely= >>> kill MLD, and ND would still work just fine. >> >> Sure, since NDP is link-local. The drawback is what happens if your >> network is using RFC 4541 snooping that relies on seeing those MLD >> messages to build forwarding/filtering tables? >> >>> Not to mention that there are nodes that default t running MLDv2 *for= >>> this* (way overkill, IMO) >>> >> >> Why is MLDv2 overkill? >> >> Brian >> >> >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --95dxQm5qUwaAq2bV05e2OukqEa5nMeOpf 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEEDhAAoJEBOZRqCi7goqHXQH/inf4cfT3+GAlVgcz9t9dHxd 4A/HfqCrtgG56J9BDMeZ5G0RW43/hh6QwT04XsOMIBHg+alnSjombYJIeZ0PyD2Q B3C4YsoAZZXgW6EYRuO5ju5dfEqytnF+fvWLPRjd1x7P5TbNOge/F2nMj1IreGvX rNOtbfUIND2alAXrktdUUUSgCzVd9ssg7cKQdi8vr7+X5++/O83YcsUPzk5RfQiO pdC/5X7+qexGk1M3baIa3rVHFu1ktLHFnNibhWsefMSW4k/KcYJ/a+MrVBHl7toz P1E6A0ZU44nKvWcjvvgoqaurm9KwZFhC8EttsJZfpTlasVo3RDai7ac5QYZ6v0o= =S0dV -----END PGP SIGNATURE----- --95dxQm5qUwaAq2bV05e2OukqEa5nMeOpf-- From nobody Wed Sep 10 05:19:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A931A0033 for ; Wed, 10 Sep 2014 05:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2pSZTgQWc2c for ; Wed, 10 Sep 2014 05:19:39 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFF91A6FC2 for ; Wed, 10 Sep 2014 05:19:16 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A6CD4880DB; Wed, 10 Sep 2014 05:19:16 -0700 (PDT) Received: from 102529956.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5338C71B0001; Wed, 10 Sep 2014 05:19:16 -0700 (PDT) Message-ID: <541041C5.4030109@innovationslab.net> Date: Wed, 10 Sep 2014 08:19:17 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , v6ops@ietf.org References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F9DF1.50402@si6networks.com> In-Reply-To: <540F9DF1.50402@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cMegbeoAq0ujQ5ijGtUxsdNcv3Ckpqihi" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QO-9xpqC-sW6eE04bzFcr2YCm9Y Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 12:19:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cMegbeoAq0ujQ5ijGtUxsdNcv3Ckpqihi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9/9/14 8:40 PM, Fernando Gont wrote: > Hi, Brian, >=20 > On 09/09/2014 02:09 PM, Brian Haberman wrote: >>> We probably use MLD because "If you use multicast, you use MLD". Trut= h >>> is that, *unless your switch does MLD snooping* (and hence you *need*= >>> MLD, or else your packets will not flow around), you could completely= >>> kill MLD, and ND would still work just fine. >> >> Sure, since NDP is link-local. The drawback is what happens if your >> network is using RFC 4541 snooping that relies on seeing those MLD >> messages to build forwarding/filtering tables? >=20 > Exactly. That's why I said "unless...". >=20 >=20 >=20 >>> Not to mention that there are nodes that default t running MLDv2 *for= >>> this* (way overkill, IMO) >> >> Why is MLDv2 overkill? >=20 > If you're just going to use MLD for ND, MLDv2 is unnecessarily complex > -- whole different game if you're using non-link-local multicast, of co= urse. I disagree. When sending MLD Reports for NDP, you don't need to involve the complexity of MLDv2 source filters. You simply send a group-only Report message. >=20 > That said, I seem to recall the node reqs RFC requires MLDv1, rather > than MLDv2? Seems orthogonal to the discussion since MLDv2 can act in MLDv1 mode for these link-local multicast groups. Additionally, RFC 5790 has simplified MLDv2 to avoid some complexities. Regards, Brian --cMegbeoAq0ujQ5ijGtUxsdNcv3Ckpqihi 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEEHFAAoJEBOZRqCi7goquP8H/RYahdskRHrEWyuUowaP2qxW 8EquUZBATzoybwxJRtoXpAVgog2fM94AfzO2X7laTSx6s4LS7jAxGb1iGZGQGI+t WX2d7fVbHgP7nvKLUs4TBPimc/+l2M5/DcYxJTFMROP5yICUH6Ca6zjVQz7jnHwX Peik8JPxYA3m4okL6g9y4v1XMxsat11u4LlV/rNAU4Rdrz5kpxVExhVo7VyL30Mv k36RVTRLObStTzUU/4z7m6VZn7v0kZp029nG3MrvuTaBS2hpBoXEAtBXUu+0BIFq JKoMDarFlK0IEH+8CEgFXJew+do9Sj4YfY+7gSY3f205T9nuB6TZ7UezDzokHY8= =IWch -----END PGP SIGNATURE----- --cMegbeoAq0ujQ5ijGtUxsdNcv3Ckpqihi-- From nobody Wed Sep 10 05:26:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A541A0039 for ; Wed, 10 Sep 2014 05:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juvUGCpaoY_v for ; Wed, 10 Sep 2014 05:26:38 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D321A002B for ; Wed, 10 Sep 2014 05:26:38 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2F933880F7 for ; Wed, 10 Sep 2014 05:26:38 -0700 (PDT) Received: from 102529956.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E8CBF71B0001 for ; Wed, 10 Sep 2014 05:26:37 -0700 (PDT) Message-ID: <5410437E.2070208@innovationslab.net> Date: Wed, 10 Sep 2014 08:26:38 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4mhBApJCuU08wgW492FLRUeq2s2tQJVno" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/myCd4iXUp3T9UB1Fa3aRrBpPFW0 Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 12:26:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4mhBApJCuU08wgW492FLRUeq2s2tQJVno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andrew, On 9/10/14 6:18 AM, Andrew =F0=9F=91=BD Yourtchenko wrote: > On 9/10/14, Brian E Carpenter wrote: >> On 10/09/2014 12:47, Fernando Gont wrote: >>> On 09/09/2014 05:40 PM, Brian E Carpenter wrote: >>>>>> Then, let me change the question: Why do I need MLD for *this*? >>>> I think Brian Haberman's reply shows why that is the wrong question.= >>>> You need MLD for every multicast group, including a solicited-node >>>> group, and if you insist on MLD snooping in the bridges (let's not >>>> obfuscate by calling them switches) then you need to snoop every >>>> solicited-node group. >>>> >>>> My question is orthogonal to MLD snooping: why do we require >>>> router-alert >>>> for MLD messages referring to a solicited-node group, since it by >>>> definition is limited to a single L2 link (even if that link is >>>> split up by bridges)? >>> >>> .. to avoid them being a special case? -- i.e., all MLD packets carr= y a >>> Router Alert option. >> >> Yes, it would be an exception. But we know that HbH options in general= >> and Router Alert in particular are a serious performance issue, and >> that all links carry this particular kind of MLD traffic, so an >> exception seems like something to be discussed. >=20 > How does this interact with the case where a "pure L2" switch within > the link would want to snoop MLD ? Presumably, today the L2 switch > would see the "router alert" and know that it needs to process this > traffic. >=20 > If this were to be removed, then it would be much trickier to direct > the traffic to the slow path in that scenario, wouldn't it ? I think that depends. As I mentioned in an earlier e-mail, some routers simply use the IPv4 Protocol field or the IPv6 Next Header field to see if they need to process the packet. It is unclear (to me) how many implementations still use the Router Alert to determine if the packet needs local processing. Maybe some vendors could chime in? Regards, Brian --4mhBApJCuU08wgW492FLRUeq2s2tQJVno 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEEN+AAoJEBOZRqCi7goqtQkIAJPf1TM8C95roi2ciPb7UyJ/ vJ/Xh7anvvRRVh0cDPPPvYngWgqssKeoRfMsxepjMQcq/Lo0EZcblHpGgAN0hKlf Mw9uYo6QuhpN/P4YKaJo5JUt3++By+U3qyyihlr3CI7DWPzR3lBYXU+6rxNZZ1RY u+ZhBQ/v4ExzP8qUl6YF9rlFZD+6mnm3g2vRZFje/Tsxmc/6a1g+Zswu+CIPi7QF 8XpkNZk0opjkcP34pXotm40K+YXeahZ5APVz5WhTJgKUl5wv+hm+t4wkjYv6DOYt MyXguOehkYdDmxo++q4DrtWyWI1GJI4KM4CbcCyPkxo2JrU2+EX1OZsB77JmdTo= =Li9A -----END PGP SIGNATURE----- --4mhBApJCuU08wgW492FLRUeq2s2tQJVno-- From nobody Wed Sep 10 06:40:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102721A8033 for ; Wed, 10 Sep 2014 06:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf-52DuzVctQ for ; Wed, 10 Sep 2014 06:40:48 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556981A7022 for ; Wed, 10 Sep 2014 06:40:48 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id tp5so8526728ieb.9 for ; Wed, 10 Sep 2014 06:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Jh8wbmIpHLXYt1GfsnQrwAUw+kYHP2f38CZC/gnbYFA=; b=h0wWgbwpcNFKKwQGl/VvRrGXkySjD1CFF+ITB6VdmNG9w5kIkY9GcZAr6fmMlQUomd Xo66TiWyUZRgQx3snlpJG4z7Amkc8h8XyCqIuA65BMcmlfautpt0UCUCQDROJOt+qKdA OMFXd9bGJXkmrjOIhcImeUGVWb6MD1ysYpJ2amSMT5qV5oOLA7c/tM3wv0wEMmaU64KV AeBjYmN39IlBVlwlCsn2Ng1+5/F5viCWDl/50GHU6q4rkbgym5MjrJATjdWQMjvnSLDG 4wlFX1IOB8bberpoX6TcGpxt9v9OwcQ1YRA0UwUc6pCWvYBTHiLG/LL4wA2n7PSAN3wX o8dw== MIME-Version: 1.0 X-Received: by 10.42.114.130 with SMTP id g2mr46097320icq.46.1410356447626; Wed, 10 Sep 2014 06:40:47 -0700 (PDT) Received: by 10.107.137.39 with HTTP; Wed, 10 Sep 2014 06:40:47 -0700 (PDT) In-Reply-To: <540F9BE0.5060403@si6networks.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <540F9BE0.5060403@si6networks.com> Date: Wed, 10 Sep 2014 15:40:47 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/l15DoudQ-N5aVy-s3Lr9lvh6lFk Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 13:40:50 -0000 On 9/10/14, Fernando Gont wrote: > On 09/09/2014 12:41 PM, Andrew =F0=9F=91=BD Yourtchenko wrote: >> >> Of course, the amount of manual work this requires today means that >> the A-bit is turned off and the DHCPv6 is being used. Which may be >> perfectly okay - but if it is not, and we do assert that "An RA with >> prefix having an A-bit set and default settings, should not cause the >> 10x expansion to the resource requirements compared to Legacy IP", >> seems like some sort of a correction in default stacks/apps behavior >> with respect to temporary addresses could be useful. > > FWIW: > Yes, we even discussed this draft with you at some point :-). My opinion (while agreeing with the spirit of this draft, somewhat) is still - it is too late. All it would do today is split the hosts into two groups - who understand this bit, and those who do not, adding more difficulty to the life of network administrator, who, having turned the knob "no temp address please" would expect one behavior, and get a mix of two in the best case. (This all puts aside any philosophical arguments of whether the network should dictate the nodes whether they can use the temporary "privacy" addresses or not: temporary addresses go against the incentives of basically *any* sufficiently large network administrator, so this bit would be almost universally on). If the host OSes/apps want to be sensible with the usage of temporary addresses, they can do so without any flag. --a > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > From nobody Wed Sep 10 07:33:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE61A02EF for ; Wed, 10 Sep 2014 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 7Ej181fVuUHA for ; Wed, 10 Sep 2014 07:33:46 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A861A01FF for ; Wed, 10 Sep 2014 07:33:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s8AEXjM4023296; Wed, 10 Sep 2014 07:33:45 -0700 Received: from XCH-BLV-408.nw.nos.boeing.com (xch-blv-408.nw.nos.boeing.com [130.247.25.166]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8AEXh8Z023199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Sep 2014 07:33:43 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.96]) with mapi id 14.03.0181.006; Wed, 10 Sep 2014 07:33:42 -0700 From: "Templin, Fred L" To: Mark Andrews Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPzAOas1qEEvpydkaz7jvT8FP9mpv43h1QgAB+0ID//5L4IIAAX9M9gAEfm4A= Date: Wed, 10 Sep 2014 14:33:42 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D15327@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <54020ECC.4000000@globis.net> <5402C26A.8060304@globis.net> <540626F6.1020103@scea.com> <2134F8430051B64F815C691A62D9831832D12EED@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D13130@XCH-BLV-504.nw.nos.boeing.com> <20140909211947.69A5B1F2609A@rock.dv.isc.org> In-Reply-To: <20140909211947.69A5B1F2609A@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WHAn1FoodU6VVhIGDosa4kfIxJA Cc: "v6ops@ietf.org" , Tom Perrine Subject: Re: [v6ops] PMTUD issue discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 14:33:48 -0000 Hi Mark, > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Tuesday, September 09, 2014 2:20 PM > To: Templin, Fred L > Cc: Mikael Abrahamsson; v6ops@ietf.org; Tom Perrine > Subject: Re: [v6ops] PMTUD issue discussion >=20 >=20 > In message <2134F8430051B64F815C691A62D9831832D13130@XCH-BLV-504.nw.nos.b= oeing.com>, "Templin, Fred L" > writes: > > Hi Mikael, > > > > > -----Original Message----- > > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > > Sent: Tuesday, September 09, 2014 8:08 AM > > > To: Templin, Fred L > > > Cc: Tom Perrine; v6ops@ietf.org > > > Subject: RE: [v6ops] PMTUD issue discussion > > > > > > On Tue, 9 Sep 2014, Templin, Fred L wrote: > > > > > > > This could be problematic when PMTUD is not functioning correctly. = As a > > > > result, IMHO any end system that wants to try for packet sizes larg= er > > > > than 1500 really should be using RFC4821 (maybe even MUST?). > > > > > > Well, even that might not solve it as there might be devices along th= e > > > path that re-assemble the packets (if they're fragmented) and then > > > fragment them again, which will break things anyway. > > > > I think RFC4821 only applies to whole packets with DF=3D1 (i.e., where > > all IPv6 packets implicitly have DF=3D1), but I get your point. > > > > > But yes, supporting 4821 or PMTUD blackhole detection should definite= ly be > > > a requirement. > > > > OK. > > > > > One problem is that a lot of people don't even know that sending a 16= k UDP > > > packet fragmented into a bunch of smaller fragments, is a perfectly v= alid > > > use of IP. They're so used to TCP and its MSS that this is all they'v= e > > > seen. > > > > Yes, isolated large UDP packets with DF=3D0 must be dealt with. >=20 > Actually there is plenty of fragmented UDP traffic. Pick just about > any IPv6 DNSSEC aware recursive nameserver and you will almost > certainly see fragmented IPv6 UDP responses. This traffic is only > increasing as more zones become signed pushing response size well > over 1500. >=20 > Below is from BIND 9.10 which tracks UDP response sizes. Find a > busy resolver and you will find a lot more. The EDNS field shows > timeouts at various EDNS UDP buffer sizes. A timeout at a small > size is counted against larger sizes as well as named tries to > workout the DNS/UDP mtu which can be as low as 512 as some firewalls > "know" that DNS/UDP payloads "never" exceeded 512 bytes. >=20 > This nameserver is behind a HE tunnel so it also has to deal with > authorative nameservers that block PTB to them. Named also forces > fragmentation at 1280 on all sockets if it can. The savings for a > nameserver in sending bigger packets just aren't there. >=20 > [edns success/4096 timeout/1432 timeout/1232 timeout/512 timeout] >=20 > [rock:~/ports] marka% grep srtt /var/named/named_dump.db | grep udpsize |= grep -v "udpsize 512" | grep > : > ; 2001:500:31::63 [srtt 119657] [flags 00806000] [edns 2/0/0/0/0] [plain = 0/0] [udpsize 965] [ttl > 1230] > ; 2001:500:2c::254 [srtt 214672] [flags 00806000] [edns 2/0/0/0/0] [plain= 0/0] [udpsize 1676] [ttl > 1222] > ; 2001:13c7:7002:3000::11 [srtt 242467] [flags 00806000] [edns 2/0/0/0/0]= [plain 0/0] [udpsize > 513] [ttl 1229] > ; 2001:500:60::30 [srtt 229183] [flags 00806000] [edns 4/0/0/0/0] [plain = 0/0] [udpsize 1816] [ttl > 1221] > ; 2001:4f8:0:2::19 [srtt 82726] [flags 00806000] [edns 2/0/0/0/0] [plain = 0/0] [udpsize 1626] [ttl > 1221] > ; 2001:500:13::108 [srtt 115528] [flags 00806000] [edns 2/0/0/0/0] [plain= 0/0] [udpsize 1991] [ttl > 1229] > [rock:~/ports] marka% It is great to have this data. It agrees with what Mikael said, and also agrees with what I was thinking but unfortunately did not say correctly. Strike what I said above, and change: =3D> Yes, isolated large UDP packets with DF=3D0 must be dealt with. to: =3D> Yes, fragmented large UDP packets must be dealt with. Thanks - Fred fred.l.templin@boeing.com >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -- > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 10 14:34:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920521A0194 for ; Wed, 10 Sep 2014 14:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXAnSHyfF3jk for ; Wed, 10 Sep 2014 14:34:47 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C57C1A0184 for ; Wed, 10 Sep 2014 14:34:47 -0700 (PDT) Received: from [2001:5c0:1400:a::14b] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XRpXF-0005td-BF; Wed, 10 Sep 2014 23:34:41 +0200 Message-ID: <5410C3D7.9020401@si6networks.com> Date: Wed, 10 Sep 2014 18:34:15 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Brian Haberman , v6ops@ietf.org References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F9DF1.50402@si6networks.com> <541041C5.4030109@innovationslab.net> In-Reply-To: <541041C5.4030109@innovationslab.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wwekI1DRi72UyPOPSIvc6pFGmpc Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Sep 2014 21:34:50 -0000 Hi, Brian, On 09/10/2014 09:19 AM, Brian Haberman wrote: >>>> Not to mention that there are nodes that default t running MLDv2 *for >>>> this* (way overkill, IMO) >>> >>> Why is MLDv2 overkill? >> >> If you're just going to use MLD for ND, MLDv2 is unnecessarily complex >> -- whole different game if you're using non-link-local multicast, of course. > > I disagree. When sending MLD Reports for NDP, you don't need to involve > the complexity of MLDv2 source filters. You simply send a group-only > Report message. That would still means that you'd have to implement it. For small devices, that might be an issue. And, given how many implementations got ND (which is rather way simpler) wrong one way or another, I wouldn't be surprised to see some interesting behaviors if one were to play with (crafted) MLDv3 packets. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Sep 10 18:33:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9A61A0141 for ; Wed, 10 Sep 2014 18:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RBES73thDSt for ; Wed, 10 Sep 2014 18:33:09 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FFE1A013B for ; Wed, 10 Sep 2014 18:33:09 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so8108185pab.18 for ; Wed, 10 Sep 2014 18:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yB3ol2oTS3u/rlZDkCKTnjp0zhlJFTvzUBFaIhRp/2A=; b=PEf6D9u2PqC/GY2Oh4oLbUroNf6aCe8KxYP9qfoIuNeLM7HjgMj3uaDKsXDOl+wS4w ET67yEo8tFsxMIj2T04kiYdQM8F7tyvc7OGqiiFvu77RSIQ5EAovIe07EQ/IOIVpGSJz D9HxTUrq+8UF5K6sBjPOVaUq1mhy/+0TPW6uphBDmkFn5ECklm80i2MMwHvFzws/ZcUR Wn6sB2iSNuTB2uD/oLM+tC8aQCXf0VHwGRg5OGLZdaxTdiq7TvwU5lclMtALksTKf1eM FYVelnlXyejvDsysSqL8zr+DMH/YDVAqZlviHVOcq4xvTAapfIk/drP9jSehHeJwVPD5 /U8w== X-Received: by 10.70.49.12 with SMTP id q12mr1558251pdn.5.1410399189177; Wed, 10 Sep 2014 18:33:09 -0700 (PDT) Received: from [192.168.178.23] (4.195.69.111.dynamic.snap.net.nz. [111.69.195.4]) by mx.google.com with ESMTPSA id wh10sm16547734pac.20.2014.09.10.18.33.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 18:33:08 -0700 (PDT) Message-ID: <5410FBDB.1070507@gmail.com> Date: Thu, 11 Sep 2014 13:33:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com> <5410437E.2070208@innovationslab.net> In-Reply-To: <5410437E.2070208@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zE0MUGyqVFmZAIVqpmnbixykN8M Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Sep 2014 01:33:10 -0000 On 11/09/2014 00:26, Brian Haberman wrote: > Hi Andrew, >=20 > On 9/10/14 6:18 AM, Andrew =F0=9F=91=BD Yourtchenko wrote: >> On 9/10/14, Brian E Carpenter wrote: >>> On 10/09/2014 12:47, Fernando Gont wrote: >>>> On 09/09/2014 05:40 PM, Brian E Carpenter wrote: >>>>>>> Then, let me change the question: Why do I need MLD for *this*? >>>>> I think Brian Haberman's reply shows why that is the wrong question= =2E >>>>> You need MLD for every multicast group, including a solicited-node >>>>> group, and if you insist on MLD snooping in the bridges (let's not >>>>> obfuscate by calling them switches) then you need to snoop every >>>>> solicited-node group. >>>>> >>>>> My question is orthogonal to MLD snooping: why do we require >>>>> router-alert >>>>> for MLD messages referring to a solicited-node group, since it by >>>>> definition is limited to a single L2 link (even if that link is >>>>> split up by bridges)? >>>> .. to avoid them being a special case? -- i.e., all MLD packets car= ry a >>>> Router Alert option. >>> Yes, it would be an exception. But we know that HbH options in genera= l >>> and Router Alert in particular are a serious performance issue, and >>> that all links carry this particular kind of MLD traffic, so an >>> exception seems like something to be discussed. >> How does this interact with the case where a "pure L2" switch within >> the link would want to snoop MLD ? Presumably, today the L2 switch >> would see the "router alert" and know that it needs to process this >> traffic. >> >> If this were to be removed, then it would be much trickier to direct >> the traffic to the slow path in that scenario, wouldn't it ? >=20 > I think that depends. As I mentioned in an earlier e-mail, some router= s > simply use the IPv4 Protocol field or the IPv6 Next Header field to see= > if they need to process the packet. It is unclear (to me) how many > implementations still use the Router Alert to determine if the packet > needs local processing. Maybe some vendors could chime in? I have the impression that many boxes will look at *any* ICMPv6 packet, because in their firewall role they filter ICMPv6. In that case the Router Alert is certainly redundant. However, we do need vendor feedback, as you say. Brian C From nobody Wed Sep 10 19:41:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37B61A046B for ; Wed, 10 Sep 2014 19:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYMUS9Tk9kgg for ; Wed, 10 Sep 2014 19:41:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C751A0456 for ; Wed, 10 Sep 2014 19:41:38 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s8B2faL6096550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Sep 2014 02:41:37 GMT (envelope-from joelja@bogus.com) Message-ID: <54110BDA.9000104@bogus.com> Date: Wed, 10 Sep 2014 19:41:30 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Brian E Carpenter , Brian Haberman References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com> <5410437E.2070208@innovationslab.net> <5410FBDB.1070507@gmail.com> In-Reply-To: <5410FBDB.1070507@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0akRQhhO6DVDwIxRJ39JA4jbOgd9KbCLG" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 11 Sep 2014 02:41:37 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ohR_MICsCiRfw8nZJ5i0SQfevWw Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Sep 2014 02:41:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0akRQhhO6DVDwIxRJ39JA4jbOgd9KbCLG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/10/14 6:33 PM, Brian E Carpenter wrote: > On 11/09/2014 00:26, Brian Haberman wrote: >> Hi Andrew, >> >> On 9/10/14 6:18 AM, Andrew =F0=9F=91=BD Yourtchenko wrote: >>> On 9/10/14, Brian E Carpenter wrote: >>>> On 10/09/2014 12:47, Fernando Gont wrote: >>>>> On 09/09/2014 05:40 PM, Brian E Carpenter wrote: >>>>>>>> Then, let me change the question: Why do I need MLD for *this*? >>>>>> I think Brian Haberman's reply shows why that is the wrong questio= n. >>>>>> You need MLD for every multicast group, including a solicited-node= >>>>>> group, and if you insist on MLD snooping in the bridges (let's not= >>>>>> obfuscate by calling them switches) then you need to snoop every >>>>>> solicited-node group. >>>>>> >>>>>> My question is orthogonal to MLD snooping: why do we require >>>>>> router-alert >>>>>> for MLD messages referring to a solicited-node group, since it by >>>>>> definition is limited to a single L2 link (even if that link is >>>>>> split up by bridges)? >>>>> .. to avoid them being a special case? -- i.e., all MLD packets ca= rry a >>>>> Router Alert option. >>>> Yes, it would be an exception. But we know that HbH options in gener= al >>>> and Router Alert in particular are a serious performance issue, and >>>> that all links carry this particular kind of MLD traffic, so an >>>> exception seems like something to be discussed. >>> How does this interact with the case where a "pure L2" switch within >>> the link would want to snoop MLD ? Presumably, today the L2 switch >>> would see the "router alert" and know that it needs to process this >>> traffic. >>> >>> If this were to be removed, then it would be much trickier to direct >>> the traffic to the slow path in that scenario, wouldn't it ? >> >> I think that depends. As I mentioned in an earlier e-mail, some route= rs >> simply use the IPv4 Protocol field or the IPv6 Next Header field to se= e >> if they need to process the packet. It is unclear (to me) how many >> implementations still use the Router Alert to determine if the packet >> needs local processing. Maybe some vendors could chime in? >=20 > I have the impression that many boxes will look at *any* ICMPv6 > packet, because in their firewall role they filter ICMPv6. > In that case the Router Alert is certainly redundant. However, > we do need vendor feedback, as you say. Beware equating filtering with with inspection by the control plane, many asic based forwarding platforms ingress acl matches are never slow path. they wouldn't be useful for dos protection if they had to hit a cpu= =2E >=20 > Brian C >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --0akRQhhO6DVDwIxRJ39JA4jbOgd9KbCLG 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 iEYEARECAAYFAlQRC9sACgkQ8AA1q7Z/VrJNswCgiSA+TTlUsYFETJg9RXMD+qmm gmgAniMpaF5DMIkeMb56HZeIqi4AB+0v =bhac -----END PGP SIGNATURE----- --0akRQhhO6DVDwIxRJ39JA4jbOgd9KbCLG-- From nobody Thu Sep 11 05:36:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9FB1A0860 for ; Thu, 11 Sep 2014 05:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOVQ0f2VSpZ9 for ; Thu, 11 Sep 2014 05:36:01 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC211A0709 for ; Thu, 11 Sep 2014 05:36:01 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 099DE88122; Thu, 11 Sep 2014 05:36:01 -0700 (PDT) Received: from 1025297146.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9FA3971B0001; Thu, 11 Sep 2014 05:36:00 -0700 (PDT) Message-ID: <5411972F.4050407@innovationslab.net> Date: Thu, 11 Sep 2014 08:35:59 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: joel jaeggli , Brian E Carpenter References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com> <5410437E.2070208@innovationslab.net> <5410FBDB.1070507@gmail.com> <54110BDA.9000104@bogus.com> In-Reply-To: <54110BDA.9000104@bogus.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qjPjdan1BPAHPuuRo8RfVwAFNFSja8ehe" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KjHOFjMoIqDmAEvFXCen9QDbaZA Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Sep 2014 12:36:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qjPjdan1BPAHPuuRo8RfVwAFNFSja8ehe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joel, On 9/10/14 10:41 PM, joel jaeggli wrote: >=20 > Beware equating filtering with with inspection by the control plane, > many asic based forwarding platforms ingress acl matches are never slow= > path. they wouldn't be useful for dos protection if they had to hit a c= pu. >=20 Agreed. What I am looking for is vendor input on whether Router Alerts are still needed for IGMP/MLD messages. Regards, Brian --qjPjdan1BPAHPuuRo8RfVwAFNFSja8ehe 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEZcvAAoJEBOZRqCi7goqDN8H/17DW8+Z5oafgRR2ZsxJdXgk oGt1PDherP5U477yQ/Ed6DSearkLNgSPe7xCbebB7m+3mvuVJT3VydLku76lXEKn JbzDJ00dFh9Sr0n0abzxyT6g6UOxxRKXBeYaOEL6h+Zal2EVSsiYFRtnqPPTeUL8 Ee8KoqFYXZrA0BCNHP7faC9VSyVgK/XmB1jdYDXboz+mpNpHx3pSPST7XSWDn83q Rp1f2idEtZbF4wc3EvOuZdEOXkY7xLkgKyNoYYGjdkGbBYhSuspdGQz4YKUesWGc yTq4ll5keyCI3Scq2urquSknWIAZC1l1X0ui+oGaSYNJ6Rskv/X7DqyFUHQuVk0= =GzIZ -----END PGP SIGNATURE----- --qjPjdan1BPAHPuuRo8RfVwAFNFSja8ehe-- From nobody Fri Sep 12 00:45:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70141A0659 for ; Fri, 12 Sep 2014 00:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grYU5car3YdF for ; Fri, 12 Sep 2014 00:45:22 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906C51A048E for ; Fri, 12 Sep 2014 00:45:22 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id f73so196727yha.19 for ; Fri, 12 Sep 2014 00:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ARFy9eqrOIVeygoxPwOXVHbz3BJUTJbGRMEWtt6zrGM=; b=CqXm1brFPiIFs4GbO4cBShNqX2peGKZb2lkRBrZe8F9AJGQRSOPMi4TjezWKyg2MOI KXJ/5u743Rk7ATsC9nrla1cB0dl27m52qfifKJD1iH3RIK5R8O9Py2yA4qZXAJQqNGWa bB479ILyMakSy9k81MQQyl4nQnvM+4ba3uxj+xzuHu76z2a+0xdSvy3AL6zr+KW8nyE1 jwzNfevA0Tjrfb/9XNgB+vXKv4v9KOc/u2FJaJSmvzJvRBR+D6Nx5ZSiOGz+2yf+h3TS F3VBNhWfjJ2QfO6qHPe8ZRAbaBms762kUf6hlZsHhpFOGiV0qbTG9ULPqV4s4JPapQu7 FrEA== X-Received: by 10.236.98.103 with SMTP id u67mr8005084yhf.14.1410507921710; Fri, 12 Sep 2014 00:45:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.133.207 with HTTP; Fri, 12 Sep 2014 00:44:41 -0700 (PDT) In-Reply-To: <53E44C55.9020306@si6networks.com> References: <20140808035717.19737.51768.idtracker@ietfa.amsl.com> <53E44C55.9020306@si6networks.com> From: Qiong Date: Fri, 12 Sep 2014 15:44:41 +0800 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c1dce8a063bf0502d97796 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6A0vdgGjcpiACW1_PpfXLZpD7aM Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Sep 2014 07:45:26 -0000 --001a11c1dce8a063bf0502d97796 Content-Type: text/plain; charset=UTF-8 Hi Fernando, This document has been a nice read. Do you know how to test if a server is vulnerable to the attack described in the document? And do you know the number of servers that are vulnerable to this attack? Thanks Best wishes Qiong On Fri, Aug 8, 2014 at 12:04 PM, Fernando Gont wrote: > Folks, > > We have published a new I-D on the topic of IPv6 Extension Headers > (EHs). The I-D is available at: > < > http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt > >. > > Abstract: > IPv6 Extension Headers allow for the extension of the IPv6 protocol, > and provide support for some core functionality such as IPv6 > fragmentation. However, IPv6 Extension Headers are deemed to present > a challenge to IPv6 implementations and networks, and are known to be > intentionally filtered in some existing IPv6 deployments. This > summarizes the issues associated with IPv6 extension headers, and > presents real-world data regarding the extent to which packets with > IPv6 extension headers are filtered in the public Internet, and where > in the network such filtering occurs. Additionally, it provides some > guidance to operators in troubleshooting IPv6 blackholes resulting > from the use of IPv6 extension headers. Finally, this document > provides some advice to protocol designers, and discusses areas where > further work might be needed. > > Comments and suggestions are welcome. > > Thanks! > > Best regards, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt > Date: Thu, 07 Aug 2014 20:57:17 -0700 > From: internet-drafts@ietf.org > To: J. Linkova , Shucheng LIU (Will) > , Tim Chown , Tim Chown > , Fernando Gont , Fernando > Gont , Will (Shucheng) Liu > , J. Linkova > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-v6ops-ipv6-ehs-in-real-world > Revision: 00 > Title: IPv6 Extension Headers in the Real World > Document date: 2014-08-07 > Group: Individual Submission > Pages: 15 > URL: > > http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-in-real-world/ > Htmlized: > http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00 > > > Abstract: > IPv6 Extension Headers allow for the extension of the IPv6 protocol, > and provide support for some core functionality such as IPv6 > fragmentation. However, IPv6 Extension Headers are deemed to present > a challenge to IPv6 implementations and networks, and are known to be > intentionally filtered in some existing IPv6 deployments. This > summarizes the issues associated with IPv6 extension headers, and > presents real-world data regarding the extent to which packets with > IPv6 extension headers are filtered in the public Internet, and where > in the network such filtering occurs. Additionally, it provides some > guidance to operators in troubleshooting IPv6 blackholes resulting > from the use of IPv6 extension headers. Finally, this document > provides some advice to protocol designers, and discusses areas where > further work might be needed. > > > > > > 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 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a11c1dce8a063bf0502d97796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fernando,

This document has bee= n a nice read.

=C2=A0Do you know how to test if a = server is vulnerable to the attack described in the document?
=C2=A0And do you know the number of servers that are vulnerable= to this attack?

Thanks=C2=A0

=
Best wishes
Qiong


On Fri, Aug 8, 2014 at 12:0= 4 PM, Fernando Gont <fgont@si6networks.com> wrote:
Folks,

We have published a new I-D on the topic of IPv6 Extension Headers
(EHs). The I-D is available at:
<http://www.ietf.org/internet-draf= ts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>.

Abstract:
=C2=A0 =C2=A0IPv6 Extension Headers allow for the extension of the IPv6 pro= tocol,
=C2=A0 =C2=A0and provide support for some core functionality such as IPv6 =C2=A0 =C2=A0fragmentation.=C2=A0 However, IPv6 Extension Headers are deeme= d to present
=C2=A0 =C2=A0a challenge to IPv6 implementations and networks, and are know= n to be
=C2=A0 =C2=A0intentionally filtered in some existing IPv6 deployments.=C2= =A0 This
=C2=A0 =C2=A0summarizes the issues associated with IPv6 extension headers, = and
=C2=A0 =C2=A0presents real-world data regarding the extent to which packets= with
=C2=A0 =C2=A0IPv6 extension headers are filtered in the public Internet, an= d where
=C2=A0 =C2=A0in the network such filtering occurs.=C2=A0 Additionally, it p= rovides some
=C2=A0 =C2=A0guidance to operators in troubleshooting IPv6 blackholes resul= ting
=C2=A0 =C2=A0from the use of IPv6 extension headers.=C2=A0 Finally, this do= cument
=C2=A0 =C2=A0provides some advice to protocol designers, and discusses area= s where
=C2=A0 =C2=A0further work might be needed.

Comments and suggestions are welcome.

Thanks!

Best regards,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt
Date: Thu, 07 Aug 2014 20:57:17 -0700
From: internet-drafts@ietf.org<= /a>
To: J. Linkova <furry@google.com= >, Shucheng LIU (Will)
<liushucheng@huawei.com>= ;, Tim Chown <tjc@ecs.soton.ac.uk= >, Tim Chown
<tjc@ecs.soton.ac.uk>, Fer= nando Gont <fgont@si6networks.c= om>, Fernando
Gont <fgont@si6networks.com= >, Will (Shucheng) Liu
<liushucheng@huawei.com>= ;, J. Linkova <furry@google.com&= gt;


A new version of I-D, draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-v6ops-ipv6-ehs-in-= real-world
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Extension Headers in the Real= World
Document date:=C2=A0 2014-08-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:
http://www.ietf.org/internet-drafts/d= raft-gont-v6ops-ipv6-ehs-in-real-world-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-v6= ops-ipv6-ehs-in-real-world/
Htmlized:
http://tools.ietf.org/html/draft-gont-v6ops-ipv6-e= hs-in-real-world-00


Abstract:
=C2=A0 =C2=A0IPv6 Extension Headers allow for the extension of the IPv6 pro= tocol,
=C2=A0 =C2=A0and provide support for some core functionality such as IPv6 =C2=A0 =C2=A0fragmentation.=C2=A0 However, IPv6 Extension Headers are deeme= d to present
=C2=A0 =C2=A0a challenge to IPv6 implementations and networks, and are know= n to be
=C2=A0 =C2=A0intentionally filtered in some existing IPv6 deployments.=C2= =A0 This
=C2=A0 =C2=A0summarizes the issues associated with IPv6 extension headers, = and
=C2=A0 =C2=A0presents real-world data regarding the extent to which packets= with
=C2=A0 =C2=A0IPv6 extension headers are filtered in the public Internet, an= d where
=C2=A0 =C2=A0in the network such filtering occurs.=C2=A0 Additionally, it p= rovides some
=C2=A0 =C2=A0guidance to operators in troubleshooting IPv6 blackholes resul= ting
=C2=A0 =C2=A0from the use of IPv6 extension headers.=C2=A0 Finally, this do= cument
=C2=A0 =C2=A0provides some advice to protocol designers, and discusses area= s where
=C2=A0 =C2=A0further work might be needed.





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

The IETF Secretariat




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



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: = http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--001a11c1dce8a063bf0502d97796-- From nobody Fri Sep 12 01:09:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF45B1A0676 for ; Fri, 12 Sep 2014 01:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_BACKHAIR_22=1, RP_MATCHES_RCVD=-1.652, 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 YfhBThZufVd7 for ; Fri, 12 Sep 2014 01:09:00 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id F20BA1A059F for ; Fri, 12 Sep 2014 01:08:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AA1D9871612; Fri, 12 Sep 2014 10:08:28 +0200 (CEST) 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 rfjN0CeT+hHa; Fri, 12 Sep 2014 10:08:28 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:7c61:ec8c:3d2a:1d78]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 29D94870064; Fri, 12 Sep 2014 10:08:28 +0200 (CEST) Message-ID: <5412A9DB.3060804@globis.net> Date: Fri, 12 Sep 2014 10:07:55 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Chuck Anderson References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> In-Reply-To: <20140909142226.GP15839@angus.ind.WPI.EDU> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2N4tkXw7WzoUy_0UOZhhnn438TY Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Sep 2014 08:09:03 -0000 Chuck Anderson wrote: > Disagree. > > In common practice, ARP doesn't need to scale to hundreds of IPv4 > addresses per host. Unforutnately, IPv6 SLAAC with Privacy Addressing > means that ND and hence MLD does need to scale much larger than ARP > ever did. The cure of using Solicited Node multicast for ND is worse > than the disease of using broadcast for ARP. The obvious history here is that Ethernet was a big yellow cable, multicast was "for free", an (ARP) broadcast disturbed all end nodes causing them to grind to a halt on large L2 nets, whereas a multicast only interrupted a subset of the end nodes. Now Ethernet is effectively a point to point protocol (wired), multicast is certainly not for free (silicon) nor reliable (wireless). > It is not reasonable to expect a switch to scale to maintaining state > for 300 * (# of hosts connected) Solicited-Node multicast groups. > 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable. > 90,000 MLD groups for a 300 port switch stack is also unreasonable. > Most switches cannot handle that many IPv4 multicast groups--expecting > them to handle that many IPv6 multicast groups is unreasonable. Agreed. > How many MLD reports per second have to be processed by the switch CPU > given reports every 150 seconds by each of the many Solicited Node > multicast groups on every connected host? 100 pps? 600 pps? > > What are the scaling numbers for IGMP groups and MLD groups and how > many IGMP/MLD reports can be processed per second on commonly > available access-layer switches? > > Having designed a ubiquitous protocol 16 years ago that can't be > implemented reasonably cheaply on current hardware is an operational > problem that can and should be dealt with by tweaking the protocol in > some cases. I think the protocol change proposals put forward in the > article are a quite reasonable starting point for discussing how to > mitigate this issue and shouldn't be dismissed out of hand. I read the article but did not see the specific recommended tweaks. Can you enumerate? One thing that might be an operational workaround (via OS patch) would be to update 4941 RID generation Section 3.2.12 to add Step 4a so that the candidate privacy addresses all hash to a limited subset of MLD group(s) per host that are used for solicited-node multicast address (RFC 4291 section 2.7.1) e.g. max of 16 MLD active groups per host out of the range FF02:0:0:0:0:1:FFXX:XXXX. As privacy addresses expire, new solicited-node multicast address groups could be activated. That would avoid the large number of multicast update messages per host. It would also put an upper limit of multicast groups a L2 switch would have to support to n * number of hosts in the L2 domain. Downside is that there is obviously less privacy address space to brute force track at any one time. The more fundamental question is whether multicast is the correct way to resolve addresses in modern L2 networks. Or whether on certain link technologies, a protocol that registers hosts over unicast to one or more L3<->L2 nameservers might be more appropriate (as per 6lo), but that is beyond v6ops. > > On Tue, Sep 09, 2014 at 10:43:07AM +0000, Hemant Singh (shemant) wrote: >> Agreed. Just because one vendor’s switch melted an ipv6 network is not enough justification to change protocols. >> >> Hemant >> >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti >> Sent: Tuesday, September 09, 2014 6:29 AM >> To: Nick Hilliard >> Cc: l.wood@surrey.ac.uk; IPv6 Operations >> Subject: Re: [v6ops] Interesting problems with using IPv6 >> >> On Tue, Sep 9, 2014 at 6:42 PM, Nick Hilliard> wrote: >> This happened because the switch CPUs were overloaded with mld report packets due to end hosts on the extended L2 network replying to MLD all-groups queries every 150 seconds. >> >> So the switch was configured to send all-groups queries to all hosts, but did not have the CPU power to process them, and could not, or was not configured, to rate-limit them. >> >> News at 11: building a network beyond the capabilities of the gear that runs it will result in failure. >> >> That does not mean the protocol is flawed. ARP could have done the same thing, and in fact that was a common problem many years ago... except that these days ARP is usually processed on the fast path and it doesn't matter. > > -- Regards, RayH From nobody Fri Sep 12 08:49:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9411A0194 for ; Fri, 12 Sep 2014 08:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 HeQiLCtD_PTc for ; Fri, 12 Sep 2014 08:49:26 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA40D1A0162 for ; Fri, 12 Sep 2014 08:49:25 -0700 (PDT) Received: from [10.0.0.157] (96-24-69-249.sfo.clearwire-wmx.net [96.24.69.249] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8CFnFoW016785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 12 Sep 2014 08:49:16 -0700 Message-ID: <541315FB.8040702@acm.org> Date: Fri, 12 Sep 2014 08:49:15 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , Fernando Gont References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> In-Reply-To: <540EAA55.7000207@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaL9FrFUuWH4MX9Gcv2pNFp04jXzkDkbYX10cuIcN1y8zQBCRxt7u8P/EcmW/VoABZiXhX8QSU4oTpTsX70ftwk X-Sonic-ID: C;BrtsWZQ65BGpFwDu5Qupew== M;gl/JWZQ65BGpFwDu5Qupew== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jEg0taRg3gypG1sjGMYfr0Has-Q Cc: IPv6 Operations , l.wood@surrey.ac.uk Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Sep 2014 15:49:28 -0000 On 9/9/14, 12:20 AM, Brian E Carpenter wrote: > On 09/09/2014 16:10, Fernando Gont wrote: >> On 09/08/2014 06:59 PM, Brian E Carpenter wrote: >>>> See: draft-pashby-magma-simplify-mld-snooping-01 >>> OK, but I would also like to understand why we require >>> MLD messages for a Solicited-Node multicast address to >>> set Router Alert. >> Because in theory the multicast router needs to process the MLD message >> to build its forwarding table.... > Why, for the Solicited-Node group, which is only meaningful on the link > from which the MLD message arrives? Correct. That is true for all the link-local groups. The only reason to report link-local groups is to enable MLD snooping switches. Routers should only care about groups scope > link-local. Thus we can remove router-alert from MLD reports for link-local groups. Another sub-optimal aspect is that when a router sends a MLD query, it gets responses for all groups including link-ocal. Only an MLD query from a snooping switch would need to elicit responses for link-local groups. (That would imply adding some flag to the MLD query which might not be worth-while at this point in time.) Erik > > (NBMA is different of course, but that is not the scenario in the blog.) > > -- or are you arguing that since the >> Dst Addr "includes" the router, the router should process the MLD >> message anyway? > In its role as a node on the same link, participating in ND on that > link, yes. In its role as a forwarding device, surely it should ignore > traffic to the Solicited-Node address? So Router Alert is not > needed. Or am I missing something? > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Sep 12 15:35:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420601A00C2 for ; Fri, 12 Sep 2014 15:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-1.652, 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 O0bEvAKbaiPi for ; Fri, 12 Sep 2014 15:34:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7131A008B for ; Fri, 12 Sep 2014 15:34:54 -0700 (PDT) Received: from [10.5.16.184] ([209.63.144.18]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s8CMYJ9U023950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Sep 2014 15:34:20 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s8CMYJ9U023950 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1410561263; bh=QKf2lWuD5NbUoK2q1ArBO04D0NU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qFqVxvUWAprtylDmBmiYK96xIrCeQ9Sy82AUITU054ZeVIt6dI2WhcKENpGG2usjj QZgwbqUoOIrYDmxxRMA36v59n1UIqHurtOzt/fK9njcuk1RWAw+odhdigDY9LEwpbf 7N8dDnfeXzhqiIOLV9sVr/Sb7frePtgxbu8lZSWA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <20140909142226.GP15839@angus.ind.WPI.EDU> Date: Fri, 12 Sep 2014 15:33:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> To: Chuck Anderson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oOuPFClhjkPu38UzpfEVdo6HaoU Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Sep 2014 22:34:59 -0000 On Sep 9, 2014, at 7:22 AM, Chuck Anderson wrote: > Disagree. =20 >=20 > In common practice, ARP doesn't need to scale to hundreds of IPv4 > addresses per host. Unforutnately, IPv6 SLAAC with Privacy Addressing > means that ND and hence MLD does need to scale much larger than ARP > ever did. The cure of using Solicited Node multicast for ND is worse > than the disease of using broadcast for ARP. Privacy addressing is the true disease here, not ND. Solicited Node = multicast actually isn=92t all that bad in any sane implementation. ARP = has certainly created its share of problems over the years. However, I=92ve never seen privacy addressing result in hundreds of = addresses per host. That would have to be a pretty broken implementation = or some really strange values for preferred/valid. If you use the (relatively standard) 3600/86400, then any addresses that = are more than a day old should get removed from the interface. Assuming you generate a new privacy address every hour, that shouldn=92t = be more than ~25 addresses per interface at any given time. > It is not reasonable to expect a switch to scale to maintaining state > for 300 * (# of hosts connected) Solicited-Node multicast groups. Nor does any rational use of SLAAC+Privacy addresses result in anything = near that. > 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable. 25*48 =3D 1,200, not 15,000. Even if we double that, it=92s still 2,400 = max. A potential improvement could be if privacy addressing created a = persistent random lower 24 bits and only rehashed the upper 40 bits of = the suffix with each address rotation. In that way, you=92d only have ~2 = ND multicast groups per host. > 90,000 MLD groups for a 300 port switch stack is also unreasonable. > Most switches cannot handle that many IPv4 multicast groups--expecting > them to handle that many IPv6 multicast groups is unreasonable. Again, this is not anything close to a real world scale for the = situation. Using hyperbole derived numbers to make things sound bad = enough that you can blame the protocol for a situation that is much more = directly the result of bad network design is absurd. > How many MLD reports per second have to be processed by the switch CPU > given reports every 150 seconds by each of the many Solicited Node > multicast groups on every connected host? 100 pps? 600 pps? Let=92s assume a 300 node subnet (rather large by most standards). Let=92s= further assume that you have 50 SNMGs per host with zero overlap. That=92s a total of 15,000 SNMGs network wide which, divided by 150 = seconds results in a PPS rate of 100. Note, this is double the actual = anticipated number of SNMGs per host and that zero overlap is a worst = case scenario. A switch stack supporting 300 nodes shouldn=92t have any = problem at all forwarding 100PPS. MLD snooping of ND traffic is a pretty bad idea and there=92s really no = good reason for the switch to not simply flood ND traffic. > What are the scaling numbers for IGMP groups and MLD groups and how > many IGMP/MLD reports can be processed per second on commonly > available access-layer switches? You probably aren=92t running a 300-node subnet on lower end common = access-layer switch hardware. It=92s going to require something higher = end than that. > Having designed a ubiquitous protocol 16 years ago that can't be > implemented reasonably cheaply on current hardware is an operational > problem that can and should be dealt with by tweaking the protocol in > some cases. I think the protocol change proposals put forward in the > article are a quite reasonable starting point for discussing how to > mitigate this issue and shouldn't be dismissed out of hand. I think that the protocol can be implemented reasonably cheaply on = current hardware if you don=92t design your network so poorly that the = fact it hasn=92t collapsed in on itself in IPv4 is a minor miracle. Lots = of people have very large IPv6 networks running just fine on a pretty = wide variety of commodity hardware at this point. The OP makes clear a number of places where his network design is an = utter failure waiting to happen, then goes on to blame IPv6 based on = little more than speculation about the cause. Smaller layer 2 zones would greatly improve his situation. Turning off = privacy addressing would also help. (This is, as has been pointed out, = under the control of the network operator as he can set the M bit, turn = off the A bit, and give out DHCP addresses as an example.) I suspect there are a number of other viable solutions. OTOH, modifying = ipv6 to support such an environment seems a fools errand to me. Owen >=20 > On Tue, Sep 09, 2014 at 10:43:07AM +0000, Hemant Singh (shemant) = wrote: >> Agreed. Just because one vendor=92s switch melted an ipv6 network is = not enough justification to change protocols. >>=20 >> Hemant >>=20 >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo = Colitti >> Sent: Tuesday, September 09, 2014 6:29 AM >> To: Nick Hilliard >> Cc: l.wood@surrey.ac.uk; IPv6 Operations >> Subject: Re: [v6ops] Interesting problems with using IPv6 >>=20 >> On Tue, Sep 9, 2014 at 6:42 PM, Nick Hilliard = > wrote: >> This happened because the switch CPUs were overloaded with mld report = packets due to end hosts on the extended L2 network replying to MLD = all-groups queries every 150 seconds. >>=20 >> So the switch was configured to send all-groups queries to all hosts, = but did not have the CPU power to process them, and could not, or was = not configured, to rate-limit them. >>=20 >> News at 11: building a network beyond the capabilities of the gear = that runs it will result in failure. >>=20 >> That does not mean the protocol is flawed. ARP could have done the = same thing, and in fact that was a common problem many years ago... = except that these days ARP is usually processed on the fast path and it = doesn't matter. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 12 16:13:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19161A00A8 for ; Fri, 12 Sep 2014 16:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.354 X-Spam-Level: X-Spam-Status: No, score=-5.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 POK8Tgj90GPf for ; Fri, 12 Sep 2014 16:13:03 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE21A0099 for ; Fri, 12 Sep 2014 16:13:01 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.9/8.14.9) with ESMTP id s8CNCw42015954; Fri, 12 Sep 2014 19:12:58 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU s8CNCw42015954 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1410563578; bh=AmbYsB1leIb9QEhHrIljUsxihqzm5swykDbcpmUfI0k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=RcJZse6Oz+hGpQj9GkTxJMxc7WGx3jy1Oo/CIIjx+462N3BOgOTCjd/1MCQ/IRnFH rIDQ8xKLW9ZZt/yH8fKEorZsfx0JXLUph99B/kfHYnEu66E4M498+HItLdttZOg/O/ GZgamRwyQlpt0HddcUxuLxMGurRJC8Kmud5Es51M= Received: from MX3.WPI.EDU (mx3.wpi.edu [130.215.36.147]) by MAIL1.WPI.EDU (8.14.9/8.14.9) with ESMTP id s8CNCwd2015951; Fri, 12 Sep 2014 19:12:58 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by MX3.WPI.EDU (8.14.4/8.14.4) with ESMTP id s8CNCvtq014989; Fri, 12 Sep 2014 19:12:58 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id s8CNCvUt029477; Fri, 12 Sep 2014 19:12:57 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id s8CNCt0C029476; Fri, 12 Sep 2014 19:12:55 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Fri, 12 Sep 2014 19:12:55 -0400 From: Chuck Anderson To: Owen DeLong Message-ID: <20140912231254.GO31944@angus.ind.WPI.EDU> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> User-Agent: Mutt/1.5.20 (2009-12-10) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Dka1WWIhOFbeUN_F5I6fyCwGLFw Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Sep 2014 23:13:06 -0000 On Fri, Sep 12, 2014 at 03:33:52PM -0700, Owen DeLong wrote: > > It is not reasonable to expect a switch to scale to maintaining state > > for 300 * (# of hosts connected) Solicited-Node multicast groups. > > Nor does any rational use of SLAAC+Privacy addresses result in anything near that. Actually deployed networks are encountering 300+ privacy addresses on some machines. Is that a bug or by design of the OS vendor? I don't know. > > 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable. > > 25*48 = 1,200, not 15,000. Even if we double that, it’s still 2,400 max. > > A potential improvement could be if privacy addressing created a persistent random lower 24 bits and only rehashed the upper 40 bits of the suffix with each address rotation. In that way, you’d only have ~2 ND multicast groups per host. Agreed. Good idea. > > 90,000 MLD groups for a 300 port switch stack is also unreasonable. > > Most switches cannot handle that many IPv4 multicast groups--expecting > > them to handle that many IPv6 multicast groups is unreasonable. > > Again, this is not anything close to a real world scale for the situation. Using hyperbole derived numbers to make things sound bad enough that you can blame the protocol for a situation that is much more directly the result of bad network design is absurd. It isn't hyperbole. It has been observed multiple times by different people: http://blog.bimajority.org/2014/07/16/ipv6-privacy-addresses-windows-just-say-no/ "it was a Windows machine, [...] I saw that it was responsible for the vast majority of those multicast memberships: 350 different multicast groups in all, nearly all of which were “solicited node†groups for different IPv6 “privacy†addresses" http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ "I used Ubuntu as an example, but it is hardly the worst offender. We have seen Windows machines with more than 300 IPv6 addresses" And a thorough description of the problem and possible solutions: http://inconcepts.biz/~jsw/ipv6_nd_problems_with_l2_mcast.pdf > > Having designed a ubiquitous protocol 16 years ago that can't be > > implemented reasonably cheaply on current hardware is an operational > > problem that can and should be dealt with by tweaking the protocol in > > some cases. I think the protocol change proposals put forward in the > > article are a quite reasonable starting point for discussing how to > > mitigate this issue and shouldn't be dismissed out of hand. > > I think that the protocol can be implemented reasonably cheaply on current hardware if you don’t design your network so poorly that the fact it hasn’t collapsed in on itself in IPv4 is a minor miracle. Lots of people have very large IPv6 networks running just fine on a pretty wide variety of commodity hardware at this point. The only reasonable way to avoid this problem today via network design, is to design you network to use DHCPv6 instead of SLAAC or turn off privacy addressing on all hosts. Unfortunately for less managed networks (the exact use case that SLAAC is designed for--hands off) it isn't feasible to go to every host and manually turn off privacy addressing. That means the only practical way to solve this problem is to only ever use DHCPv6. This is a somewhat surprising result, perhaps unanticipated by those who worked on ND & MLD, and probably not desireable for those who champion SLAAC. > Smaller layer 2 zones would greatly improve his situation. Turning off privacy addressing would also help. (This is, as has been pointed out, under the control of the network operator as he can set the M bit, turn off the A bit, and give out DHCP addresses as an example.) He doesn't have large Layer 2 zones. > I suspect there are a number of other viable solutions. OTOH, modifying ipv6 to support such an environment seems a fools errand to me. Modifying ND is not without precedent. From nobody Fri Sep 12 18:56:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF7C1A0258 for ; Fri, 12 Sep 2014 18:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrtEFD4H7SMJ for ; Fri, 12 Sep 2014 18:56:38 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB4A1A026F for ; Fri, 12 Sep 2014 18:56:38 -0700 (PDT) Received: from [2001:5c0:1000:a::fd5] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XScZh-0006Ea-99; Sat, 13 Sep 2014 03:56:29 +0200 Message-ID: <5413A448.2030104@gont.com.ar> Date: Fri, 12 Sep 2014 22:56:24 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Owen DeLong , Chuck Anderson References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> In-Reply-To: <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6MB4mQi1R2OgN_PI2ZZpLeOJ1aI Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 01:56:41 -0000 On 09/12/2014 07:33 PM, Owen DeLong wrote: > A potential improvement could be if privacy addressing created a > persistent random lower 24 bits and only rehashed the upper 40 bits > of the suffix with each address rotation. In that way, you’d only > have ~2 ND multicast groups per host. That would break the sole purpose of privacy addresses. If the lower 24-bits are kept the same, an attacker can correlate the activities of a node along time. 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 nobody Fri Sep 12 19:59:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CBF1A02E2 for ; Fri, 12 Sep 2014 19:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_57=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72kEUfxs9WBJ for ; Fri, 12 Sep 2014 19:59:42 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A771A02D8 for ; Fri, 12 Sep 2014 19:59:42 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id ft15so2442469pdb.18 for ; Fri, 12 Sep 2014 19:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ItxupuhRbXgFyBvoS+GsKAxSxPcyP1biBDCSS+JD+U8=; b=rnV0MgWSpw7bXWrNsMLOb8/qYtehUYQvWbvil+tnCTFx7f/5Yd2lM42J1+9eVtx7+0 FK7pYoCObAzznXu+lLE/CDys3PorekHElZLtKiNasCw0KyyOs3/86Hg1ssZgEFmcr64m ymIj/1GNkpVVOrIBhrYT+QEla5VuxIGmfDw5k5apayu2L13/mVsYbQ2NVXuQFaKAlN2Q XrUivJ3eG74HNrr68Ij9urGyR/SaJerUU0A03dXdOg/O1MvbpCfgwq5q7L5MQYeD9zgz 7sZHba/7wbtLngIR0X84pF0oUnLJ3byhDzsTuijtXxBPJ+0ktmEPas2Wmiwt8wkULhj4 KzTw== X-Received: by 10.69.31.170 with SMTP id kn10mr17977350pbd.100.1410577182263; Fri, 12 Sep 2014 19:59:42 -0700 (PDT) Received: from [192.168.178.23] (89.198.69.111.dynamic.snap.net.nz. [111.69.198.89]) by mx.google.com with ESMTPSA id w11sm5071634pbt.84.2014.09.12.19.59.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 19:59:41 -0700 (PDT) Message-ID: <5413B329.2010804@gmail.com> Date: Sat, 13 Sep 2014 14:59:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chuck Anderson References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <20140912231254.GO31944@angus.ind.WPI.EDU> In-Reply-To: <20140912231254.GO31944@angus.ind.WPI.EDU> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OQa9GGYuEK7SEv7qc2saGKJhn5s Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 02:59:44 -0000 Excuse front posting, but telling somebody "your network breaks our specs" just invites the response "your specs broke my network." I think the obvious next step in this matter is to write down operational and implementation guidance to prevent this sort of problem occurring. That seems to be part of v6ops' job. (Sorry, I'm not volunteering.) Regards Brian On 13/09/2014 11:12, Chuck Anderson wrote: > On Fri, Sep 12, 2014 at 03:33:52PM -0700, Owen DeLong wrote: >>> It is not reasonable to expect a switch to scale to maintaining state= >>> for 300 * (# of hosts connected) Solicited-Node multicast groups. >> Nor does any rational use of SLAAC+Privacy addresses result in anythin= g near that. >=20 > Actually deployed networks are encountering 300+ privacy addresses on > some machines. Is that a bug or by design of the OS vendor? I don't > know. >=20 >>> 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable. >> 25*48 =3D 1,200, not 15,000. Even if we double that, it=E2=80=99s stil= l 2,400 max. >> >> A potential improvement could be if privacy addressing created a persi= stent random lower 24 bits and only rehashed the upper 40 bits of the suf= fix with each address rotation. In that way, you=E2=80=99d only have ~2 N= D multicast groups per host. >=20 > Agreed. Good idea. >=20 >>> 90,000 MLD groups for a 300 port switch stack is also unreasonable. >>> Most switches cannot handle that many IPv4 multicast groups--expectin= g >>> them to handle that many IPv6 multicast groups is unreasonable. >> Again, this is not anything close to a real world scale for the situat= ion. Using hyperbole derived numbers to make things sound bad enough that= you can blame the protocol for a situation that is much more directly th= e result of bad network design is absurd. >=20 > It isn't hyperbole. It has been observed multiple times by different > people: >=20 > http://blog.bimajority.org/2014/07/16/ipv6-privacy-addresses-windows-ju= st-say-no/ >=20 > "it was a Windows machine, [...] I saw that it was responsible for the > vast majority of those multicast memberships: 350 different multicast > groups in all, nearly all of which were =E2=80=9Csolicited node=E2=80=9D= groups for > different IPv6 =E2=80=9Cprivacy=E2=80=9D addresses" >=20 > http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my= -week/ >=20 > "I used Ubuntu as an example, but it is hardly the worst offender. We > have seen Windows machines with more than 300 IPv6 addresses" >=20 > And a thorough description of the problem and possible solutions: >=20 > http://inconcepts.biz/~jsw/ipv6_nd_problems_with_l2_mcast.pdf >=20 >>> Having designed a ubiquitous protocol 16 years ago that can't be >>> implemented reasonably cheaply on current hardware is an operational >>> problem that can and should be dealt with by tweaking the protocol in= >>> some cases. I think the protocol change proposals put forward in the= >>> article are a quite reasonable starting point for discussing how to >>> mitigate this issue and shouldn't be dismissed out of hand. >> I think that the protocol can be implemented reasonably cheaply on cur= rent hardware if you don=E2=80=99t design your network so poorly that the= fact it hasn=E2=80=99t collapsed in on itself in IPv4 is a minor miracle= =2E Lots of people have very large IPv6 networks running just fine on a = pretty wide variety of commodity hardware at this point. >=20 > The only reasonable way to avoid this problem today via network > design, is to design you network to use DHCPv6 instead of SLAAC or > turn off privacy addressing on all hosts. Unfortunately for less > managed networks (the exact use case that SLAAC is designed for--hands > off) it isn't feasible to go to every host and manually turn off > privacy addressing. That means the only practical way to solve this > problem is to only ever use DHCPv6. This is a somewhat surprising > result, perhaps unanticipated by those who worked on ND & MLD, and > probably not desireable for those who champion SLAAC. >=20 >> Smaller layer 2 zones would greatly improve his situation. Turning off= privacy addressing would also help. (This is, as has been pointed out, u= nder the control of the network operator as he can set the M bit, turn of= f the A bit, and give out DHCP addresses as an example.) >=20 > He doesn't have large Layer 2 zones. >=20 >> I suspect there are a number of other viable solutions. OTOH, modifyi= ng ipv6 to support such an environment seems a fools errand to me. >=20 > Modifying ND is not without precedent. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 12 20:19:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02091A01AF for ; Fri, 12 Sep 2014 20:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-1.652, 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 JbFB3vxLL67S for ; Fri, 12 Sep 2014 20:19:26 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 479BE1A0188 for ; Fri, 12 Sep 2014 20:19:26 -0700 (PDT) Received: from [10.5.16.184] ([209.63.144.18]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s8D3IMJp000597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Sep 2014 20:18:33 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s8D3IMJp000597 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1410578313; bh=XTVdLPqOtlPOQMCWgnFcZhC66jE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3CPXq+mERWFEd2e+XVd8I64007MHLcw8HiHkqROd6fDICNZ1ZLSEkhjepmZ/NyLeh PMxpnAqSA15bZ/fi/cscIif1XJjQZ8QHNh1Btnc/HK0LU+20RxbjCXk6H0LZlY1xCl OLX7/IRIaydX4Kh0ZNv8GshZ1A0Yx1ICETWNTcOw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <20140912231254.GO31944@angus.ind.WPI.EDU> Date: Fri, 12 Sep 2014 20:17:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <20140912231254.GO31944@angus.ind.WPI.EDU> To: Chuck Anderson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/X2kvHfXVXw1ekQE63ld3cgrOpA8 Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 03:19:29 -0000 On Sep 12, 2014, at 4:12 PM, Chuck Anderson wrote: > On Fri, Sep 12, 2014 at 03:33:52PM -0700, Owen DeLong wrote: >>> It is not reasonable to expect a switch to scale to maintaining = state >>> for 300 * (# of hosts connected) Solicited-Node multicast groups. >>=20 >> Nor does any rational use of SLAAC+Privacy addresses result in = anything near that. >=20 > Actually deployed networks are encountering 300+ privacy addresses on > some machines. Is that a bug or by design of the OS vendor? I don't > know. It=92s definitely a bug. I=92ve never seen that many, so I=92d love to = know the specifics where this has occurred. >>> 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable. >>=20 >> 25*48 =3D 1,200, not 15,000. Even if we double that, it=92s still = 2,400 max. >>=20 >> A potential improvement could be if privacy addressing created a = persistent random lower 24 bits and only rehashed the upper 40 bits of = the suffix with each address rotation. In that way, you=92d only have ~2 = ND multicast groups per host. >=20 > Agreed. Good idea. >=20 >>> 90,000 MLD groups for a 300 port switch stack is also unreasonable. >>> Most switches cannot handle that many IPv4 multicast = groups--expecting >>> them to handle that many IPv6 multicast groups is unreasonable. >>=20 >> Again, this is not anything close to a real world scale for the = situation. Using hyperbole derived numbers to make things sound bad = enough that you can blame the protocol for a situation that is much more = directly the result of bad network design is absurd. >=20 > It isn't hyperbole. It has been observed multiple times by different > people: >=20 > = http://blog.bimajority.org/2014/07/16/ipv6-privacy-addresses-windows-just-= say-no/ >=20 > "it was a Windows machine, [...] I saw that it was responsible for the > vast majority of those multicast memberships: 350 different multicast > groups in all, nearly all of which were =93solicited node=94 groups = for > different IPv6 =93privacy=94 addresses" >=20 > = http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-we= ek/ >=20 > "I used Ubuntu as an example, but it is hardly the worst offender. We > have seen Windows machines with more than 300 IPv6 addresses=94 Ah, so the grotesque violations of network etiquette come from windows = boxes=85 What a surprise. Explains why I haven=92t seen them. I gave up = on Windows over a decade ago. On most well behaved OS, btw, it=92s a maximum of ~7. > And a thorough description of the problem and possible solutions: >=20 > http://inconcepts.biz/~jsw/ipv6_nd_problems_with_l2_mcast.pdf Right=85 Again, it seems like large layer 2 zones+mld snooping+privacy = addressing are the =93fire triangle=94 here and that if you remove any = leg, you eliminate the problem. >>> Having designed a ubiquitous protocol 16 years ago that can't be >>> implemented reasonably cheaply on current hardware is an operational >>> problem that can and should be dealt with by tweaking the protocol = in >>> some cases. I think the protocol change proposals put forward in = the >>> article are a quite reasonable starting point for discussing how to >>> mitigate this issue and shouldn't be dismissed out of hand. >>=20 >> I think that the protocol can be implemented reasonably cheaply on = current hardware if you don=92t design your network so poorly that the = fact it hasn=92t collapsed in on itself in IPv4 is a minor miracle. Lots = of people have very large IPv6 networks running just fine on a pretty = wide variety of commodity hardware at this point. >=20 > The only reasonable way to avoid this problem today via network > design, is to design you network to use DHCPv6 instead of SLAAC or > turn off privacy addressing on all hosts. Unfortunately for less > managed networks (the exact use case that SLAAC is designed for--hands > off) it isn't feasible to go to every host and manually turn off > privacy addressing. That means the only practical way to solve this > problem is to only ever use DHCPv6. This is a somewhat surprising > result, perhaps unanticipated by those who worked on ND & MLD, and > probably not desireable for those who champion SLAAC. No, you can also avoid it by network design by limiting the size of your = link local domains. If your switch has a 1000 multicast group limit, = then you shouldn=92t have more than about 120 hosts on that network. If = you=92re running Windows, turn off privacy addressing in group policy or = demand that Micr0$0ft fix their broken shit. >=20 >> Smaller layer 2 zones would greatly improve his situation. Turning = off privacy addressing would also help. (This is, as has been pointed = out, under the control of the network operator as he can set the M bit, = turn off the A bit, and give out DHCP addresses as an example.) >=20 > He doesn't have large Layer 2 zones. Yes he does=85 He stated that he had a campus wide L2 zone. >=20 >> I suspect there are a number of other viable solutions. OTOH, = modifying ipv6 to support such an environment seems a fools errand to = me. >=20 > Modifying ND is not without precedent. Sure, and I=92d welcome modifying ND for legitimate need, such as = RFC6106. In this case, ND doesn=92t strike me as the place where ire is best = targeted. MLD snooping could be improved to ignore solicited node = addresses. This wouldn=92t affect anything else and would clearly solve = the problem. Micr0$0ft could fix their broken shit and not generate so = many extra addresses for no reason. Owen From nobody Fri Sep 12 20:25:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1198A1A02D1 for ; Fri, 12 Sep 2014 20:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAtbHXZgHvBU for ; Fri, 12 Sep 2014 20:25:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AE2091A02BC for ; Fri, 12 Sep 2014 20:25:14 -0700 (PDT) Received: from [10.5.16.184] ([209.63.144.18]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s8D3O6gH000684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Sep 2014 20:24:07 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s8D3O6gH000684 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1410578647; bh=NRjro0OsnAAy9WwsLPBqXSU9X1w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f54w6ougQCyrx4bTnGmRSFEm9xyCbIrXr8DTz77aU+1R/JPrlks2qEdZGKNKai+p2 GkhJZ/NiiAPOT4nmnmpxJqYSUyXyP/j1ibcthu8zgVfy+50TPZ+2/p/8VhCs7g4sII KgaQ1LFQoCTifiNAhgGpcvpeaHzet+/X9OUownSY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <5413A448.2030104@gont.com.ar> Date: Fri, 12 Sep 2014 20:23:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <5413A448.2030104@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oMKIyMA8wsiLnzPuhNEQKijr3bI Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 03:25:16 -0000 On Sep 12, 2014, at 6:56 PM, Fernando Gont wrote: > On 09/12/2014 07:33 PM, Owen DeLong wrote: >> A potential improvement could be if privacy addressing created a >> persistent random lower 24 bits and only rehashed the upper 40 bits >> of the suffix with each address rotation. In that way, you=92d only >> have ~2 ND multicast groups per host. >=20 > That would break the sole purpose of privacy addresses. If the lower > 24-bits are kept the same, an attacker can correlate the activities of = a > node along time. The purpose of privacy addresses is broken by so many things as to = render them an absurd waste in general. We=92ve had this argument before. We=92ve agreed to disagree before. I suppose another viable solution would be to require all privacy = addresses to use a common lower 24 bit string. In this way, you=92d = still have anonymity within the subnet which is all you really get from = privacy addresses to begin with. Owen From nobody Sat Sep 13 04:20:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232DD1A884B for ; Sat, 13 Sep 2014 04:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiegGhb8Npez for ; Sat, 13 Sep 2014 04:20:40 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76521A06E4 for ; Sat, 13 Sep 2014 04:20:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 69DF43D; Sat, 13 Sep 2014 13:20:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1410607235; bh=j8h5JSC1FtzumYKpc2t0gNB5rCTGFHvwIZduMLygNC4=; b=g bcaju7ZzyH0x4oxlPDSdcr2BZPWPF7O5cAfEHHmT7+DWVlnrQbvz0wQrUPoPBL8+ NvVA0wpJTVMaTwOa7WZyryTbQkhh/ssKqAopKVfBTHTa4sQ6cCqap0YecuWOnfG2 k+aNop1b/ynhF0ozKHNbarRaxgGQ6EBVs37sngz7W4= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4MnXCZTGtu0W; Sat, 13 Sep 2014 13:20:35 +0200 (CEST) Received: from [IPv6:2a00:8640:1::6076:e4d6:591d:35ae] (unknown [IPv6:2a00:8640:1:0:6076:e4d6:591d:35ae]) by mail.sintact.nl (Postfix) with ESMTPSA id 9FFB73B; Sat, 13 Sep 2014 13:20:34 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sander Steffann In-Reply-To: <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com> Date: Sat, 13 Sep 2014 13:20:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <876198F8-4283-428E-8D20-B4EC6AAE440E@steffann.nl> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <5413A448.2030104@gont.com.ar> <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com> To: Owen Delong X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CGlaIwP0vmMre4BnNYWtX6iW9mw Cc: v6ops@ietf.org, Fernando Gont Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 11:20:42 -0000 Hi Owen, > I suppose another viable solution would be to require all privacy = addresses to use a common lower 24 bit string. That would defeat the purpose of the solicited node multicast address. = All of them would use the same one, so all hosts have to listen to the = same one, and we're back to ARP-like efficiency again... Cheers, Sander From nobody Sat Sep 13 05:11:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5907E1A8857 for ; Sat, 13 Sep 2014 05:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 3nRZCp-_Sffz for ; Sat, 13 Sep 2014 05:11:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB9D1A06E3 for ; Sat, 13 Sep 2014 05:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=773; q=dns/txt; s=iport; t=1410610280; x=1411819880; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mdib4ZTfvprFnkV9AtXBFHOBk7Q3WDwkkvP6YqOrwZA=; b=nF7y3feU5+czQrVi9H3nhGNs+9k+m+Ot8xQ2LGw0ZUVcfgraPVHBMBXm qGKBfuuBsEbGqdLRzQQsio8WUJyLyHsoBZ6YQz4RFj0ljGRb7GSqxHObj eYa8prN4k692Jx0pu5jFy+e3T6lM6w5/1dTm2G9zkEYoL2LcY92e35q6N o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAPcyFFStJA2L/2dsb2JhbABfgw1TV8kVCodOAYEJFniEAwEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FG4gbCA28EQETBI8aMweDLoEdAQSRTYs7lT+DXmyCSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,517,1406592000"; d="scan'208";a="354932888" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 13 Sep 2014 12:11:19 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8DCBIx9008972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Sep 2014 12:11:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.78]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Sat, 13 Sep 2014 07:11:18 -0500 From: "Bernie Volz (volz)" To: Sander Steffann Thread-Topic: [v6ops] Interesting problems with using IPv6 Thread-Index: AQHPzBJt8gpNy9O+wUihdMo7NWOju5v47XmAgAAD4oCABSo4VIAAUQTHgADYjYD//7pcLA== Date: Sat, 13 Sep 2014 12:11:18 +0000 Message-ID: References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <5413A448.2030104@gont.com.ar> <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com>, <876198F8-4283-428E-8D20-B4EC6AAE440E@steffann.nl> In-Reply-To: <876198F8-4283-428E-8D20-B4EC6AAE440E@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b-nz90F0zxymnbCtCJ7oCc-TmKQ Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 12:11:29 -0000 I would think he meant for a single node, not across all nodes. Thus each n= ode only has one multicast group (for privacy addresses). - Bernie (from iPad) > On Sep 13, 2014, at 7:21 AM, "Sander Steffann" wrote= : >=20 > Hi Owen, >=20 >> I suppose another viable solution would be to require all privacy addres= ses to use a common lower 24 bit string. >=20 > That would defeat the purpose of the solicited node multicast address. Al= l of them would use the same one, so all hosts have to listen to the same o= ne, and we're back to ARP-like efficiency again... >=20 > Cheers, > Sander >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Sep 13 05:15:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB041A8860 for ; Sat, 13 Sep 2014 05:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEYNqwF2tB4P for ; Sat, 13 Sep 2014 05:14:57 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1BB1A885F for ; Sat, 13 Sep 2014 05:14:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 122043B; Sat, 13 Sep 2014 14:14:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1410610493; bh=gCuWBZHuqE1A064pDCa6ZJeCqoKVeTEDE2zk/LWhNaM=; b=p oxjxcWdWAt8w/+c9H25tcb1xnILE+KZys+q1OUt4k043FYWJwZo6XTqhwCSDBT/q AcIlbUh6NT/PJCoxPAbradaNJziXv2PXZSL24ZMc6oavgfTR9musA/Ymwz+X0eZ/ 68U8G5q7drLM1vBG6jNvxM2DLijKJeybRHODNdt5kk= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3GsQMzgohEJA; Sat, 13 Sep 2014 14:14:53 +0200 (CEST) Received: from [IPv6:2a00:8640:1::6076:e4d6:591d:35ae] (unknown [IPv6:2a00:8640:1:0:6076:e4d6:591d:35ae]) by mail.sintact.nl (Postfix) with ESMTPSA id 56F7934; Sat, 13 Sep 2014 14:14:52 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sander Steffann In-Reply-To: Date: Sat, 13 Sep 2014 14:14:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F718CBC-F926-4A37-B9ED-13078AF4926B@steffann.nl> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <5413A448.2030104@gont.com.ar> <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com>, <876198F8-4283-428E-8D20-B4EC6AAE440E@steffann.nl> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KoY3iypGz2rcCzGtu84Qq490Qv8 Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 12:14:57 -0000 Hi Bernie, >>> I suppose another viable solution would be to require all privacy = addresses to use a common lower 24 bit string. >>=20 >> That would defeat the purpose of the solicited node multicast = address. All of them would use the same one, so all hosts have to listen = to the same one, and we're back to ARP-like efficiency again... >=20 > I would think he meant for a single node, not across all nodes. Thus = each node only has one multicast group (for privacy addresses). I would hope so as well but I got the impression he didn't... Cheers :) Sander From nobody Sat Sep 13 13:05:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8897A1A00AD for ; Sat, 13 Sep 2014 13:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN7Crfr_gknc for ; Sat, 13 Sep 2014 13:05:08 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 00F1C1A00AE for ; Sat, 13 Sep 2014 13:05:06 -0700 (PDT) Received: from [IPv6:2620::930:0:855:e155:2c81:9ecc] ([IPv6:2620:0:930:0:855:e155:2c81:9ecc]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s8DJxpHu009727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Sep 2014 12:59:51 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s8DJxpHu009727 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1410638393; bh=SdlEUc12Je4ERlldaPtT19MfIB4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gJPIZJrfNDkhGAIu3KiVmm8hRHHUVRPwk9pwWJTql5ygNwAGkshZBSY6WmKy03CNZ M1JeaqorRb1gPf9JwrE/EIC2vq7qPvl1RzgLl7GCYQ/ifFxP4QKx5n+pHmZmVqByXc rGxaqZdun1sB+qg00EsWLXr72B/C78eIG2QEXSwQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (11D257) In-Reply-To: <876198F8-4283-428E-8D20-B4EC6AAE440E@steffann.nl> Date: Sat, 13 Sep 2014 12:59:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81DE6AB9-A581-4EB6-89C7-00F1CDB314F7@delong.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <5413A448.2030104@gont.com.ar> <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com> <876198F8-4283-428E-8D20-B4EC6AAE440E@steffann.nl> To: Sander Steffann Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ofImbYeFWgravFfHH0FLCcfTtWk Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 20:05:14 -0000 No... It would only have that impact on hosts that choose to use privacy add= resses. I'd much rather see the impact of privacy addressing transferred to t= he hosts using it than to the network infrastructure.=20 > On Sep 13, 2014, at 4:20, Sander Steffann wrote: >=20 > Hi Owen, >=20 >> I suppose another viable solution would be to require all privacy address= es to use a common lower 24 bit string. >=20 > That would defeat the purpose of the solicited node multicast address. All= of them would use the same one, so all hosts have to listen to the same one= , and we're back to ARP-like efficiency again... >=20 > Cheers, > Sander From nobody Sat Sep 13 13:05:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7DC1A00D4 for ; Sat, 13 Sep 2014 13:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Xk6VKGhhya3 for ; Sat, 13 Sep 2014 13:05:33 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A380A1A00AD for ; Sat, 13 Sep 2014 13:05:33 -0700 (PDT) Received: from [IPv6:2620::930:0:855:e155:2c81:9ecc] ([IPv6:2620:0:930:0:855:e155:2c81:9ecc]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s8DK3dKb009883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Sep 2014 13:03:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s8DK3dKb009883 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1410638620; bh=pLg5xmyHcL42J09pEEkCf5NIgVg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Rqbw2Ihlt+jVK0920/XSG00AeBoBbN3q2gIhCTNsKYzdf3I0WvJtVcPmTW0GDm/Nq 81ggeKuK5BF01KPtU8onlU69Rih4kS8nRDx1JahK6umhM/Wbfp2Vv12Rbpv6FQq/ri lVOTuDj3UTgWW2xMkCxyDDp2LxM/BUFtVMBgO5DI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (11D257) In-Reply-To: <4F718CBC-F926-4A37-B9ED-13078AF4926B@steffann.nl> Date: Sat, 13 Sep 2014 13:03:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65C14298-7D07-4A2E-93EA-610C78707342@delong.com> References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU> <101C89B1-019B-4E51-B869-FABC534E6D3D@delong.com> <5413A448.2030104@gont.com.ar> <0E61F8D0-22C6-4E37-93E2-9D9B13254055@delong.com> <876198F8-4283-428E-8D20-B4EC6AAE440E@steffann.nl> <4F718CBC-F926-4A37-B9ED-13078AF4926B@steffann.nl> To: Sander Steffann Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hzJUXeF9bxyLxE5cW3n9MS3z838 Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Sep 2014 20:05:37 -0000 It was in response to someone who felt that would defeat privacy addressing (= which it likely would). However, having all hosts use the same last 24 for a= ll privacy addresses would preserve privacy while transferring the negative i= mpact from them onto the hosts in a much less impactful way than the current= impacts in network infrastructure.=20 I do like the idea of having a limited number of low-24 bit patterns that pr= ivacy addresses can rotate through. Seems like a potential best of both worl= ds.=20 Owen > On Sep 13, 2014, at 5:14, Sander Steffann wrote: >=20 > Hi Bernie, >=20 >>>> I suppose another viable solution would be to require all privacy addre= sses to use a common lower 24 bit string. >>>=20 >>> That would defeat the purpose of the solicited node multicast address. A= ll of them would use the same one, so all hosts have to listen to the same o= ne, and we're back to ARP-like efficiency again... >>=20 >> I would think he meant for a single node, not across all nodes. Thus each= node only has one multicast group (for privacy addresses). >=20 > I would hope so as well but I got the impression he didn't... >=20 > Cheers :) > Sander From nobody Sun Sep 14 18:03:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B1F1A0464 for ; Sun, 14 Sep 2014 18:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.203 X-Spam-Level: ** X-Spam-Status: No, score=2.203 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, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=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 pOU6P62o3HDb for ; Sun, 14 Sep 2014 18:03:22 -0700 (PDT) Received: from nm36-vm8.bullet.mail.bf1.yahoo.com (nm36-vm8.bullet.mail.bf1.yahoo.com [72.30.239.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E1B1A0462 for ; Sun, 14 Sep 2014 18:03:21 -0700 (PDT) Received: from [98.139.215.142] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 01:03:20 -0000 Received: from [98.139.212.224] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 01:03:20 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 01:03:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 884294.56539.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 11050 invoked by uid 60001); 15 Sep 2014 01:03:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1410743000; bh=2HTzsdb6dwlrcv1WYxx1Cj9XR2bTvViQG+OBITrCtQU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jxN/XP4UwepNAzUub7fWiT982GBDeU6ZQsmFTgTAakrOECYpdxk6Eae3Udsow3hgqBhI/paDHQNTzPHsMm8+uKVgngtJacJPBTAtxCHkEkOLturhKqt0IcuMU9UTiZYzwpLTx4c2dwO/p1skEbDjWGn+slD/RxUWtOCywiaq3qo= X-YMail-OSG: DnZ1WC0VM1mnMvGKWqY9Vx94MA8QUMIW41wN_UIGT7e.6ou aEfOvylIlSdOFksh0.PXHYAo90vmB9orjSXjlSQ1qcnwgYrSGQzuBbpPXbeR 4XWuuxq_7rl1bjP2.gvr4dxk0rdumHe56MlR3CYgbdh2IXnEJCuZxghiFU5O duSuz1FYUP30VKXkrHhVGYIjiFrgfKsRwXH1AG2D0TkG0aLXh2pgVEb7uLXJ MmUyui6HdSpeTQbDKR.LaZNADQ1L8u.0KnFZIr2GJE8ErbAKEbdlSBxSMyEo LfDWFMdhVOHtV0Z7jRvJjnc_rzsVNW0WBQbKzHmciwmTre5OzM7N8VnczHOy g.y2ffgfv9mRZedSEZ3MQ7bVbtwbkjZ7zLk7s2UM.7MUi3.m9FL506VkBsHq yS73P74OFD3vxX0gbm_mdiMerlmtTHRNmwC9U_5kZ6OadqkprpvO9Q4KILqY hid4q9XKqSMZliX0mUeWWX_XyOgnz8YC5xEFjQTeiMBdJ3wVAYwO_kuOBPW_ riMNpJpqcUHxQXK0gSrbjuKYFaEEH4Jxt9ab2SLCMJXPRxcscpV0FSExzCSw xr1deqxYBHvCPh0cEPfU1iXV1J0Ko8CXuBa037Z8_14bLq5.MlzPHyEr8KNj E3hkQZKPUL1YakpRdlP9qIjOCEe0I_4Qg0.cVZnceygGAvE8BfoLomDK1U9V icFrvTsh6Sk7MJ9XMq6p7tp5TNSJPDRg_qLwdNDKnnnrFhXGk.esEqRMriaX Wxx88jvX0kzad6zjKxe6rgRO23ojYjs.UwW.omdiAHglS2o.S_g-- Received: from [49.182.6.179] by web162204.mail.bf1.yahoo.com via HTTP; Sun, 14 Sep 2014 18:03:20 PDT X-Rocket-MIMEInfo: 002.001, SGkgQnJpYW4sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBEYWxlIFcuIENhcmRlciA8ZHdjYXJkZXJAd2lzYy5lZHU.OyBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPjsgImwud29vZEBzdXJyZXkuYWMudWsiIDxsLndvb2RAc3VycmV5LmFjLnVrPgo.IFNlbnQ6IFR1ZXNkYXksIDkgU2VwdGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> Message-ID: <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Sun, 14 Sep 2014 18:03:20 -0700 From: Mark ZZZ Smith To: Brian E Carpenter In-Reply-To: <540E6299.2050003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Eo8LGonJvf4ZCIiXLoKN2EdSpAQ Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 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: Mon, 15 Sep 2014 01:03:24 -0000 Hi Brian,=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter = =0A> To: Mark ZZZ Smith =0A> Cc: Dale W. Carder ; IPv6 Operations ; "l.wood@surrey.ac.uk" =0A> Sent: Tuesday, 9 S= eptember 2014, 12:14=0A> Subject: Re: [v6ops] Interesting problems with usi= ng IPv6=0A> =0A> Mark,=0A> =0A> My point is that it's worth *understanding*= such problems and then=0A> perhaps writing up operational or implementatio= n recommendations.=0A=0A=0ASure.=0A=0AThe trouble with that blog post is th= at it doesn't provide conclusive evidence that the Router Alert option in M= LD messages is the only cause of their networking problems.=0A=0AThe actual= blog post doesn't really provide much technical evidence of anything. The = evidence is does provide however is that they haven't been performing troub= leshooting well, nor maintaining their network very well:=0A=0A- they took = a 'suck-it-and-see' approach to trying to fix the first issue, and in parti= cular, changed multiple things at once. If the problem then disappears, whi= ch change made resolved it? Would they now perform disruptive firmware upgr= ades even though that change may not have been the one that fixed the probl= em?=0A=0A- they suspect they have 'bridge loops' forming, and that is overl= oading the control plane during these 'bridge loops'. Yet they don't say th= ey have spent any time confirming their speculation, or any effort in ident= ifying the cause of these 'bridge loops'. They also speculate about what th= e consequences of these 'bridge loops' are (STP messages being dropped beca= use of control plane overload). They're actively working on taking actions = to remedy this, without any evidence their speculation is true. They're jum= ping to conclusions.=0A=0AWith so little apparent proper evidence collectin= g and proper troubleshooting and diagnosis, how can the blog author be sure= IPv6 MLD with the RA option is the specific cause of their problems? Conse= quently, how can this group then accept that as conclusive and therefore sp= end time speculating on changes that could be made to MLD that may also be = completely ineffective on that network - because it may not be the cause at= all? There isn't even enough detail in that blog post to be able to reprod= uce the scenario independently - what hosts/host OSes are they using, how m= any are there, are they running other multicast applications etc., etc.,=0A= =0AI think it is possible that RA option in MLD messages might be one of th= e causes of or contributors to their problems. However, there are many othe= r possible causes that don't seem to have been investigated.=0A=0A=0AOne re= ason I'm sceptical about MLD being the cause is because versions of Windows= since Vista (released January 2007) have been IPv6 enabled by default, and= have been issuing solicited-node MLDv2 reports for its link-local addresse= s, and if global or ULA prefixes are available, has been generating privacy= addresses and corresponding solicited-node MLDv2 reports for those too. So= since at least 2007, many MLD messages have been sent onto many different = switched networks for many years. If RA option in MLDv2 reports were such a= problem to switched networks, we should have heard about it by now and hav= e also seen other networks suffer from this problem. This problem seems to = be unique to this network, and therefore I think that is a sign that someth= ing else is going on, in addition to the other signs like this 'bridge loop= s' and unexplained software and perhaps hardware faults.=0A=0AI've proposed= using these solicited-node MLD reports to further help mitigate the ND cac= he DoS (draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node). People were con= cerned that hosts weren't sending them, so I've collected some packet captu= res of an individual host booting on a (virtual) network with a single IPv6= router (OpenWRT 14.07 rc1) announcing a single ULA prefix. If people want = to see what is typical, here are the Windows captures (Windows XP after IPv= 6 was enabled). Note the captures were taken at the router's interface rath= er than the host's, so they're showing what the router receives from the ho= sts or sends towards them, rather than what the hosts were sending or recei= ving.=0A=0Ahttp://www.users.on.net/~markachy/windows-xp-sp3-boot-rtr-cap.pc= ap=0A=0Ahttp://www.users.on.net/~markachy/windows-vista-boot-rtr-cap.pcap= =0A=0Ahttp://www.users.on.net/~markachy/windows-7-boot-rtr-cap.pcap=0A=0Aht= tp://www.users.on.net/~markachy/windows-8.1-boot-rtr-cap.pcap=0A=0ARegards,= =0AMark.=0A=0A=0A> Exactly what the v6ops charter says we should do, in fac= t.=0A> =0A> "1. Solicit input from network operators and users to identify= =0A> operational issues with the IPv4/IPv6 Internet, and=0A> determine solu= tions or workarounds to those issues. These issues=0A> will be documented i= n Informational or BCP RFCs, or in=0A> Internet-Drafts."=0A> =0A> Or recomm= end protocol changes if they might help, which is why I=0A> want to underst= and the value of Router Alert in MLD messages for=0A> Solicited-Node multic= ast addresses. Or should we revive=0A> draft-pashby-magma-simplify-mld-snoo= ping-01?=0A> =0A> Brian=0A> =0A> =0A> =0A> On 09/09/2014 13:55, Mark ZZ= Z Smith wrote:=0A>> =0A>> =0A>> =0A>> ----- Original Message -----=0A>>> = From: Brian E Carpenter =0A>>> To: Dale W. Ca= rder =0A>>> Cc: IPv6 Operations ; l.woo= d@surrey.ac.uk=0A>>> Sent: Tuesday, 9 September 2014, 7:59=0A>>> Subject:= Re: [v6ops] Interesting problems with using IPv6=0A>>> =0A>>> I switched = to the relevant list.=0A>>> =0A>>> On 09/09/2014 06:33, Dale W. Carder wro= te:=0A>>>> Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on = Mon, =0A> Sep 08, =0A>>> 2014 at 07:50:26AM +1200:=0A>>>>> If they reall= y are interesting problems, it might be more to =0A> the=0A>>>>> point to= analyse them over on v6ops. Given the number of large=0A>>>>> IPv6 deplo= yments that don't have such problems, it seems =0A> like=0A>>>>> this par= ticular deployment hit an unfortunate combination of=0A>>>>> implementati= on issues.=0A>> =0A>> =0A>> If this email is referring to this blog post:= =0A>> =0A>> =0A> http://blog.bimajority.org/2014/09/05/the-network-nightmar= e-that-ate-my-week/=0A>> =0A>> =0A>> then I think this particular network = was already on the verge of =0A> catastrophic failure, and some of IPv6's N= D differences were just the =0A> trigger to push it over that threshold.=0A= >> =0A>> =0A>> According to the blog post, they might have:=0A>> =0A>> - = hardware errors=0A>> - software errors=0A>> - 'bridge loops' causing the = control plane to overload=0A>> =0A>> In some of these cases they've taken = actions to try to resolve them, =0A> however the actions taken seem to be b= ased on speculating what is happening =0A> rather than finding evidence to = support the hypothesised cause before taking =0A> action.=0A>> =0A>> For e= xample, there isn't any evidence that they've actually =0A> determined that= 'bridge loops' are occurring, found out what is causing =0A> them, and the= n taking measures to prevent them or at least reduce the chances of =0A> th= em occurring. If a 'bridge loop' can cause the control plane to =0A> overlo= ad, then adding anything to this network like IPv6 is likely to only make = =0A> the problem worse.=0A>> =0A>> I'd like to see them get to the bottom = of and then fix these =0A> 'bridge loop' and other problems first before an= y value is placed on =0A> addressing their criticisms of IPv6. Other people= have deployed IPv6 without =0A> these problems, so what is different betwe= en this network and everybody =0A> else's that doesn't have these sorts of = problems?=0A>> =0A>> =0A>> =0A>> That is worth understanding (for example= ,=0A>>>>> how large is the layer 2 network that leads to the MLD =0A> lis= tener=0A>>>>> report overload?).=0A>>>> Implementing MLD snooping for S= olicited-Node multicast addresses =0A>>>> is probably a bad idea.=0A>>>> = =0A>> =0A>>>> See: draft-pashby-magma-simplify-mld-snooping-01=0A>>> OK,= but I would also like to understand why we require=0A>>> MLD messages for= a Solicited-Node multicast address to=0A>>> set Router Alert.=0A>>> =0A>>= > Brian=0A>>> =0A>>> _______________________________________________= =0A>>> v6ops mailing list=0A>>> v6ops@ietf.org=0A>>> https://www.ietf.or= g/mailman/listinfo/v6ops=0A>>> =0A>> =0A> From nobody Sun Sep 14 21:45:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E07B1A063E for ; Sun, 14 Sep 2014 21:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpjS8CeBtLpZ for ; Sun, 14 Sep 2014 21:45:31 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1721A01E2 for ; Sun, 14 Sep 2014 21:45:30 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id p10so5408866pdj.30 for ; Sun, 14 Sep 2014 21:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=akZuoIQejbH/SPKIDD9qKR+KErUQStpQd+UIPbtqq9s=; b=HiZxmH7rMZIfH5Z69BtarQiFtO/EzccAd+bnW8iZ8gaRskG3+FSlHzoC7HHUuxasyN j1HQpGAigcJPQsxSy6so1vtXpfRAz/HUCx2JCk6oyHq8FkxVR82NEmGRi9fyDjDU46AX GsEbkL1NkvVHgEpDIkxPBeyalY8Dn93zYLYajLRBAn1C/Pw+C67Db/u74XO/Pbfjkewy v8ydMwBk6hO6zTTXgWR3qsOByO+AeePtN8xfXc8uPTZR84VXhCiQjyPXX1P3Vn+rlXWw njjdCHnm5/zGCbM3sso0AlN500NEkFadjMsUQQKvJfqAbTkRGVFKa9BjkuifKifc1aKf 4Rsg== X-Received: by 10.67.4.1 with SMTP id ca1mr34940048pad.50.1410756330447; Sun, 14 Sep 2014 21:45:30 -0700 (PDT) Received: from [192.168.178.23] (237.198.69.111.dynamic.snap.net.nz. [111.69.198.237]) by mx.google.com with ESMTPSA id fn4sm10453268pab.39.2014.09.14.21.45.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Sep 2014 21:45:29 -0700 (PDT) Message-ID: <54166EE5.9080007@gmail.com> Date: Mon, 15 Sep 2014 16:45:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oAYHn0ctd5rAUzqAzkcu-u1_6vY Cc: IPv6 Operations , "l.wood@surrey.ac.uk" Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Sep 2014 04:45:33 -0000 > With so little apparent proper evidence collecting and proper troubleshooting and diagnosis, how can the blog author be sure IPv6 MLD with the RA option is the specific cause of their problems? I'm pretty sure that the Router Alert is a red herring and the real problem was MLD snooping (i.e. a layer violation by L2 switches). Even so, the MLD Router Alert issue seems to be a real one, if not in this scenario. Regards Brian On 15/09/2014 13:03, Mark ZZZ Smith wrote: > Hi Brian, > > > ----- Original Message ----- >> From: Brian E Carpenter >> To: Mark ZZZ Smith >> Cc: Dale W. Carder ; IPv6 Operations ; "l.wood@surrey.ac.uk" >> Sent: Tuesday, 9 September 2014, 12:14 >> Subject: Re: [v6ops] Interesting problems with using IPv6 >> >> Mark, >> >> My point is that it's worth *understanding* such problems and then >> perhaps writing up operational or implementation recommendations. > > > Sure. > > The trouble with that blog post is that it doesn't provide conclusive evidence that the Router Alert option in MLD messages is the only cause of their networking problems. > > The actual blog post doesn't really provide much technical evidence of anything. The evidence is does provide however is that they haven't been performing troubleshooting well, nor maintaining their network very well: > > - they took a 'suck-it-and-see' approach to trying to fix the first issue, and in particular, changed multiple things at once. If the problem then disappears, which change made resolved it? Would they now perform disruptive firmware upgrades even though that change may not have been the one that fixed the problem? > > - they suspect they have 'bridge loops' forming, and that is overloading the control plane during these 'bridge loops'. Yet they don't say they have spent any time confirming their speculation, or any effort in identifying the cause of these 'bridge loops'. They also speculate about what the consequences of these 'bridge loops' are (STP messages being dropped because of control plane overload). They're actively working on taking actions to remedy this, without any evidence their speculation is true. They're jumping to conclusions. > > With so little apparent proper evidence collecting and proper troubleshooting and diagnosis, how can the blog author be sure IPv6 MLD with the RA option is the specific cause of their problems? Consequently, how can this group then accept that as conclusive and therefore spend time speculating on changes that could be made to MLD that may also be completely ineffective on that network - because it may not be the cause at all? There isn't even enough detail in that blog post to be able to reproduce the scenario independently - what hosts/host OSes are they using, how many are there, are they running other multicast applications etc., etc., > > I think it is possible that RA option in MLD messages might be one of the causes of or contributors to their problems. However, there are many other possible causes that don't seem to have been investigated. > > > One reason I'm sceptical about MLD being the cause is because versions of Windows since Vista (released January 2007) have been IPv6 enabled by default, and have been issuing solicited-node MLDv2 reports for its link-local addresses, and if global or ULA prefixes are available, has been generating privacy addresses and corresponding solicited-node MLDv2 reports for those too. So since at least 2007, many MLD messages have been sent onto many different switched networks for many years. If RA option in MLDv2 reports were such a problem to switched networks, we should have heard about it by now and have also seen other networks suffer from this problem. This problem seems to be unique to this network, and therefore I think that is a sign that something else is going on, in addition to the other signs like this 'bridge loops' and unexplained software and perhaps hardware faults. > > I've proposed using these solicited-node MLD reports to further help mitigate the ND cache DoS (draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node). People were concerned that hosts weren't sending them, so I've collected some packet captures of an individual host booting on a (virtual) network with a single IPv6 router (OpenWRT 14.07 rc1) announcing a single ULA prefix. If people want to see what is typical, here are the Windows captures (Windows XP after IPv6 was enabled). Note the captures were taken at the router's interface rather than the host's, so they're showing what the router receives from the hosts or sends towards them, rather than what the hosts were sending or receiving. > > http://www.users.on.net/~markachy/windows-xp-sp3-boot-rtr-cap.pcap > > http://www.users.on.net/~markachy/windows-vista-boot-rtr-cap.pcap > > http://www.users.on.net/~markachy/windows-7-boot-rtr-cap.pcap > > http://www.users.on.net/~markachy/windows-8.1-boot-rtr-cap.pcap > > Regards, > Mark. > > >> Exactly what the v6ops charter says we should do, in fact. >> >> "1. Solicit input from network operators and users to identify >> operational issues with the IPv4/IPv6 Internet, and >> determine solutions or workarounds to those issues. These issues >> will be documented in Informational or BCP RFCs, or in >> Internet-Drafts." >> >> Or recommend protocol changes if they might help, which is why I >> want to understand the value of Router Alert in MLD messages for >> Solicited-Node multicast addresses. Or should we revive >> draft-pashby-magma-simplify-mld-snooping-01? >> >> Brian >> >> >> >> On 09/09/2014 13:55, Mark ZZZ Smith wrote: >>> >>> >>> ----- Original Message ----- >>>> From: Brian E Carpenter >>>> To: Dale W. Carder >>>> Cc: IPv6 Operations ; l.wood@surrey.ac.uk >>>> Sent: Tuesday, 9 September 2014, 7:59 >>>> Subject: Re: [v6ops] Interesting problems with using IPv6 >>>> >>>> I switched to the relevant list. >>>> >>>> On 09/09/2014 06:33, Dale W. Carder wrote: >>>>> Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Mon, >> Sep 08, >>>> 2014 at 07:50:26AM +1200: >>>>>> If they really are interesting problems, it might be more to >> the >>>>>> point to analyse them over on v6ops. Given the number of large >>>>>> IPv6 deployments that don't have such problems, it seems >> like >>>>>> this particular deployment hit an unfortunate combination of >>>>>> implementation issues. >>> >>> If this email is referring to this blog post: >>> >>> >> http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ >>> >>> then I think this particular network was already on the verge of >> catastrophic failure, and some of IPv6's ND differences were just the >> trigger to push it over that threshold. >>> >>> According to the blog post, they might have: >>> >>> - hardware errors >>> - software errors >>> - 'bridge loops' causing the control plane to overload >>> >>> In some of these cases they've taken actions to try to resolve them, >> however the actions taken seem to be based on speculating what is happening >> rather than finding evidence to support the hypothesised cause before taking >> action. >>> For example, there isn't any evidence that they've actually >> determined that 'bridge loops' are occurring, found out what is causing >> them, and then taking measures to prevent them or at least reduce the chances of >> them occurring. If a 'bridge loop' can cause the control plane to >> overload, then adding anything to this network like IPv6 is likely to only make >> the problem worse. >>> I'd like to see them get to the bottom of and then fix these >> 'bridge loop' and other problems first before any value is placed on >> addressing their criticisms of IPv6. Other people have deployed IPv6 without >> these problems, so what is different between this network and everybody >> else's that doesn't have these sorts of problems? >>> >>> >>> That is worth understanding (for example, >>>>>> how large is the layer 2 network that leads to the MLD >> listener >>>>>> report overload?). >>>>> Implementing MLD snooping for Solicited-Node multicast addresses >>>>> is probably a bad idea. >>>>> >>>>> See: draft-pashby-magma-simplify-mld-snooping-01 >>>> OK, but I would also like to understand why we require >>>> MLD messages for a Solicited-Node multicast address to >>>> set Router Alert. >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> > From nobody Sun Sep 14 22:04:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09281A0650 for ; Sun, 14 Sep 2014 22:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 TaH_W-9nXpBY for ; Sun, 14 Sep 2014 22:04:29 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60B91A0645 for ; Sun, 14 Sep 2014 22:04:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B8237A5; Mon, 15 Sep 2014 07:04:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1410757466; bh=aAzh5WKAAPNVXWS07pmxyZIoZj6MtH7QjzrqA4zMU40=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Q2HOJVWJj5P3AEkbH4eEARduB97chGH37xlocHJEnc0cwGbzcdd7+Hpe+CcyKtuA6 zEVEFjUPHVShYlYU7e5vjU8sQdf3SgiW6LDbtNlPPoLB+XfSbkm5/1Y0CcK08LC+br +qDYpyyzRlZgVRiiLP7vppbchBvbMwdShJShlMeM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AC3EAA2; Mon, 15 Sep 2014 07:04:26 +0200 (CEST) Date: Mon, 15 Sep 2014 07:04:26 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <54166EE5.9080007@gmail.com> Message-ID: References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3VTh01NCGWPJdYwUENdzRqw341o Cc: IPv6 Operations Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Sep 2014 05:04:31 -0000 On Mon, 15 Sep 2014, Brian E Carpenter wrote: > was MLD snooping (i.e. a layer violation by L2 switches). Even so, This is the first time I have seen anyone calling MLD/IGMP snooping a "layer violation by L2 switches" (I'm interpreting this as you thinking it's negative, do tell if this is not the case). How else is L2 equipment going to make intelligent decisions about multicast forwarding within an L2? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Sep 14 22:58:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527091A05D3 for ; Sun, 14 Sep 2014 22:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=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 06NySTwzmorg for ; Sun, 14 Sep 2014 22:58:51 -0700 (PDT) Received: from nm49.bullet.mail.ne1.yahoo.com (nm49.bullet.mail.ne1.yahoo.com [98.138.120.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D611A058E for ; Sun, 14 Sep 2014 22:58:51 -0700 (PDT) Received: from [127.0.0.1] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2014 05:58:50 -0000 Received: from [98.138.226.179] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2014 05:55:51 -0000 Received: from [98.139.212.153] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2014 05:55:51 -0000 Received: from [98.139.212.214] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 05:55:51 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 05:55:51 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 459518.5101.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 95872 invoked by uid 60001); 15 Sep 2014 05:55:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1410760551; bh=Mpsg0lBqjkUHBCJx51wrNhie9TCnfJTZUTyGtN7XNWA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PA7pC/a1iUuurdnZ6Wa49LH7SYA7LFbONKTwbJ7+It1e/29xZFcn3PhPAq17eqCEhPI0QFOO63jTaq/UY8f6ebsSO3RtIjGKC3+xa15hZqKAht/jhxeDXpNs62oTi+Ldt7+sjoTh2zLEtIlvvszbci2XeBE9TJ3eCAd1hmyjcIs= X-YMail-OSG: 4qZL2cAVM1mA3XoYXMZUAdF1pXV8RizMIxW4RXBssvsBQB. Gv2bLwq.0rMr9tBDhAQU1m67gMWvUOIrcLzNNQypFmn0j9ii7K01Pib9KFR0 iq7QxkBYd0DvJV3OWuQRMNGHYT7Cau0QRbm7APncT0sLJ2lyiPVTtvaoO4eH dWWVOxA6NtlibfEQ4DUVr7lbp8p3I38tDI1y0oMMqWnq_h94GbdwrrqOZ_Yq .wCiWMwoF7CIkXhU1ZXxnerIT3N0GTgLFTaiZIoucnTOmCcapv5t_keNIUK1 chxNU_M9yLksW6AcAgQbQV.0G9EkiUjaIWKU9J8fqn31nHymHYaG6ips3lR6 ki5R4ZZ5D7OsfTqnqo3lFlcPKrima.shfNyarm7rPMmpOG4_9pFvdPu2yi_W EpDXph6KO9P0BQPdqmSQmiFzHcKSnxb2Hbz6EXvVdm8oFg47C2fI.4Pl0F49 sLMx.Dgmsc36RkQL22mqCWsuU2FlK1rQ2LrukCk.JYrTSEqYjrtueRbPJlH_ m5FD5sGDj42nwmXjLEisYil8hnn.VhG1Liy6Y0YdtVbqRMwHm33ajBVXP_0_ _Qg1r.qZOYIgG4XOfFbMsYTK_8ZBinKF87n7DWBxwF3D8SMTmyoixPHhICXA 81eu8wB8pzEDnWQZBIG453vEq4N0fHkkr3Nk- Received: from [220.247.153.116] by web162201.mail.bf1.yahoo.com via HTTP; Sun, 14 Sep 2014 22:55:51 PDT X-Rocket-MIMEInfo: 002.001, SGkgYWxsLAoKUmVnYXJkaW5nIHRoaXMsIEkgcHJlc2VudGVkIG9uIHRoaXMgYXQgQXVzbm9nIGluIFN5ZG5leSBqdXN0IG92ZXIgYSB3ZWVrIGFnby4gRm9yIHRob3NlIGludGVyZXN0ZWQsIGhlcmUgYXJlIHRoZSBzbGlkZXM6CgoiTmV0d29yayBWaXJ0dWFsaXNhdGlvbjogVGhlIEtpbGxlciBBcHAgZm9yIElQdjY_IgpodHRwOi8vd3d3LnVzZXJzLm9uLm5ldC9.bWFya2FjaHkvbnZ0a2FpcHY2LnBkZgoKClRoYW5rcywKTWFyay4KCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogRnJlZCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <20140816101041.6913.45904.idtracker@ietfa.amsl.com> <5AE88B79-FB7F-4C47-BEEC-4290A48477E3@cisco.com> Message-ID: <1410760551.17161.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Sun, 14 Sep 2014 22:55:51 -0700 From: Mark ZZZ Smith To: "Fred Baker \(fred\)" , IPv6 Ops WG In-Reply-To: <5AE88B79-FB7F-4C47-BEEC-4290A48477E3@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LD6dn7dFEI_DfjKRJRUa6mNUy2o Subject: Re: [v6ops] Fwd: I-D Action: draft-smith-enhance-vne-with-ipv6-04.txt 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: Mon, 15 Sep 2014 05:58:52 -0000 Hi all,=0A=0ARegarding this, I presented on this at Ausnog in Sydney just o= ver a week ago. For those interested, here are the slides:=0A=0A"Network Vi= rtualisation: The Killer App for IPv6?"=0Ahttp://www.users.on.net/~markachy= /nvtkaipv6.pdf=0A=0A=0AThanks,=0AMark.=0A=0A=0A----- Original Message -----= =0A> From: Fred Baker (fred) =0A> To: IPv6 Ops WG =0A> Cc: =0A> Sent: Sunday, 17 August 2014, 5:17=0A> Subject: [v6ops= ] Fwd: I-D Action: draft-smith-enhance-vne-with-ipv6-04.txt=0A> =0A> Mark w= ould like our comments, please=0A> =0A>> From: = =0A>> Subject: I-D Action: draft-smith-enhance-vne-with-ipv6-04.txt=0A>> = Date: August 16, 2014 at 3:10:41 AM PDT=0A>> To: = =0A>> Reply-To: =0A>> =0A>> =0A>> A New Interne= t-Draft is available from the on-line Internet-Drafts =0A> directories.=0A>= > =0A>> =0A>> Title : Enhancing Virtual Network Encapsulat= ion with IPv6=0A>> Author : Mark Smith=0A>> Filename = : draft-smith-enhance-vne-with-ipv6-04.txt=0A>> Pages = : 17=0A>> Date : 2014-08-16=0A>> =0A>> Abstract:=0A>> A = variety of network virtualization over layer 3 methods are=0A>> currently= being developed and deployed. These methods treat IPv4 and=0A>> IPv6 as= equivalent underlay network technologies. This memo suggests=0A>> how I= Pv6's additional capabilities may be used to enhance Virtual=0A>> Network= encapsulation over an IPv6 Underlay Network.=0A>> =0A>> =0A>> The IETF da= tatracker status page for this draft is:=0A>> https://datatracker.ietf.org= /doc/draft-smith-enhance-vne-with-ipv6/=0A>> =0A>> There's also a htmlized= version available at:=0A>> http://tools.ietf.org/html/draft-smith-enhance= -vne-with-ipv6-04=0A>> =0A>> A diff from the previous version is available= at:=0A>> http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-enhance-vne-with-= ipv6-04=0A>> =0A>> =0A>> Please note that it may take a couple of minutes = from the time of =0A> submission=0A>> until the htmlized version and diff = are available at tools.ietf.org.=0A>> =0A>> Internet-Drafts are also avail= able by anonymous FTP at:=0A>> ftp://ftp.ietf.org/internet-drafts/=0A>> = =0A>> _______________________________________________=0A>> I-D-Announce m= ailing list=0A>> I-D-Announce@ietf.org=0A>> https://www.ietf.org/mailman/= listinfo/i-d-announce=0A>> Internet-Draft directories: http://www.ietf.org= /shadow.html=0A>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A> =0A> __= _____________________________________________=0A> v6ops mailing list=0A> v6= ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From nobody Mon Sep 15 04:47:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1161A0B84 for ; Mon, 15 Sep 2014 04:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 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=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLccV7WjtUDD for ; Mon, 15 Sep 2014 04:47:07 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E451A0B04 for ; Mon, 15 Sep 2014 04:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134; q=dns/txt; s=iport; t=1410781627; x=1411991227; h=date:from:message-id:to:subject:cc; bh=mFS66LgHbiGlMCFLMuYOCf8hHFRBMiQO5pTKOMi+x/g=; b=koGqKzM0K4xmTGK0nuhhnWTMFL6aUv8FlBjyuHFRFW7kmuZipHQvX6Jt +GkSTaQtme8CUYSXx7b1OoVHmT2cpsktpL0gySOI260MRWfDdQhjsMWQk q4cTQNtaCpj0bIGj8mk4KOTRZCztr7hsL8IIgbFhjDEtRHvR+esz5NGoe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYHAMvQFlStJV2c/2dsb2JhbABggw1TWLZoAZQBh0UJgRcWeIUDPDSJHgENuicBF49NHYQ1BYs/ikWIY5Ngg36DFgEBAQ X-IronPort-AV: E=Sophos;i="5.04,527,1406592000"; d="scan'208";a="78007760" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 15 Sep 2014 11:47:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8FBl4Ju003199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2014 11:47:04 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s8FBl2Lk022750; Mon, 15 Sep 2014 04:47:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s8FBl2Xn022746; Mon, 15 Sep 2014 04:47:02 -0700 Date: Mon, 15 Sep 2014 04:47:02 -0700 From: fred@cisco.com Message-Id: <201409151147.s8FBl2Xn022746@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1pOAvBPdVq80CMdgVVfg9VrNF68 Cc: draft-anderson-v6ops-siit-dc-2xlat@tools.ietf.org Subject: [v6ops] new draft: draft-anderson-v6ops-siit-dc-2xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Sep 2014 11:47:09 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-siit-dc-2xlat. Please take a look at it and comment. From nobody Mon Sep 15 04:47:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A517B1A0B04 for ; Mon, 15 Sep 2014 04:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 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=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4868699GUpYb for ; Mon, 15 Sep 2014 04:47:07 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BAB1A0B74 for ; Mon, 15 Sep 2014 04:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=128; q=dns/txt; s=iport; t=1410781627; x=1411991227; h=date:from:message-id:to:subject:cc; bh=s0NO72wOqBC1prhCmZ1kc3GRYZBvhe39jAVqzGojoqQ=; b=lFZI4a1qQu11jZ1P8j/Xy7HXrgFCi9mjKF9IZq0NpmvAFxJAllDetPyz asZb+sRJzE7/6CTP7zEV4lK4kozGv+Nsciitshv1kjtojPwmS6DziqrXN Af/e+E2tgEK4pLrjUxIUW5ERdtW1EkmBFipt7z99weFIh2W2MTRE4By5V g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYHACLRFlStJV2T/2dsb2JhbABggw1TWLZoAZQBh0UJgRcWeIUDPDSJHgENuicBF49NHYQ1BYs/ikWIY5Ngg36DFgEBAQ X-IronPort-AV: E=Sophos;i="5.04,527,1406592000"; d="scan'208";a="78007896" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 15 Sep 2014 11:47:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8FBl45s008296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2014 11:47:04 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s8FBl2Dp022751; Mon, 15 Sep 2014 04:47:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s8FBl2Va022742; Mon, 15 Sep 2014 04:47:02 -0700 Date: Mon, 15 Sep 2014 04:47:02 -0700 From: fred@cisco.com Message-Id: <201409151147.s8FBl2Va022742@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nEH2qjz1uTMn3Z46kcb6_BVfyRo Cc: draft-anderson-v6ops-siit-dc@tools.ietf.org Subject: [v6ops] new draft: draft-anderson-v6ops-siit-dc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 11:47:09 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-siit-dc. Please take a look at it and comment. From nobody Mon Sep 15 10:27:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97831A913F; Mon, 15 Sep 2014 10:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-_al41bDkzl; Mon, 15 Sep 2014 10:27:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA67D1A9140; Mon, 15 Sep 2014 09:47:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140915164739.30007.58222.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 09:47:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wN-YrequYQl3AzYj2JZkPUA8XfI Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv6 Roaming Behavior Analysis) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:27:34 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 Roaming Behavior Analysis' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 15 13:21:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4001A1A7031 for ; Mon, 15 Sep 2014 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K86BXkGGFzu for ; Mon, 15 Sep 2014 13:20:56 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C942A1A6FE0 for ; Mon, 15 Sep 2014 13:20:56 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lj1so7265763pab.41 for ; Mon, 15 Sep 2014 13:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hZDv1I68gdBNRqrgs3jERrgQNk968FZwhND81O3CU4I=; b=B8K+5AQVZX2m8Yznt8FyPbBoN3oZhfYkE+nhjASlDZSzwJ254sajngoROPUCU3me+1 ndY2Dp8aH08o+XaAtc9LOwHyT6Tw9KBQimlpxXgl0T43xL66D3CKg9DjLrxv0eQExwnq qffi9m5T9JFmsprTzH5hDRyC4cto16mGRUjo6Sqr+Y3ZEL4zsV9fCGteXzR8gv+iOWOz s7DFNLZSzqcrgz8P97l2p5+muH1yXdynSyAEcjKVoiC7VqH8PNplo6UOPCendeoIANHe BAuCeYoBLlzLr0dN1T5TDh+YiJk5scncAiPK7sEU/HrRh13mGvkRRfw4RLFtGcoc7ia0 a6Dg== X-Received: by 10.68.209.169 with SMTP id mn9mr42353917pbc.37.1410812456506; Mon, 15 Sep 2014 13:20:56 -0700 (PDT) Received: from [192.168.178.23] (182.197.69.111.dynamic.snap.net.nz. [111.69.197.182]) by mx.google.com with ESMTPSA id jw6sm12129307pbc.79.2014.09.15.13.20.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 13:20:55 -0700 (PDT) Message-ID: <54174A26.1050206@gmail.com> Date: Tue, 16 Sep 2014 08:20:54 +1200 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: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DKERpx6DDJ2jPTzbvTe1KE5m6Xo Cc: IPv6 Operations Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Sep 2014 20:20:58 -0000 On 15/09/2014 17:04, Mikael Abrahamsson wrote: > On Mon, 15 Sep 2014, Brian E Carpenter wrote: > >> was MLD snooping (i.e. a layer violation by L2 switches). Even so, > > This is the first time I have seen anyone calling MLD/IGMP snooping a > "layer violation by L2 switches" (I'm interpreting this as you thinking > it's negative, do tell if this is not the case). Yes, layer violations have this nasty habit of coming back and biting you, and this is an example. > How else is L2 equipment going to make intelligent decisions about > multicast forwarding within an L2? They're not. That's why DEC Gigaswitches had ARP throttling, for example, to control broadcast storms. It's unavoidable if you build big L2 networks. I learnt not to do that. Brian From nobody Mon Sep 15 15:09:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BC91A87F0 for ; Mon, 15 Sep 2014 15:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ia6HuFqHMw22 for ; Mon, 15 Sep 2014 15:08:59 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2153A1A87C4 for ; Mon, 15 Sep 2014 15:08:59 -0700 (PDT) Received: from [172.22.229.45] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8FM8sOC001507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 15:08:55 -0700 Message-ID: <54176375.3070003@acm.org> Date: Mon, 15 Sep 2014 15:08:53 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , Mikael Abrahamsson References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> <54174A26.1050206@gmail.com> In-Reply-To: <54174A26.1050206@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVY3x7atgBirB3kAwa5Zf2HNAzJQ92EiSZ1u3w1rs50fiudkPd3TiEmsG5uCLLfYRbWpVpTeRnEXQHJILylCRzl4 X-Sonic-ID: C;Giep4SQ95BGJ4jZXoK8kYw== M;KB9r4iQ95BGJ4jZXoK8kYw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/u18eao6WhBCU5oOQGSrC2OIi1b0 Cc: IPv6 Operations Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Sep 2014 22:09:01 -0000 On 9/15/14, 1:20 PM, Brian E Carpenter wrote: > On 15/09/2014 17:04, Mikael Abrahamsson wrote: >> On Mon, 15 Sep 2014, Brian E Carpenter wrote: >> >>> was MLD snooping (i.e. a layer violation by L2 switches). Even so, >> This is the first time I have seen anyone calling MLD/IGMP snooping a >> "layer violation by L2 switches" (I'm interpreting this as you thinking >> it's negative, do tell if this is not the case). > Yes, layer violations have this nasty habit of coming back and > biting you, and this is an example. Brian, I don't think we have sufficient data on the contributions of the different factors that resulted in triggering the implementation problems in this case. The overloading of IGMP for to both feed L3 multicast routing information into routers and to feed L2 multicast information into IGMP snooping switches (which was faithfully carries forward into MLD) certainly is part of the picture. That results in the routers seeing MLD reports for link-local groups, which the routers do not care about. But even if we had a non-overloaded approach (with L2 multicast membership being propagated by IEEE *Multiple Registration Protocol* (*MRP*) instead of IGMP/MLD snooping), the L2 switches would still be overloaded with so many temporary addresses and associated solicited-node multicast addresses. Of course, I've never seen a host which implements MRP, but that is separate from the implied architectural question about which part of the blame should be placed on overloading (or layer violations if you prefer that term) in this case. Regards, Erik > >> How else is L2 equipment going to make intelligent decisions about >> multicast forwarding within an L2? > They're not. That's why DEC Gigaswitches had ARP throttling, for example, > to control broadcast storms. It's unavoidable if you build big L2 > networks. I learnt not to do that. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 15 16:40:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C801A0027 for ; Mon, 15 Sep 2014 16:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUrqxLTEMkq3 for ; Mon, 15 Sep 2014 16:40:48 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72DF1A002A for ; Mon, 15 Sep 2014 16:40:47 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s8FNeeXD054069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 16 Sep 2014 00:40:40 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <541778F8.8090605@foobar.org> Date: Tue, 16 Sep 2014 00:40:40 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> <54174A26.1050206@gmail.com> In-Reply-To: <54174A26.1050206@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mqVA8C8AxGZViJiGzxTobwytj7E Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Sep 2014 23:40:50 -0000 On 15/09/2014 21:20, Brian E Carpenter wrote: >> How else is L2 equipment going to make intelligent decisions about >> multicast forwarding within an L2? > > They're not. That's why DEC Gigaswitches had ARP throttling, for example, > to control broadcast storms. It's unavoidable if you build big L2 > networks. I learnt not to do that. let's be careful what we're talking about here. The problems of yesteryear were related to large broadcast domains. The problems we're discussing here relate to modest-sized broadcast domains, but potentially with a large number of them traversing a single switch. These are different problem spaces and it is not helpful to confuse the two. This original issue brings up a number of awkward questions about scalability, which at heart is a protocol design issue and not - as stated by others - either a vendor implementation issue or a protocol issue. The IETF created a protocol dependency mechanism to assist scalability by allowing large numbers of v6 addresses to exist on the same l2 network (both single broadcast domain and multiple broadcast domains). The mechanism operates along the lines of: - ND depends on multicast for basic functionality - ND multicast addressing uses multicast groups to assist scalability - MLD is implemented to help l2 devices decide how and where to prune v6 multicast transmission - this mechanism pushes state into the l2 forwarding control plane (SP = switch processor) - privacy addresses increase the number of v6 addresses on any single/multi broadcast domains by an order of magnitude, give or take. - anecdotally, it seems that the continued existence of large-ish but segmented multiple vlan l2 networks and the advent of privacy addresses means that switches are seeing a problematic quantity of state being pushed to the SP on some networks. Stepping back a little to broadcast vs multicast, the v6 protocol was designed this way to work around the rampant broadcast storm problems of the 1990s where large broadcast domains were all the rage. Those who were around at the time will remember windows 3.1 cpus pegging due to 10 megs of broadcast traffic on the campus /16. In this sort of situation, mld snooping might well have worked nicely to stop problems at the network edge The problem set has changed - modern networks rarely use large flat networks but instead segment networks into large numbers of vlans on a shared physical infrastructure. This means that today, the protocol that was designed to help at the network edge is hurting at the network core and we are applying a solution to a problem which largely no longer exists in its original context. The irony is that the solution which was created to allow ipv6 to scale on large layer 2 domains is restricting scalability on large layer 2 domains. We have merely swapped one scaling problem for another. Nick (*) there is an exception in large scale virtualised infrastructure, where VM networking people have not learned the lessons of the past and there is a massive push to create underlay protocols to allow enormous l2 domains which span multiple locations. From nobody Mon Sep 15 17:03:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1703F1A0066 for ; Mon, 15 Sep 2014 17:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTqjLHLi0rsP for ; Mon, 15 Sep 2014 17:03:26 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DDA1A0049 for ; Mon, 15 Sep 2014 17:03:25 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id p10so7345955pdj.30 for ; Mon, 15 Sep 2014 17:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F40BjTL0wLBy8Y2/BDDkbEdjaf4w7mbJDbdk37zDvSo=; b=R18ExzzYGBM+hfgkNZ4HJkDSkcxvGfERntuU7icmgdS0TPyTsoqaNlqiwGKOvMs3UN xeXKX2zzmIUj0Wj8aSboivd4SXwM+X7k6Pm/JP0eHXwInR4povZiy0WYaiNyaY66sFBu R6YnGb+W4cbWw9P3k0Ld+eqNAnn+BQNMTz1ZhgMHoy9wpviOuGpxOAGo+cAChrlOQhxe QJR9XD1nSdalmIFFd1FSZcOLHOs+IvOK/r8e4NtgZESXJjNwXhN30kt9ZxR9muX42WOI 4oE34xOCtXss54gQtLihQ7jPO8bZmkJYuo5Pmgf+djDqXih2VvopHemECvDsAdTTfoi1 qAIg== X-Received: by 10.70.131.199 with SMTP id oo7mr52157017pdb.95.1410825805685; Mon, 15 Sep 2014 17:03:25 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id cz1sm2916928pdb.85.2014.09.15.17.03.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 17:03:25 -0700 (PDT) Message-ID: <54177E4B.5010004@gmail.com> Date: Tue, 16 Sep 2014 12:03:23 +1200 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: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> <54174A26.1050206@gmail.com> <541778F8.8090605@foobar.org> In-Reply-To: <541778F8.8090605@foobar.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xC1_UjDt0sXICIDR61q0MlbhcIc Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Sep 2014 00:03:28 -0000 On 16/09/2014 11:40, Nick Hilliard wrote: > On 15/09/2014 21:20, Brian E Carpenter wrote: >>> How else is L2 equipment going to make intelligent decisions about >>> multicast forwarding within an L2? >> They're not. That's why DEC Gigaswitches had ARP throttling, for example, >> to control broadcast storms. It's unavoidable if you build big L2 >> networks. I learnt not to do that. > > let's be careful what we're talking about here. The problems of yesteryear > were related to large broadcast domains. The problems we're discussing > here relate to modest-sized broadcast domains, but potentially with a large > number of them traversing a single switch. These are different problem > spaces and it is not helpful to confuse the two. Well, that's true, and the definition of "large" has changed as microelectronics has continued to improve. But the point is that for any particular scenario and generation of technology, there is scaling limit for L2. What you say below is also very true. Brian > > This original issue brings up a number of awkward questions about > scalability, which at heart is a protocol design issue and not - as stated > by others - either a vendor implementation issue or a protocol issue. The > IETF created a protocol dependency mechanism to assist scalability by > allowing large numbers of v6 addresses to exist on the same l2 network > (both single broadcast domain and multiple broadcast domains). > > The mechanism operates along the lines of: > > - ND depends on multicast for basic functionality > > - ND multicast addressing uses multicast groups to assist scalability > > - MLD is implemented to help l2 devices decide how and where to prune v6 > multicast transmission > > - this mechanism pushes state into the l2 forwarding control plane (SP = > switch processor) > > - privacy addresses increase the number of v6 addresses on any single/multi > broadcast domains by an order of magnitude, give or take. > > - anecdotally, it seems that the continued existence of large-ish but > segmented multiple vlan l2 networks and the advent of privacy addresses > means that switches are seeing a problematic quantity of state being pushed > to the SP on some networks. > > Stepping back a little to broadcast vs multicast, the v6 protocol was > designed this way to work around the rampant broadcast storm problems of > the 1990s where large broadcast domains were all the rage. Those who were > around at the time will remember windows 3.1 cpus pegging due to 10 megs of > broadcast traffic on the campus /16. In this sort of situation, mld > snooping might well have worked nicely to stop problems at the network edge > > The problem set has changed - modern networks rarely use large flat > networks but instead segment networks into large numbers of vlans on a > shared physical infrastructure. This means that today, the protocol that > was designed to help at the network edge is hurting at the network core and > we are applying a solution to a problem which largely no longer exists in > its original context. > > The irony is that the solution which was created to allow ipv6 to scale on > large layer 2 domains is restricting scalability on large layer 2 domains. > We have merely swapped one scaling problem for another. > > Nick > > (*) there is an exception in large scale virtualised infrastructure, where > VM networking people have not learned the lessons of the past and there is > a massive push to create underlay protocols to allow enormous l2 domains > which span multiple locations. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 15 22:16:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED0C1A02A2 for ; Mon, 15 Sep 2014 22:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 WmZpEOJUaZdh for ; Mon, 15 Sep 2014 22:16:43 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906321A02A0 for ; Mon, 15 Sep 2014 22:16:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 75EDDA6; Tue, 16 Sep 2014 07:16:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1410844601; bh=RFnxtEAXkO/5pKTWRd6xsIer1netcNhc/z8qEfHVYaA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kpyH/1+D4lPy3uaYC+xC7qwg0WWi3B74TC+5pTAHuPFCR0UejaodmcIN01R8SUxkd knzsIgKUNc3pIaPf6GtzHvN3AlH3/YaefW0GTmYpOKoxtwdD4sgYeBH7dKcx53jGfu QDIP9MLl5Bi+9XoAq5/r81L68pRbfl/w1eSLtMPs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6E3D7A5; Tue, 16 Sep 2014 07:16:41 +0200 (CEST) Date: Tue, 16 Sep 2014 07:16:41 +0200 (CEST) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <541778F8.8090605@foobar.org> Message-ID: References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> <54174A26.1050206@gmail.com> <541778F8.8090605@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EwF6CeAQji7Kq8-T1BjvueEf6IM Cc: v6ops@ietf.org Subject: Re: [v6ops] Interesting problems with using IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Sep 2014 05:16:45 -0000 On Tue, 16 Sep 2014, Nick Hilliard wrote: > - MLD is implemented to help l2 devices decide how and where to prune v6 > multicast transmission Well, one could argue that MLD is there to tell the NIC what multicast packets to actually forward into the computer, and which ones are safe to drop on the floor at the NIC level. So one doesn't actually have to have L2 switches look at MLD and use it for forwarding decisions to actually get some benefit out of the multicast/broadcast distinction in IPv6. So if bandwidth isn't a problem, but CPU IRQs are (they're usually not), then it's still a benefit. But I generally agree with your assessment of the situation, I just wanted to add this one point. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 17 22:30:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F211A6F63; Wed, 17 Sep 2014 22:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMn_o33ECkfh; Wed, 17 Sep 2014 22:30:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6C31A6F82; Wed, 17 Sep 2014 22:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918053003.31797.24863.idtracker@ietfa.amsl.com> Date: Wed, 17 Sep 2014 22:30:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ragp7Z2lKp7yeY9zoxhJADGPQV0 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 05:30:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-12.txt Pages : 20 Date : 2014-09-17 Abstract: This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 18 15:55:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F191A8F40; Thu, 18 Sep 2014 15:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBc4RfbH4vuI; Thu, 18 Sep 2014 15:55:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D8B1A8F49; Thu, 18 Sep 2014 15:55:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918225506.28674.39149.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 15:55:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YSn3SSKzrGGoLc-1FGwtxJUbQVI Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 22:55:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-03.txt Pages : 16 Date : 2014-09-18 Abstract: This document presents advice on the design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 18 16:04:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3E1A90E8 for ; Thu, 18 Sep 2014 16:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3VpUWsjRyzj for ; Thu, 18 Sep 2014 16:04:14 -0700 (PDT) Received: from mail-01.primus.ca (smtp4.primus.ca [216.254.141.18]) by ietfa.amsl.com (Postfix) with ESMTP id 41D961A8F49 for ; Thu, 18 Sep 2014 16:04:12 -0700 (PDT) Received: from bas2-kanata16-2925101811.dsl.bell.ca ([174.89.130.243] helo=[10.0.2.3]) by mail-01.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1XUkkF-0008CN-0y; Thu, 18 Sep 2014 19:04:11 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20140918225506.28674.39149.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 19:04:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94D4C026-F771-4B47-B42D-C7C4336727CC@magma.ca> References: <20140918225506.28674.39149.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas2-kanata16-2925101811.dsl.bell.ca ([10.0.2.3]) [174.89.130.243] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Kei9ABSdO6L1QbwSop5kP7znpvE Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 23:04:16 -0000 Victor and I have made a minor revision to the draft to address the = recent comments posted to the list. Changes: * Added a reference to RFC5375 (the unicast addressing considerations = document) in section 2.1.2, as requested by Nick Chettle. * Corrected a few grammatical and spelling errors. - Phillip On 2014-09-18, at 18:55 , Internet-Drafts@ietf.org wrote: >=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 : Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-03.txt > Pages : 16 > Date : 2014-09-18 >=20 > Abstract: > This document presents advice on the design choices that arise when > designing IPv6 networks (both dual-stack and IPv6-only). The > intended audience is someone designing an IPv6 network who is > knowledgeable about best current practices around IPv4 network > design, and wishes to learn the corresponding practices for IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-03 >=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 >=20 From nobody Thu Sep 18 16:12:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEDE1A90F0 for ; Thu, 18 Sep 2014 16:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YGtOfiMyeU0 for ; Thu, 18 Sep 2014 16:12:00 -0700 (PDT) Received: from mail-08.primus.ca (smtp4.primus.ca [216.254.141.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA761A8F49 for ; Thu, 18 Sep 2014 16:12:00 -0700 (PDT) Received: from bas2-kanata16-2925101811.dsl.bell.ca ([174.89.130.243] helo=[10.0.2.3]) by mail-08.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1XUkrm-0006T7-1s; Thu, 18 Sep 2014 19:11:59 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Thu, 18 Sep 2014 19:11:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140905015058.25008.89518.idtracker@ietfa.amsl.com> <6F628257-7830-4824-A56B-DA54F61E3193@magma.ca> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas2-kanata16-2925101811.dsl.bell.ca ([10.0.2.3]) [174.89.130.243] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2cMz0qUG8TDiLuemgEM9t5jJdHk Cc: v6ops list , Victor Kuarsingh Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 23:12:01 -0000 Mikael: Victor and I re-reviewed section 2.1.1 in light of your comments.=20 Your basic point, that at some times it is necessary to have IPv4 and = IPv6 on different VLANs, is the whole point of this section, and neither = of us could think of anything useful to add to this section to expand on = it more without making the section extremely long. However, if you have some suggested text, or additional points to add, = then please send them to us. Philip On 2014-09-09, at 3:36 , Mikael Abrahamsson wrote: > On Thu, 4 Sep 2014, Philip Matthews wrote: >=20 >> Thanks in advance for any comments, and sorry that we have been a bit = slow in updating the draft. >=20 > Hi, >=20 > In 2.1.1, I'd like to see some text talking about methods where IPv4 = and IPv6 can be separated by means of protocol based vlans, so end = system complexity isn't increased, it's only a network change. This way = IPv4 and IPv6 can have different topology, so that IPv4 choices don't = have to affect IPv6 choices. In light of recent talk about IPv6 = multicast and privacy addressing causing problems in networks, we should = give guidance pointing to the problems of having very large L2 domains. >=20 > One article: >=20 > = http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-we= ek/ >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Sep 19 04:47:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B006D1A011F for ; Fri, 19 Sep 2014 04:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 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=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVlVYVVX41zv for ; Fri, 19 Sep 2014 04:47:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599501A0119 for ; Fri, 19 Sep 2014 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=142; q=dns/txt; s=iport; t=1411127224; x=1412336824; h=date:from:message-id:to:subject:cc; bh=autJoK6zlB/2Ncoobjd8j/lit3h+/6BInA0ywx0pH9E=; b=bTxVwP9N/K1c+3SP+Pdkf+RZtysldbwlMasy4DrVtYsVPHzgGP7laS5X Chkq0bTcTi78WzapNWImDcsmKC2A1grsHL4oI378bGvv76JSTJLo4sIzN xgPGivZ5+WqHJXFVWXi0ByXkLfrwsae2RAsgxu7uo5cNmzztQB/VGmZa3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQHALYWHFStJV2Y/2dsb2JhbABggw1TWLhVAZEPh0QJgQMWAXmFAzw0iR4BDcJuGI93HYQ1BYtAikWIZ5Nog36DFgEBAQ X-IronPort-AV: E=Sophos;i="5.04,554,1406592000"; d="scan'208";a="356559614" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 19 Sep 2014 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8JBl2YE017431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2014 11:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s8JBl188016486; Fri, 19 Sep 2014 04:47:01 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s8JBl1Fe016458; Fri, 19 Sep 2014 04:47:01 -0700 Date: Fri, 19 Sep 2014 04:47:01 -0700 From: fred@cisco.com Message-Id: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OTXS89O---9yIl5c3GAUlApPr0I Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 11:47:04 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. Please take a look at it and comment. From nobody Fri Sep 19 04:47:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312291A0119 for ; Fri, 19 Sep 2014 04:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 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=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7_o6VvnfTiu for ; Fri, 19 Sep 2014 04:47:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C091A011D for ; Fri, 19 Sep 2014 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=138; q=dns/txt; s=iport; t=1411127224; x=1412336824; h=date:from:message-id:to:subject:cc; bh=vZpRNKMPFZiwfd937dZl6rKfv3SJrJ+c0ATHVFmUlEY=; b=T7uzwUjaMocj1Fu5dE3kAqg9GfQnVZOyuYo3NNynTcWvbYz9RtQStPHF DSp1bf7ZzUUHJXQnZbOLIzmIO3+Rg4cIdaWR5gdm8vSr/UDWO6ly0xd8I YW5T78bWU3uWAVtktVH1y0j3UK9sEhaf/rtuxEz6elFgaeGKMl7zsB2QF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQHANAWHFStJV2S/2dsb2JhbABggw1TWLhVAZEPh0QJgQMWAXmFAzw0iR4BDcJuGI93HYQ1BYtAikWIZ5Nog36DFgEBAQ X-IronPort-AV: E=Sophos;i="5.04,554,1406592000"; d="scan'208";a="79418033" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 19 Sep 2014 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8JBl2qJ029889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2014 11:47:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s8JBl1Pe016580; Fri, 19 Sep 2014 04:47:01 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s8JBl1Zv016462; Fri, 19 Sep 2014 04:47:01 -0700 Date: Fri, 19 Sep 2014 04:47:01 -0700 From: fred@cisco.com Message-Id: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Yzze3prPwWp7DcpHLeCFIBQbWY0 Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org Subject: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please take a look at it and comment. From nobody Fri Sep 19 09:41:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFF61A032E for ; Fri, 19 Sep 2014 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duIzsG2ueya5 for ; Fri, 19 Sep 2014 09:41:16 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54BA1A0326 for ; Fri, 19 Sep 2014 09:41:16 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id y20so3900515ier.33 for ; Fri, 19 Sep 2014 09:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5o08iUS8qqLVXljMOc5DeueCREMIAZQQ8fgKsV2cB3I=; b=ASGPxMgBPogRk8ZCaCn+jqk1bmbE1uGLs8eY88t1Zo2YgjcOO0F+hDgXSKu4AgNZAe fCvyQ6ifDZpZNFtENXo6oba/Q3IK4MLfV3/efu8w8orAz/XetGjnccqTQTaJpIp6tF3A K4egz9+DRVc26SfBwY36lhwqLZd1ZixmjwFlVlKV4pTJtkZHTQFu3NdhNz9oRN7ifsgN HrjJfuGFCQKaTqGoLNbWSNqjCaxYqQ/kTgpnAnkaqW88IuKdCp2V/AxpuJbIoU7PMhwI iyocRnBvqpGKnrM3sAuJ1pyovq76R1jikuny0G4AC2MaatmZLQi3Oi27q1Bt81ZbQQuM Zu6Q== MIME-Version: 1.0 X-Received: by 10.50.78.70 with SMTP id z6mr7867217igw.23.1411144876062; Fri, 19 Sep 2014 09:41:16 -0700 (PDT) Received: by 10.107.137.65 with HTTP; Fri, 19 Sep 2014 09:41:16 -0700 (PDT) In-Reply-To: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> Date: Fri, 19 Sep 2014 18:41:16 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/R9EHCS27rq5XhpEpQ8Ao01w9n2I Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 16:41:18 -0000 Looks like a reference to http://tools.ietf.org/html/rfc7051#page-15 could be useful, as well as the more detailed discussion of what factors are preventing from using the RFC7050's method ? The short sentence "But it is difficult and depends on DNS64" raises immediate questions: 1) "it is difficult" Needs to be qualified/reasoned. C code to create a DNS request can be implemented in ~200 lines, and the code to parse it can be done in ~300 lines, so even a host that does not use the DNS otherwise can have a lightweight module just for the sake of getting a prefix. That host already has to implement DHCPv6 client, this does not look like a lot of code nor a lot of complexity in comparison. 2) "requires DNS64" This in itself could be a valid consideration for a 464XLAT deployment choose to not use DNS64. But: what is the best *real-world* operational practice today - to use DNS64 or not ? If the real-world practice shows that DNS64 is harmful in 464XLAT deployments, this should be documented accordingly - and then there would be no uncertainty about the rationale for this approach. If the best practice is to use DNS64 anyway, then do we want to steer people away from it by providing a method that does not depend on DNS64 ? --a On 9/19/14, fred@cisco.com wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please > take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Sep 19 10:14:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC021A03A8 for ; Fri, 19 Sep 2014 10:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSc8nyQTMVub for ; Fri, 19 Sep 2014 10:14:49 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EC31A037B for ; Fri, 19 Sep 2014 10:14:18 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id y20so3966008ier.33 for ; Fri, 19 Sep 2014 10:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=St/g8gHh4uB3B62jcYUjzU6ATgyT5sSHV1TuvlGHris=; b=mkm+vlIs8DHzQmC8HU2anPSBW2XREjx7uT3APU8Qaj8YR9PHEjePIeNpU1p+xLkPA4 YbAPcppGcBFtSY2cu73rSuHHUnYo3xmLnwW4IUvk6Lh8peaZEsI5MSjl0kougi+IxbpI UaWZ5zeX6PW2HUMzwkOq4nUTOX7iNemJpsEsnSto9MXHE9Q9x399n99QJ4iUGzkSA4tZ zjAmPsBivBwg9IECFR1oGYed+cYBKBFcK92JLwe0tkCDTVFKq8Qcmv1ykwLFU406o/LS w5j2MDDriLEfAVKoIsmkZ//+7q8oPdpJE+d+md9n8g7yTuzX5z7AVsKGgp3anWBdUdqe grLQ== MIME-Version: 1.0 X-Received: by 10.50.41.104 with SMTP id e8mr56198963igl.35.1411146857083; Fri, 19 Sep 2014 10:14:17 -0700 (PDT) Received: by 10.107.137.65 with HTTP; Fri, 19 Sep 2014 10:14:17 -0700 (PDT) In-Reply-To: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> Date: Fri, 19 Sep 2014 19:14:17 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/R2O7wp4MffYiL9BBfwArc43rsPQ Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 17:14:50 -0000 A directed broadcast ping on IPv4 gives pretty much the same result. Did you test the effects of that ? Of course, private VLANs or (if we are talking VMs) or just using p2p links with /128s would help this in the environments where the hosts can not be trusted - and this of course is not virtual/physical specific. If we're talking specifically virtual environment, here's an approach on how to use ebtables to isolate the hosts: ebtables -P FORWARD DROP ebtables -F FORWARD ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow from uplink to any ports ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic flow from any ports to uplink (source: http://serverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-linux-bridges) So looks like the question at hand is: "Should IPv6 nodes respond to Ping to FF0x::1?" Which can be rephrased differently to ease the start of the discussion: "What are the legitimate uses of a ping to ff0x::1 ?" Right ? --a On 9/19/14, fred@cisco.com wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. > Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Sep 19 12:24:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5F81A876F for ; Fri, 19 Sep 2014 12:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 KK2fGiJYlov2 for ; Fri, 19 Sep 2014 12:24:33 -0700 (PDT) Received: from nm5-vm2.bullet.mail.ne1.yahoo.com (nm5-vm2.bullet.mail.ne1.yahoo.com [98.138.90.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36DB1A871E for ; Fri, 19 Sep 2014 12:24:32 -0700 (PDT) Received: from [98.138.101.129] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 19:24:32 -0000 Received: from [98.138.89.194] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 19:24:32 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 19:24:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 3630.88380.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 81716 invoked by uid 60001); 19 Sep 2014 19:24:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411154671; bh=M/SlAGpnAKHYX9tYu41DmnTpza2t9d9x/MJFWu7e5Ho=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vm80jY7gRNMn5YVUVoQ2usRDhcChvAyndbGtq8yyBiIrViWkS6NG+E2JwUB74VEwgnM8bf5GelEnzJxCh70mGQHcDryB3MhN+hKINX0+MMc48qMiPb3twgLwqKWQHT3AHxqcXik++RlBx6v1A5amkbIMXKAs95MmfWnktwYLHK4= X-YMail-OSG: d3Ei03kVM1mcqwr5gqz_hbHPa8mL.uDj0vQdwHV4GhoOx7i HgRa6yTpEwHwvZts9TN12AvcJ.Lhd8T0Hwx5ZKmrj0Qv6bmBZCwTrKzvbAHI vedYonT6hMc1PLfWD4DyWemyp4mJUr_8zXHNZoD9vPwlYERmFXDI0bwCzRwD vuySk5_hYHIPuqvJpmJagM3lWRcdA4TUxrGG5hmBexCd.FeTOd6PDyBO6IcP Ub0g1gL43NokAUThon3Lw44tSgHz8zAwFblZTDAuoBLw50sdboP0xtv5Ul4n euokBvKoNUhDHFT7ccZmESLaAQJqJUSbJ.sq4pYF_onfTOwGMWFV1ScgakrK 8X9F8IHqk8VNA3HY0kh_6gLsqa6nXdyV_JgFnJl6tsEE1JNQWTZd.cDGzlQz OKpuGR.6W6DiX6iUcbfmMtQjgWNUG2_SZqQMX8gsajOvO6turQI4pfXoJfua 7vJXlSc5PGxy.XHzMHSIA8WVhBXYgcDWcmVDgdI3GGrymt6W55IQUIaa7lV5 ehow6ZEpoJNbK5FlZRyDrd8ECKbOPte0smfeRSzw5TjEuCam8fTKQ4DgqNkV 1gSV0vQxTBVnXK3yCthz8yGPAtJcbbrqlFXmPe.t.tokiTXZelh7XsB1xok6 eJyQTm8G5OA2pHQQ5JCB0Zt1xhQ_XBel8LUoikaLO957neqGslkJZ44EPvIx iHJcCbjowSiMyPKgCDnVVh5a83nuI_YqiQw-- Received: from [24.130.244.175] by web125102.mail.ne1.yahoo.com via HTTP; Fri, 19 Sep 2014 12:24:31 PDT X-Rocket-MIMEInfo: 002.001, IAo.QSBkaXJlY3RlZCBicm9hZGNhc3QgcGluZyBvbiBJUHY0IGdpdmVzIHByZXR0eSBtdWNoIHRoZSBzYW1lIHJlc3VsdC4KPkRpZCB5b3UgdGVzdCB0aGUgZWZmZWN0cyBvZiB0aGF0ID8KCkkgaGFkIG5vdC4gIEJ1dCwgc2luY2UgeW91IG1lbnRpb25lZCBpdCwgSSBkaWQgaXQgb24gdHdvIGRpZmZlcmVudCBXaW5kb3dzIG1hY2hpbmVzLiAgVGhlIG9uZSB0aGF0IGlzIHRoZSBzZXJ2ZXIgaW4gcXVlc3Rpb24gaGFkIHRoZSBmb2xsb3dpbmcgcmVzdWx0czoKCkM6XFVzZXJzXEFkbWluaXN0cmF0b3I.cGluZyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> Message-ID: <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Fri, 19 Sep 2014 12:24:31 -0700 From: Nalini Elkins To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= , "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-559651860-586533891-1411154671=:21942" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eWEBuKCspQ9GTmKINxqIKG4slc0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 19:24:35 -0000 ---559651860-586533891-1411154671=:21942 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A>A directed broadcast ping on IPv4 gives pretty much the same result.= =0A>Did you test the effects of that ?=0A=0AI had not. But, since you ment= ioned it, I did it on two different Windows machines. The one that is the = server in question had the following results:=0A=0AC:\Users\Administrator>p= ing x.x.x.255=0A=0APinging x.x.x.255 with 32 bytes of data:=0ARequest timed= out.=0ARequest timed out.=0ARequest timed out.=0ARequest timed out.=0A=0AP= ing statistics for x.x.x.255:=0A Packets: Sent =3D 4, Received =3D 0, Lo= st =3D 4 (100% loss),=0A=0AArp cache was not updated. I did a packet trac= e in the background and indeed no ICMP replies were seen. =0A=0AI did the= same ping x.x.x.255 on one of my client PCs and saw:=0A=0APinging x.x.x.25= 5 with 32 bytes of data:=0ARequest timed out.=0ARequest timed out.=0AReques= t timed out.=0ARequest timed out.=0A=0ABut this time the packet trace showe= d that actually ICMP replies were sent.=0A=0A>Of course, private VLANs or (= if we are talking VMs) or just using p2p=0A>links with /128s would help thi= s in the environments where the hosts=0A>can not be trusted - and this of c= ourse is not virtual/physical=0A>specific.=0A=0AYes. We wanted to bring up= the topic of isolation of nodes for discussion.=0A=0A>If we're talking spe= cifically virtual environment, here's an approach=0A>on how to use ebtables= to isolate the hosts:=0A=0A>ebtables -P FORWARD DROP=0A>ebtables -F FORWAR= D=0A>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow=0A= >from uplink to any ports=0A>ebtables -A FORWARD -o $uplinkPort -j ACCEPT #= let the traffic flow=0A>from any ports to uplink=0A=0A>(source:http://serv= erfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-lin= ux-bridges)=0A=0AI think this is very good. But, unfortunately not very we= ll known. Also, is this possible for all platforms or just Linux?=0A=0A>S= o looks like the question at hand is:=0A=0A>"Should IPv6 nodes respond to P= ing to FF0x::1?"=0A=0A>Which can be rephrased differently to ease the start= of the discussion:=0A=0A>"What are the legitimate uses of a ping to ff0x::= 1 ?"=0A=0A>Right ?=0A=0AYes.=0A=0A--a=0A=0A=0AOn 9/19/14, fred@cisco.com wrote:=0A> A new draft has been posted, at=0A> http://tools.= ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes.=0A> Please take a= look at it and comment.=0A>=0A> __________________________________________= _____=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/ma= ilman/listinfo/v6ops=0A> ---559651860-586533891-1411154671=:21942 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
 
>A directed broadcast ping on IPv4 gives pretty much the same re= sult.
>Did you test the effects = of that ?

I = had not.  But, since you mentioned it, I did it on two different Windo= ws machines.  The one that is the server in question had the following= results:

C:\Users\Administrator>ping x.x.x.255
<= div class=3D"" style=3D"">
Pinging x.x.x.255 with 32 bytes of data:
<= div class=3D"" style=3D"">Request ti= med out.
Request timed out.
Request timed out.
Request timed out.<= /font>

Ping statistics for x.x.x.255:
    Packets: Sent = =3D 4, Received =3D 0, Lost =3D 4 (100% loss),

Arp cache was not updated.   I did a packet trace in the backgro= und and indeed no ICMP replies were seen.   

I did the same ping x.x.x.255 on one of my client PCs and saw:

Pinging x.x.x.255 with 32 bytes of data:
Request = timed out.
Request timed out.
=
Request timed out.
= Request timed out.

But this time the packet trace showed that ac= tually ICMP replies were sent.

>Of course, private VLAN= s or (if we are talking VMs) or just using p2p
>links with /128s would help this in the environments where = the hosts
>can not be trusted - = and this of course is not virtual/physical
>specific.

Yes.  We wanted to bring up the topic of is= olation of nodes for discussion.

>If we're talking specifically virtual environment, here'= s an approach
>on how to use ebt= ables to isolate the hosts:

>ebtables -P FORWARD DROP
>ebtables -F FORWARD
>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the= traffic flow
>from uplink to an= y ports
>ebtables -A FORWARD -o = $uplinkPort -j ACCEPT # let the traffic flow
>from any ports to uplink

>(source: http://s= erverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-= linux-bridges)

I think this is very good.  But, = unfortunately not very well known.   Also, is this possible for all pl= atforms or just Linux?

>So looks like the question at hand is= :

>"Should IPv6 nodes respond to Ping to FF0x::1?"

>Which= can be rephrased differently to ease the start of the discussion:

>"What are the legitimate uses of a = ping to ff0x::1 ?"

>Right ?

Yes.

--a

On 9/19/14, fred@cisco.com <fred@cisco.com> wrote:
>= A new draft has been posted, at
> htt= p://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes.
> Please take a look at it and comment.=
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


---559651860-586533891-1411154671=:21942-- From nobody Fri Sep 19 13:27:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612181A04E7 for ; Fri, 19 Sep 2014 13:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybwxz0dbsssq for ; Fri, 19 Sep 2014 13:27:14 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A651A0476 for ; Fri, 19 Sep 2014 13:27:14 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id l13so190066iga.12 for ; Fri, 19 Sep 2014 13:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mqygEQMxzBshxgZ/a8ce300zHPn+GCL2z1keGO597rs=; b=urXIH2EfIMu+mSTZmtUU8aAvcgkCD/vZaDyMVJb/t9JidYsPN2topN1HYPxkXfqCiG RrY2F0QmXnKOzgoiEDbc5hVuAoF6h8ZWdmU9Eu+fYRukYX+35iQH+V3iL6K34YBO/+Fq C9EXQ1jlwPGcTv1MiPl49RzLxQq0udPwcFdi1tyRrKTyZRXYbsVrBndRTrXNytNd4Rio HWZBCGUxKAtpfL+FpF3Sj+Bb7XOaLOKWxcu4oVPJIDe/EBoPviRWls3UwHImn2bl5ivB qW0dP2fmxxHqQDl8IyGXIUYrPlrGQU2iH7Cku2z9k5scVVUAIaxGuf5sjKEp7EFE4Tgf Ue/A== MIME-Version: 1.0 X-Received: by 10.43.61.4 with SMTP id wu4mr1755565icb.77.1411158434065; Fri, 19 Sep 2014 13:27:14 -0700 (PDT) Received: by 10.107.137.65 with HTTP; Fri, 19 Sep 2014 13:27:14 -0700 (PDT) In-Reply-To: <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Fri, 19 Sep 2014 22:27:14 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Nalini Elkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/l3RaFesPWyJwvyz9ViunlQstAuc Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 20:27:16 -0000 On 9/19/14, Nalini Elkins wrote: > >>A directed broadcast ping on IPv4 gives pretty much the same result. >>Did you test the effects of that ? > > I had not. But, since you mentioned it, I did it on two different Windows > machines. The one that is the server in question had the following results: > > C:\Users\Administrator>ping x.x.x.255 > > Pinging x.x.x.255 with 32 bytes of data: > Request timed out. > Request timed out. > Request timed out. > Request timed out. > > Ping statistics for x.x.x.255: > Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), > > Arp cache was not updated. I did a packet trace in the background and > indeed no ICMP replies were seen. > > I did the same ping x.x.x.255 on one of my client PCs and saw: > > Pinging x.x.x.255 with 32 bytes of data: > Request timed out. > Request timed out. > Request timed out. > Request timed out. > > But this time the packet trace showed that actually ICMP replies were sent. > So, besides this cosmetic difference the behavior is identical for the case of IPv4 ping ? >>Of course, private VLANs or (if we are talking VMs) or just using p2p >>links with /128s would help this in the environments where the hosts >>can not be trusted - and this of course is not virtual/physical >>specific. > > Yes. We wanted to bring up the topic of isolation of nodes for discussion. This is a useful topic in general - especially in light of the MLD-related thread, but the draft seems to focus on a very corner case - there are many much better reasons not to do large L2 networks. > >>If we're talking specifically virtual environment, here's an approach >>on how to use ebtables to isolate the hosts: > >>ebtables -P FORWARD DROP >>ebtables -F FORWARD >>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow >>from uplink to any ports >>ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic flow >>from any ports to uplink > >>(source:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-linux-bridges) > > I think this is very good. But, unfortunately not very well known. Also, > is this possible for all platforms or just Linux? This was just my first google.com search result when searching for "private vlans linux". The first google.com search result on "private vlans windows" brings up http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx which seems to document similar technique. "private vlan vmware" results in http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691 as its first hit. Would an IETF publication be easier to find than the above ? > >>So looks like the question at hand is: > >>"Should IPv6 nodes respond to Ping to FF0x::1?" > >>Which can be rephrased differently to ease the start of the discussion: > >>"What are the legitimate uses of a ping to ff0x::1 ?" > >>Right ? > > Yes. Allright, so I'll mention my use of ping6 ff0x::1: * quick check to find "a few hosts that are alive on this link" (obviously not to be done on large segments). * A way to trigger the remote side's ND process without having to do one myself (I know the multicast packet to all-hosts *will* usually get received regardless of the underlying issues with the L2.5 infrastructure (snooping, etc.) * A way to further debug malfunctioning L2.5 infra, by comparing the reaction to pings to ff02::1, solicited node multicast, other multicast groups, etc. Summary: the ff02::1 current ping behavior does help in a non-trivial amount of cases. The security aspects the draft mentions indeed do exist, but in a properly configured network can be easily mitigated as I've shown above. So I'd be against changing the functionality in the existing stacks. On the education side: the existing search results https://www.google.com/?gws_rd=ssl#q=ping6+ff02::1 show 8000-something results - so indeed probably this behavior may be highlighted more during the IPv6 education. However: every IPv6 course I've heard says "there is no broadcast in IPv6, but there is all-hosts multicast" which should not make the behavior the draft describes a major surprise. --a > > --a > > > On 9/19/14, fred@cisco.com wrote: >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. >> Please take a look at it and comment. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From nobody Fri Sep 19 13:56:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9704C1A8035 for ; Fri, 19 Sep 2014 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_FSL_HELO_BARE_IP_2=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj8K7EkLQD79 for ; Fri, 19 Sep 2014 13:56:10 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C8D1A88AD for ; Fri, 19 Sep 2014 13:56:09 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 021CB1020DF for ; Fri, 19 Sep 2014 15:56:09 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 557C51291FA; Fri, 19 Sep 2014 15:56:08 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 73F834F8053; Fri, 19 Sep 2014 16:53:46 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva1.bcbsm.com (Postfix) with ESMTP id 7180E4F804F; Fri, 19 Sep 2014 16:53:46 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([::1]) with mapi id 14.01.0438.000; Fri, 19 Sep 2014 16:55:38 -0400 From: "Ackermann, Michael" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= , Nalini Elkins Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes Thread-Index: AQHP0/9nr2GOGmtz+E6bwFtua+J9j5wI9ViAgAAkY4CAABGGAP//wkeQ Date: Fri, 19 Sep 2014 20:55:37 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CCCABFB@PWN401EA160.ent.corp.bcbsm.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 6861e22b-9032-4df9-8c92-648f0939b921 X-VPM-MSG-ID: 3e98d435-73f1-4f4e-9780-845fc250b7df X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wT62BZioDvER7_vtKBjnu45zKPc Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 20:56:13 -0000 SEkgQW5kcmV3DQoNClRoYW5rcyBmb3IgdGhlIGdyZWF0IHJlc3BvbnNlcyBhbmQgcmVsYXRl ZCBpbmZvcm1hdGlvbi4gICANCg0KTXkgY29tbWVudCBvbiB0aGUgaW5jbHVzaW9uIG9mIE1M RCwgIGlzIHRoYXQgd2UgdGFsa2VkIGEgbG90IGFib3V0IE1MRCBkdXJpbmcgdGhlIGNyZWF0 aW9uIG9mIHRoaXMgZHJhZnQgYW5kIGl0IGNlcnRhaW5seSBpcyBjb25zaXN0ZW50IHdpdGgg dGhlIHRoZW1lIGFuZCBhZGRzIHRvIHRoZSBpc3N1ZXMuICAgSG93ZXZlciwgd2UgY2hvc2Ug dG8gbGVhdmUgTUxEIG91dCBvZiB0aGlzIGRyYWZ0LCBpbiBhbiBlZmZvcnQgdG8ga2VlcCB0 aGUgZHJhZnQgc21hbGxlciBhbmQgbW9yZSBmb2N1c2VkLiAgIFdlIGRvIG1lbnRpb24gTUxE IGFzIGJlaW5nIGEgcmVsYXRlZCBmYWN0b3IgYnV0IHN0YXRlIGl0IGlzIG91dHNpZGUgb2Yg dGhlIHNjb3BlIG9mIHRoZSBkcmFmdC4gICAgIEdpdmVuIHRoYXQsIGEgcXVlc3Rpb24gZm9y IHlvdSBpcyBpZiB5b3UgZmVlbCB0aGlzIGRyYWZ0IFNIT1VMRCBpbmNsdWRlIE1MRD8gICAg DQoNCk9uZSBvdGhlciBjb21tZW50IGlzIHRoYXQgYWx0aG91Z2ggdGhlcmUgaXMgZWR1Y2F0 aW9uIGFuZCBpbmZvcm1hdGlvbiBhYm91dCB0aGVzZSB0eXBlcyBvZiBJUHY2IHN1YmplY3Rz L2lzc3VlcywgbW9zdCBsYXJnZSBlbnRlcnByaXNlcyBhcmUgdW5hd2FyZSBvZiBhbnkgb2Yg dGhpcy4gICBPdXIgaG9wZSB3YXMgdG8gc3BhcmUgdGhlbSBmcm9tIGhhdmluZyBhbiB1bnBs ZWFzYW50IGluaXRpYWwgZXhwZXJpZW5jZSB3aXRoIElQdjYsIGJ5IHBvaW50aW5nIG91dCBz b21lIGlzc3VlcyAgYW5kIHBpdGZhbGxzIHdlIGhhdmUgcnVuIGludG8uICAgVGhlcmUgaXMg ZW5vdWdoIHJlbHVjdGFuY2UgdG8gcHVyc3VlIElQdjYsIGluIHRoZSBjb3Jwb3JhdGUgYW5k IGxhcmdlIGVudGVycHJpc2UgZW52aXJvbm1lbnRzIHRvZGF5IGFuZCB3ZSB3YW50IHRvIGVs aW1pbmF0ZSBhcyBtYW55IG5lZ2F0aXZlcyBmcm9tIHRoYXQgZGVjaXNpb24gcHJvY2VzcyBh cyBwb3NzaWJsZS4gIA0KDQpIb3BlIHRoYXQgbWFrZXMgc2Vuc2UuIA0KDQpUaGFua3MgYWdh aW4NCg0KTWlrZQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJl dyA/PyBZb3VydGNoZW5rbw0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTksIDIwMTQgNDoy NyBQTQ0KVG86IE5hbGluaSBFbGtpbnMNCkNjOiBkcmFmdC1lbGtpbnMtdjZvcHMtbXVsdGlj YXN0LXZpcnR1YWwtbm9kZXNAdG9vbHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWVsa2lucy12Nm9wcy1tdWx0aWNh c3QtdmlydHVhbC1ub2Rlcw0KDQpPbiA5LzE5LzE0LCBOYWxpbmkgRWxraW5zIDxuYWxpbmku ZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4gd3JvdGU6DQo+DQo+PkEgZGlyZWN0ZWQgYnJv YWRjYXN0IHBpbmcgb24gSVB2NCBnaXZlcyBwcmV0dHkgbXVjaCB0aGUgc2FtZSByZXN1bHQu DQo+PkRpZCB5b3UgdGVzdCB0aGUgZWZmZWN0cyBvZiB0aGF0ID8NCj4NCj4gSSBoYWQgbm90 LiAgQnV0LCBzaW5jZSB5b3UgbWVudGlvbmVkIGl0LCBJIGRpZCBpdCBvbiB0d28gZGlmZmVy ZW50IA0KPiBXaW5kb3dzIG1hY2hpbmVzLiAgVGhlIG9uZSB0aGF0IGlzIHRoZSBzZXJ2ZXIg aW4gcXVlc3Rpb24gaGFkIHRoZSBmb2xsb3dpbmcgcmVzdWx0czoNCj4NCj4gQzpcVXNlcnNc QWRtaW5pc3RyYXRvcj5waW5nIHgueC54LjI1NQ0KPg0KPiBQaW5naW5nIHgueC54LjI1NSB3 aXRoIDMyIGJ5dGVzIG9mIGRhdGE6DQo+IFJlcXVlc3QgdGltZWQgb3V0Lg0KPiBSZXF1ZXN0 IHRpbWVkIG91dC4NCj4gUmVxdWVzdCB0aW1lZCBvdXQuDQo+IFJlcXVlc3QgdGltZWQgb3V0 Lg0KPg0KPiBQaW5nIHN0YXRpc3RpY3MgZm9yIHgueC54LjI1NToNCj4gICAgIFBhY2tldHM6 IFNlbnQgPSA0LCBSZWNlaXZlZCA9IDAsIExvc3QgPSA0ICgxMDAlIGxvc3MpLA0KPg0KPiBB cnAgY2FjaGUgd2FzIG5vdCB1cGRhdGVkLiAgIEkgZGlkIGEgcGFja2V0IHRyYWNlIGluIHRo ZSBiYWNrZ3JvdW5kIGFuZA0KPiBpbmRlZWQgbm8gSUNNUCByZXBsaWVzIHdlcmUgc2Vlbi4N Cj4NCj4gSSBkaWQgdGhlIHNhbWUgcGluZyB4LngueC4yNTUgb24gb25lIG9mIG15IGNsaWVu dCBQQ3MgYW5kIHNhdzoNCj4NCj4gUGluZ2luZyB4LngueC4yNTUgd2l0aCAzMiBieXRlcyBv ZiBkYXRhOg0KPiBSZXF1ZXN0IHRpbWVkIG91dC4NCj4gUmVxdWVzdCB0aW1lZCBvdXQuDQo+ IFJlcXVlc3QgdGltZWQgb3V0Lg0KPiBSZXF1ZXN0IHRpbWVkIG91dC4NCj4NCj4gQnV0IHRo aXMgdGltZSB0aGUgcGFja2V0IHRyYWNlIHNob3dlZCB0aGF0IGFjdHVhbGx5IElDTVAgcmVw bGllcyB3ZXJlIHNlbnQuDQo+DQoNClNvLCBiZXNpZGVzIHRoaXMgY29zbWV0aWMgZGlmZmVy ZW5jZSB0aGUgYmVoYXZpb3IgaXMgaWRlbnRpY2FsIGZvciB0aGUgY2FzZSBvZiBJUHY0IHBp bmcgPw0KDQo+Pk9mIGNvdXJzZSwgcHJpdmF0ZSBWTEFOcyBvciAoaWYgd2UgYXJlIHRhbGtp bmcgVk1zKSBvciBqdXN0IHVzaW5nIHAycCANCj4+bGlua3Mgd2l0aCAvMTI4cyB3b3VsZCBo ZWxwIHRoaXMgaW4gdGhlIGVudmlyb25tZW50cyB3aGVyZSB0aGUgaG9zdHMgDQo+PmNhbiBu b3QgYmUgdHJ1c3RlZCAtIGFuZCB0aGlzIG9mIGNvdXJzZSBpcyBub3QgdmlydHVhbC9waHlz aWNhbCANCj4+c3BlY2lmaWMuDQo+DQo+IFllcy4gIFdlIHdhbnRlZCB0byBicmluZyB1cCB0 aGUgdG9waWMgb2YgaXNvbGF0aW9uIG9mIG5vZGVzIGZvciBkaXNjdXNzaW9uLg0KDQpUaGlz IGlzIGEgdXNlZnVsIHRvcGljIGluIGdlbmVyYWwgLSBlc3BlY2lhbGx5IGluIGxpZ2h0IG9m IHRoZSBNTEQtcmVsYXRlZCB0aHJlYWQsIGJ1dCB0aGUgZHJhZnQgc2VlbXMgdG8gZm9jdXMg b24gYSB2ZXJ5IGNvcm5lciBjYXNlDQotIHRoZXJlIGFyZSBtYW55IG11Y2ggYmV0dGVyIHJl YXNvbnMgbm90IHRvIGRvIGxhcmdlIEwyIG5ldHdvcmtzLg0KDQo+DQo+PklmIHdlJ3JlIHRh bGtpbmcgc3BlY2lmaWNhbGx5IHZpcnR1YWwgZW52aXJvbm1lbnQsIGhlcmUncyBhbiBhcHBy b2FjaCANCj4+b24gaG93IHRvIHVzZSBlYnRhYmxlcyB0byBpc29sYXRlIHRoZSBob3N0czoN Cj4NCj4+ZWJ0YWJsZXMgLVAgRk9SV0FSRCBEUk9QDQo+PmVidGFibGVzIC1GIEZPUldBUkQN Cj4+ZWJ0YWJsZXMgLUEgRk9SV0FSRCAtaSAkdXBsaW5rUG9ydCAtaiBBQ0NFUFQgIyBsZXQg dGhlIHRyYWZmaWMgZmxvdyANCj4+ZnJvbSB1cGxpbmsgdG8gYW55IHBvcnRzIGVidGFibGVz IC1BIEZPUldBUkQgLW8gJHVwbGlua1BvcnQgLWogQUNDRVBUIA0KPj4jIGxldCB0aGUgdHJh ZmZpYyBmbG93IGZyb20gYW55IHBvcnRzIHRvIHVwbGluaw0KPg0KPj4oc291cmNlOmh0dHA6 Ly9zZXJ2ZXJmYXVsdC5jb20vcXVlc3Rpb25zLzM4ODU0NC9pcy1pdC1wb3NzaWJsZS10by1l bmFiDQo+PmxlLXBvcnQtaXNvbGF0aW9uLW9uLWxpbnV4LWJyaWRnZXMpDQo+DQo+IEkgdGhp bmsgdGhpcyBpcyB2ZXJ5IGdvb2QuICBCdXQsIHVuZm9ydHVuYXRlbHkgbm90IHZlcnkgd2Vs bCBrbm93bi4gICBBbHNvLA0KPiBpcyB0aGlzIHBvc3NpYmxlIGZvciBhbGwgcGxhdGZvcm1z IG9yIGp1c3QgTGludXg/DQoNClRoaXMgd2FzIGp1c3QgbXkgZmlyc3QgZ29vZ2xlLmNvbSBz ZWFyY2ggcmVzdWx0IHdoZW4gc2VhcmNoaW5nIGZvciAicHJpdmF0ZSB2bGFucyBsaW51eCIu DQoNClRoZSBmaXJzdCBnb29nbGUuY29tIHNlYXJjaCByZXN1bHQgb24gInByaXZhdGUgdmxh bnMgd2luZG93cyIgYnJpbmdzIHVwIGh0dHA6Ly9ibG9ncy50ZWNobmV0LmNvbS9iL3Njdm1t L2FyY2hpdmUvMjAxMy8wNi8wNC9sb2dpY2FsLW5ldHdvcmtzLXBhcnQtaXYtcHZsYW4taXNv bGF0aW9uLmFzcHgNCndoaWNoIHNlZW1zIHRvIGRvY3VtZW50IHNpbWlsYXIgdGVjaG5pcXVl Lg0KDQoicHJpdmF0ZSB2bGFuIHZtd2FyZSIgcmVzdWx0cyBpbg0KaHR0cDovL2tiLnZtd2Fy ZS5jb20vc2VsZnNlcnZpY2UvbWljcm9zaXRlcy9zZWFyY2guZG8/bGFuZ3VhZ2U9ZW5fVVMm Y21kPWRpc3BsYXlLQyZleHRlcm5hbElkPTEwMTA2OTENCmFzIGl0cyBmaXJzdCBoaXQuDQoN CldvdWxkIGFuIElFVEYgcHVibGljYXRpb24gYmUgZWFzaWVyIHRvIGZpbmQgdGhhbiB0aGUg YWJvdmUgPw0KDQo+DQo+PlNvIGxvb2tzIGxpa2UgdGhlIHF1ZXN0aW9uIGF0IGhhbmQgaXM6 DQo+DQo+PiJTaG91bGQgSVB2NiBub2RlcyByZXNwb25kIHRvIFBpbmcgdG8gRkYweDo6MT8i DQo+DQo+PldoaWNoIGNhbiBiZSByZXBocmFzZWQgZGlmZmVyZW50bHkgdG8gZWFzZSB0aGUg c3RhcnQgb2YgdGhlIGRpc2N1c3Npb246DQo+DQo+PiJXaGF0IGFyZSB0aGUgbGVnaXRpbWF0 ZSB1c2VzIG9mIGEgcGluZyB0byBmZjB4OjoxID8iDQo+DQo+PlJpZ2h0ID8NCj4NCj4gWWVz Lg0KDQpBbGxyaWdodCwgc28gSSdsbCBtZW50aW9uIG15IHVzZSBvZiBwaW5nNiBmZjB4Ojox Og0KDQoqIHF1aWNrIGNoZWNrIHRvIGZpbmQgImEgZmV3IGhvc3RzIHRoYXQgYXJlIGFsaXZl IG9uIHRoaXMgbGluayINCihvYnZpb3VzbHkgbm90IHRvIGJlIGRvbmUgb24gbGFyZ2Ugc2Vn bWVudHMpLg0KDQoqIEEgd2F5IHRvIHRyaWdnZXIgdGhlIHJlbW90ZSBzaWRlJ3MgTkQgcHJv Y2VzcyB3aXRob3V0IGhhdmluZyB0byBkbyBvbmUgbXlzZWxmIChJIGtub3cgdGhlIG11bHRp Y2FzdCBwYWNrZXQgdG8gYWxsLWhvc3RzICp3aWxsKiB1c3VhbGx5IGdldCByZWNlaXZlZCBy ZWdhcmRsZXNzIG9mIHRoZSB1bmRlcmx5aW5nIGlzc3VlcyB3aXRoIHRoZSBMMi41IGluZnJh c3RydWN0dXJlIChzbm9vcGluZywgZXRjLikNCg0KKiBBIHdheSB0byBmdXJ0aGVyIGRlYnVn IG1hbGZ1bmN0aW9uaW5nIEwyLjUgaW5mcmEsIGJ5IGNvbXBhcmluZyB0aGUgcmVhY3Rpb24g dG8gcGluZ3MgdG8gZmYwMjo6MSwgc29saWNpdGVkIG5vZGUgbXVsdGljYXN0LCBvdGhlciBt dWx0aWNhc3QgZ3JvdXBzLCBldGMuDQoNClN1bW1hcnk6IHRoZSBmZjAyOjoxIGN1cnJlbnQg cGluZyBiZWhhdmlvciBkb2VzIGhlbHAgaW4gYSBub24tdHJpdmlhbCBhbW91bnQgb2YgY2Fz ZXMuDQoNClRoZSBzZWN1cml0eSBhc3BlY3RzIHRoZSBkcmFmdCBtZW50aW9ucyBpbmRlZWQg ZG8gZXhpc3QsIGJ1dCBpbiBhIHByb3Blcmx5IGNvbmZpZ3VyZWQgbmV0d29yayBjYW4gYmUg ZWFzaWx5IG1pdGlnYXRlZCBhcyBJJ3ZlIHNob3duIGFib3ZlLiBTbyBJJ2QgYmUgYWdhaW5z dCBjaGFuZ2luZyB0aGUgZnVuY3Rpb25hbGl0eSBpbiB0aGUgZXhpc3Rpbmcgc3RhY2tzLg0K DQpPbiB0aGUgZWR1Y2F0aW9uIHNpZGU6IHRoZSBleGlzdGluZyBzZWFyY2ggcmVzdWx0cw0K aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8/Z3dzX3JkPXNzbCNxPXBpbmc2K2ZmMDI6OjEgc2hv dyA4MDAwLXNvbWV0aGluZyByZXN1bHRzIC0gc28gaW5kZWVkIHByb2JhYmx5IHRoaXMgYmVo YXZpb3IgbWF5IGJlIGhpZ2hsaWdodGVkIG1vcmUgZHVyaW5nIHRoZSBJUHY2IGVkdWNhdGlv bi4gSG93ZXZlcjogZXZlcnkgSVB2NiBjb3Vyc2UgSSd2ZSBoZWFyZCBzYXlzICJ0aGVyZSBp cyBubyBicm9hZGNhc3QgaW4gSVB2NiwgYnV0IHRoZXJlIGlzIGFsbC1ob3N0cyBtdWx0aWNh c3QiIHdoaWNoIHNob3VsZCBub3QgbWFrZSB0aGUgYmVoYXZpb3IgdGhlIGRyYWZ0IGRlc2Ny aWJlcyBhIG1ham9yIHN1cnByaXNlLg0KDQotLWENCg0KPg0KPiAtLWENCj4NCj4NCj4gT24g OS8xOS8xNCwgZnJlZEBjaXNjby5jb20gPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCj4+IEEg bmV3IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZCwgYXQNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWVsa2lucy12Nm9wcy1tdWx0aWNhc3QtdmlydHVhbC1ub2Rlcy4NCj4+ IFBsZWFzZSB0YWtlIGEgbG9vayBhdCBpdCBhbmQgY29tbWVudC4NCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gdjZvcHMgbWFp bGluZyBsaXN0DQo+PiB2Nm9wc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCgoK VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGln aGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVj dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhl cmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9y IGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVwaG9uZSwg b2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNz YWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGll bGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBu b25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhl IEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo= From nobody Fri Sep 19 15:02:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2791A88BF for ; Fri, 19 Sep 2014 15:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 fQpSyaMAC6QZ for ; Fri, 19 Sep 2014 15:02:01 -0700 (PDT) Received: from nm3-vm2.bullet.mail.ne1.yahoo.com (nm3-vm2.bullet.mail.ne1.yahoo.com [98.138.91.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9E31A875F for ; Fri, 19 Sep 2014 15:01:59 -0700 (PDT) Received: from [98.138.101.130] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 22:01:59 -0000 Received: from [98.138.89.168] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 22:01:59 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 22:01:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 134263.29258.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 58011 invoked by uid 60001); 19 Sep 2014 22:01:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411164119; bh=//ZDCcCOMJgfYVJRKpVEFTzDesppx88ptedS4OX6D8M=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QXTB05G7W1AF69TXqZIIkfaqTvBUoWxGypIcBI/K4HAoHcj7N6J0uUIKHomMqVnLj9IsIlCPwailAYQu5uQVFALwm//Hz14mmGUMY6mUvyKA0JRLfYEJXbT0pxCebX3nKHDgo+0/a/tZAO7rKaQcvngLPdepyMCY3mXytwWaxDM= X-YMail-OSG: TfTCzoUVM1kZO9eEn8s311uT.j7PJdfM7xMCW1d1saFTrI1 SWtHZODHFKL.8rEMULCj4I5sg8865OzVPAu.v9.OX5vX4hs0ySZ1ukEsPH0R ETOWTLOu8JdOFEYMF.yTarSGaRHiYjAwQ9NLii6YsyQr3J8eU_9Ew9kOdSjW FhgqW9hZivhbpWOdqKjZW.WIDyCgl3fc31gMe.CoepKgL4n9NypUtBI_Cv_8 Kllae5xrHREI6tBVQ_2j6DBO.BhaQYOd7.qduz72EAFPSVCBj_XEMLJmwp_z wF_3V4U0QPivuDWAsF3463D7DlEQnA.LhnP1sqbp8eF2NUGSgzl2SKN1xaOJ eKpkYOK4xu78LUjANLBw.i0rJiULL21ytOz9GKjjrHoerZQDBl1CFvF6pS0N lhuRUrWItS757PX31.TO3iN6FbzdvcekiMa.P6i_LBAbdO3zxFZ2a8EdnTGK Y.8LNUan93F6G3Ynl7aNdtKqRiVxpssAYVimynE0a0QDnJhL4_NixnoT24RH fgdmVtKr2JqL65WY7iDa4KQIDu1bwfOb8UWw1CPbOQVLa6g4PjgFl7HQKO59 YZKMI5nmUhOuX8mi9nAIvdxE9pHSa1jwnRqDxRyeqrhdXwzOuSIfOrPcvkes za.KDOwVg8OFuYNQ51kdwTupT578b4pluAX8s9ss61g70WdnaV2tnz1xACwh I65HhLf54o5ppmfjD_bCy3HAERrClW.ncJrtH_En0N3VScLqHtRNueUg7CBJ iq6unY7tVugoid2OYyNx9fewO4soNhFaOrQ5Wby2AcRglEP_lXKHsoCRd_sY 6qB.3Q9jiBKjRgTfTdAy6IdluPgb.6ckGddneizzxfzLu.64UIP3QWbFvN_H yh_jNQXdMMgELJ8EJjuARzFUZI2210kEtsRsq4dGjnVEO1lJu1elnL3QHSqT 7gwaeUXQTzt4M.ffwAQfWZWCMWtg4eLcYEjm6zLTgLTwD_nkcf4LtVFWNRF2 28ioQa1EwBV.6mlaX7m.kuqQDDuRP4s4CsAoRs01yuaRlXd5HUDad3.gaJ8B j9cnIfldkPvjlvz5o8LFUepTmBfR3vC0MMcEix9x8OLEvPNs73oqf2JtqUo4 MEYHAAFAZMm.1xFUGLIYfGaj7BNg8p7.fay9jNy4hrMaBrqcz710rAoNiw8e VI.tZ3kelUMf4LMuVy8zreHPCN_oLnVSYtDS08Vr262kOjgGfnHUo5twNdRE qaeivuPaA_keSgw-- Received: from [24.130.244.175] by web125106.mail.ne1.yahoo.com via HTTP; Fri, 19 Sep 2014 15:01:58 PDT X-Rocket-MIMEInfo: 002.001, CgpPbiA5LzE5LzE0LCBOYWxpbmkgRWxraW5zIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4gd3JvdGU6Cj4KPj5BIGRpcmVjdGVkIGJyb2FkY2FzdCBwaW5nIG9uIElQdjQgZ2l2ZXMgcHJldHR5IG11Y2ggdGhlIHNhbWUgcmVzdWx0Lgo.PkRpZCB5b3UgdGVzdCB0aGUgZWZmZWN0cyBvZiB0aGF0ID8KPgo.IEkgaGFkIG5vdC4gIEJ1dCwgc2luY2UgeW91IG1lbnRpb25lZCBpdCwgSSBkaWQgaXQgb24gdHdvIGRpZmZlcmVudCBXaW5kb3dzCj4gbWFjaGluZXMuICBUaGUgb25lIHRoYXQgaXMgdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> Message-ID: <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Fri, 19 Sep 2014 15:01:58 -0700 From: Nalini Elkins To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sdx59rnB3SG3YoDKkR2_h29DRhE Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 22:02:03 -0000 =0A=0AOn 9/19/14, Nalini Elkins wrote:= =0A>=0A>>A directed broadcast ping on IPv4 gives pretty much the same resul= t.=0A>>Did you test the effects of that ?=0A>=0A> I had not. But, since yo= u mentioned it, I did it on two different Windows=0A> machines. The one th= at is the server in question had the following results:=0A>=0A> C:\Users\Ad= ministrator>ping x.x.x.255=0A>=0A> Pinging x.x.x.255 with 32 bytes of data:= =0A> Request timed out.=0A> Request timed out.=0A> Request timed out.=0A> R= equest timed out.=0A>=0A> Ping statistics for x.x.x.255:=0A> Packets: S= ent =3D 4, Received =3D 0, Lost =3D 4 (100% loss),=0A>=0A> Arp cache was no= t updated. I did a packet trace in the background and=0A> indeed no ICMP = replies were seen.=0A>=0A> I did the same ping x.x.x.255 on one of my clien= t PCs and saw:=0A>=0A> Pinging x.x.x.255 with 32 bytes of data:=0A> Request= timed out.=0A> Request timed out.=0A> Request timed out.=0A> Request timed= out.=0A>=0A> But this time the packet trace showed that actually ICMP repl= ies were sent.=0A>=0A=0A>So, besides this cosmetic difference the behavior = is identical for the=0A>case of IPv4 ping ?=0A=0AAndrew, I think you may ha= ve misunderstand me. The behavior is very definitely not=0Aidentical in IP= v4. In IPv4, many people block or disable directed broadcast PING. Such= =0APINGs can be used for amplification in Smurf attacks.=0A=0Ahttp://www.te= chrepublic.com/article/understanding-a-smurf-attack-is-the-first-step-towar= d-thwarting-one/=0A=0APing to FF02::1 is definitely amplification when 10 e= cho requests can create 2,000+ =0Aecho replies. When you do a Ping on Lin= ux, it is continuous until you stop it.=0ASo, you may very easily do amplif= ication without even meaning to.=0A=0A=0A>>Of course, private VLANs or (if = we are talking VMs) or just using p2p=0A>>links with /128s would help this = in the environments where the hosts=0A>>can not be trusted - and this of co= urse is not virtual/physical=0A>>specific.=0A>=0A> Yes. We wanted to bring= up the topic of isolation of nodes for discussion.=0A=0A>This is a useful = topic in general - especially in light of the=0A>MLD-related thread, but th= e draft seems to focus on a very corner case=0A>- there are many much bette= r reasons not to do large L2 networks.=0A=0AWe wanted to pick one specific = instance. Maybe we went TOO small!=0A=0A>=0A>>If we're talking specificall= y virtual environment, here's an approach=0A>>on how to use ebtables to iso= late the hosts:=0A>=0A>>ebtables -P FORWARD DROP=0A>>ebtables -F FORWARD=0A= >>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow=0A>>f= rom uplink to any ports=0A>>ebtables -A FORWARD -o $uplinkPort -j ACCEPT # = let the traffic flow=0A>>from any ports to uplink=0A>=0A>>(source:http://se= rverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-l= inux-bridges)=0A>=0A> I think this is very good. But, unfortunately not ve= ry well known. Also,=0A> is this possible for all platforms or just Linux= ?=0A=0A>This was just my first google.com search result when searching for= =0A>"private vlans linux".=0A=0A>The first google.com search result on "pri= vate vlans windows" brings=0A>up http://blogs.technet.com/b/scvmm/archive/2= 013/06/04/logical-networks-part-iv-pvlan-isolation.aspx=0A>which seems to d= ocument similar technique.=0A=0A>"private vlan vmware" results in=0A>http:/= /kb.vmware.com/selfservice/microsites/search.do?language=3Den_US&cmd=3Ddisp= layKC&externalId=3D1010691=0A>as its first hit.=0A=0A>Would an IETF publica= tion be easier to find than the above ?=0A=0AMaybe not but the hosting comp= any who provided us the service where we did this real life test does not s= eem to have read any of the documents you reference.=0A=0AWhat to do is a g= ood question. IPv6 implementation at end user sites is new to many & mista= kes are being made. I do not know what is the answer.=0A=0A>=0A>>So looks = like the question at hand is:=0A>=0A>>"Should IPv6 nodes respond to Ping to= FF0x::1?"=0A>=0A>>Which can be rephrased differently to ease the start of = the discussion:=0A>=0A>>"What are the legitimate uses of a ping to ff0x::1 = ?"=0A>=0A>>Right ?=0A>=0A> Yes.=0A=0A>Allright, so I'll mention my use of p= ing6 ff0x::1:=0A=0A>* quick check to find "a few hosts that are alive on th= is link"=0A>(obviously not to be done on large segments).=0A=0A>* A way to = trigger the remote side's ND process without having to do=0A>one myself (I = know the multicast packet to all-hosts *will* usually=0A>get received regar= dless of the underlying issues with the L2.5=0A>infrastructure (snooping, e= tc.)=0A=0A>* A way to further debug malfunctioning L2.5 infra, by comparing= the=0A>reaction to pings to ff02::1, solicited node multicast, other=0A>mu= lticast groups, etc.=0A=0A>Summary: the ff02::1 current ping behavior does = help in a non-trivial=0A>amount of cases.=0A=0A>The security aspects the dr= aft mentions indeed do exist, but in a=0A>properly configured network can b= e easily mitigated as I've shown=0A>above. So I'd be against changing the f= unctionality in the existing=0A>stacks.=0A=0AI don't know, Andrew. I worry= about the broadcast nature of the ping.=0AI feel like it is trouble waitin= g to happen.=0A=0A=0A--a=0A=0A>=0A> --a=0A>=0A>=0A> On 9/19/14, fred@cisco.= com wrote:=0A>> A new draft has been posted, at=0A>> http:= //tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes.=0A>> Plea= se take a look at it and comment.=0A>>=0A>> _______________________________= ________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://w= ww.ietf.org/mailman/listinfo/v6ops=0A>> From nobody Fri Sep 19 15:20:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177111A88F7; Fri, 19 Sep 2014 15:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbtcKwveTjfJ; Fri, 19 Sep 2014 15:20:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 402711A88E7; Fri, 19 Sep 2014 15:20:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: gilligan@intransa.com,erik.nordmark@sun.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919222022.9031.3309.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 15:20:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6y2MMuPxbV3j936K1ZBoPP6pdZE Cc: v6ops@ietf.org, fred.baker@cisco.com, ipr-announce@ietf.org Subject: [v6ops] IPR Disclosure: SSH Communications Security Oyj's Statement about IPR related to RFC 4213 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 22:20:24 -0000 Dear Robert E. Gilligan, Erik Nordmark: An IPR disclosure that pertains to your RFC entitled "Basic Transition Mechanisms for IPv6 Hosts and Routers" (RFC4213) was submitted to the IETF Secretariat on 2014-09-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2434/). The title of the IPR disclosure is "SSH Communications Security Oyj's Statement about IPR related to RFC 4213.""); The IETF Secretariat From nobody Fri Sep 19 15:24:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98031A88E4 for ; Fri, 19 Sep 2014 15:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7cJLMXY107Q for ; Fri, 19 Sep 2014 15:24:34 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D481D1A88F6 for ; Fri, 19 Sep 2014 15:24:32 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar1so4490569iec.21 for ; Fri, 19 Sep 2014 15:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WVx71wCoU5zjrOnt6K5sk8EEz+XpxyASacGr6w1O5UA=; b=ntjQ+WJNOg/64sUjzqb5kjb+C/cHLLvtLdTUMbVmS/Agz1Mo3MSj/FmPKvzmKiVDBW 72H7gL9fWgNy5/jfhJVUjRQlZhtaL2SCpX2RtohupLa3uEAF9RBemYGpinndJbN4bS9U HyloHTLN3erZoFX/YjcaRGZ6vFg+2773QQD1LPGwf5St75Mwyk3zssp8+SZRlSgbk8RD CIiB4GPfauSL3XFY9sMyEJ6qH3cgwcMPIZR5CXn6iBYOLGaWd9Aktn2fc4PpOuA03CPP CBUwtcYB+0hgp10qSDLTl1/cThS7ZPBuT+RKxqPSBju3FNM3JPblEqyVgtIDxChuL/QB VHag== MIME-Version: 1.0 X-Received: by 10.50.61.99 with SMTP id o3mr1402520igr.30.1411165472237; Fri, 19 Sep 2014 15:24:32 -0700 (PDT) Received: by 10.107.137.65 with HTTP; Fri, 19 Sep 2014 15:24:32 -0700 (PDT) In-Reply-To: <4FC37E442D05A748896589E468752CAA0CCCABFB@PWN401EA160.ent.corp.bcbsm.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0CCCABFB@PWN401EA160.ent.corp.bcbsm.com> Date: Sat, 20 Sep 2014 00:24:32 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Ackermann, Michael" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/254FONkPecHMaUbzWpdfFuh_Erg Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 22:24:36 -0000 Hi Michael, On 9/19/14, Ackermann, Michael wrote: > HI Andrew > > Thanks for the great responses and related information. > > My comment on the inclusion of MLD, is that we talked a lot about MLD > during the creation of this draft and it certainly is consistent with the > theme and adds to the issues. However, we chose to leave MLD out of this > draft, in an effort to keep the draft smaller and more focused. We do > mention MLD as being a related factor but state it is outside of the scope > of the draft. Given that, a question for you is if you feel this draft > SHOULD include MLD? No, my point was about the overall approach of the draft - there seemed to be two aims: 1) the "TBD" placed into the section aiming at general design of subnets, 2) a question "should the hosts respond to ff0x::1?" following after the description of a link-local equivalent of a smurf attack. If the draft had just the (2) above (even limit it to just observations, maybe? Could someone else from the community chime in who thinks it is a problem?), and also discussed whether one can use larger scopes (what happens if ff05::1?), and the *operational* measures that can be taken today to prevent that threat, this would make it self-contained. As of now, it reads a bit unclear, and (1) is a rather broad topic to cover adequately while keeping it a short read, if you wanted to do so. > > One other comment is that although there is education and information about > these types of IPv6 subjects/issues, most large enterprises are unaware of > any of this. Our hope was to spare them from having an unpleasant initial > experience with IPv6, by pointing out some issues and pitfalls we have run > into. There is enough reluctance to pursue IPv6, in the corporate and > large enterprise environments today and we want to eliminate as many > negatives from that decision process as possible. > > Hope that makes sense. My general feeling: if a network is designed/operated in such a way that ping6 ff02::1 is an unpleasant experience, there should be a big warning sign "this is the least of your worries, you did not do your homework, so buckle up for the real fun to come". At the same time, if you indeed saw someone operationally messing up the network due to this issue - a short focused document discussing the observations and mitigations would be useful to point those people to. --a > > Thanks again > > Mike > > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Andrew ?? > Yourtchenko > Sent: Friday, September 19, 2014 4:27 PM > To: Nalini Elkins > Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org; > v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes > > On 9/19/14, Nalini Elkins wrote: >> >>>A directed broadcast ping on IPv4 gives pretty much the same result. >>>Did you test the effects of that ? >> >> I had not. But, since you mentioned it, I did it on two different >> Windows machines. The one that is the server in question had the >> following results: >> >> C:\Users\Administrator>ping x.x.x.255 >> >> Pinging x.x.x.255 with 32 bytes of data: >> Request timed out. >> Request timed out. >> Request timed out. >> Request timed out. >> >> Ping statistics for x.x.x.255: >> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >> >> Arp cache was not updated. I did a packet trace in the background and >> indeed no ICMP replies were seen. >> >> I did the same ping x.x.x.255 on one of my client PCs and saw: >> >> Pinging x.x.x.255 with 32 bytes of data: >> Request timed out. >> Request timed out. >> Request timed out. >> Request timed out. >> >> But this time the packet trace showed that actually ICMP replies were >> sent. >> > > So, besides this cosmetic difference the behavior is identical for the case > of IPv4 ping ? > >>>Of course, private VLANs or (if we are talking VMs) or just using p2p >>>links with /128s would help this in the environments where the hosts >>>can not be trusted - and this of course is not virtual/physical >>>specific. >> >> Yes. We wanted to bring up the topic of isolation of nodes for >> discussion. > > This is a useful topic in general - especially in light of the MLD-related > thread, but the draft seems to focus on a very corner case > - there are many much better reasons not to do large L2 networks. > >> >>>If we're talking specifically virtual environment, here's an approach >>>on how to use ebtables to isolate the hosts: >> >>>ebtables -P FORWARD DROP >>>ebtables -F FORWARD >>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow >>>from uplink to any ports ebtables -A FORWARD -o $uplinkPort -j ACCEPT >>># let the traffic flow from any ports to uplink >> >>>(source:http://serverfault.com/questions/388544/is-it-possible-to-enab >>>le-port-isolation-on-linux-bridges) >> >> I think this is very good. But, unfortunately not very well known. >> Also, >> is this possible for all platforms or just Linux? > > This was just my first google.com search result when searching for "private > vlans linux". > > The first google.com search result on "private vlans windows" brings up > http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx > which seems to document similar technique. > > "private vlan vmware" results in > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691 > as its first hit. > > Would an IETF publication be easier to find than the above ? > >> >>>So looks like the question at hand is: >> >>>"Should IPv6 nodes respond to Ping to FF0x::1?" >> >>>Which can be rephrased differently to ease the start of the discussion: >> >>>"What are the legitimate uses of a ping to ff0x::1 ?" >> >>>Right ? >> >> Yes. > > Allright, so I'll mention my use of ping6 ff0x::1: > > * quick check to find "a few hosts that are alive on this link" > (obviously not to be done on large segments). > > * A way to trigger the remote side's ND process without having to do one > myself (I know the multicast packet to all-hosts *will* usually get received > regardless of the underlying issues with the L2.5 infrastructure (snooping, > etc.) > > * A way to further debug malfunctioning L2.5 infra, by comparing the > reaction to pings to ff02::1, solicited node multicast, other multicast > groups, etc. > > Summary: the ff02::1 current ping behavior does help in a non-trivial amount > of cases. > > The security aspects the draft mentions indeed do exist, but in a properly > configured network can be easily mitigated as I've shown above. So I'd be > against changing the functionality in the existing stacks. > > On the education side: the existing search results > https://www.google.com/?gws_rd=ssl#q=ping6+ff02::1 show 8000-something > results - so indeed probably this behavior may be highlighted more during > the IPv6 education. However: every IPv6 course I've heard says "there is no > broadcast in IPv6, but there is all-hosts multicast" which should not make > the behavior the draft describes a major surprise. > > --a > >> >> --a >> >> >> On 9/19/14, fred@cisco.com wrote: >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. >>> Please take a look at it and comment. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential and > is intended solely for the use of the individual(s) to whom this > communication is directed. If you are not the intended recipient, you are > hereby notified that any viewing, copying, disclosure or distribution of > this information is prohibited. Please notify the sender, by electronic mail > or telephone, of any unintended receipt and delete the original message > without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are > nonprofit corporations and independent licensees of the Blue Cross and Blue > Shield Association. > From nobody Fri Sep 19 15:55:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720F51A88A9 for ; Fri, 19 Sep 2014 15:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1I7h7g33o-J for ; Fri, 19 Sep 2014 15:55:02 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78A71A87CB for ; Fri, 19 Sep 2014 15:55:01 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s8JMsvQ0006423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 19 Sep 2014 23:54:58 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <541CB43F.2040508@foobar.org> Date: Fri, 19 Sep 2014 23:54:55 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> In-Reply-To: <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kyVlVGPz2GiaUsoxwaO_3dt-TjE Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 22:55:04 -0000 On 19/09/2014 23:01, Nalini Elkins wrote: > Andrew, I think you may have misunderstand me. The behavior is very definitely not > identical in IPv4. In IPv4, many people block or disable directed broadcast PING. Such > PINGs can be used for amplification in Smurf attacks. > > http://www.techrepublic.com/article/understanding-a-smurf-attack-is-the-first-step-toward-thwarting-one/ > > Ping to FF02::1 is definitely amplification when 10 echo requests can create 2,000+ > echo replies. When you do a Ping on Linux, it is continuous until you stop it. > So, you may very easily do amplification without even meaning to. directed broadcast ping on ipv4 is harmful because it uses global addresses, and the directed broadcast ping can be initiated remotely and can be used to target third party addresses. ff02::1 is link-local only, which means that directed broadcast ping can only be initiated locally. If the operator follows BCP38, the replies will stay local so the scope for damage is minimal. The two aren't comparable. Nick From nobody Fri Sep 19 15:56:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3691A88A9 for ; Fri, 19 Sep 2014 15:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw31tFiFTKvA for ; Fri, 19 Sep 2014 15:56:38 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C221A01E4 for ; Fri, 19 Sep 2014 15:56:38 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id y20so4351450ier.5 for ; Fri, 19 Sep 2014 15:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FN9JnNrYgqH0QUa6CoACut/uoFYd0NZBKpEyEyBYYC8=; b=a5Ebdjc0mryc+lOYoX3HzH8Sdxgvi3VxcgjGuSy3nHx4xlW3AWsPt/JcAnQa1SfQp3 wqmsxZqwfOoACpZ4vLFdGbGghPse/zDd4oxpZw2eTKMHyN3EFVd4eeMwEmqBho890AnY Dj1OPD7x8ZkycX0ADxYyakwJP8UW36xZZRc5n9T3NH1AO3i8hNzaUIwLrSUfCS3ZBHbS rEU8NMwYd5ol/Figqlv4Q/kxBpH5f84D/RsuYCbYiJraBKkM7HMlhFRVN4kHpk4+guj3 SsT280gRz5lNtLg2ACNvZ7a5imFOMmY4LOVr63jTbpMNdeHSvnkk53fjnAiIs+jGfxh1 LGtQ== MIME-Version: 1.0 X-Received: by 10.42.63.129 with SMTP id c1mr3907785ici.82.1411167398087; Fri, 19 Sep 2014 15:56:38 -0700 (PDT) Received: by 10.107.137.65 with HTTP; Fri, 19 Sep 2014 15:56:38 -0700 (PDT) In-Reply-To: <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Sat, 20 Sep 2014 00:56:38 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Nalini Elkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/91QFP3y49p8CVwT6VrSaWXStfqg Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 22:56:40 -0000 On 9/20/14, Nalini Elkins wrote: > > > On 9/19/14, Nalini Elkins wrote: >> >>>A directed broadcast ping on IPv4 gives pretty much the same result. >>>Did you test the effects of that ? >> >> I had not. But, since you mentioned it, I did it on two different Windows >> machines. The one that is the server in question had the following >> results: >> >> C:\Users\Administrator>ping x.x.x.255 >> >> Pinging x.x.x.255 with 32 bytes of data: >> Request timed out. >> Request timed out. >> Request timed out. >> Request timed out. >> >> Ping statistics for x.x.x.255: >> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >> >> Arp cache was not updated. I did a packet trace in the background and >> indeed no ICMP replies were seen. >> >> I did the same ping x.x.x.255 on one of my client PCs and saw: >> >> Pinging x.x.x.255 with 32 bytes of data: >> Request timed out. >> Request timed out. >> Request timed out. >> Request timed out. >> >> But this time the packet trace showed that actually ICMP replies were >> sent. >> > >>So, besides this cosmetic difference the behavior is identical for the >>case of IPv4 ping ? > > Andrew, I think you may have misunderstand me. The behavior is very > definitely not > identical in IPv4. In IPv4, many people block or disable directed > broadcast PING. Such On the same subnet ? You wrote that the replies were indeed amplified and sent, or did I misunderstand ? > PINGs can be used for amplification in Smurf attacks. > > http://www.techrepublic.com/article/understanding-a-smurf-attack-is-the-first-step-toward-thwarting-one/ > > Ping to FF02::1 is definitely amplification when 10 echo requests can create > 2,000+ > echo replies. When you do a Ping on Linux, it is continuous until you stop > it. > So, you may very easily do amplification without even meaning to. This is all link-local. The reason Smurf is dangerous is that one can send the request from across the internet. Here it's on the same segment - so it's a customer-provider relationship, and there are ton of the existing operational mechanisms that can be used to take care of this if this is a concern - documenting them might be useful. Saying that the hosts should not reply altogether - not; for the reasons outlined in the previous mail. (Of course this is just my experience, would be interesting to hear others' opinions). > > >>>Of course, private VLANs or (if we are talking VMs) or just using p2p >>>links with /128s would help this in the environments where the hosts >>>can not be trusted - and this of course is not virtual/physical >>>specific. >> >> Yes. We wanted to bring up the topic of isolation of nodes for >> discussion. > >>This is a useful topic in general - especially in light of the >>MLD-related thread, but the draft seems to focus on a very corner case >>- there are many much better reasons not to do large L2 networks. > > We wanted to pick one specific instance. Maybe we went TOO small! No, the more focused the doc is, the better. > >> >>>If we're talking specifically virtual environment, here's an approach >>>on how to use ebtables to isolate the hosts: >> >>>ebtables -P FORWARD DROP >>>ebtables -F FORWARD >>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow >>>from uplink to any ports >>>ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic flow >>>from any ports to uplink >> >>>(source:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-linux-bridges) >> >> I think this is very good. But, unfortunately not very well known. >> Also, >> is this possible for all platforms or just Linux? > >>This was just my first google.com search result when searching for >>"private vlans linux". > >>The first google.com search result on "private vlans windows" brings >>up >> http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx >>which seems to document similar technique. > >>"private vlan vmware" results in >>http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691 >>as its first hit. > >>Would an IETF publication be easier to find than the above ? > > Maybe not but the hosting company who provided us the service where we did > this real life test does not seem to have read any of the documents you > reference. If you were not spoofing the source, then the only DoS target was yourself, and the inter-customer resource isolation should take care of the rest. This is relates to "Oops I don't know what I'm doing" part. Now, if you start to spoof your source and send the traffic at high rates, we're into the ToS violation territory, and the hosting company probably assumes a certain degree of good citizenship from its clients towards each other. If you were to try this kind of link-local smurf, why not try stealing other VM's IPv4 addresses and running MITM on them ? Or try spoofing the default router ? Or try sweep-scanning their entire /64 from Internet at high rate ? Or get into legacy and try ARP-flooding with broadcast ARP requests/replies at line rate ? There usually is a very simple mitigation to all of the above: first warn the hosting customer that is being naughty, then terminate the contract. I know for sure it is being practiced. --a > > What to do is a good question. IPv6 implementation at end user sites is new > to many & mistakes are being made. I do not know what is the answer. > >> >>>So looks like the question at hand is: >> >>>"Should IPv6 nodes respond to Ping to FF0x::1?" >> >>>Which can be rephrased differently to ease the start of the discussion: >> >>>"What are the legitimate uses of a ping to ff0x::1 ?" >> >>>Right ? >> >> Yes. > >>Allright, so I'll mention my use of ping6 ff0x::1: > >>* quick check to find "a few hosts that are alive on this link" >>(obviously not to be done on large segments). > >>* A way to trigger the remote side's ND process without having to do >>one myself (I know the multicast packet to all-hosts *will* usually >>get received regardless of the underlying issues with the L2.5 >>infrastructure (snooping, etc.) > >>* A way to further debug malfunctioning L2.5 infra, by comparing the >>reaction to pings to ff02::1, solicited node multicast, other >>multicast groups, etc. > >>Summary: the ff02::1 current ping behavior does help in a non-trivial >>amount of cases. > >>The security aspects the draft mentions indeed do exist, but in a >>properly configured network can be easily mitigated as I've shown >>above. So I'd be against changing the functionality in the existing >>stacks. > > I don't know, Andrew. I worry about the broadcast nature of the ping. > I feel like it is trouble waiting to happen. > > > --a > >> >> --a >> >> >> On 9/19/14, fred@cisco.com wrote: >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. >>> Please take a look at it and comment. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From nobody Fri Sep 19 16:34:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238061A88F9 for ; Fri, 19 Sep 2014 16:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 eoVIEfy5TSPl for ; Fri, 19 Sep 2014 16:34:55 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD501A8715 for ; Fri, 19 Sep 2014 16:34:54 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s8JNYPUh006787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 00:34:45 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <541CBD81.20209@foobar.org> Date: Sat, 20 Sep 2014 00:34:25 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0CCCABFB@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sQSjyoDDHz3SFNNKAoJCCFD-J_E Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Sep 2014 23:34:56 -0000 On 19/09/2014 23:24, Andrew 👽 Yourtchenko wrote: > If the draft had just the (2) above (even limit it to just > observations, maybe? Could someone else from the community chime in > who thinks it is a problem?),and also discussed whether one can use > larger scopes (what happens if ff05::1?), and the *operational* > measures that can be taken today to prevent that threat, this would > make it self-contained. the draft describes that when pinging the mcast all-hosts address, a bunch of replies are received from third party hosts which populated the nd cache on the author's machine with a bunch of entries. The authors have not provided enough detail in the email to show the cause of the amplification; anecdotally on my home network, pinging ff02::1%en0 causes some ND packets and gets a single echo reply per node, which is nothing like what the authors of this draft are seeing. It would be more useful at this stage for the authors to upload a pcap file for analysis rather than assuming there is a protocol level problem. It seems unusual that 10 icmp requests would result in 2840 replies but without details, it's not possible to tell what's going on and on that basis, an ID seems premature. As a side note, the ND cache entries look like they're derived from Xen MAC adddresses (00:16:3E:*). If the virtual hosting provider in question has made ipv6 end-user access available on a shared broadcast domain on Xen, then large ND caches are probably the least of their worries: neither Xen nor openvswitch support RA guard at the time of writing, which means that if the authors were to inject fake RAs, they could trivially take over the entire ipv6 network. Nick From nobody Fri Sep 19 16:37:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837B51A88FA for ; Fri, 19 Sep 2014 16:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGUMpmAeETzz for ; Fri, 19 Sep 2014 16:37:08 -0700 (PDT) Received: from nm18-vm0.bullet.mail.ne1.yahoo.com (nm18-vm0.bullet.mail.ne1.yahoo.com [98.138.91.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144A71A88F9 for ; Fri, 19 Sep 2014 16:37:08 -0700 (PDT) Received: from [98.138.101.132] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:37:07 -0000 Received: from [98.138.89.197] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:37:07 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:37:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 315408.93718.bm@omp1055.mail.ne1.yahoo.com Received: (qmail 73445 invoked by uid 60001); 19 Sep 2014 23:37:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411169827; bh=5qWiPe19B9e/4pKpcz2uVrwYbL/B3mYsCOGOZe1lECM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=U2H4aW0v2Ax6QT9uPogWTjJxxNyaVSA50XeD/tg7ZYyX7KeShSEzVzp98vehibrgtde3jKiR8xfo5qNwjqSLtQ/y8xRlmpbnT90JN74NB6cQbmzhTQ/J5HpEWmhTlKX0weytQJ/2BcTXoTokwTidiEcH4Xs6aKBsC6y0/Jn7yi0= X-YMail-OSG: 2wNCKLgVM1my1mEZpXaWvO0NxZJN7.pAAlh5.JgKCojt50O 8SDKg0MseYT1EvwyaIk78Liq4dfocz_0q3YAlXhVUiJ2JhUDUkmRZwzgUhmR 8sLtSmZPGCUnOh2Mqyj4hP2_UUpCFIxAGBHLTNtbXnCXyIhapCuojAuhCIJ3 BYEgs.idsGO4arBAWC9lPM2sH72t47iwGVRSk_gBFK_XZbFMEIV04e6RplFW BWaZ4UlHQwgn220XCZ0VYi9cRDlYzwe835Ev5T4exg2P7iASSf7EWMkHndqk HrAOuGwQfIr5CNjnnhfQJefI0eCtU56FTBzGpGU3P9yTVbIGutj6kZ13mm0g Vd1NNOPR6agjmZzQLHmvYK7t6xhdUpWHCcdKy_W8XPsK3yuEZ26jPH7G5IML _HfK21E5vnjVMZYYKSRfe.PrV1lO9anEyt8HftNjXFh3dgCg1RfJazE11dQK Wri6mIvgLYGeUN4jpudCz5d20AeM6Cg_bNQSTjxwuyst._ZArLPycPdhUjI4 obOt7UcMb24k9NtHrA4pzXFsM_0Ue50JAuqf4ORXGn05a0e_rra_yzKk- Received: from [24.130.244.175] by web125102.mail.ne1.yahoo.com via HTTP; Fri, 19 Sep 2014 16:37:07 PDT X-Rocket-MIMEInfo: 002.001, Cgo.ZGlyZWN0ZWQgYnJvYWRjYXN0IHBpbmcgb24gaXB2NCBpcyBoYXJtZnVsIGJlY2F1c2UgaXQgdXNlcyBnbG9iYWwKPmFkZHJlc3NlcywgYW5kIHRoZSBkaXJlY3RlZCBicm9hZGNhc3QgcGluZyBjYW4gYmUgaW5pdGlhdGVkIHJlbW90ZWx5IGFuZAo.Y2FuIGJlIHVzZWQgdG8gdGFyZ2V0IHRoaXJkIHBhcnR5IGFkZHJlc3Nlcy4gIGZmMDI6OjEgaXMgbGluay1sb2NhbCBvbmx5LAo.d2hpY2ggbWVhbnMgdGhhdCBkaXJlY3RlZCBicm9hZGNhc3QgcGluZyBjYW4gb25seSBiZSBpbml0aWF0ZWQgbG9jYWxseS4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <541CB43F.2040508@foobar.org> Message-ID: <1411169827.72819.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Fri, 19 Sep 2014 16:37:07 -0700 From: Nalini Elkins To: Nick Hilliard , "v6ops@ietf.org" In-Reply-To: <541CB43F.2040508@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dhrBZyCl-ToyLD90w75OhPLPCzw Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:37:09 -0000 >directed broadcast ping on ipv4 is harmful because it uses global >addresses, and the directed broadcast ping can be initiated remotely and >can be used to target third party addresses. ff02::1 is link-local only, >which means that directed broadcast ping can only be initiated locally. If >the operator follows BCP38, the replies will stay local so the scope for >damage is minimal. The two aren't comparable. I think the similarity has to do with the potential for amplification. The other point we were trying to make is that "replies staying local" is not really harmless. In IPv6 subnets, there may be many other nodes on link with you. We were using the Ping to FF02::1 as a graphic example of how it is possible to impact both yourself and other nodes without even meaning to. Nick _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 19 16:49:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405091A8902 for ; Fri, 19 Sep 2014 16:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ayYfe2vjYuSC for ; Fri, 19 Sep 2014 16:49:24 -0700 (PDT) Received: from nm27-vm2.bullet.mail.ne1.yahoo.com (nm27-vm2.bullet.mail.ne1.yahoo.com [98.138.91.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224021A8901 for ; Fri, 19 Sep 2014 16:49:24 -0700 (PDT) Received: from [98.138.100.111] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:49:23 -0000 Received: from [98.138.87.3] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:49:23 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:49:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 377330.16916.bm@omp1003.mail.ne1.yahoo.com Received: (qmail 39108 invoked by uid 60001); 19 Sep 2014 23:49:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411170563; bh=lv3AU1vmZC2YcwpP44GN18GXk4sE+Rhgf9I5B1zjbuc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UcwMyQ7bp1V0XNS1/xHosecSBVttItIXshwZnHUFURSZwBnLApLbbG7cGmxGFnrAPgONxmgmegfsawBI/zGAOqLgK3PY6yfoRUtkVSa3oEbhplSBL6wXTNqHRhbpwRyaqcW0pLzZLggISzlJUNIQc9TREoeXTkeyOYJWkZ+34g0= X-YMail-OSG: yxo8W14VM1lnxsVhfZmsl5JQgpDT9GHDGqs0Ce1wcmVZwLm 0Gz.vQVaudeorRbd6KSg3y1yHdDRFb_Hr4KLmmlxsT7TsgCm6giSLhzJJcNW bocDXw8ytjEaCVmG8mAToICbQ6x4T8lbQRYvUHYKbYY0ajaaE1ELTxQO8GBN eUJ9cxJLsGuRJRHeVkrqdTcUd0WBaufg3YY_bwrOxaJpbElwnTOq._86kCnM dzxnB9tLBzGwW8QI9bfOEqL8PH4cIUfJjjF1fKGqznCYTCwuU_fPUTtuMGgP af2ReJEAmEdHhXsUa9fv042qnsw.OMaGURceqyJ2xyTKHcmlWWERPnzWPRpj i3aSUCFdO.HFUOHE4Gvpf6fJPTsfQR1FSckcHPEL1HxD1InxkuZrmgIZ3T9_ KSmB.XUsS6Mop1WfnYNqZbtsYfHJ7dOBaU08zkiuDOY0QSmbYJsZ.5YGZ32Z mW3D4qRuuv0TjQwk9YNCpQpoYtMKoF_o.dJWft3pDHLbCIDIhB3kTVa0wxXy joUIVRBSV23O3ICP7K7JWJnwuipgOH1eNu9LJgDHbh41j.f9QL5LnBcuknvN xaakhN3Ur8QYLWZcjKYJZtMuYziOQtiLmXm2tNRS2U2u8fU.W05NW2OHfRGP Ib.pa.ltnrIDsS2NSckdM4oo0hClV982eJbDMiZ1fNXRGnLzBoikpDXdu.HK gRVEoCiHHIhirKGy9HLGouzIwnnqBVGkS9jRfkjMMdy3j4i_hZlvHyu630sZ pNsOzVQytIxuIT_eXnr3nfKHawo8z2YWGgRQQ3Cfn.xnWFxlnkPt2KDXWftV utgiSaR0APpmzTwiPVU_JC3.17jGSdFajkr_qpzipFXBktqT_rloH_hDzDU8 KNdx6rSKgnQylIsqfbMZVvQWaXYlTYFdgdVNZnvpUrGEvxFAxHlVoLSlUKCQ t3bkJLvp.itrVDuAlvkSMGz54YI1gRPRpyx_ixrU.W.pgmuphE1uXsrhmoMM 9mUQggsn1fu1M.OM_z_KmHaO4_2WCXhwytzq3x63GSn7w2en3r4O80G.shTG eQMik.sYpncXuBdJR1fjCY3ed368JZcCfv6331VrB1iOax57uzERxXjluqr0 Sw.XVAm0fLIjST2SPhJKjqtALtbWoSBI_Dguq2UNhvP9iKHrbPVmjsfm2KB_ q9GoMrvZk8r5c0WxFCEt2ANACsGjGh8tVkWegUOjVzj1VJdBERljB4eTCIcc MxbIGSU1BhbRnDw-- Received: from [24.130.244.175] by web125101.mail.ne1.yahoo.com via HTTP; Fri, 19 Sep 2014 16:49:23 PDT X-Rocket-MIMEInfo: 002.001, Cgo.Pgo.Pj5BIGRpcmVjdGVkIGJyb2FkY2FzdCBwaW5nIG9uIElQdjQgZ2l2ZXMgcHJldHR5IG11Y2ggdGhlIHNhbWUgcmVzdWx0Lgo.Pj5EaWQgeW91IHRlc3QgdGhlIGVmZmVjdHMgb2YgdGhhdCA_Cj4.Cj4.IEkgaGFkIG5vdC4gIEJ1dCwgc2luY2UgeW91IG1lbnRpb25lZCBpdCwgSSBkaWQgaXQgb24gdHdvIGRpZmZlcmVudCBXaW5kb3dzCj4.IG1hY2hpbmVzLiAgVGhlIG9uZSB0aGF0IGlzIHRoZSBzZXJ2ZXIgaW4gcXVlc3Rpb24gaGFkIHRoZSBmb2xsb3dpbmcKPj4gcmVzdWx0czoKPj4KPj4gQzpcVXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> Message-ID: <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> Date: Fri, 19 Sep 2014 16:49:23 -0700 From: Nalini Elkins To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3hEpN9fJHuONAalr2EQ9t4odPtU Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:49:26 -0000 =0A=0A>>=0A>>>A directed broadcast ping on IPv4 gives pretty much the same = result.=0A>>>Did you test the effects of that ?=0A>>=0A>> I had not. But, = since you mentioned it, I did it on two different Windows=0A>> machines. T= he one that is the server in question had the following=0A>> results:=0A>>= =0A>> C:\Users\Administrator>ping x.x.x.255=0A>>=0A>> Pinging x.x.x.255 wit= h 32 bytes of data:=0A>> Request timed out.=0A>> Request timed out.=0A>> Re= quest timed out.=0A>> Request timed out.=0A>>=0A>> Ping statistics for x.x.= x.255:=0A>> Packets: Sent =3D 4, Received =3D 0, Lost =3D 4 (100% loss)= ,=0A>>=0A>> Arp cache was not updated. I did a packet trace in the backgr= ound and=0A>> indeed no ICMP replies were seen.=0A>>=0A>> I did the same pi= ng x.x.x.255 on one of my client PCs and saw:=0A>>=0A>> Pinging x.x.x.255 w= ith 32 bytes of data:=0A>> Request timed out.=0A>> Request timed out.=0A>> = Request timed out.=0A>> Request timed out.=0A>>=0A>> But this time the pack= et trace showed that actually ICMP replies were=0A>> sent.=0A>>=0A>=0A>>So,= besides this cosmetic difference the behavior is identical for the=0A>>cas= e of IPv4 ping ?=0A>=0A> Andrew, I think you may have misunderstand me. Th= e behavior is very=0A> definitely not=0A> identical in IPv4. In IPv4, man= y people block or disable directed=0A> broadcast PING. Such=0A=0A>On the s= ame subnet ? You wrote that the replies were indeed amplified=0A>and sent, = or did I misunderstand ?=0A=0AThe replies on the same subnet appear to be b= locked in one case and not blocked in another case. =0ASo, one cannot make= a blanket statement (at least based on two data points!).=0A=0A=0A> PINGs = can be used for amplification in Smurf attacks.=0A>=0A> http://www.techrepu= blic.com/article/understanding-a-smurf-attack-is-the-first-step-toward-thwa= rting-one/=0A>=0A> Ping to FF02::1 is definitely amplification when 10 echo= requests can create=0A> 2,000+=0A> echo replies. When you do a Ping on L= inux, it is continuous until you stop=0A> it.=0A> So, you may very easily d= o amplification without even meaning to.=0A=0A>This is all link-local. The = reason Smurf is dangerous is that one can=0A>send the request from across t= he internet. Here it's on the same=0A>segment - so it's a customer-provider= relationship, and there are ton=0A>of the existing operational mechanisms = that can be used to take care=0A>of this if this is a concern - documenting= them might be useful.=0A>Saying that the hosts should not reply altogether= - not; for the=0A>reasons outlined in the previous mail.=0A=0A>(Of course = this is just my experience, would be interesting to hear=0A>others' opinion= s).=0A=0AAs I said in another response, in IPv6 subnets, there may be many = other nodes=0Aon link with you. We were using the=0A Ping to FF02::1 as a= graphic example of how=0Ait is possible to impact both yourself and other = nodes without even meaning to. =0A=0AWe discovered this by accident. We w= ere doing testing for another=0Apurpose and were quite surprised to see tha= t both servers were seeing all the=0Amulticast packets and even more surpri= sed when we did the PING to FF02::1.=0A=0A>=0A>=0A>>>Of course, private VLA= Ns or (if we are talking VMs) or just using p2p=0A>>>links with /128s would= help this in the environments where the hosts=0A>>>can not be trusted - an= d this of course is not virtual/physical=0A>>>specific.=0A>>=0A>> Yes. We = wanted to bring up the topic of isolation of nodes for=0A>> discussion.=0A>= =0A>>This is a useful topic in general - especially in light of the=0A>>MLD= -related thread, but the draft seems to focus on a very corner case=0A>>- t= here are many much better reasons not to do large L2 networks.=0A>=0A> We w= anted to pick one specific instance. Maybe we went TOO small!=0A=0ANo, the= more focused the doc is, the better.=0A=0A>=0A>>=0A>>>If we're talking spe= cifically virtual environment, here's an approach=0A>>>on how to use ebtabl= es to isolate the hosts:=0A>>=0A>>>ebtables -P FORWARD DROP=0A>>>ebtables -= F FORWARD=0A>>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traff= ic flow=0A>>>from uplink to any ports=0A>>>ebtables -A FORWARD -o $uplinkPo= rt -j ACCEPT # let the traffic flow=0A>>>from any ports to uplink=0A>>=0A>>= >(source:http://serverfault.com/questions/388544/is-it-possible-to-enable-p= ort-isolation-on-linux-bridges)=0A>>=0A>> I think this is very good. But, = unfortunately not very well known.=0A>> Also,=0A>> is this possible for all= platforms or just Linux?=0A>=0A>>This was just my first google.com search = result when searching for=0A>>"private vlans linux".=0A>=0A>>The first goog= le.com search result on "private vlans windows" brings=0A>>up=0A>> http://b= logs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-= isolation.aspx=0A>>which seems to document similar technique.=0A>=0A>>"priv= ate vlan vmware" results in=0A>>http://kb.vmware.com/selfservice/microsites= /search.do?language=3Den_US&cmd=3DdisplayKC&externalId=3D1010691=0A>>as its= first hit.=0A>=0A>>Would an IETF publication be easier to find than the ab= ove ?=0A>=0A> Maybe not but the hosting company who provided us the service= where we did=0A> this real life test does not seem to have read any of the= documents you=0A> reference.=0A=0A>If you were not spoofing the source, th= en the only DoS target was=0A>yourself, and the inter-customer resource iso= lation should take care=0A>of the rest. This is relates to "Oops I don't kn= ow what I'm doing"=0A>part.=0A=0AActually, not. In this case, there was no= inter-customer resource=0Aisolation. So, we were impacting everyone. As= I say, we discovered=0Athis by accident.=0A=0AI am thinking that the bigge= r question that we should address is=0Anode isolation. I think that people= implementing IPv6 have got the=0A/64 for subnet in their heads pretty well= . But, not the other part=0Aabout how multicast - and other packets impact= nodes on link with you.=0AAnd that they should do node isolation.=0A=0AWha= t do you think?=0A=0A>Now, if you start to spoof your source and send the t= raffic at high=0A>rates, we're into the ToS violation territory, and the ho= sting company=0A>probably assumes a certain degree of good citizenship from= its clients=0A>towards each other.=0A=0A>If you were to try this kind of l= ink-local smurf, why not=0A>try stealing other VM's IPv4 addresses and runn= ing MITM on them ? Or=0A>try spoofing the default router ? Or try sweep-sca= nning their entire=0A>/64 from Internet at high rate ? Or get into legacy a= nd try=0A>ARP-flooding with broadcast ARP requests/replies at line rate ?= =0A=0A>There usually is a very simple mitigation to all of the above: first= =0A>warn the hosting customer that is being naughty, then terminate the=0A>= contract. I know for sure it is being practiced.=0A=0AWe discovered this by= accident & were using the example of Ping FF02::1 to=0Aillustrate what can= happen. =0A=0A=0A=0A--a=0A=0A>=0A> What to do is a good question. IPv6 im= plementation at end user sites is new=0A> to many & mistakes are being made= . I do not know what is the answer.=0A>=0A>>=0A>>>So looks like the questi= on at hand is:=0A>>=0A>>>"Should IPv6 nodes respond to Ping to FF0x::1?"=0A= >>=0A>>>Which can be rephrased differently to ease the start of the discuss= ion:=0A>>=0A>>>"What are the legitimate uses of a ping to ff0x::1 ?"=0A>>= =0A>>>Right ?=0A>>=0A>> Yes.=0A>=0A>>Allright, so I'll mention my use of pi= ng6 ff0x::1:=0A>=0A>>* quick check to find "a few hosts that are alive on t= his link"=0A>>(obviously not to be done on large segments).=0A>=0A>>* A way= to trigger the remote side's ND process without having to do=0A>>one mysel= f (I know the multicast packet to all-hosts *will* usually=0A>>get received= regardless of the underlying issues with the L2.5=0A>>infrastructure (snoo= ping, etc.)=0A>=0A>>* A way to further debug malfunctioning L2.5 infra, by = comparing the=0A>>reaction to pings to ff02::1, solicited node multicast, o= ther=0A>>multicast groups, etc.=0A>=0A>>Summary: the ff02::1 current ping b= ehavior does help in a non-trivial=0A>>amount of cases.=0A>=0A>>The securit= y aspects the draft mentions indeed do exist, but in a=0A>>properly configu= red network can be easily mitigated as I've shown=0A>>above. So I'd be agai= nst changing the functionality in the existing=0A>>stacks.=0A>=0A> I don't = know, Andrew. I worry about the broadcast nature of the ping.=0A> I feel l= ike it is trouble waiting to happen.=0A>=0A>=0A> --a=0A>=0A>>=0A>> --a=0A>>= =0A>>=0A>> On 9/19/14, fred@cisco.com wrote:=0A>>> A new d= raft has been posted, at=0A>>> http://tools.ietf.org/html/draft-elkins-v6op= s-multicast-virtual-nodes.=0A>>> Please take a look at it and comment.=0A>>= >=0A>>> _______________________________________________=0A>>> v6ops mailing= list=0A>>> v6ops@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/v6op= s=0A>>>=0A> From nobody Fri Sep 19 16:52:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401B51A8902 for ; Fri, 19 Sep 2014 16:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 jGq8TlBeVZtO for ; Fri, 19 Sep 2014 16:52:20 -0700 (PDT) Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (nm20-vm4.bullet.mail.ne1.yahoo.com [98.138.91.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7D31A8901 for ; Fri, 19 Sep 2014 16:52:19 -0700 (PDT) Received: from [98.138.100.117] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:52:19 -0000 Received: from [98.138.226.161] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:52:19 -0000 Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 19 Sep 2014 23:52:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 149417.16600.bm@omp1062.mail.ne1.yahoo.com Received: (qmail 50876 invoked by uid 60001); 19 Sep 2014 23:52:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411170739; bh=9eDuKt4CYm3RsGCSl1cMjp+HeeO/e1HTvTR2AH2/Doc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=y4DDz6RR1iFXAAfQmWZzIInAlQEzryV7gSCzM/qnFvApAXhlUp0BGDNnvosQBqka1QiUloQSplpws1DnCciaH1McRAqng7smwsWU8FttxVM7+iIGn6sLaNM6qVK/w18K/5WJpekyVYsmyuys0QYvozTLejJziG7AIHWmwVKXT/8= X-YMail-OSG: 0TxfN5gVM1mjvvLW2M17igXzWtg3rqzB26VNDM_OeWzKeJD KOiy2dqYQcmVCA9qW8qP9EE9jBww19Utrs1qI7WSqM7xhkd33G94Prq0o11v eBCA3OTrH09yepKD5LGZO9SNSAu.EgTuP40LugZ22bBvp9LHC91ByAx7gC2X 1_vWHm_8hhEjcP9Z299Y6zDtj.fHSk_lLoSjFZElaBKzzG.P_v1u7pnC7Np_ KNQfnPkcKrH3rY55cifWl_d6H2FQmDklJhM5wyFsunSdqfQGLkBFaWIh0K1o rPXl1hkvBC1L7A1bcZAfoi0jKBS.0sEpcep6GXwENSYhvKK1ILGHhpC3lmkS kn5njqE6nEVXMoi0p7Q2jWl.vn8nbKO7zfUAqh7HHMi28Xzxo2UFfMD6nAau 5gS.2KI_yu6ZMek28lgLP7E6Eeik1Oysocj4CBJJitJji6PxAs3ORRQm_Reh Z0X5M5N_7W5Xa9Bt9UwtEY7LwHO3VuxpJkBiGrVr3dD5p2lKWwj.8M9Vd4wj 5ZpmcknjfDmPOw5tVg7LLRczRYOWeg_cgFU9koNuYapYiFl4GIo.e7vO.Bib _oDijdB1xcl4IMHIunkfwmBlPcw49Z0NGL_afovMTeyJgxX4bGUtWKq40dr1 Xwy2mRNOn76eAt42tgg-- Received: from [24.130.244.175] by web125106.mail.ne1.yahoo.com via HTTP; Fri, 19 Sep 2014 16:52:18 PDT X-Rocket-MIMEInfo: 002.001, TmljaywKClRyeSBkb2luZyA6CgpQSU5HIEZGMDI6OjEgLW4gMTAKCkhvdyBtYW55IGRldmljZXMgaGF2ZSB5b3Ugb24gbGluayB3aXRoIHlvdT8KCkFtIGhhcHB5IHRvIHNoYXJlIHRoZSBQQ0FQIHdpdGggeW91IHByaXZhdGVseS4gICBQbHMgbGV0IG1lIGtub3cuCiAKVGhhbmtzLAoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCkZyb206IE5pY2sgSGlsbGlhcmQgPG4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0CCCABFB@PWN401EA160.ent.corp.bcbsm.com> <541CBD81.20209@foobar.org> Message-ID: <1411170738.31683.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Fri, 19 Sep 2014 16:52:18 -0700 From: Nalini Elkins To: Nick Hilliard , =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= In-Reply-To: <541CBD81.20209@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AuFRR1jJagspJToC20DYKDidq8w Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:52:21 -0000 Nick,=0A=0ATry doing :=0A=0APING FF02::1 -n 10=0A=0AHow many devices have y= ou on link with you?=0A=0AAm happy to share the PCAP with you privately. = Pls let me know.=0A =0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.= =0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A----- Original Messag= e -----=0AFrom: Nick Hilliard =0ATo: Andrew =F0=9F=91=BD Y= ourtchenko =0ACc: "draft-elkins-v6ops-multicast-virtual= -nodes@tools.ietf.org" ; "v6ops@ietf.org" =0ASent: Friday, September 19, 20= 14 4:34 PM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-v= irtual-nodes=0A=0AOn 19/09/2014 23:24, Andrew =F0=9F=91=BD Yourtchenko wro= te:=0A> If the draft had just the (2) above (even limit it to just=0A> obse= rvations, maybe? Could someone else from the community chime in=0A> who thi= nks it is a problem?),and also discussed whether one can use=0A> larger sco= pes (what happens if ff05::1?), and the *operational*=0A> measures that can= be taken today to prevent that threat, this would=0A> make it self-contain= ed. =0A=0Athe draft describes that when pinging the mcast all-hosts address= , a bunch=0Aof replies are received from third party hosts which populated = the nd cache=0Aon the author's machine with a bunch of entries. The author= s have not=0Aprovided enough detail in the email to show the cause of the a= mplification;=0Aanecdotally on my home network, pinging ff02::1%en0 causes = some ND packets=0Aand gets a single echo reply per node, which is nothing l= ike what the=0Aauthors of this draft are seeing.=0A=0AIt would be more usef= ul at this stage for the authors to upload a pcap file=0Afor analysis rathe= r than assuming there is a protocol level problem. It=0Aseems unusual that= 10 icmp requests would result in 2840 replies but=0Awithout details, it's = not possible to tell what's going on and on that=0Abasis, an ID seems prema= ture.=0A=0AAs a side note, the ND cache entries look like they're derived f= rom Xen MAC=0Aadddresses (00:16:3E:*). If the virtual hosting provider in = question has=0Amade ipv6 end-user access available on a shared broadcast do= main on Xen,=0Athen large ND caches are probably the least of their worries= : neither Xen=0Anor openvswitch support RA guard at the time of writing, wh= ich means that=0Aif the authors were to inject fake RAs, they could trivial= ly take over the=0Aentire ipv6 network.=0A=0ANick=0A=0A=0A=0A=0A=0A________= _______________________________________=0Av6ops mailing list=0Av6ops@ietf.o= rg=0Ahttps://www.ietf.org/mailman/listinfo/v6ops=0A From nobody Fri Sep 19 17:36:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B863C1A890E for ; Fri, 19 Sep 2014 17:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BlvZJ8BzDtp for ; Fri, 19 Sep 2014 17:36:25 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D411A889F for ; Fri, 19 Sep 2014 17:36:25 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id x19so4544802ier.22 for ; Fri, 19 Sep 2014 17:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IWJE5CtqMilpvM7HOr9SfO1ftggNFvCDsWJZlYq3D7U=; b=wTyA3w2hzbXBzIxvWBI/qPfUkmNr7FzKDmgYClANl0+TGXu0Y8C5YO7d4CsnjE+EGM PnFnV7MvB32Wpg8OliZst+1u8crofhd+ZttQMIlRCP5hgDrjG82d8/K+wv8L44Xm0RV1 vEHjO3iepVFLFKRQeVTDZrVQzcC8rC/Y6pkg28ic3viCWHSnbkrvN+UGHp2PatucBIxi 4ZXwDsf17lMmsAedV9izDu9dLhy7nzqUH0IxELiX6YwXlIgGD2wR7OKXEpj8/LNgasz4 zJHzi7KBFbl/R8yN9QcrVPfAxjpV11i4iE3gkmM/6lEI9+/IiiUpqQlclJ9Ve2AyUdNT GGRA== MIME-Version: 1.0 X-Received: by 10.50.138.233 with SMTP id qt9mr173300igb.30.1411173384513; Fri, 19 Sep 2014 17:36:24 -0700 (PDT) Received: by 10.107.137.65 with HTTP; Fri, 19 Sep 2014 17:36:24 -0700 (PDT) In-Reply-To: <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> Date: Sat, 20 Sep 2014 02:36:24 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Nalini Elkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-kPmwZ6nFXqfLNLxNGiGCDdYtdE Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Sep 2014 00:36:27 -0000 On 9/20/14, Nalini Elkins wrote: > > >>> >>>>A directed broadcast ping on IPv4 gives pretty much the same result. >>>>Did you test the effects of that ? >>> >>> I had not. But, since you mentioned it, I did it on two different >>> Windows >>> machines. The one that is the server in question had the following >>> results: >>> >>> C:\Users\Administrator>ping x.x.x.255 >>> >>> Pinging x.x.x.255 with 32 bytes of data: >>> Request timed out. >>> Request timed out. >>> Request timed out. >>> Request timed out. >>> >>> Ping statistics for x.x.x.255: >>> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >>> >>> Arp cache was not updated. I did a packet trace in the background and >>> indeed no ICMP replies were seen. >>> >>> I did the same ping x.x.x.255 on one of my client PCs and saw: >>> >>> Pinging x.x.x.255 with 32 bytes of data: >>> Request timed out. >>> Request timed out. >>> Request timed out. >>> Request timed out. >>> >>> But this time the packet trace showed that actually ICMP replies were >>> sent. >>> >> >>>So, besides this cosmetic difference the behavior is identical for the >>>case of IPv4 ping ? >> >> Andrew, I think you may have misunderstand me. The behavior is very >> definitely not >> identical in IPv4. In IPv4, many people block or disable directed >> broadcast PING. Such > >>On the same subnet ? You wrote that the replies were indeed amplified >>and sent, or did I misunderstand ? > > The replies on the same subnet appear to be blocked in one case and not > blocked in another case. > So, one cannot make a blanket statement (at least based on two data > points!). > With the test I did within my home network, I saw amplified replies on both, so one can not make a blanket statement indeed and it depends on the OS and the setup. > >> PINGs can be used for amplification in Smurf attacks. >> >> http://www.techrepublic.com/article/understanding-a-smurf-attack-is-the-first-step-toward-thwarting-one/ >> >> Ping to FF02::1 is definitely amplification when 10 echo requests can >> create >> 2,000+ >> echo replies. When you do a Ping on Linux, it is continuous until you >> stop >> it. >> So, you may very easily do amplification without even meaning to. > >>This is all link-local. The reason Smurf is dangerous is that one can >>send the request from across the internet. Here it's on the same >>segment - so it's a customer-provider relationship, and there are ton >>of the existing operational mechanisms that can be used to take care >>of this if this is a concern - documenting them might be useful. >>Saying that the hosts should not reply altogether - not; for the >>reasons outlined in the previous mail. > >>(Of course this is just my experience, would be interesting to hear >>others' opinions). > > As I said in another response, in IPv6 subnets, there may be many other > nodes > on link with you. We were using the > Ping to FF02::1 as a graphic example of how > it is possible to impact both yourself and other nodes without even meaning > to. So you ping ff02::1 on a network with X hosts, where X is large. So each of these X hosts has to process 1 packet and generate 1 packet, you have to process X responses, you populate ND cache on your hosts with X entries, each of the X hosts populates their ND cache with your address. Your host is quite obviously impacted. But the others process a 1/X share of the load compared to you, an equivalent to a regular 1 host exchange. So I don't see how they are impacted. > > We discovered this by accident. We were doing testing for another > purpose and were quite surprised to see that both servers were seeing all > the > multicast packets and even more surprised when we did the PING to FF02::1. Nick has a good point this whole situation would benefit of some more debugging. > >> >> >>>>Of course, private VLANs or (if we are talking VMs) or just using p2p >>>>links with /128s would help this in the environments where the hosts >>>>can not be trusted - and this of course is not virtual/physical >>>>specific. >>> >>> Yes. We wanted to bring up the topic of isolation of nodes for >>> discussion. >> >>>This is a useful topic in general - especially in light of the >>>MLD-related thread, but the draft seems to focus on a very corner case >>>- there are many much better reasons not to do large L2 networks. >> >> We wanted to pick one specific instance. Maybe we went TOO small! > > No, the more focused the doc is, the better. > >> >>> >>>>If we're talking specifically virtual environment, here's an approach >>>>on how to use ebtables to isolate the hosts: >>> >>>>ebtables -P FORWARD DROP >>>>ebtables -F FORWARD >>>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow >>>>from uplink to any ports >>>>ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic flow >>>>from any ports to uplink >>> >>>>(source:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-linux-bridges) >>> >>> I think this is very good. But, unfortunately not very well known. >>> Also, >>> is this possible for all platforms or just Linux? >> >>>This was just my first google.com search result when searching for >>>"private vlans linux". >> >>>The first google.com search result on "private vlans windows" brings >>>up >>> http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx >>>which seems to document similar technique. >> >>>"private vlan vmware" results in >>>http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691 >>>as its first hit. >> >>>Would an IETF publication be easier to find than the above ? >> >> Maybe not but the hosting company who provided us the service where we did >> this real life test does not seem to have read any of the documents you >> reference. > >>If you were not spoofing the source, then the only DoS target was >>yourself, and the inter-customer resource isolation should take care >>of the rest. This is relates to "Oops I don't know what I'm doing" >>part. > > Actually, not. In this case, there was no inter-customer resource > isolation. So, we were impacting everyone. As I say, we discovered > this by accident. Again, it's obvious to see how you're impacting yourself but it's unclear to me how were you impacting the others. I did a quick test in my lab, and the only node that significantly grew the ND cache in my test was the one sending the ping. The rest just added only the sender's address. Sure, the sender also triggered NUD on the addresses, but again it is only the sender that was impacted - the rest had just 1 packet to handle, which is not much. Please help me understand where is the problem ? > > I am thinking that the bigger question that we should address is > node isolation. I think that people implementing IPv6 have got the > /64 for subnet in their heads pretty well. But, not the other part > about how multicast - and other packets impact nodes on link with you. > And that they should do node isolation. > > What do you think? Give each vhost a routed /64 and use link-local next-hops - this will give the same "broadcast profile" as for IPv4, and reduce the hoster's resources needed to manage the allocated addresses, and still allows to sell 65536 vhosts, assuming the said hoster has only /48. Then on the shared segment that carries the routed traffic, intra-subnet apply the same security policy to the ff02::1 IPv6 traffic as you do to IPv4 x.x.x.255 originated within and destined for that subnet - private VLANs, p2p links, or nothing. --a > >>Now, if you start to spoof your source and send the traffic at high >>rates, we're into the ToS violation territory, and the hosting company >>probably assumes a certain degree of good citizenship from its clients >>towards each other. > >>If you were to try this kind of link-local smurf, why not >>try stealing other VM's IPv4 addresses and running MITM on them ? Or >>try spoofing the default router ? Or try sweep-scanning their entire >>/64 from Internet at high rate ? Or get into legacy and try >>ARP-flooding with broadcast ARP requests/replies at line rate ? > >>There usually is a very simple mitigation to all of the above: first >>warn the hosting customer that is being naughty, then terminate the >>contract. I know for sure it is being practiced. > > We discovered this by accident & were using the example of Ping FF02::1 to > illustrate what can happen. > > > > --a > >> >> What to do is a good question. IPv6 implementation at end user sites is >> new >> to many & mistakes are being made. I do not know what is the answer. >> >>> >>>>So looks like the question at hand is: >>> >>>>"Should IPv6 nodes respond to Ping to FF0x::1?" >>> >>>>Which can be rephrased differently to ease the start of the discussion: >>> >>>>"What are the legitimate uses of a ping to ff0x::1 ?" >>> >>>>Right ? >>> >>> Yes. >> >>>Allright, so I'll mention my use of ping6 ff0x::1: >> >>>* quick check to find "a few hosts that are alive on this link" >>>(obviously not to be done on large segments). >> >>>* A way to trigger the remote side's ND process without having to do >>>one myself (I know the multicast packet to all-hosts *will* usually >>>get received regardless of the underlying issues with the L2.5 >>>infrastructure (snooping, etc.) >> >>>* A way to further debug malfunctioning L2.5 infra, by comparing the >>>reaction to pings to ff02::1, solicited node multicast, other >>>multicast groups, etc. >> >>>Summary: the ff02::1 current ping behavior does help in a non-trivial >>>amount of cases. >> >>>The security aspects the draft mentions indeed do exist, but in a >>>properly configured network can be easily mitigated as I've shown >>>above. So I'd be against changing the functionality in the existing >>>stacks. >> >> I don't know, Andrew. I worry about the broadcast nature of the ping. >> I feel like it is trouble waiting to happen. >> >> >> --a >> >>> >>> --a >>> >>> >>> On 9/19/14, fred@cisco.com wrote: >>>> A new draft has been posted, at >>>> http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. >>>> Please take a look at it and comment. >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >> > From nobody Fri Sep 19 20:54:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437A21A00F3 for ; Fri, 19 Sep 2014 20:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 bNrXsLWfAgkG for ; Fri, 19 Sep 2014 20:54:28 -0700 (PDT) Received: from nm28-vm3.bullet.mail.ne1.yahoo.com (nm28-vm3.bullet.mail.ne1.yahoo.com [98.138.91.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17641A0071 for ; Fri, 19 Sep 2014 20:54:27 -0700 (PDT) Received: from [98.138.100.118] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 03:54:27 -0000 Received: from [98.138.89.161] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 03:54:27 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 03:54:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 113371.25227.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 51231 invoked by uid 60001); 20 Sep 2014 03:54:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411185267; bh=QUJscnh/nGvcGS66yAn06aR1PKqYPr3bKWVP9vgGPro=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fPiamJ5heUbz4XOqyRmBgP48bEIRpIH7onWKYvTA+FfXGLIj9gqBA2+AMBNW8gSSStmB8uokkTUCrClcqhidVrILrmGQjgbn7HMydD41ZrjkM5WboGOP+xj5t02Yyc7G14yUNkPzwrtagfkKEVrfE/FaJd82fBM2TPgInHXElZo= X-YMail-OSG: XRmj3U0VM1lIXB_dAWod7Ei8YiBtjlk9vqQ15NXrxqWCYDI tOfsKD_r6WY.9ypm8MnIx151WfRvNC8WoLlPJEaRvPnA9KTpRc5GQtsDM_Fo 66Yo241L2638P0V2PhE82AS6camYJFPUByPE9myUtIbKelgM3nCo_KNGfEcD YmVyQAD0mhj6QBE_Fr47W2m0oXd90RpX87AoFK45nUu.eSupxm6.BrknLYUJ 4t7p1wub_J6BP9tRDSBehvuFVnw834HHItspgyc1L0f1dTEyr..QBaesDqtd c753OCPYzIVb53VozhaMAXARAbqNLzK_pZTCvbmVwdPWkVMFIo6nHtZCpOmV YFRuDRUW.ty8iCcz7FD28f1ptqlKaaGE1TNo7rFRLQwALLnvGSQ56VGtcEZm v7xuR6ub9LOV8LxzXtCkAltaZYqfEJm9kjfyGTenp7.0O.s1FnGIx9hZQ1vA V1VL4GW0O7pUyNmbm0oDDzk6t9js9LdqCnko0VKo26JnFzyD1AbtGuuiNwvy YcxvaA3BQqC8X.eBSLLgY0UQJw2SsH7OONvVPVqPRS9yD1TJ6ym9GB4YUDLO 320W8GQ2_aogWZSBo479FVRX.qMbmzJMGvkYqrvFnDhNaCI9gSY.pTEPFw5j 0OSsLcUiYNwiUuxaA1t6xrL3e0S4scYptHy1nTUeISFUNY3pyYGUgbfg7rLh bE_R_tR7.t0zVKb2XtabIxhg4UdFcL5eXR6on6S0GJqL7GJCD5QcoVdF6PEC aawaZIrII3JiDiBU6Bww5d6KEqsbwopGRDIdrqxSUABBWO2w7.l4ZAhz6Vj_ ERZWczJejahqYaOMUozlJyojPgxy8HPI.l7IxmyIl1fRkELlQVNGKO9r1YJ9 S5F4ReiGy2c3pg_lP1zsqw8cIyQKbsPvKrU925.DIJNHwhxhlycMOjy8SFBG X3s_3KVu6vUGBmtTA9on4pa56OlMGvoNIzvjvkAtlbbYt5QXb2xrf5u4_k6r SUpPjqqUlVSM11ImXVLWia7wnxP1Z5zZWPks0yuJI2Hqt7hrXkGF8odgSq2g QMFUtGvsRVuURp3wz8VGIlz92UM7rhhF6N_dRlSAJ4_a0JpqrPeIVfkrp839 SNQjgFxvmiq.NJALR_0esACOk57XSdEAuaNnEI_avfLI24_l0B0b8du1JTfL LkLXtCVC85qzvynaF_fxjRS9SBV15nzoZ6IozR_bnGAdzi_QwkpRydprJ94t vQEPeHZcVKCw- Received: from [24.130.244.175] by web125102.mail.ne1.yahoo.com via HTTP; Fri, 19 Sep 2014 20:54:26 PDT X-Rocket-MIMEInfo: 002.001, Cgo.Cj4.Pgo.Pj4.QSBkaXJlY3RlZCBicm9hZGNhc3QgcGluZyBvbiBJUHY0IGdpdmVzIHByZXR0eSBtdWNoIHRoZSBzYW1lIHJlc3VsdC4KPj4.PkRpZCB5b3UgdGVzdCB0aGUgZWZmZWN0cyBvZiB0aGF0ID8KPj4.Cj4.PiBJIGhhZCBub3QuICBCdXQsIHNpbmNlIHlvdSBtZW50aW9uZWQgaXQsIEkgZGlkIGl0IG9uIHR3byBkaWZmZXJlbnQKPj4.IFdpbmRvd3MKPj4.IG1hY2hpbmVzLiAgVGhlIG9uZSB0aGF0IGlzIHRoZSBzZXJ2ZXIgaW4gcXVlc3Rpb24gaGFkIHRoZSBmb2xsb3dpbmcKPj4.IHJlc3VsdHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> Message-ID: <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Fri, 19 Sep 2014 20:54:26 -0700 From: Nalini Elkins To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-559651860-1474897163-1411185266=:51203" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WVd4RQbRoj5FDUKh3Ecisel2wxo Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 03:54:32 -0000 ---559651860-1474897163-1411185266=:51203 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A>=0A>>>=0A>>>>A directed broadcast ping on IPv4 gives pretty much the= same result.=0A>>>>Did you test the effects of that ?=0A>>>=0A>>> I had no= t. But, since you mentioned it, I did it on two different=0A>>> Windows=0A= >>> machines. The one that is the server in question had the following=0A>= >> results:=0A>>>=0A>>> C:\Users\Administrator>ping x.x.x.255=0A>>>=0A>>> P= inging x.x.x.255 with 32 bytes of data:=0A>>> Request timed out.=0A>>> Requ= est timed out.=0A>>> Request timed out.=0A>>> Request timed out.=0A>>>=0A>>= > Ping statistics for x.x.x.255:=0A>>> Packets: Sent =3D 4, Received = =3D 0, Lost =3D 4 (100% loss),=0A>>>=0A>>> Arp cache was not updated. I d= id a packet trace in the background and=0A>>> indeed no ICMP replies were s= een.=0A>>>=0A>>> I did the same ping x.x.x.255 on one of my client PCs and = saw:=0A>>>=0A>>> Pinging x.x.x.255 with 32 bytes of data:=0A>>> Request tim= ed out.=0A>>> Request timed out.=0A>>> Request timed out.=0A>>> Request tim= ed out.=0A>>>=0A>>> But this time the packet trace showed that actually ICM= P replies were=0A>>> sent.=0A>>>=0A>>=0A>>>So, besides this cosmetic differ= ence the behavior is identical for the=0A>>>case of IPv4 ping ?=0A>>=0A>> A= ndrew, I think you may have misunderstand me. The behavior is very=0A>> de= finitely not=0A>> identical in IPv4. In IPv4, many people block or disabl= e directed=0A>> broadcast PING. Such=0A>=0A>>On the same subnet ? You wrot= e that the replies were indeed amplified=0A>>and sent, or did I misundersta= nd ?=0A>=0A> The replies on the same subnet appear to be blocked in one cas= e and not=0A> blocked in another case.=0A> So, one cannot make a blanket st= atement (at least based on two data=0A> points!).=0A>=0A=0A>With the test I= did within my home network, I saw amplified replies on=0A>both, so one can= not make a blanket statement indeed and it depends on=0A>the OS and the se= tup.=0A=0A>=0A>> PINGs can be used for amplification in Smurf attacks.=0A>>= =0A>> http://www.techrepublic.com/article/understanding-a-smurf-attack-is-t= he-first-step-toward-thwarting-one/=0A>>=0A>> Ping to FF02::1 is definitely= amplification when 10 echo requests can=0A>> create=0A>> 2,000+=0A>> echo = replies. When you do a Ping on Linux, it is continuous until you=0A>> sto= p=0A>> it.=0A>> So, you may very easily do amplification without even meani= ng to.=0A>=0A>>This is all link-local. The reason Smurf is dangerous is tha= t one can=0A>>send the request from across the internet. Here it's on the s= ame=0A>>segment - so it's a customer-provider relationship, and there are t= on=0A>>of the existing operational mechanisms that can be used to take care= =0A>>of this if this is a concern - documenting them might be useful.=0A>>S= aying that the hosts should not reply altogether - not; for the=0A>>reasons= outlined in the previous mail.=0A>=0A>>(Of course this is just my experien= ce, would be interesting to hear=0A>>others' opinions).=0A>=0A> As I said i= n another response, in IPv6 subnets, there may be many other=0A> nodes=0A> = on link with you. We were using the=0A> Ping to FF02::1 as a graphic exa= mple of how=0A> it is possible to impact both yourself and other nodes with= out even meaning=0A> to.=0A=0A>So you ping ff02::1 on a network with X host= s, where X is large. So=0A>each of these X hosts has to process 1 packet an= d generate 1 packet,=0A>you have to process X responses, you populate ND ca= che on your hosts=0A>with X entries, each of the X hosts populates their ND= cache with your=0A>address.=0A=0A>Your host is quite obviously impacted. B= ut the others process a 1/X=0A>share of the load compared to you, an equiva= lent to a regular 1 host=0A>exchange. So I don't see how they are impacted.= =0A=0AOn Windows, I did a : ping ff02::1 -n 10=0A=0Awhere the -n is the co= unt.=0A=0ASo for each 1 ping request I send out, each of my neighbors sends= me 10 responses.=0ASo, I have made them do 10 times as much work as me. A= lso, since in this case, I=0Ahad about 200 neighbors, the link had a bunch = of traffic on it (the ping requests =0Aand replies from everyone) (as well = as the neighbor discovery packets) which were =0Ain the way of anyone wanti= ng to actual productive work.=0A=0A>=0A> We discovered this by accident. = We were doing testing for another=0A> purpose and were quite surprised to s= ee that both servers were seeing all=0A> the=0A> multicast packets and even= more surprised when we did the PING to FF02::1.=0A=0A>Nick has a good poin= t this whole situation would benefit of some more=0A>debugging.=0A=0ASuch a= s what? BTW, I have sent Nick the trace & can send to you as well.=0A=0A>= =0A>>=0A>>=0A>>>>Of course, private VLANs or (if we are talking VMs) or jus= t using p2p=0A>>>>links with /128s would help this in the environments wher= e the hosts=0A>>>>can not be trusted - and this of course is not virtual/ph= ysical=0A>>>>specific.=0A>>>=0A>>> Yes. We wanted to bring up the topic of= isolation of nodes for=0A>>> discussion.=0A>>=0A>>>This is a useful topic = in general - especially in light of the=0A>>>MLD-related thread, but the dr= aft seems to focus on a very corner case=0A>>>- there are many much better = reasons not to do large L2 networks.=0A>>=0A>> We wanted to pick one specif= ic instance. Maybe we went TOO small!=0A>=0A> No, the more focused the doc= is, the better.=0A>=0A>>=0A>>>=0A>>>>If we're talking specifically virtual= environment, here's an approach=0A>>>>on how to use ebtables to isolate th= e hosts:=0A>>>=0A>>>>ebtables -P FORWARD DROP=0A>>>>ebtables -F FORWARD=0A>= >>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow=0A>>= >>from uplink to any ports=0A>>>>ebtables -A FORWARD -o $uplinkPort -j ACCE= PT # let the traffic flow=0A>>>>from any ports to uplink=0A>>>=0A>>>>(sourc= e:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-iso= lation-on-linux-bridges)=0A>>>=0A>>> I think this is very good. But, unfor= tunately not very well known.=0A>>> Also,=0A>>> is this possible for all pl= atforms or just Linux?=0A>>=0A>>>This was just my first google.com search r= esult when searching for=0A>>>"private vlans linux".=0A>>=0A>>>The first go= ogle.com search result on "private vlans windows" brings=0A>>>up=0A>>> http= ://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pv= lan-isolation.aspx=0A>>>which seems to document similar technique.=0A>>=0A>= >>"private vlan vmware" results in=0A>>>http://kb.vmware.com/selfservice/mi= crosites/search.do?language=3Den_US&cmd=3DdisplayKC&externalId=3D1010691=0A= >>>as its first hit.=0A>>=0A>>>Would an IETF publication be easier to find = than the above ?=0A>>=0A>> Maybe not but the hosting company who provided u= s the service where we did=0A>> this real life test does not seem to have r= ead any of the documents you=0A>> reference.=0A>=0A>>If you were not spoofi= ng the source, then the only DoS target was=0A>>yourself, and the inter-cus= tomer resource isolation should take care=0A>>of the rest. This is relates = to "Oops I don't know what I'm doing"=0A>>part.=0A>=0A> Actually, not. In = this case, there was no inter-customer resource=0A> isolation. So, we were= impacting everyone. As I say, we discovered=0A> this by accident.=0A=0A>= Again, it's obvious to see how you're impacting yourself but it's=0A>unclea= r to me how were you impacting the others.=0A=0A>I did a quick test in my l= ab, and the only node that significantly=0A>grew the ND cache in my test wa= s the one sending the ping. The rest=0A>just added only the sender's addres= s. Sure, the sender also triggered=0A>NUD on the addresses, but again it is= only the sender that was=0A>impacted - the rest had just 1 packet to handl= e, which is not much.=0A=0A>Please help me understand where is the problem = ?=0A=0ASee above. Also, I believe it is not a question of the neighbor cac= he.=0AWe just showed that to prove that other nodes actually were respondin= g.=0A=0AAlso, our topic actually was a bit more broad. We were not talking= only=0Aof the PING to FF02::1, but of multicast. Multicast is seen by al= l the =0Aneighbors and can be quite a bit of the link activity. Again, ge= tting in=0Athe way of productive traffic.=0A=0AWe may be spending a bit too= much time focused solely on the Ping.=0AI stand by my statement that the P= ing can be an amplification. =0AHowever, we used the example of the Ping = to show that if you have a =0Anumber of neighbors on link, as shown by the = Ping, then they will see=0Aall the multicast packets generated as well.=0A= =0A>=0A> I am thinking that the bigger question that we should address is= =0A> node isolation. I think that people implementing IPv6 have got the=0A= > /64 for subnet in their heads pretty well. But, not the other part=0A> a= bout how multicast - and other packets impact nodes on link with you.=0A> A= nd that they should do node isolation.=0A>=0A> What do you think?=0A=0A>Giv= e each vhost a routed /64 and use link-local next-hops - this will=0A>give = the same "broadcast profile" as for IPv4, and reduce the hoster's=0A>resour= ces needed to manage the allocated addresses, and still allows=0Ato sell 65= 536 vhosts, assuming the said hoster has only /48.=0A=0A>Then on the shared= segment that carries the routed traffic,=0A>intra-subnet apply the same se= curity policy to the ff02::1 IPv6=0A>traffic as you do to IPv4 x.x.x.255 or= iginated within and destined for=0A>that subnet - private VLANs, p2p links,= or nothing.=0A=0A=0A=0AI think this focuses too narrowly on the Ping. I= need to think some=0Amore on how to talk about isolation.=0A=0A=0A--a=0A= =0A>=0A>>Now, if you start to spoof your source and send the traffic at hig= h=0A>>rates, we're into the ToS violation territory, and the hosting compan= y=0A>>probably assumes a certain degree of good citizenship from its client= s=0A>>towards each other.=0A>=0A>>If you were to try this kind of link-loca= l smurf, why not=0A>>try stealing other VM's IPv4 addresses and running MIT= M on them ? Or=0A>>try spoofing the default router ? Or try sweep-scanning = their entire=0A>>/64 from Internet at high rate ? Or get into legacy and tr= y=0A>>ARP-flooding with broadcast ARP requests/replies at line rate ?=0A>= =0A>>There usually is a very simple mitigation to all of the above: first= =0A>>warn the hosting customer that is being naughty, then terminate the=0A= >>contract. I know for sure it is being practiced.=0A>=0A> We discovered th= is by accident & were using the example of Ping FF02::1 to=0A> illustrate w= hat can happen.=0A>=0A>=0A>=0A> --a=0A>=0A>>=0A>> What to do is a good ques= tion. IPv6 implementation at end user sites is=0A>> new=0A>> to many & mis= takes are being made. I do not know what is the answer.=0A>>=0A>>>=0A>>>>S= o looks like the question at hand is:=0A>>>=0A>>>>"Should IPv6 nodes respon= d to Ping to FF0x::1?"=0A>>>=0A>>>>Which can be rephrased differently to ea= se the start of the discussion:=0A>>>=0A>>>>"What are the legitimate uses o= f a ping to ff0x::1 ?"=0A>>>=0A>>>>Right ?=0A>>>=0A>>> Yes.=0A>>=0A>>>Allri= ght, so I'll mention my use of ping6 ff0x::1:=0A>>=0A>>>* quick check to fi= nd "a few hosts that are alive on this link"=0A>>>(obviously not to be done= on large segments).=0A>>=0A>>>* A way to trigger the remote side's ND proc= ess without having to do=0A>>>one myself (I know the multicast packet to al= l-hosts *will* usually=0A>>>get received regardless of the underlying issue= s with the L2.5=0A>>>infrastructure (snooping, etc.)=0A>>=0A>>>* A way to f= urther debug malfunctioning L2.5 infra, by comparing the=0A>>>reaction to p= ings to ff02::1, solicited node multicast, other=0A>>>multicast groups, etc= .=0A>>=0A>>>Summary: the ff02::1 current ping behavior does help in a non-t= rivial=0A>>>amount of cases.=0A>>=0A>>>The security aspects the draft menti= ons indeed do exist, but in a=0A>>>properly configured network can be easil= y mitigated as I've shown=0A>>>above. So I'd be against changing the functi= onality in the existing=0A>>>stacks.=0A>>=0A>> I don't know, Andrew. I wor= ry about the broadcast nature of the ping.=0A>> I feel like it is trouble w= aiting to happen.=0A>>=0A>>=0A>> --a=0A>>=0A>>>=0A>>> --a=0A>>>=0A>>>=0A>>>= On 9/19/14, fred@cisco.com wrote:=0A>>>> A new draft has = been posted, at=0A>>>> http://tools.ietf.org/html/draft-elkins-v6ops-multic= ast-virtual-nodes.=0A>>>> Please take a look at it and comment.=0A>>>>=0A>>= >> _______________________________________________=0A>>>> v6ops mailing lis= t=0A>>>> v6ops@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/v6ops= =0A>>>>=0A>>=0A> ---559651860-1474897163-1411185266=:51203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

>
>>>
>>>= ;>A directed broadcast ping on IPv4 gives pretty much the same result.>>>>Did you test the effects of that ?
>>>
>>> I had not.  But= , since you mentioned it, I did it on two different
>&= gt;> Windows
>>> machines.  The one that= is the server in question had the following
>>>= results:
>>>
>>> C:\Users\Admini= strator>ping x.x.x.255
>>>
= >>> Pinging x.x.x.255 with 32 bytes of data:
>= ;>> Request timed out.
>>> Request timed o= ut.
>>> Request timed out.
>= ;>> Request timed out.
>>>
>>> Ping statistics for x.x.x.255:
>>&g= t;    Packets: Sent =3D 4, Received =3D 0, Lost =3D 4 (100% loss= ),
>>>
>>> Arp cache = was not updated.  I did a packet trace in the background and
>>> indeed no ICMP replies were seen.
= >>>
>>> I did the same ping x.x.x.255 o= n one of my client PCs and saw:
>>>
>>> Pinging x.x.x.255 with 32 bytes of data:
>>> Request ti= med out.
>>> Request timed out.
>>> Request timed out.
>>> Request ti= med out.
>>>
>>> But = this time the packet trace showed that actually ICMP replies were
>>> sent.
>>>
>>
>>>So, besides this cosmetic differe= nce the behavior is identical for the
>>>case of= IPv4 ping ?
>>
>> Andrew, = I think you may have misunderstand me.  The behavior is very
>> definitely not
>> identical in I= Pv4.  In IPv4, many people block or disable directed
>> broadcast PING.  Such
>
>>On the same subnet ? You wrote that the replies were indeed amplified
>&= gt;and sent, or did I misunderstand ?
>
> The replies on the same subnet appear to be blocked in one case an= d not
> blocked in another case.
>= ; So, one cannot make a blanket statement (at least based on two data
> points!).
>

>With the test I did within my home network, I saw amplifie= d replies on
>both, so one can not make a blanket stat= ement indeed and it depends on
>the OS and the setup.<= br clear=3D"none">
>
>> PINGs = can be used for amplification in Smurf attacks.
>><= br clear=3D"none">>> http://www.techrepublic.com/article/understanding-a-smur= f-attack-is-the-first-step-toward-thwarting-one/
>= >
>> Ping to FF02::1 is definitely amplification= when 10 echo requests can
>> create
>> 2,000+
>> echo replies.  When yo= u do a Ping on Linux, it is continuous until you
>>= stop
>> it.
>> So, you may= very easily do amplification without even meaning to.
&g= t;
>>This is all link-local. The reason Smurf is da= ngerous is that one can
>>send the request from acr= oss the internet. Here it's on the same
>>segment -= so it's a customer-provider relationship, and there are ton
>>of the existing operational mechanisms that can be used to take= care
>>of this if this is a concern - documenting them mig= ht be useful.
>>Saying that the hosts should not re= ply altogether - not; for the
>>reasons outlined in= the previous mail.
>
>>(Of co= urse this is just my experience, would be interesting to hear
>>others' opinions).
>
&g= t; As I said in another response, in IPv6 subnets, there may be many other<= br clear=3D"none">> nodes
> on link with you. = We were using the
>  Ping to FF02::1 as a graph= ic example of how
> it is possible to impact both your= self and other nodes without even meaning
> to.

>So you ping ff02::1 on a network with X = hosts, where X is large. So
>each of these X hosts has= to process 1 packet and generate 1 packet,
>you have to process X responses, = you populate ND cache on your hosts
>with X entries, e= ach of the X hosts populates their ND cache with your
>= ;address.

>Your host is quite obvio= usly impacted. But the others process a 1/X
>share of = the load compared to you, an equivalent to a regular 1 host
>exchange. So I don't see how they are impacted.

On Windows, I did = a :  ping ff02::1 -n 10

=
where the -n is the count.

So for each 1= ping request I send out, each of my neighbors sends me 10 responses.
=
So, I have made them do 10 times as much wor= k as me.  Also, since in this case, I
had about 200&nb= sp;neighbors, the link had a bunch of traf= fic on it (the ping requests 
and replies from everyone) = (as well as the neighbor discovery packets= ) which were 
in the way of anyone wanting to actual productive work.

>
> We discovere= d this by accident.  We were doing testing for another
> purpose and were quite surprised to see that both servers were see= ing all
> the
> multicast packets= and even more surprised when we did the PING to FF02::1.

>Nick has a good point this whole situation would benefi= t of some more
>debugging.

Such as what?  BTW, = I have sent Nick the trace & can send to you as well.

>
>>
>>
>>>= ;>Of course, private VLANs or (if we are talking VMs) or just using p2p<= br clear=3D"none">>>>>links with /128s would help this in the e= nvironments where the hosts
>>>>can not be tr= usted - and this of course is not virtual/physical
>&g= t;>>specific.
>>>
>&g= t;> Yes.  We wanted to bring up the topic of isolation of nodes for=
>>> discussion.
>>
>>>This is a useful topic in general - especially = in light of the
>>>MLD-related thread, but the d= raft seems to focus on a very corner case
>>>- t= here are many much better reasons not to do large L2 networks.
>>
>> We wanted to pick one specific in= stance.  Maybe we went TOO small!
>
> No, the more focused the doc is, the better.
&g= t;
>>
>>>
>>>>If we're talking specifically virtual environment, here= 's an approach
>>>>on how to use ebtables to = isolate the hosts:
>>>
>>= ;>>ebtables -P FORWARD DROP
>>>>ebtable= s -F FORWARD
>>>>ebtables -A FORWARD -i $upli= nkPort -j ACCEPT # let the traffic flow
>>>>from uplink to any port= s
>>>>ebtables -A FORWARD -o $uplinkPort -j A= CCEPT # let the traffic flow
>>>>from any por= ts to uplink
>>>
>>>&= gt;(source:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-is= olation-on-linux-bridges)
>>>
>>> I think this is very good.  But, unfortunately not ve= ry well known.
>>> Also,
>&= gt;> is this possible for all platforms or just Linux?
>>
>>>This was just my first google.com s= earch result when searching for
>>>"private vlan= s linux".
>>
>>>The first google.com= search result on "private vlans windows" brings
>>= >up
>>> http://blogs.technet.com/b/scvmm/archive/201= 3/06/04/logical-networks-part-iv-pvlan-isolation.aspx
>>>which seems to document similar technique.
&= gt;>
>>>"private vlan vmware" results in
>>>http://kb.vmware.com/selfservice/micro= sites/search.do?language=3Den_US&cmd=3DdisplayKC&externalId=3D10106= 91
>>>as its first hit.
&g= t;>
>>>Would an IETF publication be easier to find tha= n the above ?
>>
>> Maybe n= ot but the hosting company who provided us the service where we did
>> this real life test does not seem to have read any of t= he documents you
>> reference.
&g= t;
>>If you were not spoofing the source, then the = only DoS target was
>>yourself, and the inter-custo= mer resource isolation should take care
>>of the re= st. This is relates to "Oops I don't know what I'm doing"
>>part.
>
> Actually, not.=   In this case, there was no inter-customer resource
> isolation.  So, we were impacting everyone.  As I say, we = discovered
> this by accident.

>Again, it's obvious to see how you're impacting yourself but it's
>unclear to me how were you impacting the others.
<= br clear=3D"none">>I did a quick test in my lab, and the only node that = significantly
>grew the ND cache in my test was the on= e sending the ping. The rest
>just added only the send= er's address. Sure, the sender also triggered
>NUD on = the addresses, but again it is only the sender that was
&= gt;impacted - the rest had just 1 packet to handle, which is not much.

>Please help me understand where is the= problem ?

See above.  Also, I believe it is not a question of = the neighbor cache.
We just showed that= to prove that other nodes actually were responding.

Also, our topic actu= ally was a bit more broad.  We were not talking only
of the PING to FF02::1, but of multicast.   Multicast is seen by = all the 
neighbors and can be quit= e a bit of the link activity.   Again, getting in
the way of productive traffic.

We may be spending a bit t= oo much time focused solely on the Ping.
I stand by my statement that the Ping can be an amplification.  &nbs= p;
However, we used the example of the = Ping to show that if you have a 
num= ber of neighbors on link, as shown by the Ping, then they will see
all the multicast packets generated as well.

>
> I am thinking that the bigger question that we should addres= s is
> node isolation.  I think that people imple= menting IPv6 have got the
> /64 for subnet in their he= ads pretty well.  But, not the other part
> about= how multicast - and other packets impact nodes on link with you.
> And that they should do node isolation.
&g= t;
> What do you think?

>Give each vhost a routed /64 and use link-local next-hops - this= will
>give the same "broadcast profile" as for IPv4, = and reduce the hoster's
>resources needed to manage th= e allocated addresses, and still allows
to sell 65536 vho= sts, assuming the said hoster has only /48.

>Then on the = shared segment that carries the routed traffic,
>intra= -subnet apply the same security policy to the ff02::1 IPv6
>traffic as you do to IPv4 x.x.x.255 originated within and destined fo= r
>that subnet - private VLANs, p2p links, or nothing.=



I = think this focuses too narrowly on the Ping.    I need to think s= ome
more on how to talk= about isolation.


--a

&= gt;
>>Now, if you start to spoof your source and se= nd the traffic at high
>>rates, we're into the ToS = violation territory, and the hosting company
>>probably assumes a certain degre= e of good citizenship from its clients
>>towards ea= ch other.
>
>>If you were to t= ry this kind of link-local smurf, why not
>>try ste= aling other VM's IPv4 addresses and running MITM on them ? Or
>>try spoofing the default router ? Or try sweep-scanning their = entire
>>/64 from Internet at high rate ? Or get in= to legacy and try
>>ARP-flooding with broadcast ARP= requests/replies at line rate ?
>
&= gt;>There usually is a very simple mitigation to all of the above: first=
>>warn the hosting customer that is being naughty,= then terminate the
>>contract. I know for sure it = is being practiced.
>
> We discov= ered this by accident & were using the example of Ping FF02::1 to
> ill= ustrate what can happen.
>
>
>
> --a
>
>>
>> What to do is a good questi= on.  IPv6 implementation at end user sites is
>&g= t; new
>> to many & mistakes are being made.&nb= sp; I do not know what is the answer.
>>
>>>
>>>>So looks like the = question at hand is:
>>>
>&= gt;>>"Should IPv6 nodes respond to Ping to FF0x::1?"
>>>
>>>>Which can be rephrased dif= ferently to ease the start of the discussion:
>>>= ;
>>>>"What are the legitimate uses of a ping= to ff0x::1 ?"
>>>
>>>>Right ?
>>>
>>> Yes.
>>
>>>Allright, so I'll mention my u= se of ping6 ff0x::1:
>>
>>&= gt;* quick check to find "a few hosts that are alive on this link"
>>>(obviously not to be done on large segments).
>>
>>>* A way to trigger the re= mote side's ND process without having to do
>>>o= ne myself (I know the multicast packet to all-hosts *will* usually
>>>get received regardless of the underlying issues with= the L2.5
>>>infrastructure (snooping, etc.)
>>
>>>* A way to further de= bug malfunctioning L2.5 infra, by comparing the
>>&= gt;reaction to pings to ff02::1, solicited node multicast, other
>>>mul= ticast groups, etc.
>>
>>&g= t;Summary: the ff02::1 current ping behavior does help in a non-trivial
>>>amount of cases.
>>
>>>The security aspects the draft mentions indeed do= exist, but in a
>>>properly configured network = can be easily mitigated as I've shown
>>>above. = So I'd be against changing the functionality in the existing
>>>stacks.
>>
>&g= t; I don't know, Andrew.  I worry about the broadcast nature of the pi= ng.
>> I feel like it is trouble waiting to happen.=
>>
>>
&g= t;> --a
>>
>>>
>>> --a
>>>
>>>
>>> On 9/19/14, fred@cisco.com <= fred@cisco.com> wrote:
>>>> A new draf= t has been posted, at
>>>> http://tools.ietf.= org/html/draft-elkins-v6ops-multicast-virtual-nodes.
>= >>> Please take a look at it and comment.
>&g= t;>>
>>>> _____________________________= __________________
>>>> v6ops mailing list>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>
>= ;


---559651860-1474897163-1411185266=:51203-- From nobody Sat Sep 20 00:30:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE90C1A8932 for ; Sat, 20 Sep 2014 00:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShWiocvgp2eB for ; Sat, 20 Sep 2014 00:30:11 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CF51A8868 for ; Sat, 20 Sep 2014 00:30:11 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar1so1872203iec.25 for ; Sat, 20 Sep 2014 00:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hhUFKmP+YNOGaR5tLDX9HaV5fFBXTcvGHvYF00jMFl8=; b=MgIl1UBZIQHLwzBMBQKuW4vOktlxJJj6EawEUJ3iuytpnMoxwF8S887S8NM7k8540U 8pFiZrJk6hW504uzqAxMD2l0lNhcc2jcvBXX0y9bk+6RMGwHpNNwx+L6fEyxwynpMtfK ddNl18qhLlel/EPgzNwlkLt020Djw2N7WkQ13wQd3QIlwIaOM8sHvyIGK9NtAORTeKte SsI5j5rJKN5v0+g8t71ibz8gJObrIjsIkYWeiCj9RmS6uLaiVuL6Y49K/tlWNZ+kQ5/W epgvTqUV/LDa8LNDxGeGRgDHR6cSloMoH4GD79pEkErH5IT5Ob50D4Ck+mJFviHZ2WU5 mAgA== MIME-Version: 1.0 X-Received: by 10.50.41.104 with SMTP id e8mr1482344igl.35.1411198210863; Sat, 20 Sep 2014 00:30:10 -0700 (PDT) Received: by 10.107.137.65 with HTTP; Sat, 20 Sep 2014 00:30:10 -0700 (PDT) In-Reply-To: <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Sat, 20 Sep 2014 09:30:10 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Nalini Elkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7R3-tQD_92U-ISZsY6rWBGNhIAU Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Sep 2014 07:30:15 -0000 On 9/20/14, Nalini Elkins wrote: > > >> >>>> >>>>>A directed broadcast ping on IPv4 gives pretty much the same result. >>>>>Did you test the effects of that ? >>>> >>>> I had not. But, since you mentioned it, I did it on two different >>>> Windows >>>> machines. The one that is the server in question had the following >>>> results: >>>> >>>> C:\Users\Administrator>ping x.x.x.255 >>>> >>>> Pinging x.x.x.255 with 32 bytes of data: >>>> Request timed out. >>>> Request timed out. >>>> Request timed out. >>>> Request timed out. >>>> >>>> Ping statistics for x.x.x.255: >>>> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >>>> >>>> Arp cache was not updated. I did a packet trace in the background and >>>> indeed no ICMP replies were seen. >>>> >>>> I did the same ping x.x.x.255 on one of my client PCs and saw: >>>> >>>> Pinging x.x.x.255 with 32 bytes of data: >>>> Request timed out. >>>> Request timed out. >>>> Request timed out. >>>> Request timed out. >>>> >>>> But this time the packet trace showed that actually ICMP replies were >>>> sent. >>>> >>> >>>>So, besides this cosmetic difference the behavior is identical for the >>>>case of IPv4 ping ? >>> >>> Andrew, I think you may have misunderstand me. The behavior is very >>> definitely not >>> identical in IPv4. In IPv4, many people block or disable directed >>> broadcast PING. Such >> >>>On the same subnet ? You wrote that the replies were indeed amplified >>>and sent, or did I misunderstand ? >> >> The replies on the same subnet appear to be blocked in one case and not >> blocked in another case. >> So, one cannot make a blanket statement (at least based on two data >> points!). >> > >>With the test I did within my home network, I saw amplified replies on >>both, so one can not make a blanket statement indeed and it depends on >>the OS and the setup. > >> >>> PINGs can be used for amplification in Smurf attacks. >>> >>> http://www.techrepublic.com/article/understanding-a-smurf-attack-is-the-first-step-toward-thwarting-one/ >>> >>> Ping to FF02::1 is definitely amplification when 10 echo requests can >>> create >>> 2,000+ >>> echo replies. When you do a Ping on Linux, it is continuous until you >>> stop >>> it. >>> So, you may very easily do amplification without even meaning to. >> >>>This is all link-local. The reason Smurf is dangerous is that one can >>>send the request from across the internet. Here it's on the same >>>segment - so it's a customer-provider relationship, and there are ton >>>of the existing operational mechanisms that can be used to take care >>>of this if this is a concern - documenting them might be useful. >>>Saying that the hosts should not reply altogether - not; for the >>>reasons outlined in the previous mail. >> >>>(Of course this is just my experience, would be interesting to hear >>>others' opinions). >> >> As I said in another response, in IPv6 subnets, there may be many other >> nodes >> on link with you. We were using the >> Ping to FF02::1 as a graphic example of how >> it is possible to impact both yourself and other nodes without even >> meaning >> to. > >>So you ping ff02::1 on a network with X hosts, where X is large. So >>each of these X hosts has to process 1 packet and generate 1 packet, >>you have to process X responses, you populate ND cache on your hosts >>with X entries, each of the X hosts populates their ND cache with your >>address. > >>Your host is quite obviously impacted. But the others process a 1/X >>share of the load compared to you, an equivalent to a regular 1 host >>exchange. So I don't see how they are impacted. > > On Windows, I did a : ping ff02::1 -n 10 > > where the -n is the count. > > So for each 1 ping request I send out, each of my neighbors sends me 10 > responses. No, the "-n 10" means you send 10 requests, each of them triggers a response from each of the neighbors, at least according to Microsoft documentation at http://technet.microsoft.com/en-us/library/cc737478%28v=ws.10%29.aspx > So, I have made them do 10 times as much work as me. No, you did not. You made them do the same amount of work as you did sending the packets - you sent 10 requests, they sent 10 replies. > Also, since in this > case, I > had about 200 neighbors, the link had a bunch of traffic on it (the ping > requests > and replies from everyone) (as well as the neighbor discovery packets) which > were > in the way of anyone wanting to actual productive work. ICMP echo requests in the syntax you described are sent ~1 per second, so the replies is about 200 per second. It's a very small amount of traffic. > >> >> We discovered this by accident. We were doing testing for another >> purpose and were quite surprised to see that both servers were seeing all >> the >> multicast packets and even more surprised when we did the PING to FF02::1. > >>Nick has a good point this whole situation would benefit of some more >>debugging. > > Such as what? BTW, I have sent Nick the trace & can send to you as well. Sure, feel free to send it. > >> >>> >>> >>>>>Of course, private VLANs or (if we are talking VMs) or just using p2p >>>>>links with /128s would help this in the environments where the hosts >>>>>can not be trusted - and this of course is not virtual/physical >>>>>specific. >>>> >>>> Yes. We wanted to bring up the topic of isolation of nodes for >>>> discussion. >>> >>>>This is a useful topic in general - especially in light of the >>>>MLD-related thread, but the draft seems to focus on a very corner case >>>>- there are many much better reasons not to do large L2 networks. >>> >>> We wanted to pick one specific instance. Maybe we went TOO small! >> >> No, the more focused the doc is, the better. >> >>> >>>> >>>>>If we're talking specifically virtual environment, here's an approach >>>>>on how to use ebtables to isolate the hosts: >>>> >>>>>ebtables -P FORWARD DROP >>>>>ebtables -F FORWARD >>>>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow >>>>>from uplink to any ports >>>>>ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic flow >>>>>from any ports to uplink >>>> >>>>>(source:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-linux-bridges) >>>> >>>> I think this is very good. But, unfortunately not very well known. >>>> Also, >>>> is this possible for all platforms or just Linux? >>> >>>>This was just my first google.com search result when searching for >>>>"private vlans linux". >>> >>>>The first google.com search result on "private vlans windows" brings >>>>up >>>> http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx >>>>which seems to document similar technique. >>> >>>>"private vlan vmware" results in >>>>http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691 >>>>as its first hit. >>> >>>>Would an IETF publication be easier to find than the above ? >>> >>> Maybe not but the hosting company who provided us the service where we >>> did >>> this real life test does not seem to have read any of the documents you >>> reference. >> >>>If you were not spoofing the source, then the only DoS target was >>>yourself, and the inter-customer resource isolation should take care >>>of the rest. This is relates to "Oops I don't know what I'm doing" >>>part. >> >> Actually, not. In this case, there was no inter-customer resource >> isolation. So, we were impacting everyone. As I say, we discovered >> this by accident. > >>Again, it's obvious to see how you're impacting yourself but it's >>unclear to me how were you impacting the others. > >>I did a quick test in my lab, and the only node that significantly >>grew the ND cache in my test was the one sending the ping. The rest >>just added only the sender's address. Sure, the sender also triggered >>NUD on the addresses, but again it is only the sender that was >>impacted - the rest had just 1 packet to handle, which is not much. > >>Please help me understand where is the problem ? > > See above. > Also, I believe it is not a question of the neighbor cache. > We just showed that to prove that other nodes actually were responding. > > Also, our topic actually was a bit more broad. We were not talking only > of the PING to FF02::1, but of multicast. Multicast is seen by all the > neighbors and can be quite a bit of the link activity. Again, getting in > the way of productive traffic. > > We may be spending a bit too much time focused solely on the Ping. > I stand by my statement that the Ping can be an amplification. > However, we used the example of the Ping to show that if you have a > number of neighbors on link, as shown by the Ping, then they will see > all the multicast packets generated as well. The address is named all-hosts multicast, so it is logical for the hosts to see it and react. > >> >> I am thinking that the bigger question that we should address is >> node isolation. I think that people implementing IPv6 have got the >> /64 for subnet in their heads pretty well. But, not the other part >> about how multicast - and other packets impact nodes on link with you. >> And that they should do node isolation. >> >> What do you think? > >>Give each vhost a routed /64 and use link-local next-hops - this will >>give the same "broadcast profile" as for IPv4, and reduce the hoster's >>resources needed to manage the allocated addresses, and still allows > to sell 65536 vhosts, assuming the said hoster has only /48. > >>Then on the shared segment that carries the routed traffic, >>intra-subnet apply the same security policy to the ff02::1 IPv6 >>traffic as you do to IPv4 x.x.x.255 originated within and destined for >>that subnet - private VLANs, p2p links, or nothing. > > > > I think this focuses too narrowly on the Ping. I need to think some > more on how to talk about isolation. Subnets is the industry-standard way of isolating the broadcast domains. --a > > > --a > >> >>>Now, if you start to spoof your source and send the traffic at high >>>rates, we're into the ToS violation territory, and the hosting company >>>probably assumes a certain degree of good citizenship from its clients >>>towards each other. >> >>>If you were to try this kind of link-local smurf, why not >>>try stealing other VM's IPv4 addresses and running MITM on them ? Or >>>try spoofing the default router ? Or try sweep-scanning their entire >>>/64 from Internet at high rate ? Or get into legacy and try >>>ARP-flooding with broadcast ARP requests/replies at line rate ? >> >>>There usually is a very simple mitigation to all of the above: first >>>warn the hosting customer that is being naughty, then terminate the >>>contract. I know for sure it is being practiced. >> >> We discovered this by accident & were using the example of Ping FF02::1 to >> illustrate what can happen. >> >> >> >> --a >> >>> >>> What to do is a good question. IPv6 implementation at end user sites is >>> new >>> to many & mistakes are being made. I do not know what is the answer. >>> >>>> >>>>>So looks like the question at hand is: >>>> >>>>>"Should IPv6 nodes respond to Ping to FF0x::1?" >>>> >>>>>Which can be rephrased differently to ease the start of the discussion: >>>> >>>>>"What are the legitimate uses of a ping to ff0x::1 ?" >>>> >>>>>Right ? >>>> >>>> Yes. >>> >>>>Allright, so I'll mention my use of ping6 ff0x::1: >>> >>>>* quick check to find "a few hosts that are alive on this link" >>>>(obviously not to be done on large segments). >>> >>>>* A way to trigger the remote side's ND process without having to do >>>>one myself (I know the multicast packet to all-hosts *will* usually >>>>get received regardless of the underlying issues with the L2.5 >>>>infrastructure (snooping, etc.) >>> >>>>* A way to further debug malfunctioning L2.5 infra, by comparing the >>>>reaction to pings to ff02::1, solicited node multicast, other >>>>multicast groups, etc. >>> >>>>Summary: the ff02::1 current ping behavior does help in a non-trivial >>>>amount of cases. >>> >>>>The security aspects the draft mentions indeed do exist, but in a >>>>properly configured network can be easily mitigated as I've shown >>>>above. So I'd be against changing the functionality in the existing >>>>stacks. >>> >>> I don't know, Andrew. I worry about the broadcast nature of the ping. >>> I feel like it is trouble waiting to happen. >>> >>> >>> --a >>> >>>> >>>> --a >>>> >>>> >>>> On 9/19/14, fred@cisco.com wrote: >>>>> A new draft has been posted, at >>>>> http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. >>>>> Please take a look at it and comment. >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>> >> From nobody Sat Sep 20 02:16:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5A1A03A9 for ; Sat, 20 Sep 2014 02:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 t6RNu8i4BkWZ for ; Sat, 20 Sep 2014 02:16:50 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875A51A00DF for ; Sat, 20 Sep 2014 02:16:50 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s8K9GCP4012683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 10:16:37 +0100 (IST) (envelope-from nick@foobar.org) Message-ID: <541D45DB.5010703@foobar.org> Date: Sat, 20 Sep 2014 10:16:11 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Nalini Elkins , =?UTF-8?B?QW5kcmV3IA==?= =?UTF-8?B?8J+RvSBZb3VydGNoZW5rbw==?= References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> In-Reply-To: <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A1-k56bbXu-WJODf3AArMwqs4jU Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Sep 2014 09:16:52 -0000 On 20/09/2014 04:54, Nalini Elkins wrote: > On Windows, I did a : ping ff02::1 -n 10 > > where the -n is the count. > > So for each 1 ping request I send out, each of my neighbors sends me 10 > responses. The "-n" parameter specifies how many icmp echo requests are sent out, not how many replies are solicited. > Such as what? BTW, I have sent Nick the trace & can send to you as well. The pcap file shows 10 icmp echo requests and 2840 echo replies, and that the echo replies used 284 unique link-local ipv6 addresses associated with 284 unique MAC addresses. This looks both correct and consistent with the figures in the draft. The lesson is that if you have a lot of ipv6 hosts on the same broadcast domain, you will get lots of echo replies from a ping to ff02::1. Nalini, if you feel that there is an issue here, you should talk to your hosting provider and suggest that they don't put as many ipv6 hosts on the same broadcast domain. This isn't a protocol level problem: it's expected and correct behaviour. Nick From nobody Sat Sep 20 07:15:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9AC1A0275 for ; Sat, 20 Sep 2014 07:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 jgM9XMv0czKU for ; Sat, 20 Sep 2014 07:15:51 -0700 (PDT) Received: from nm18-vm4.bullet.mail.ne1.yahoo.com (nm18-vm4.bullet.mail.ne1.yahoo.com [98.138.91.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12C81A00B8 for ; Sat, 20 Sep 2014 07:15:50 -0700 (PDT) Received: from [98.138.100.103] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 14:15:48 -0000 Received: from [98.138.89.167] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 14:15:48 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 14:15:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 673733.32517.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 24000 invoked by uid 60001); 20 Sep 2014 14:15:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411222548; bh=3+9spr1WfpgCKHQn+5yvqsyV7o2815Bg1JcHXiiw+l8=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xvkWoeFgMRnbc1By+0QbVkL1vX+n8YdAkZxcyJkshiv7oc1v5/eQu4fop46YmlO3sxcSsgfOeF0BxBNGpdOM0OWRlFY1tP8CIF9W7HdUNOoIDOetIAdn3SHqmQfeSpMvQ1QXUSCApVjaRH+wC5bT1QnX//7FJJiGeYTwPg8uu5Q= X-YMail-OSG: Q2sOg9QVM1nmDppEeuXZJnhq9u7feA1nvB8ehh.Ri2Pz5kB Ja7vVFzIB5K4Tp2HIZVqakwyqFkCYuTxAisxBgKSg4wvbjAWIVR61BmN3PQP TlVS_9V10EqQ1zeBe818XYOwflN6xZrBTL2ClGbE.O2h2JqBF9_imZ4NC.nB QvRDhl8eTq.ZYoaNkYdv7OB0amD1x9T98Iy78QgGpZJUgsYzx8UPeVatgkeN 0B5vhbxN2MjwNOKjktN2R6tyQxnCqsTiLv0B4dW7zMIp_pRRTUDyRMJJHd6K SEKEu7VhrRVHp2.jTP9bFltt5xf0h0BsqZYGzUdw_9OO3itC7Hap6AUEXI3H CNyumurc0HFg6rr.2rsexhj65WBYsAwtXPJUza8kIglMBazp3Fw7SAB1rr_M Qr6tU4YV.kpZUuEAyoH2K3ptJ3hVd21lG0pmjv1mSqo0WtTw0mabl_abzQVo BK7xinB7wpop23IiFRvb2cZuFhEcRrfNcSbH.K4uv16D3lpV1WwvTnTJFI0h C_ZXUNQma4dIJtWe10oUW9YGeFgGaWZ_auaYWxsK7zhJN8uye Received: from [24.130.244.175] by web125105.mail.ne1.yahoo.com via HTTP; Sat, 20 Sep 2014 07:15:48 PDT X-Rocket-MIMEInfo: 002.001, CgpPbiAyMC8wOS8yMDE0IDA0OjU0LCBOYWxpbmkgRWxraW5zIHdyb3RlOgo.IE9uIFdpbmRvd3MsIEkgZGlkIGEgOiAgcGluZyBmZjAyOjoxIC1uIDEwCj4KPiB3aGVyZSB0aGUgLW4gaXMgdGhlIGNvdW50Lgo.Cj4gU28gZm9yIGVhY2ggMSBwaW5nIHJlcXVlc3QgSSBzZW5kIG91dCwgZWFjaCBvZiBteSBuZWlnaGJvcnMgc2VuZHMgbWUgMTAKPiByZXNwb25zZXMuCgpUaGUgIi1uIiBwYXJhbWV0ZXIgc3BlY2lmaWVzIGhvdyBtYW55IGljbXAgZWNobyByZXF1ZXN0cyBhcmUgc2VudCBvdXQsIG5vdCAKaG93IG0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> Message-ID: <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> Date: Sat, 20 Sep 2014 07:15:48 -0700 From: Nalini Elkins To: Nick Hilliard , =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= In-Reply-To: <541D45DB.5010703@foobar.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="461871616-406499951-1411222548=:10128" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b5-7lQLSQIZM8kZt6Tat2M_h15g Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:15:53 -0000 --461871616-406499951-1411222548=:10128 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AOn 20/09/2014 04:54, Nalini Elkins wrote:=0A> On Windows, I did a : = ping ff02::1 -n 10=0A>=0A> where the -n is the count.=0A>=0A> So for each 1= ping request I send out, each of my neighbors sends me 10=0A> responses.= =0A=0AThe "-n" parameter specifies how many icmp echo requests are sent out= , not =0Ahow many replies are solicited.=0A=0A> Such as what? BTW, I have = sent Nick the trace & can send to you as well.=0A=0A>The pcap file shows 10= icmp echo requests and 2840 echo replies, and that =0A>the echo replies us= ed 284 unique link-local ipv6 addresses associated with =0A>284 unique MAC = addresses. This looks both correct and consistent with the =0A>figures in = the draft. The lesson is that if you have a lot of ipv6 hosts =0A>on the s= ame broadcast domain, you will get lots of echo replies from a ping =0A>to = ff02::1.=0A=0AThis is the point we were trying to make. But, we were using= Ping to illustrate=0Athat much layer 2 communication will occur - such as = multicast.=0A=0AAlso, I was wrong in my explanation of multicast ping ampli= fication. How it=0Aworks is this:=0A=0ASituation: node A is on a subnet = with 25 other nodes (B-Z)=0A=0A1. Node A sends 10 ICMP ping requests to FF= 02::1=0A2. Nodes B through Z send Node A back ICMP 10 ping replies each=0A= =0AImpact: with very little work by Node A, he has made B - Z do work &=0Ac= reated network congestion with 250+ packets.=0A=0A>Nalini, if you feel that= there is an issue here, you should talk to your =0A=0A>hosting provider an= d suggest that they don't put as many ipv6 hosts on the =0A>same broadcast = domain. This isn't a protocol level problem: it's expected =0A>and correct= behaviour.=0A=0AI think people will be quite surprised at this behavior. = We think that the=0Aissues of how many hosts are on a broadcast domain and= node isolation=0Ashould be addressed. We will add this to our draft.=0A= =0A=0A=0A=0ABecause It is not just ICMP but all link local and multicast co= mmunication. I tell =0Ayou, I do not think that people are not considering= this in their network design. =0AWe are using the hosting company as an e= xample of what really is happening in =0Athe wild.=0A=0ANick --461871616-406499951-1411222548=:10128 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 20/09/2014 04:54, Nalini Elkins wrote:
> = On Windows, I did a :  ping ff02::1 -n 10
>
> where the -n is the count.
>
> So for each 1 ping request I send out, each of my neighbors= sends me 10
> responses.

The "-n" parameter specifies how many icmp echo requests are sent= out, not
how many replies are solicited.

> Such as what?  BTW, I have sent Nick the trace &a= mp; can send to you as well.

>The p= cap file shows 10 icmp echo requests and 2840 echo replies, and that
>the echo replies used 284 unique link-local ipv6 addresses= associated with
>284 unique MAC addresses.  Thi= s looks both correct and consistent with the
>figures= in the draft.  The lesson is that if you have a lot of ipv6 hosts >on the same broadcast domain, you will get lots of echo= replies from a ping
>to ff02::1.

This is the point= we were trying to make.  But, we were using Ping to illustrate
<= div class=3D"y_msg_container">that much layer 2 communication will occur - = such as multicast.

Also, I was wrong in my explanation of multicast= ping amplification.   How it
work= s is this:

Situation:  node A is on a subnet with 25 other nodes (B-= Z)

1.  Node A sends 10 ICMP ping requests to FF02::1
2.  Nodes B through Z send Node A back ICMP 10 pi= ng replies each

Impact: with very little work by Node A, he has made B - = Z do work &
created network congestion with 250+ packets.

>Nalini, if you feel that there is an issue here,= you should talk to your 
>hosting prov= ider and suggest that they don't put as many ipv6 hosts on the
>same broadcast domain.  This isn't a protocol level problem= : it's expected
>and correct behaviour.

I think peo= ple will be quite surprised at this behavior.   We think that the
issues of how many hosts are on a broadcast= domain and node isolation
should be ad= dressed.   We will add this to our draft.



Because It = is not just ICMP but all link local and multicast communication.  I te= ll 
you, I do not = think that people are not considering this in their network design.  
We are using the hosting company as an example of what really is happening in&nbs= p;
the wild.

Nick



--461871616-406499951-1411222548=:10128-- From nobody Sat Sep 20 07:22:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C6C1A026E for ; Sat, 20 Sep 2014 07:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31] 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 uZWVBhQCUctw for ; Sat, 20 Sep 2014 07:22:39 -0700 (PDT) Received: from nm13-vm4.bullet.mail.ne1.yahoo.com (nm13-vm4.bullet.mail.ne1.yahoo.com [98.138.91.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1605B1A0181 for ; Sat, 20 Sep 2014 07:22:39 -0700 (PDT) Received: from [98.138.100.116] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 14:22:38 -0000 Received: from [98.138.88.235] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 14:22:38 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 14:22:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 396967.26669.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 61100 invoked by uid 60001); 20 Sep 2014 14:22:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411222958; bh=Y6CaLpkoxlfCmXdtI5TdC05zAOFjvS8eM7v0DzUoDNk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TxmDoIXpQcilSVQauUj0fVqdbUSKZJ3YfNSXDpgk/8zwzV5b7HL0XXKhWDihYswYN3ibRg8ukOeXezjEePfLoOV3dTmFYmr+j5p5LwgpHxTE9+UH5BnkCjMpGX9C5cEPDIUa0OSDQbE3FNtI6DaZUaCbT0CeHnVeBIXGNUqUguQ= X-YMail-OSG: szxO1EQVM1mT4V603YrKrfltRJXBLBt1bO8oJRTs_WD99X6 yXn8geHShwGmSWN_zN5GRZlQUDyoy5hMp18I7KqMzvyQryZ_e6ofy30gyFy5 t10Q.cSkjju7ZV9d015trNk5P_RRyAmgF8gBy9pw6N6yrZDsRNzhIT1YBBxR EURJ1Xrq3ZEyqzCSOQxox6KbLhlaRgsO.iz2KGXzXsFjtHViIA0hiJHdl0RH VOsu02j_IFisKClLUQjiD_4kGAULRiMInjbjaTG1YCjYjlF8nqaUvl67PDsy pDK.zAk.Ov8U2w1WyoScea_b1_pipZWRWWlsTXsDuttYlKmsZs5X2rL9Y8_B DBHSX4OgGNh9UpFhxxvLXT..RiAAhUVPvzKOrwNXukjDqsOB76bWoblm9GMC TKi_sIFFd9Y_YK.HACz0DJnJOYFszkwYUJ84FREGHMndtb_4HNV38WLLPtpd yyG0ptaxjbC2wSgMWPCVspg1R6Cq08bBsEMFtyMGY9jAO3k4_duyvS7kWSce uJpJTX8SsvG1IcA2jAIqpKX3Ij27cJZFn4ZOMZ5vY8CHd6FLjvi2Snou2MDE lo.EN2lg6kdBjjJxg5b.B617Fwoh9PMGmfc_Fg2UjSlK1gNr.BoAoBeHFkYf 9UY20CVr977nO.osZxEA.ROuENpq6fZp4ZxQLpIW1Gk6tdjqYEhxZZGsb_w1 tapp7Vmpn7SG2I88VNwewxo1SRGi6w5C2ZonKV3R0ZTbiEe6E1GBhSdaCt9Z aXwfbRa3wZqwsB6s3n3o3Fxll4NalxHlaZ8gXC.lSL7YxCa.HrqmxQ7QVhH9 ZLUCsjLdTHy4QOzu4lMh_OjFhQLFX6XeC3.1V14mul9_4s.kRhyLRC.nkf_o hE1n3tPSPVZAMYIvTIbotqp8c7hN1kSDFbxLjMy7pXfL3Lrt.Vv9GEVJ11pm mef_gFtc5kxsZqa_JnlMGE21c81N1npjI0HJ41_LYSZ46N07SA2nWWLwZP6S oZYvBbslYoXdkMaPCxADa1xjjIXwCfILyCn7uJND5VFnvATVXqg3udb0BMmc n9p.kGyS0iBlXcKCg4qXX6m2YkU6.Aya.KZIAdqc6R1dOmUMeXVUJ9b9xRFB .QOJTXXBFoux3kPQ21Kl2TcSRNU4W.DuhpJE4_mH9jY6o94FJro_Cv0CMSl7 93BOxjlYFGCP2Op6dGhuDTFd.8Qu5yW22zctAW6fXIW5jj0qB55YqNx.za4d 0hK9POFmqe1TFNF3TBa_8F57Ys46vGdn4MMwj.lGpnScXxRFmDzPacMywPS_ NnbZSdCWpvrX_of37qWqrboeHDUZSeRkId0fL_SA6NmbuUdcMoaWF1m7yfPv y1s4PQg-- Received: from [24.130.244.175] by web125102.mail.ne1.yahoo.com via HTTP; Sat, 20 Sep 2014 07:22:38 PDT X-Rocket-MIMEInfo: 002.001, CgpPbiA5LzIwLzE0LCBOYWxpbmkgRWxraW5zIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4gd3JvdGU6Cj4KPgo.Pgo.Pj4.Cj4.Pj4.QSBkaXJlY3RlZCBicm9hZGNhc3QgcGluZyBvbiBJUHY0IGdpdmVzIHByZXR0eSBtdWNoIHRoZSBzYW1lIHJlc3VsdC4KPj4.Pj5EaWQgeW91IHRlc3QgdGhlIGVmZmVjdHMgb2YgdGhhdCA_Cj4.Pj4KPj4.PiBJIGhhZCBub3QuICBCdXQsIHNpbmNlIHlvdSBtZW50aW9uZWQgaXQsIEkgZGlkIGl0IG9uIHR3byBkaWZmZXJlbnQKPj4.PiBXaW5kb3dzCj4.Pj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> Message-ID: <1411222958.28642.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Sat, 20 Sep 2014 07:22:38 -0700 From: Nalini Elkins To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-559651860-2015326298-1411222958=:28642" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A-PK1u5_KRPHM9p4bmGSL6lA1ew Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:22:44 -0000 ---559651860-2015326298-1411222958=:28642 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AOn 9/20/14, Nalini Elkins wrote:= =0A>=0A>=0A>>=0A>>>>=0A>>>>>A directed broadcast ping on IPv4 gives pretty = much the same result.=0A>>>>>Did you test the effects of that ?=0A>>>>=0A>>= >> I had not. But, since you mentioned it, I did it on two different=0A>>>= > Windows=0A>>>> machines. The one that is the server in question had the = following=0A>>>> results:=0A>>>>=0A>>>> C:\Users\Administrator>ping x.x.x.2= 55=0A>>>>=0A>>>> Pinging x.x.x.255 with 32 bytes of data:=0A>>>> Request ti= med out.=0A>>>> Request timed out.=0A>>>> Request timed out.=0A>>>> Request= timed out.=0A>>>>=0A>>>> Ping statistics for x.x.x.255:=0A>>>> Packets= : Sent =3D 4, Received =3D 0, Lost =3D 4 (100% loss),=0A>>>>=0A>>>> Arp cac= he was not updated. I did a packet trace in the background and=0A>>>> ind= eed no ICMP replies were seen.=0A>>>>=0A>>>> I did the same ping x.x.x.255 = on one of my client PCs and saw:=0A>>>>=0A>>>> Pinging x.x.x.255 with 32 by= tes of data:=0A>>>> Request timed out.=0A>>>> Request timed out.=0A>>>> Req= uest timed out.=0A>>>> Request timed out.=0A>>>>=0A>>>> But this time the p= acket trace showed that actually ICMP replies were=0A>>>> sent.=0A>>>>=0A>>= >=0A>>>>So, besides this cosmetic difference the behavior is identical for = the=0A>>>>case of IPv4 ping ?=0A>>>=0A>>> Andrew, I think you may have misu= nderstand me. The behavior is very=0A>>> definitely not=0A>>> identical in= IPv4. In IPv4, many people block or disable directed=0A>>> broadcast PIN= G. Such=0A>>=0A>>>On the same subnet ? You wrote that the replies were ind= eed amplified=0A>>>and sent, or did I misunderstand ?=0A>>=0A>> The replies= on the same subnet appear to be blocked in one case and not=0A>> blocked i= n another case.=0A>> So, one cannot make a blanket statement (at least base= d on two data=0A>> points!).=0A>>=0A>=0A>>With the test I did within my hom= e network, I saw amplified replies on=0A>>both, so one can not make a blank= et statement indeed and it depends on=0A>>the OS and the setup.=0A>=0A>>=0A= >>> PINGs can be used for amplification in Smurf attacks.=0A>>>=0A>>> http:= //www.techrepublic.com/article/understanding-a-smurf-attack-is-the-first-st= ep-toward-thwarting-one/=0A>>>=0A>>> Ping to FF02::1 is definitely amplific= ation when 10 echo requests can=0A>>> create=0A>>> 2,000+=0A>>> echo replie= s. When you do a Ping on Linux, it is continuous until you=0A>>> stop=0A>= >> it.=0A>>> So, you may very easily do amplification without even meaning = to.=0A>>=0A>>>This is all link-local. The reason Smurf is dangerous is that= one can=0A>>>send the request from across the internet. Here it's on the s= ame=0A>>>segment - so it's a customer-provider relationship, and there are = ton=0A>>>of the existing operational mechanisms that can be used to take ca= re=0A>>>of this if this is a concern - documenting them might be useful.=0A= >>>Saying that the hosts should not reply altogether - not; for the=0A>>>re= asons outlined in the previous mail.=0A>>=0A>>>(Of course this is just my e= xperience, would be interesting to hear=0A>>>others' opinions).=0A>>=0A>> A= s I said in another response, in IPv6 subnets, there may be many other=0A>>= nodes=0A>> on link with you. We were using the=0A>> Ping to FF02::1 as = a graphic example of how=0A>> it is possible to impact both yourself and ot= her nodes without even=0A>> meaning=0A>> to.=0A>=0A>>So you ping ff02::1 on= a network with X hosts, where X is large. So=0A>>each of these X hosts has= to process 1 packet and generate 1 packet,=0A>>you have to process X respo= nses, you populate ND cache on your hosts=0A>>with X entries, each of the X= hosts populates their ND cache with your=0A>>address.=0A>=0A>>Your host is= quite obviously impacted. But the others process a 1/X=0A>>share of the lo= ad compared to you, an equivalent to a regular 1 host=0A>>exchange. So I do= n't see how they are impacted.=0A>=0A> On Windows, I did a : ping ff02::1 = -n 10=0A>=0A> where the -n is the count.=0A>=0A> So for each 1 ping request= I send out, each of my neighbors sends me 10=0A> responses.=0A=0ANo, the "= -n 10" means you send 10 requests, each of them triggers a=0Aresponse from = each of the neighbors, at least according to Microsoft=0Adocumentation at= =0Ahttp://technet.microsoft.com/en-us/library/cc737478%28v=3Dws.10%29.aspx= =0A=0A> So, I have made them do 10 times as much work as me.=0A=0A>No, you = did not. You made them do the same amount of work as you did=0A>sending the= packets - you sent 10 requests, they sent 10 replies.=0A=0AYou are correct= . I was wrong in my explanation of multicast ping amplification. =0AHow I b= elieve it works is this:=0A=0ASituation: node A is on a subnet with 25 oth= er nodes (B-Z)=0A=0A1. Node A sends 10 ICMP ping requests to FF02::1=0A2. = Nodes B through Z send Node A back ICMP 10 ping replies each=0A=0AImpact: = with very little work by Node A, he has made B - Z do work &=0Acreated netw= ork congestion with 250+ packets.=0A=0A=0A> Also, since in this=0A> case, I= =0A> had about 200 neighbors, the link had a bunch of traffic on it (the pi= ng=0A> requests=0A> and replies from everyone) (as well as the neighbor dis= covery packets) which=0A> were=0A> in the way of anyone wanting to actual p= roductive work.=0A=0A>ICMP echo requests in the syntax you described are se= nt ~1 per second,=0A>so the replies is about 200 per second. It's a very sm= all amount of=0A>traffic.=0A=0AIn this case. The surprise (at least to us)= was that it happens at all. Also,=0Ait highlighted the point of node isol= ation - that one node can impact others=0Aand the network with both link-lo= cal and multicast traffic.=0A=0ABTW, this is also a security issue.=0A=0A>= =0A>>=0A>> We discovered this by accident. We were doing testing for anot= her=0A>> purpose and were quite surprised to see that both servers were see= ing all=0A>> the=0A>> multicast packets and even more surprised when we did= the PING to FF02::1.=0A>=0A>>Nick has a good point this whole situation wo= uld benefit of some more=0A>>debugging.=0A>=0A> Such as what? BTW, I have = sent Nick the trace & can send to you as well.=0A=0A>Sure, feel free to sen= d it.=0A=0ADoing so privately.=0A=0A>=0A>>=0A>>>=0A>>>=0A>>>>>Of course, pr= ivate VLANs or (if we are talking VMs) or just using p2p=0A>>>>>links with = /128s would help this in the environments where the hosts=0A>>>>>can not be= trusted - and this of course is not virtual/physical=0A>>>>>specific.=0A>>= >>=0A>>>> Yes. We wanted to bring up the topic of isolation of nodes for= =0A>>>> discussion.=0A>>>=0A>>>>This is a useful topic in general - especia= lly in light of the=0A>>>>MLD-related thread, but the draft seems to focus = on a very corner case=0A>>>>- there are many much better reasons not to do = large L2 networks.=0A>>>=0A>>> We wanted to pick one specific instance. Ma= ybe we went TOO small!=0A>>=0A>> No, the more focused the doc is, the bette= r.=0A>>=0A>>>=0A>>>>=0A>>>>>If we're talking specifically virtual environme= nt, here's an approach=0A>>>>>on how to use ebtables to isolate the hosts:= =0A>>>>=0A>>>>>ebtables -P FORWARD DROP=0A>>>>>ebtables -F FORWARD=0A>>>>>e= btables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow=0A>>>>>f= rom uplink to any ports=0A>>>>>ebtables -A FORWARD -o $uplinkPort -j ACCEPT= # let the traffic flow=0A>>>>>from any ports to uplink=0A>>>>=0A>>>>>(sour= ce:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-is= olation-on-linux-bridges)=0A>>>>=0A>>>> I think this is very good. But, un= fortunately not very well known.=0A>>>> Also,=0A>>>> is this possible for a= ll platforms or just Linux?=0A>>>=0A>>>>This was just my first google.com s= earch result when searching for=0A>>>>"private vlans linux".=0A>>>=0A>>>>Th= e first google.com search result on "private vlans windows" brings=0A>>>>up= =0A>>>> http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-network= s-part-iv-pvlan-isolation.aspx=0A>>>>which seems to document similar techni= que.=0A>>>=0A>>>>"private vlan vmware" results in=0A>>>>http://kb.vmware.co= m/selfservice/microsites/search.do?language=3Den_US&cmd=3DdisplayKC&externa= lId=3D1010691=0A>>>>as its first hit.=0A>>>=0A>>>>Would an IETF publication= be easier to find than the above ?=0A>>>=0A>>> Maybe not but the hosting c= ompany who provided us the service where we=0A>>> did=0A>>> this real life = test does not seem to have read any of the documents you=0A>>> reference.= =0A>>=0A>>>If you were not spoofing the source, then the only DoS target wa= s=0A>>>yourself, and the inter-customer resource isolation should take care= =0A>>>of the rest. This is relates to "Oops I don't know what I'm doing"=0A= >>>part.=0A>>=0A>> Actually, not. In this case, there was no inter-custome= r resource=0A>> isolation. So, we were impacting everyone. As I say, we = discovered=0A>> this by accident.=0A>=0A>>Again, it's obvious to see how yo= u're impacting yourself but it's=0A>>unclear to me how were you impacting t= he others.=0A>=0A>>I did a quick test in my lab, and the only node that sig= nificantly=0A>>grew the ND cache in my test was the one sending the ping. T= he rest=0A>>just added only the sender's address. Sure, the sender also tri= ggered=0A>>NUD on the addresses, but again it is only the sender that was= =0A>>impacted - the rest had just 1 packet to handle, which is not much.=0A= >=0A>>Please help me understand where is the problem ?=0A>=0A> See above.= =0A> Also, I believe it is not a question of the neighbor cache.=0A> We jus= t showed that to prove that other nodes actually were responding.=0A>=0A> A= lso, our topic actually was a bit more broad. We were not talking only=0A>= of the PING to FF02::1, but of multicast. Multicast is seen by all the= =0A> neighbors and can be quite a bit of the link activity. Again, gettin= g in=0A> the way of productive traffic.=0A>=0A> We may be spending a bit to= o much time focused solely on the Ping.=0A> I stand by my statement that th= e Ping can be an amplification.=0A> However, we used the example of the Pin= g to show that if you have a=0A> number of neighbors on link, as shown by t= he Ping, then they will see=0A> all the multicast packets generated as well= .=0A=0A>The address is named all-hosts multicast, so it is logical for the= =0A>hosts to see it and react.=0A=0A>=0A>>=0A>> I am thinking that the bigg= er question that we should address is=0A>> node isolation. I think that pe= ople implementing IPv6 have got the=0A>> /64 for subnet in their heads pret= ty well. But, not the other part=0A>> about how multicast - and other pack= ets impact nodes on link with you.=0A>> And that they should do node isolat= ion.=0A>>=0A>> What do you think?=0A>=0A>>Give each vhost a routed /64 and = use link-local next-hops - this will=0A>>give the same "broadcast profile" = as for IPv4, and reduce the hoster's=0A>>resources needed to manage the all= ocated addresses, and still allows=0A> to sell 65536 vhosts, assuming the s= aid hoster has only /48.=0A>=0A>>Then on the shared segment that carries th= e routed traffic,=0A>>intra-subnet apply the same security policy to the ff= 02::1 IPv6=0A>>traffic as you do to IPv4 x.x.x.255 originated within and de= stined for=0A>>that subnet - private VLANs, p2p links, or nothing.=0A>=0A>= =0A>=0A> I think this focuses too narrowly on the Ping. I need to think = some=0A> more on how to talk about isolation.=0A=0A>Subnets is the industry= -standard way of isolating the broadcast domains.=0A=0AThen, IMHO, there ne= eds to be a "Best Practices" document for how to create=0Asubnets. I am no= t of the opinion that creating a subnet that spans multiple=0Avirtual machi= nes, which could really expect to have separation from each=0Aother, is a g= reat practice.=0A=0AI believe that in the wild, /64 appears to be the stand= ard for a subnet no matter=0Awhat the circumstances are.=0A=0A=0A--a=0A=0A>= =0A>=0A> --a=0A>=0A>>=0A>>>Now, if you start to spoof your source and send = the traffic at high=0A>>>rates, we're into the ToS violation territory, and= the hosting company=0A>>>probably assumes a certain degree of good citizen= ship from its clients=0A>>>towards each other.=0A>>=0A>>>If you were to try= this kind of link-local smurf, why not=0A>>>try stealing other VM's IPv4 a= ddresses and running MITM on them ? Or=0A>>>try spoofing the default router= ? Or try sweep-scanning their entire=0A>>>/64 from Internet at high rate ?= Or get into legacy and try=0A>>>ARP-flooding with broadcast ARP requests/r= eplies at line rate ?=0A>>=0A>>>There usually is a very simple mitigation t= o all of the above: first=0A>>>warn the hosting customer that is being naug= hty, then terminate the=0A>>>contract. I know for sure it is being practice= d.=0A>>=0A>> We discovered this by accident & were using the example of Pin= g FF02::1 to=0A>> illustrate what can happen.=0A>>=0A>>=0A>>=0A>> --a=0A>>= =0A>>>=0A>>> What to do is a good question. IPv6 implementation at end use= r sites is=0A>>> new=0A>>> to many & mistakes are being made. I do not kno= w what is the answer.=0A>>>=0A>>>>=0A>>>>>So looks like the question at han= d is:=0A>>>>=0A>>>>>"Should IPv6 nodes respond to Ping to FF0x::1?"=0A>>>>= =0A>>>>>Which can be rephrased differently to ease the start of the discuss= ion:=0A>>>>=0A>>>>>"What are the legitimate uses of a ping to ff0x::1 ?"=0A= >>>>=0A>>>>>Right ?=0A>>>>=0A>>>> Yes.=0A>>>=0A>>>>Allright, so I'll mentio= n my use of ping6 ff0x::1:=0A>>>=0A>>>>* quick check to find "a few hosts t= hat are alive on this link"=0A>>>>(obviously not to be done on large segmen= ts).=0A>>>=0A>>>>* A way to trigger the remote side's ND process without ha= ving to do=0A>>>>one myself (I know the multicast packet to all-hosts *will= * usually=0A>>>>get received regardless of the underlying issues with the L= 2.5=0A>>>>infrastructure (snooping, etc.)=0A>>>=0A>>>>* A way to further de= bug malfunctioning L2.5 infra, by comparing the=0A>>>>reaction to pings to = ff02::1, solicited node multicast, other=0A>>>>multicast groups, etc.=0A>>>= =0A>>>>Summary: the ff02::1 current ping behavior does help in a non-trivia= l=0A>>>>amount of cases.=0A>>>=0A>>>>The security aspects the draft mention= s indeed do exist, but in a=0A>>>>properly configured network can be easily= mitigated as I've shown=0A>>>>above. So I'd be against changing the functi= onality in the existing=0A>>>>stacks.=0A>>>=0A>>> I don't know, Andrew. I = worry about the broadcast nature of the ping.=0A>>> I feel like it is troub= le waiting to happen.=0A>>>=0A>>>=0A>>> --a=0A>>>=0A>>>>=0A>>>> --a=0A>>>>= =0A>>>>=0A>>>> On 9/19/14, fred@cisco.com wrote:=0A>>>>> A= new draft has been posted, at=0A>>>>> http://tools.ietf.org/html/draft-elk= ins-v6ops-multicast-virtual-nodes.=0A>>>>> Please take a look at it and com= ment.=0A>>>>>=0A>>>>> _______________________________________________=0A>>>= >> v6ops mailing list=0A>>>>> v6ops@ietf.org=0A>>>>> https://www.ietf.org/m= ailman/listinfo/v6ops=0A>>>>>=0A>>>=0A>> ---559651860-2015326298-1411222958=:28642 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 9/20/14, Nalini Elk= ins <n= alini.elkins@insidethestack.com> wrote:
>
>
>>
>>>>
>>>>&= gt;A directed broadcast ping on IPv4 gives pretty much the same result.
>>>= >>Did you test the effects of that ?
>>>>
>>&g= t;> I had not.  But, since you mentioned it, I did it on two differ= ent
>>>> Windows
>>>> machines.  The one = that is the server in question had the following
>>>> results:
>>>>
>>>= > C:\Users\Administrator>ping x.x.x.255
>>>>
>>= ;>> Pinging x.x.x.255 with 32 bytes of data:
>>>> Request timed out.
>>>> Request timed out.
>>>> Request timed out.>>>> Request timed out.<= br clear=3D"none" class=3D"" style=3D"">>>>>
>>>> Ping statistics for x.x.x.255:
>>>>    Packets: = Sent =3D 4, Received =3D 0, Lost =3D 4 (100% loss),
>>>>
&= gt;>>> Arp cache was not updated.  I did a packet trace in t= he background and
>>>> = indeed no ICMP replies were seen.
&= gt;>>>
>>>> I = did the same ping x.x.x.255 on one of my client PCs and saw:
>>>>
>>>> Pinging x.x.x.255 with 32 bytes of data:
>>>> Request timed out.>>>> Request timed out.<= br clear=3D"none" class=3D"" style=3D"">>>>> Request timed out.=
>>>> Request timed out= .
>>>>
>>>> But this time the packet trace sho= wed that actually ICMP replies were
>>>> sent.
>>>= ;>
>>>
>>>>So, besides this cosmetic differenc= e the behavior is identical for the
>>>>case of IPv4 ping ?
>>>
>>> Andrew,= I think you may have misunderstand me.  The behavior is very
>>> definitely not
>>> identical in IPv4.  In I= Pv4, many people block or disable directed
>>> broadcast PING.  Such
>>
>>>O= n the same subnet ? You wrote that the replies were indeed amplified
>>>and sent, or did I misunderst= and ?
>>
>> The replies on the same subnet appear to be bl= ocked in one case and not
>> = blocked in another case.
>> S= o, one cannot make a blanket statement (at least based on two data
>> points!).
>>
>
>>With the test I did within my= home network, I saw amplified replies on
>>both, so one can not make a blanket statement indeed and it = depends on
>>the OS and the s= etup.
>
>>
>>&= gt; PINGs can be used for amplification in Smurf attacks.
>>>
>>> http://www.techrepublic.com/article/und= erstanding-a-smurf-attack-is-the-first-step-toward-thwarting-one/
>>>
>>> Ping to FF02::1 is definitely amplification when 10 echo requests can
>>> create
>>&= gt; 2,000+
>>> echo replie= s.  When you do a Ping on Linux, it is continuous until you
>>> stop
>>> it.
&= gt;>> So, you may very easily do amplification without even meaning t= o.
>>
>>>This is all link-local. The reason Smurf is da= ngerous is that one can
>>>= ;send the request from across the internet. Here it's on the same
>>>segment - so it's a customer-pr= ovider relationship, and there are ton
>>>of the existing operational mechanisms that can be used to take care
>>>o= f this if this is a concern - documenting them might be useful.
>>>Saying that the hosts should not r= eply altogether - not; for the
>= >>reasons outlined in the previous mail.
>>
>>>(O= f course this is just my experience, would be interesting to hear
>>>others' opinions).
>>
>> As I said in another response, in IPv6 subnets, there may be man= y other
>> nodes
>> on link with you.  We were using= the
>>  Ping to FF02::1= as a graphic example of how
>> it is possible to impact both yourself and other nodes= without even
>> meaning
>> to.
>
>>So you p= ing ff02::1 on a network with X hosts, where X is large. So
>>each of these X hosts has to process 1 pac= ket and generate 1 packet,
>>= you have to process X responses, you populate ND cache on your hosts
>>with X entries, each of the X hos= ts populates their ND cache with your
>>address.
>
>>Your host is quite obviously impact= ed. But the others process a 1/X
&g= t;>share of the load compared to you, an equivalent to a regular 1 host
>>exchange. S= o I don't see how they are impacted.
>
> On Windows, I did a :&n= bsp; ping ff02::1 -n 10
>
> where the -n is the count.
>
> So for each 1 ping request I send out, each of my neighbors sends me= 10
> responses.

No, the "= -n 10" means you send 10 requests, each of them triggers a
response from each of the neighbors, at least accor= ding to Microsoft
documentation at<= br clear=3D"none" class=3D"" style=3D"">http://technet.microsoft.com/en-us= /library/cc737478%28v=3Dws.10%29.aspx

> So, I have made them d= o 10 times as much work as me.

= >No, you did not. You made them do the same amount of work as you did>sending the packets - you sent 10= requests, they sent 10 replies.

You are correct. I was wrong in my explanat= ion of multicast ping amplification. 
How I believe it works is this:

Situation:  node A is on a subnet with 25 other nodes (B-Z)

<= div class=3D"" style=3D"font-size: 16.3636360168457px;">1.  Node A sen= ds 10 ICMP ping requests to FF02::1
2.  Nodes B through Z send Node A back ICMP 10 = ping replies each

Impact: with very little work by Node A, he has made B -= Z do work &
created network congestion = with 250+ packets.


&g= t; Also, since in this
> case, I=
> had about 200 neighbors, the link had a bunch of traffic on it (the ping
> requests
> and replies from everyone) (as well as the neighbor discovery pa= ckets) which
> were
> in the way of anyone wanting to actual pro= ductive work.

>ICMP echo requests in the syntax you described are = sent ~1 per second,
>so the repl= ies is about 200 per second. It's a very small amount of
>traffic.

In this case.  The surprise (at least to = us) was that it happens at all.  Also,
it highlighted the point of node isolation - that one node can impact othe= rs
and the network with both link-local and multicast traffic.
BTW, this is also a security issue.
=

>>>
>> We discovered this by accident.  We were doing t= esting for another
>> purpose= and were quite surprised to see that both servers were seeing all
>> the
>> multicast packets and even more surprised when we did th= e PING to FF02::1.
>
>>Nick has a good point this whole situa= tion would benefit of some more
>= ;>debugging.
>
> Such as what?  BTW, I have sent Nick the trace & can send to you as well.

>Sure, feel free to= send it.

Doing so privately.

>
>>
>>>
>>>
>>>>>Of course, private VLANs or (if we are talking V= Ms) or just using p2p
>>>&= gt;>links with /128s would help this in the environments where the hosts=
>>>>>can not be tru= sted - and this of course is not virtual/physical
>>>>>specific.
>>>>
>>>> Yes.  We wanted to bring up the topic of = isolation of nodes for
>>>= > discussion.
>>>
>>>>This is a useful topic i= n general - especially in light of the
>>>>MLD-related thread, but the draft seems to focus on a= very corner case
>>>>-= there are many much better reasons not to do large L2 networks.
>>>
>>> We wanted to pick one specific instance.  Maybe= we went TOO small!
>>
>> No, the more focused the doc is,= the better.
>>
>>>
>>>>
>&g= t;>>>If we're talking specifically virtual environment, here's an = approach
>>>>>on how= to use ebtables to isolate the hosts:
>>>>
>>>= >>ebtables -P FORWARD DROP
&g= t;>>>>ebtables -F FORWARD
>>>>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let t= he traffic flow
>>>>>= ;from uplink to any ports
>>&= gt;>>ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic f= low
>>>>>from any po= rts to uplink
>>>>
>>>>>(source:http://serverfault.co= m/questions/388544/is-it-possible-to-enable-port-isolation-on-linux-bridges= )
>>>>
>>>> I think this is very good.&nbs= p; But, unfortunately not very well known.
>>>> Also,
>= >>> is this possible for all platforms or just Linux?
>>>
>>>>This was just my first google.com search result when = searching for
>>>>"priv= ate vlans linux".
>>>
>>>>The first google.com search result on "private vlans windows" brings
>>>>up
>>>> http://blogs.technet.com/b= /scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx=
>>>>which seems to doc= ument similar technique.
>>&g= t;
>>>>"private vlan vm= ware" results in
>>>>http://kb.vmware.com/selfservice/microsites/search.do?language= =3Den_US&cmd=3DdisplayKC&externalId=3D1010691
>>>>as its first hit.
>>>
= >>>>Would an IETF publication be easier to find than the above = ?
>>>
>>> Maybe not but the hosting company who prov= ided us the service where we
>&g= t;> did
>>> this real l= ife test does not seem to have read any of the documents you
>>> reference.
>>
>>&= gt;If you were not spoofing the source, then the only DoS target was
>>>yourself, and the inter-customer resource isolation should take care
>>>of the rest. This is relates to "Oops I don't = know what I'm doing"
>>>pa= rt.
>>
>> Actually, not.  In this case, there was no = inter-customer resource
>> is= olation.  So, we were impacting everyone.  As I say, we discover= ed
>> this by accident.
>
>>Again, it's obvious to see how you're impacting yourself but = it's
>>unclear to me how were= you impacting the others.
>
>>I did a quick test in my lab, = and the only node that significantly
>>grew the ND cache in my test was the one sen= ding the ping. The rest
>>jus= t added only the sender's address. Sure, the sender also triggered
>>NUD on the addresses, but again it = is only the sender that was
>>= ;impacted - the rest had just 1 packet to handle, which is not much.
>
>>Please help me understand where is the problem ?
>
&g= t; See above.
> Also, I believe = it is not a question of the neighbor cache.
> We just showed that to prove that other nodes actually were r= esponding.
>
> Also, our topic actually was a bit more broad.  We were not talking only
> of the PING to FF02::1, but of multicast.  Multicast is se= en by all the
> neighbors and ca= n be quite a bit of the link activity.  Again, getting in
> the way of productive traffic.
>
> We may be spending a bit too much time focused solely on the Ping.> I stand by my statement that th= e Ping can be an amplification.
>= ; However, we used the example of the Ping to show that if you have a
> number of neighbors on link, as sho= wn by the Ping, then they will see
= > all the multicast packets generated as well.

>The address is named all-hosts multicast, so it is logical for the
>hosts to see it and react.

>
>>
>> I am thinking that the bigger question that we should ad= dress is
>> node isolation.&n= bsp; I think that people implementing IPv6 have got the
>> /64 for subnet in their heads pretty well.&nb= sp; But, not the other part
>>= ; about how multicast - and other packets impact nodes on link with you.>> And that they should do node= isolation.
>>
>> What do you think?
>
>>Give each vhost a routed /64 and use link-local next-ho= ps - this will
>>give the sam= e "broadcast profile" as for IPv4, and reduce the hoster's
>>resources needed to manage the allocated ad= dresses, and still allows
> to s= ell 65536 vhosts, assuming the said hoster has only /48.
>
>>= Then on the shared segment that carries the routed traffic,
>>intra-subnet apply the same security polic= y to the ff02::1 IPv6
>>traff= ic as you do to IPv4 x.x.x.255 originated within and destined for
>>that subnet - private VLANs, p2p li= nks, or nothing.
>
>
>
> I think this = focuses too narrowly on the Ping.    I need to think some
> more on how to talk about isolation.<= br clear=3D"none" class=3D"" style=3D"">
>Subnets is the industry-standard way of isolating the broadcast d= omains.

Then, IMHO, there needs to be a "Best Practices" document for how to crea= te
subnets.  I am not of the opinion t= hat creating a subnet that spans multiple
v= irtual machines, which could really expect to have separation from each
other, is a great practice.

I believe that in the wi= ld, /64 appears to be the standard for a subnet no matter
what the circumstances are.

=

--a

>
>
> --a
>
>>
>>>Now, if you start to spoof your so= urce and send the traffic at high
&= gt;>>rates, we're into the ToS violation territory, and the hosting c= ompany
>>>probably assumes= a certain degree of good citizenship from its clients
>>>towards each other.
>>
>>&= gt;If you were to try this kind of link-local smurf, why not
>>>try stealing other VM's IPv4 addresses and running = MITM on them ? Or
>>>try s= poofing the default router ? Or try sweep-scanning their entire
>>>/64 from Internet at high rate ? O= r get into legacy and try
>>&= gt;ARP-flooding with broadcast ARP requests/replies at line rate ?
>>
>>>There usually is a very simple mitigation to all of the a= bove: first
>>>warn the ho= sting customer that is being naughty, then terminate the
>>>contract. I know for sure it is being pra= cticed.
>>
>> We discovered this by accident & were us= ing the example of Ping FF02::1 to
>> illustrate what can happen.<= br clear=3D"none" class=3D"" style=3D"">>>
>>
>>
>> --a
>>
>>&= gt;
>>> What to do is a go= od question.  IPv6 implementation at end user sites is
>>> new
>>> to many & mistakes are being made.  I do not k= now what is the answer.
>>>= ;
>>>>
>>>>>So looks like the question at h= and is:
>>>>
>>>>>"Should IPv6 nodes resp= ond to Ping to FF0x::1?"
>>>>
>>>>>Which can be rephra= sed differently to ease the start of the discussion:
>>>>
= >>>>>"What are the legitimate uses of a ping to ff0x::1 ?">>>>
>>>>>Right ?
>>>>
>= >>> Yes.
>>>
>>>>Allright, so I'll menti= on my use of ping6 ff0x::1:
>>= ;>
>>>>* quick check= to find "a few hosts that are alive on this link"
>>>>(obviously not to be done on large segments).
>>>
>>>>* A way to trigger the remo= te side's ND process without having to do
>>>>one myself (I know the multicast packet to all-hosts= *will* usually
>>>>get= received regardless of the underlying issues with the L2.5
>>>>infrastructure (snooping, etc.)>>>
>>>>* A way to further debug malfunctioning L2= .5 infra, by comparing the
>>= >>reaction to pings to ff02::1, solicited node multicast, other
>>>>multicast groups, etc.>>>
>>>>Summary: the ff02::1 current ping behavior does help in a non-trivial
>>>>amount of cases.
>>>
>>>>= The security aspects the draft mentions indeed do exist, but in a
>>>>properly configured network= can be easily mitigated as I've shown
>>>>above. So I'd be against changing the functionality i= n the existing
>>>>stac= ks.
>>>
>>> I don't know, Andrew.  I worry abou= t the broadcast nature of the ping.
>>> I feel like it is trouble waiting to happen.
>>>
>>>
>>> --a
>>>
>>>>
>>>> --a
>>= >>
>>>>
>>>> On 9/19/14, fred@cisco.com <fred@= cisco.com> wrote:
>>&g= t;>> A new draft has been posted, at
>>>>> http://tools.ietf.org/html/draft-elkins-v6ops-= multicast-virtual-nodes.
>>&g= t;>> Please take a look at it and comment.
>>>>>
>>>>> __________________________________________= _____
>>>>> v6ops ma= iling list
>>>>> v6ops@ietf.org
>>>>> https:/= /www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>= >
>>


---559651860-2015326298-1411222958=:28642-- From nobody Sat Sep 20 10:26:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436621A0191 for ; Sat, 20 Sep 2014 10:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 iZMpXebpQv3H for ; Sat, 20 Sep 2014 10:25:58 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1311A016B for ; Sat, 20 Sep 2014 10:25:58 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s8KHOC1X015992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 18:25:01 +0100 (IST) (envelope-from nick@foobar.org) Message-ID: <541DB824.7080408@foobar.org> Date: Sat, 20 Sep 2014 18:23:48 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Nalini Elkins , =?UTF-8?B?QW5kcmV3IA==?= =?UTF-8?B?8J+RvSBZb3VydGNoZW5rbw==?= References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> In-Reply-To: <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D_QuT9zDH_Ptb5yy6JVICWHUBn0 Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Sep 2014 17:26:00 -0000 On 20/09/2014 15:15, Nalini Elkins wrote: > Situation: node A is on a subnet with 25 other nodes (B-Z) > > 1. Node A sends 10 ICMP ping requests to FF02::1 > 2. Nodes B through Z send Node A back ICMP 10 ping replies each > > Impact: with very little work by Node A, he has made B - Z do work & > created network congestion with 250+ packets. If the hosting provider has any sense, this will count towards node A's bandwidth allocation and if they persist in doing this, they will end up with a large bill as well as having trashed their connectivity. The lesson is that if you shoot yourself in the foot, it will hurt. If your network design is such that shooting yourself in the foot causes other hosts to be shot in the foot, then your network design may have a problem. If you are a commercial hosting provider who provides third party shared tenancy networks which use this design, then you should expect problems of this sort. Most hosting providers know these things and there is no need for the IETF to remind them. Nick From nobody Sat Sep 20 16:25:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8412A1A02D8 for ; Sat, 20 Sep 2014 16:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 xXs2wBND5HAX for ; Sat, 20 Sep 2014 16:25:05 -0700 (PDT) Received: from nm28-vm5.bullet.mail.ne1.yahoo.com (nm28-vm5.bullet.mail.ne1.yahoo.com [98.138.91.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3741A02D6 for ; Sat, 20 Sep 2014 16:25:05 -0700 (PDT) Received: from [98.138.101.129] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 23:25:04 -0000 Received: from [98.138.89.246] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 23:25:04 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 20 Sep 2014 23:25:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 662055.88598.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 29373 invoked by uid 60001); 20 Sep 2014 23:25:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411255504; bh=L+Obcd+0zoXdp3LrcegBqg/9pU4eW78fbrScTTAZwCg=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=uv3Vcxyh3wBmw/V0e0tVJbDn7jQtljyRQs/eqgd88uBvumI0/0Ux0MnE4NC5JhgffydNzHnfPE57ZDYNn+ZnLvZgbLtKWyK3NKuLkKU0+VH07iQM2hkXL1mkHGcRuLSRixLMhBQ9FZhkP1NRRQ9ezuSDqipboe3a7hE+pZ92uRI= X-YMail-OSG: pxRwp08VM1mMLfTc.DzXqrxS_qYXG9MCPhv7wjDn_Q5jmr. uaJ43YJcsj5V4ecLh_vHTmJpYJSqNHnCoHy8eY429HIXw8ZqwgGos458wq7m Z2lEOvzxvLdAHJpLpXDuy0OJ.ZqUWaOKCnlRdl5Q5WyQU2npV4NmjJW8aCuT FLkdyIAiwtOuu1FcG5aewEWqDygIjuKBxEe_MEU7Owxp.M3HdYQyMrI4Oupi avOTZNtHMETz3.JU00i7kjcbSyGL6BLEjy.pziblEY7jiRCvKXOEQFMzbrH5 pDU9v1iyESfutCI2Noq7GK7Qnubfg3aQZyMvSQR_cPcV3u_Zg2yeVLPTO8gK U5Aidy4fffEq8hsOuCCqbfcjO2dExpp1Kts80bH7SZmJyZ8bYuRncp.DnKAZ bHwtKLHY2HkDcVJrEJM_Z9NXyI3EChoLpz.Bsqc2nU62iLt9VkgSKYWh_K2m 0tRbdl7jzVGRkCqztSkAxjueHLi31UPriAi3VANTyvhoGBfIhLPHq8zRIoig PGT56ReCWYppNA4iAtxreVPHRJqIkkWjgLn.l_12aLlG2___Q Received: from [24.130.244.175] by web125102.mail.ne1.yahoo.com via HTTP; Sat, 20 Sep 2014 16:25:04 PDT X-Rocket-MIMEInfo: 002.001, CgpPbiAyMC8wOS8yMDE0IDE1OjE1LCBOYWxpbmkgRWxraW5zIHdyb3RlOgo.IFNpdHVhdGlvbjogIG5vZGUgQSBpcyBvbiBhIHN1Ym5ldCB3aXRoIDI1IG90aGVyIG5vZGVzIChCLVopCj4KPiAxLiAgTm9kZSBBIHNlbmRzIDEwIElDTVAgcGluZyByZXF1ZXN0cyB0byBGRjAyOjoxCj4gMi4gIE5vZGVzIEIgdGhyb3VnaCBaIHNlbmQgTm9kZSBBIGJhY2sgSUNNUCAxMCBwaW5nIHJlcGxpZXMgZWFjaAo.Cj4gSW1wYWN0OiB3aXRoIHZlcnkgbGl0dGxlIHdvcmsgYnkgTm9kZSBBLCBoZSBoYXMgbWFkZSBCIC0gWiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> Message-ID: <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Sat, 20 Sep 2014 16:25:04 -0700 From: Nalini Elkins To: Nick Hilliard , =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= In-Reply-To: <541DB824.7080408@foobar.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-559651860-1242465560-1411255504=:4053" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/o8nP6m6_2-o0wUob9o4nrP9pFkw Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 23:25:07 -0000 ---559651860-1242465560-1411255504=:4053 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AOn 20/09/2014 15:15, Nalini Elkins wrote:=0A> Situation: node A is o= n a subnet with 25 other nodes (B-Z)=0A>=0A> 1. Node A sends 10 ICMP ping = requests to FF02::1=0A> 2. Nodes B through Z send Node A back ICMP 10 ping= replies each=0A>=0A> Impact: with very little work by Node A, he has made = B - Z do work &=0A> created network congestion with 250+ packets.=0A=0A>If = the hosting provider has any sense, this will count towards node A's =0A>ba= ndwidth allocation and if they persist in doing this, they will end up =0A>= with a large bill as well as having trashed their connectivity.=0A=0A>The l= esson is that if you shoot yourself in the foot, it will hurt. If =0A>your= network design is such that shooting yourself in the foot causes other =0A= >hosts to be shot in the foot, then your network design may have a problem.= =0A=0A>If you are a commercial hosting provider who provides third party sh= ared =0A>tenancy networks which use this design, then you should expect pro= blems of =0A>this sort.=0A=0A>Most hosting providers know these things and = there is no need for the IETF =0A>to remind them.=0A=0AReally?=0A=0ASo then= , are you saying that the hosting company example we gave was for a =0Apart= icularly ignorant or incompetent firm? That most hosting providers of IPv= 6=0Aservices and most end user enterprises (because our draft is for them a= s well)=0Aare quite well aware of the potential drawbacks and implications = of IPv6 link-local =0Aand multicast traffic in the design of their subnets = or broadcast domains.=0AAnd, furthermore take such traffic and / or the nee= d for isolation of nodes for=0Asecurity or regulatory purposes into account= when doing their network design?=0A=0AAnd, basically, the issues that we a= re trying to bring up are quite well known =0Ato everyone. You could be r= ight (but I am betting against it!). =0A=0AMaybe my co-author, who works= for a large end-user enterprise, and whose =0Aorganization is trying to im= plement IPv6, can chime in and let us know how =0Awell known these issues a= re in his own organization and those he speaks to=0Aregularly.=0A=0AMaybe o= ther enterprise customers on the list can speak as well. Would love=0Ato h= ear from them. Having said that, probably if they are on this email list,= =0Athey are probably orders of magnitude more sophisticated than most.=0A= =0AI can also take an informal poll. I can call 2 -3 other hosting compan= ies =0Ato see what their IPv6 addressing structure is & let you all know. = I can also=0Acall 5 - 10 large enterprise companies in the US (Fortune 500= & large federal =0Aagencies & the like) to tell you if they take such thin= gs into consideration. =0A=0AA few years ago, I compiled IPv6 addressing = plans (subnet structure,=0Anaming conventions, etc) from 6 - 7 universities= (commercial entities will=0Agenerally not speak publicly about how they do= things). I can tell you there=0Awere no such considerations in their pla= ns. I can go back and ask them=0Aif they will allow me to distribute their= plans publicly.=0A=0A=0A=0A=0AAll this will take me a few days, so maybe w= e can pick up the discussion=0Aon Wed / Thurs of next week.=0A=0AI believe = that guidance on network design is needed for end-user sites -=0Aincluding = hosting companies. That was the reason for our draft. If I am =0Awrong a= nd no such guidance is needed, then I will be quiet and withdraw=0Athe draf= t.=0A=0ANalini ---559651860-1242465560-1411255504=:4053 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 20/09/2014 15:15, Nalini Elkins wrote:
> = Situation:  node A is on a subnet with 25 other nodes (B-Z)
>
> 1.  Node A sends 10 ICMP ping re= quests to FF02::1
> 2.  Nodes B through Z send No= de A back ICMP 10 ping replies each
>
> Impact: with very little work by Node A, he has made B - Z do work &= amp;
> created network congestion with 250+ packets.
>If the hosting provider has any sens= e, this will count towards node A's
>bandwidth alloca= tion and if they persist in doing this, they will end up
>with a large bill as well as having trashed their connectivity.

>The lesson is that if you shoot yourself= in the foot, it will hurt.  If
>your network de= sign is such that shooting yourself in the foot causes other
>hosts to be shot in the foot, then your network design may have a = problem.

>If you are a commercial h= osting provider who provides third party shared
>tena= ncy networks which use this design, then you should expect problems of
>this sort.

>Most= hosting providers know these things and there is no need for the IETF
>to remind them.

Really?

So then, are you saying that the hosting company = example we gave was for a 
particu= larly ignorant or incompetent firm? &= nbsp; That most hosting providers of IPv6
services and most end user enter= prises (because our draft is for them as well)
are quite well aware of the= potential drawbacks and implications of IPv6 link-local 
=
and multica= st traffic in the design of th= eir subnets or broadcast domains.
And, furthermore take such traffic and / or the need for isolation of nodes for
security or = regulatory purposes into account when doing their network design?

And, basically, the issues that we = are trying to bring up are quite well known 
to everyone.   You co= uld be right (but I am betting against it!).    

Maybe m= y co-author, who works for a large en= d-user enterprise, and whose 
organization is trying to <= span style=3D"font-size: 12pt;">implement IPv6, can chime in and let us know how 
well known these issues are in his own organization and those he spe= aks to
regularly.

Maybe other enterprise customers on the list ca= n speak as well.  Would love
to hear from them.  Having said tha= t, probably if they are on this email list,
they are probably orders of ma= gnitude more sophisticated than most.

I can also take an informal poll.   I can = call 2 -3 other hosting companies 
to see what their IPv6 addressing&= nbsp;structure is & let you all= know.   I can also
call 5 - 10 large enterprise compa= nies in the US (Fortune 500 & large federal 
agencies & = the like) to tell you if they take = such things into consideration.   

A few years ago, I compiled IPv6 addressing plans (sub= net structure,
naming conventions, etc) fr= om 6 - 7 universities (commercial entities will
generally not speak publicly about how they do things).   I c= an tell you there
were no such consider= ations in their plans.  I can go back and ask them
if they will allow me to distribute their plans publicly.<= /div>



All this will take me a few days, so maybe we can pick up = the discussion
on Wed /= Thurs of next week.
I believe that guida= nce on network design is needed for end-user sites -
including hosting companies.   That was the reason for our draft.  If I am 
wrong and no such guidance is needed, then I will be quiet and withdraw
t= he draft.

Nalini


---559651860-1242465560-1411255504=:4053-- From nobody Sun Sep 21 07:30:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA16D1A010E for ; Sun, 21 Sep 2014 07:30:33 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 39ll2dQ5eNgV for ; Sun, 21 Sep 2014 07:30:31 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C701A010A for ; Sun, 21 Sep 2014 07:30:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id 926D11C24 for ; Sun, 21 Sep 2014 10:30:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 21 Sep 2014 10:30:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=6ZS pYNy+mp/QIt3m/wCT8rD6Y0k=; b=VcljNRd5xW2cqYhKkeo/3Au5CTU+szCkXYu sGCldnA+oyp8vipvsHTrs/oQJxu8n4hctq9S2MxMlvr0nvXJsJtX6wBN3X/Fn9v7 7TW775C56LQSV/hLjblyFRpYLkgjxZc/XF6n56du78x/TjerBqRM1rhSwdMf2JxF Bh79gybw= X-Sasl-enc: jBFHj4A4KNdk3DHlQuDfHg6r0PYVb/omdme2hyKKjg+X 1411309827 Received: from [192.168.1.107] (unknown [96.35.101.179]) by mail.messagingengine.com (Postfix) with ESMTPA id F13E3C00910; Sun, 21 Sep 2014 10:30:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F5838D67-5ED1-45DB-903A-6F7012A65330" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Bill Cerveny In-Reply-To: <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Sun, 21 Sep 2014 10:29:39 -0400 Message-Id: <5C813403-8F3A-4A04-A746-359A60CEE6B3@wjcerveny.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> To: Nalini Elkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qS-H2X0N7duGGezHovZ_DZ3bzG4 Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 14:30:33 -0000 --Apple-Mail=_F5838D67-5ED1-45DB-903A-6F7012A65330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I personally think that the question "4.2 Should nodes respond to Ping = to FF0x::1" in the recommendations section is an interesting one. Just = as I would expect there is guidance (but don't know if there is) = regarding responses to IPv4 broadcast ICMP echo requests, it seems it = could be helpful to provide guidance to OS or OS firewall manufacturers = regarding if or how nodes should respond to ICMPv6 echo requests via = multicast addresses (if this guidance doesn't already exist). Bill Cerveny On Sep 20, 2014, at 7:25 PM, Nalini Elkins = wrote: >=20 > On 20/09/2014 15:15, Nalini Elkins wrote: > > Situation: node A is on a subnet with 25 other nodes (B-Z) > > > > 1. Node A sends 10 ICMP ping requests to FF02::1 > > 2. Nodes B through Z send Node A back ICMP 10 ping replies each > > > > Impact: with very little work by Node A, he has made B - Z do work & > > created network congestion with 250+ packets. >=20 > >If the hosting provider has any sense, this will count towards node = A's=20 > >bandwidth allocation and if they persist in doing this, they will end = up=20 > >with a large bill as well as having trashed their connectivity. >=20 > >The lesson is that if you shoot yourself in the foot, it will hurt. = If=20 > >your network design is such that shooting yourself in the foot causes = other=20 > >hosts to be shot in the foot, then your network design may have a = problem. >=20 > >If you are a commercial hosting provider who provides third party = shared=20 > >tenancy networks which use this design, then you should expect = problems of=20 > >this sort. >=20 > >Most hosting providers know these things and there is no need for the = IETF=20 > >to remind them. >=20 > Really? >=20 > So then, are you saying that the hosting company example we gave was = for a=20 > particularly ignorant or incompetent firm? That most hosting = providers of IPv6 > services and most end user enterprises (because our draft is for them = as well) > are quite well aware of the potential drawbacks and implications of = IPv6 link-local=20 > and multicast traffic in the design of their subnets or broadcast = domains. > And, furthermore take such traffic and / or the need for isolation of = nodes for > security or regulatory purposes into account when doing their network = design? >=20 > And, basically, the issues that we are trying to bring up are quite = well known=20 > to everyone. You could be right (but I am betting against it!). =20= >=20 > Maybe my co-author, who works for a large end-user enterprise, and = whose=20 > organization is trying to implement IPv6, can chime in and let us know = how=20 > well known these issues are in his own organization and those he = speaks to > regularly. >=20 > Maybe other enterprise customers on the list can speak as well. Would = love > to hear from them. Having said that, probably if they are on this = email list, > they are probably orders of magnitude more sophisticated than most. >=20 > I can also take an informal poll. I can call 2 -3 other hosting = companies=20 > to see what their IPv6 addressing structure is & let you all know. I = can also > call 5 - 10 large enterprise companies in the US (Fortune 500 & large = federal=20 > agencies & the like) to tell you if they take such things into = consideration. =20 >=20 > A few years ago, I compiled IPv6 addressing plans (subnet structure, > naming conventions, etc) from 6 - 7 universities (commercial entities = will > generally not speak publicly about how they do things). I can tell = you there > were no such considerations in their plans. I can go back and ask = them > if they will allow me to distribute their plans publicly. >=20 >=20 >=20 > All this will take me a few days, so maybe we can pick up the = discussion > on Wed / Thurs of next week. >=20 > I believe that guidance on network design is needed for end-user sites = - > including hosting companies. That was the reason for our draft. If = I am=20 > wrong and no such guidance is needed, then I will be quiet and = withdraw > the draft. >=20 > Nalini >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_F5838D67-5ED1-45DB-903A-6F7012A65330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = personally think that the question "4.2 Should nodes respond to = Ping to FF0x::1" in the recommendations section is an interesting one. = Just as I would expect there is guidance (but don't know if there is) = regarding responses to IPv4 broadcast ICMP echo requests, it seems it = could be helpful to provide guidance to OS or OS firewall manufacturers = regarding if or how nodes should respond to ICMPv6 echo requests via = multicast addresses (if this guidance doesn't already = exist).

Bill Cerveny

On = Sep 20, 2014, at 7:25 PM, Nalini Elkins <nalini.elkins@insidethest= ack.com> wrote:


On 20/09/2014 15:15, Nalini Elkins = wrote:
> Situation:  node A is on a subnet = with 25 other nodes (B-Z)
>
> = 1.  Node A sends 10 ICMP ping requests to FF02::1
> 2.  Nodes B through Z send Node A back ICMP 10 = ping replies each
>
> Impact: = with very little work by Node A, he has made B - Z do work &
> created network congestion with 250+ packets.

>If the hosting provider has any = sense, this will count towards node A's 
>bandwidth allocation and if they persist in doing = this, they will end up 
>with = a large bill as well as having trashed their connectivity.

>The lesson is that if you shoot = yourself in the foot, it will hurt.  If 
>your = network design is such that shooting yourself in the foot causes = other 
>hosts to be shot in the foot, then your network = design may have a problem.

>If = you are a commercial hosting provider who provides third party = shared 
>tenancy networks which use this design, then you = should expect problems of 
>this = sort.

>Most hosting providers = know these things and there is no need for the IETF 
>to = remind them.

Really?

So = then, are you saying that the hosting company example we gave was for = a 
particularly = ignorant or incompetent firm? =   That most hosting providers of IPv6
services and = most end user enterprises (because our draft is for them as = well)
are quite well aware of the potential drawbacks and implications = of IPv6 link-local 
and multicast traffic in the design of their subnets or = broadcast domains.
And, = furthermore take such traffic and / or the need for isolation of nodes = for
security or regulatory purposes into account when doing = their network design?

And, basically, the issues that we are trying = to bring up are quite well known 
to everyone.   You could be right (but I am betting against = it!).    

Maybe = my co-author, who works for a = large end-user enterprise, and whose 
organization = is trying to implement = IPv6, can chime in and let = us know how 
well known these issues are in his own organization and those he = speaks to
regularly.

Maybe other enterprise customers on the list = can speak as well.  Would love
to hear from = them.  Having said that, probably if they are on this email = list,
they are probably orders of magnitude more sophisticated than = most.

I can also take an informal poll.   I = can call 2 -3 other hosting companies 
to see what = their IPv6 addressing structure is & let you all know.   I can = also
call 5 - 10 large = enterprise companies in the = US (Fortune 500 & large federal 
agencies = & the like) to tell you = if they take such things into consideration. =   

A few years ago, I compiled IPv6 addressing = plans (subnet structure,
naming = conventions, etc) from 6 - 7 universities (commercial entities = will
generally not speak publicly = about how they do things).   I can tell you there
were no such considerations in their plans. =  I can go back and ask them
if = they will allow me to distribute their plans publicly.



All this will take me a few days, so maybe we can pick = up the discussion
on = Wed / Thurs of next week.

I believe that guidance on network design is needed = for end-user sites -
including hosting companies.   That was the reason for our draft.  If I = am 
wrong and no such guidance is needed, then I will be quiet and = withdraw
the draft.

Nalini


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
= --Apple-Mail=_F5838D67-5ED1-45DB-903A-6F7012A65330-- From nobody Sun Sep 21 08:00:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0D71A01C3 for ; Sun, 21 Sep 2014 08:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FRT_PROFILE2=1.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_FSL_HELO_BARE_IP_2=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5Y2helsL9XQ for ; Sun, 21 Sep 2014 08:00:24 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EB81A0194 for ; Sun, 21 Sep 2014 08:00:24 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 3E9EE281FE5 for ; Sun, 21 Sep 2014 10:00:23 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 25E9B281FCB; Sun, 21 Sep 2014 10:00:21 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 2E6C02F0045; Sun, 21 Sep 2014 10:58:34 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 1F47D2F0040; Sun, 21 Sep 2014 10:58:34 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Sun, 21 Sep 2014 10:59:48 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Sun, 21 Sep 2014 10:59:48 -0400 From: "Ackermann, Michael" To: Nalini Elkins , Nick Hilliard , =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes Thread-Index: AQHP0/9nr2GOGmtz+E6bwFtua+J9j5wI9ViAgAAkY4CAABGGAIAAGngAgAAPRgCAAA69gIAADSMAgAA3VACAAFnmgIAAU7YAgAA0hwCAAGTvAIAAvOOw Date: Sun, 21 Sep 2014 14:59:47 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CCCAF4B@PWN401EA160.ent.corp.bcbsm.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> In-Reply-To: <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.3176-7.500.1018-20968.000 x-tm-as-result: No--54.043300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0CCCAF4BPWN401EA160entc_" MIME-Version: 1.0 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: c08d6cd0-9c75-49af-9e1c-d1b48563b887 X-VPM-MSG-ID: 11a48b03-26be-4999-8c85-3337a4d8ae80 X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rjmLcVXMQXpX_N0sYh9nUc03S0s Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 15:00:29 -0000 --_000_4FC37E442D05A748896589E468752CAA0CCCAF4BPWN401EA160entc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gcmVzcG9uc2UgdG8gaG93IG11Y2ggcmVsYXRpdmUga25vd2xlZGdlIHRoZXJlIGlzIG9u IElQVjYgYW5kIHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgaXNzdWVzIHN1Y2ggYXMgdGhpcyBt YXkgZXhpc3TigKbigKYuLg0KSW4gbW9zdCBjb3Jwb3JhdGUgYW5kIGVudGVycHJpc2Ugd29y bGRzIHRoYXQgSSBkZWFsIHdpdGgsIHdoaWNoIGlzIHByaW1hcmlseSBGaW5hbmNpYWwsIGlu c3VyYW5jZSBhbmQgSGVhbHRoIENhcmUsICAgdGhlIGFuc3dlciBpcyBuZWFybHkgemVyby4g ICBJIGZpbmQgdGhpcyB1bmZvcnR1bmF0ZSBhbmQgZnJ1c3RyYXRpbmcsICBidXQgdHJ1ZS4g ICBJIGFuZCBhIGZldyBvdGhlcnMgYXJlIHRyeWluZyB0byBjaGFuZ2UgdGhpcyBhbmQgZXZh bmdlbGl6ZSBJUHY2LCBidXQgd2UgYXJlIHB1c2hpbmcgcm9wZXMgdXAgaGlsbHMgaW4gdGhl c2UgZW52aXJvbm1lbnRzLiAgICBNb3N0IGxhcmdlIGVudGVycHJpc2VzIHdhbnQgdG8gYXZv aWQgSVB2NiBhcyBsb25nIGFzIHBvc3NpYmxlIGFuZCBsb29rIGZvciBleGN1c2VzIHRvIGRv IHNvLg0KSSBmdWxseSByZWNvZ25pemUgdGhhdCB0aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgZHJhZnQsICBtYXkgYmUgY29uc2lkZXJlZCBlbGVtZW50YXJ5 LCAgdHJpdmlhbCwgIG9yIGV2ZW4gdW5uZWNlc3NhcnkgaW4gSUVURiBjaXJjbGVzLCBidXQg SSBjYW4gZ3VhcmFudGVlIHlvdSB0aGF0IHRoZSBwcmVwb25kZXJhbmNlIG9mIG5ldHdvcmsg dGVjaG5pY2lhbnMgaW4gIHRoZSBjb3Jwb3JhdGUgd29ybGQgZG8gbm90IGV2ZW4ga25vdyB0 aGVzZSBwcm90b2NvbHMgZXhpc3QsIG11Y2ggbGVzcyB1bmRlcnN0YW5kIHRoZSBwb3RlbnRp YWwgZGFtYWdlIHRoZXkgY2FuIGluZmxpY3QuDQpNeSBzdXNwaWNpb24gcmVnYXJkaW5nIOKA nEhvc3RpbmcgQ29tcGFuaWVz4oCdLCAgaXMgdGhhdCB0aGVpciBJUHY2IGtub3dsZWRnZSBs ZXZlbHMgbGllIHNvbWV3aGVyZSBhYm92ZSB0aGUgZGVhcnRoIG9mIGNvcnBvcmF0ZSBBbWVy aWNhLCBidXQgd2VsbCBiZWxvdyB0aGUga25vd2xlZGdlIGxldmVsIG9mIHRob3NlIGludm9s dmVkIGluIElFVEYuDQoNClRoZXJlZm9yZSwgSSBiZWxpZXZlIHRoYXQgaW5mb3JtYXRpb24g YW5kIGFkdmljZSwgc3VjaCBhcyBjb250YWluZWQgaW4gdGhpcyBkcmFmdCwgd2lsbCBiZSB2 ZXJ5IGhlbHBmdWwgdG8gdGhvc2Ugbm90IHByb2ZpY2llbnQgaW4gSVB2NiBhbmQgaGVuY2Ug cG9zaXRpdmUgdG8gdGhlIGNhdXNlIG9mIHByb21vdGluZyBJUHY2IGRlcGxveW1lbnQuDQoN CkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE5hbGluaSBFbGtpbnMNClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMjAsIDIwMTQg NzoyNSBQTQ0KVG86IE5pY2sgSGlsbGlhcmQ7IEFuZHJldyDwn5G9IFlvdXJ0Y2hlbmtvDQpD YzogZHJhZnQtZWxraW5zLXY2b3BzLW11bHRpY2FzdC12aXJ0dWFsLW5vZGVzQHRvb2xzLmll dGYub3JnOyB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0 OiBkcmFmdC1lbGtpbnMtdjZvcHMtbXVsdGljYXN0LXZpcnR1YWwtbm9kZXMNCg0KDQpPbiAy MC8wOS8yMDE0IDE1OjE1LCBOYWxpbmkgRWxraW5zIHdyb3RlOg0KPiBTaXR1YXRpb246ICBu b2RlIEEgaXMgb24gYSBzdWJuZXQgd2l0aCAyNSBvdGhlciBub2RlcyAoQi1aKQ0KPg0KPiAx LiAgTm9kZSBBIHNlbmRzIDEwIElDTVAgcGluZyByZXF1ZXN0cyB0byBGRjAyOjoxDQo+IDIu ICBOb2RlcyBCIHRocm91Z2ggWiBzZW5kIE5vZGUgQSBiYWNrIElDTVAgMTAgcGluZyByZXBs aWVzIGVhY2gNCj4NCj4gSW1wYWN0OiB3aXRoIHZlcnkgbGl0dGxlIHdvcmsgYnkgTm9kZSBB LCBoZSBoYXMgbWFkZSBCIC0gWiBkbyB3b3JrICYNCj4gY3JlYXRlZCBuZXR3b3JrIGNvbmdl c3Rpb24gd2l0aCAyNTArIHBhY2tldHMuDQoNCj5JZiB0aGUgaG9zdGluZyBwcm92aWRlciBo YXMgYW55IHNlbnNlLCB0aGlzIHdpbGwgY291bnQgdG93YXJkcyBub2RlIEEncw0KPmJhbmR3 aWR0aCBhbGxvY2F0aW9uIGFuZCBpZiB0aGV5IHBlcnNpc3QgaW4gZG9pbmcgdGhpcywgdGhl eSB3aWxsIGVuZCB1cA0KPndpdGggYSBsYXJnZSBiaWxsIGFzIHdlbGwgYXMgaGF2aW5nIHRy YXNoZWQgdGhlaXIgY29ubmVjdGl2aXR5Lg0KDQo+VGhlIGxlc3NvbiBpcyB0aGF0IGlmIHlv dSBzaG9vdCB5b3Vyc2VsZiBpbiB0aGUgZm9vdCwgaXQgd2lsbCBodXJ0LiAgSWYNCj55b3Vy IG5ldHdvcmsgZGVzaWduIGlzIHN1Y2ggdGhhdCBzaG9vdGluZyB5b3Vyc2VsZiBpbiB0aGUg Zm9vdCBjYXVzZXMgb3RoZXINCj5ob3N0cyB0byBiZSBzaG90IGluIHRoZSBmb290LCB0aGVu IHlvdXIgbmV0d29yayBkZXNpZ24gbWF5IGhhdmUgYSBwcm9ibGVtLg0KDQo+SWYgeW91IGFy ZSBhIGNvbW1lcmNpYWwgaG9zdGluZyBwcm92aWRlciB3aG8gcHJvdmlkZXMgdGhpcmQgcGFy dHkgc2hhcmVkDQo+dGVuYW5jeSBuZXR3b3JrcyB3aGljaCB1c2UgdGhpcyBkZXNpZ24sIHRo ZW4geW91IHNob3VsZCBleHBlY3QgcHJvYmxlbXMgb2YNCj50aGlzIHNvcnQuDQoNCj5Nb3N0 IGhvc3RpbmcgcHJvdmlkZXJzIGtub3cgdGhlc2UgdGhpbmdzIGFuZCB0aGVyZSBpcyBubyBu ZWVkIGZvciB0aGUgSUVURg0KPnRvIHJlbWluZCB0aGVtLg0KDQpSZWFsbHk/DQoNClNvIHRo ZW4sIGFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIGhvc3RpbmcgY29tcGFueSBleGFtcGxlIHdl IGdhdmUgd2FzIGZvciBhDQpwYXJ0aWN1bGFybHkgaWdub3JhbnQgb3IgaW5jb21wZXRlbnQg ZmlybT8gICBUaGF0IG1vc3QgaG9zdGluZyBwcm92aWRlcnMgb2YgSVB2Ng0Kc2VydmljZXMg YW5kIG1vc3QgZW5kIHVzZXIgZW50ZXJwcmlzZXMgKGJlY2F1c2Ugb3VyIGRyYWZ0IGlzIGZv ciB0aGVtIGFzIHdlbGwpDQphcmUgcXVpdGUgd2VsbCBhd2FyZSBvZiB0aGUgcG90ZW50aWFs IGRyYXdiYWNrcyBhbmQgaW1wbGljYXRpb25zIG9mIElQdjYgbGluay1sb2NhbA0KYW5kIG11 bHRpY2FzdCB0cmFmZmljIGluIHRoZSBkZXNpZ24gb2YgdGhlaXIgc3VibmV0cyBvciBicm9h ZGNhc3QgZG9tYWlucy4NCkFuZCwgZnVydGhlcm1vcmUgdGFrZSBzdWNoIHRyYWZmaWMgYW5k IC8gb3IgdGhlIG5lZWQgZm9yIGlzb2xhdGlvbiBvZiBub2RlcyBmb3INCnNlY3VyaXR5IG9y IHJlZ3VsYXRvcnkgcHVycG9zZXMgaW50byBhY2NvdW50IHdoZW4gZG9pbmcgdGhlaXIgbmV0 d29yayBkZXNpZ24/DQoNCkFuZCwgYmFzaWNhbGx5LCB0aGUgaXNzdWVzIHRoYXQgd2UgYXJl IHRyeWluZyB0byBicmluZyB1cCBhcmUgcXVpdGUgd2VsbCBrbm93bg0KdG8gZXZlcnlvbmUu ICAgWW91IGNvdWxkIGJlIHJpZ2h0IChidXQgSSBhbSBiZXR0aW5nIGFnYWluc3QgaXQhKS4N Cg0KTWF5YmUgbXkgY28tYXV0aG9yLCB3aG8gd29ya3MgZm9yIGEgbGFyZ2UgZW5kLXVzZXIg ZW50ZXJwcmlzZSwgYW5kIHdob3NlDQpvcmdhbml6YXRpb24gaXMgdHJ5aW5nIHRvIGltcGxl bWVudCBJUHY2LCBjYW4gY2hpbWUgaW4gYW5kIGxldCB1cyBrbm93IGhvdw0Kd2VsbCBrbm93 biB0aGVzZSBpc3N1ZXMgYXJlIGluIGhpcyBvd24gb3JnYW5pemF0aW9uIGFuZCB0aG9zZSBo ZSBzcGVha3MgdG8NCnJlZ3VsYXJseS4NCg0KTWF5YmUgb3RoZXIgZW50ZXJwcmlzZSBjdXN0 b21lcnMgb24gdGhlIGxpc3QgY2FuIHNwZWFrIGFzIHdlbGwuICBXb3VsZCBsb3ZlDQp0byBo ZWFyIGZyb20gdGhlbS4gIEhhdmluZyBzYWlkIHRoYXQsIHByb2JhYmx5IGlmIHRoZXkgYXJl IG9uIHRoaXMgZW1haWwgbGlzdCwNCnRoZXkgYXJlIHByb2JhYmx5IG9yZGVycyBvZiBtYWdu aXR1ZGUgbW9yZSBzb3BoaXN0aWNhdGVkIHRoYW4gbW9zdC4NCg0KSSBjYW4gYWxzbyB0YWtl IGFuIGluZm9ybWFsIHBvbGwuICAgSSBjYW4gY2FsbCAyIC0zIG90aGVyIGhvc3RpbmcgY29t cGFuaWVzDQp0byBzZWUgd2hhdCB0aGVpciBJUHY2IGFkZHJlc3Npbmcgc3RydWN0dXJlIGlz ICYgbGV0IHlvdSBhbGwga25vdy4gICBJIGNhbiBhbHNvDQpjYWxsIDUgLSAxMCBsYXJnZSBl bnRlcnByaXNlIGNvbXBhbmllcyBpbiB0aGUgVVMgKEZvcnR1bmUgNTAwICYgbGFyZ2UgZmVk ZXJhbA0KYWdlbmNpZXMgJiB0aGUgbGlrZSkgdG8gdGVsbCB5b3UgaWYgdGhleSB0YWtlIHN1 Y2ggdGhpbmdzIGludG8gY29uc2lkZXJhdGlvbi4NCg0KQSBmZXcgeWVhcnMgYWdvLCBJIGNv bXBpbGVkIElQdjYgYWRkcmVzc2luZyBwbGFucyAoc3VibmV0IHN0cnVjdHVyZSwNCm5hbWlu ZyBjb252ZW50aW9ucywgZXRjKSBmcm9tIDYgLSA3IHVuaXZlcnNpdGllcyAoY29tbWVyY2lh bCBlbnRpdGllcyB3aWxsDQpnZW5lcmFsbHkgbm90IHNwZWFrIHB1YmxpY2x5IGFib3V0IGhv dyB0aGV5IGRvIHRoaW5ncykuICAgSSBjYW4gdGVsbCB5b3UgdGhlcmUNCndlcmUgbm8gc3Vj aCBjb25zaWRlcmF0aW9ucyBpbiB0aGVpciBwbGFucy4gIEkgY2FuIGdvIGJhY2sgYW5kIGFz ayB0aGVtDQppZiB0aGV5IHdpbGwgYWxsb3cgbWUgdG8gZGlzdHJpYnV0ZSB0aGVpciBwbGFu cyBwdWJsaWNseS4NCg0KDQpBbGwgdGhpcyB3aWxsIHRha2UgbWUgYSBmZXcgZGF5cywgc28g bWF5YmUgd2UgY2FuIHBpY2sgdXAgdGhlIGRpc2N1c3Npb24NCm9uIFdlZCAvIFRodXJzIG9m IG5leHQgd2Vlay4NCg0KSSBiZWxpZXZlIHRoYXQgZ3VpZGFuY2Ugb24gbmV0d29yayBkZXNp Z24gaXMgbmVlZGVkIGZvciBlbmQtdXNlciBzaXRlcyAtDQppbmNsdWRpbmcgaG9zdGluZyBj b21wYW5pZXMuICAgVGhhdCB3YXMgdGhlIHJlYXNvbiBmb3Igb3VyIGRyYWZ0LiAgSWYgSSBh bQ0Kd3JvbmcgYW5kIG5vIHN1Y2ggZ3VpZGFuY2UgaXMgbmVlZGVkLCB0aGVuIEkgd2lsbCBi ZSBxdWlldCBhbmQgd2l0aGRyYXcNCnRoZSBkcmFmdC4NCg0KTmFsaW5pDQoNCgoKVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNv bmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3Ry aWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55 IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdp dGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2Yg TWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9m aXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUg Q3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo= --_000_4FC37E442D05A748896589E468752CAA0CCCAF4BPWN401EA160entc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHJlc3BvbnNl IHRvIGhvdyBtdWNoIHJlbGF0aXZlIGtub3dsZWRnZSB0aGVyZSBpcyBvbiBJUFY2IGFuZCB0 aGUgdW5kZXJzdGFuZGluZyB0aGF0IGlzc3VlcyBzdWNoIGFzIHRoaXMgbWF5IGV4aXN04oCm 4oCmLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gbW9zdCBjb3Jw b3JhdGUgYW5kIGVudGVycHJpc2Ugd29ybGRzIHRoYXQgSSBkZWFsIHdpdGgsIHdoaWNoIGlz IHByaW1hcmlseSBGaW5hbmNpYWwsIGluc3VyYW5jZSBhbmQgSGVhbHRoIENhcmUsJm5ic3A7 Jm5ic3A7IHRoZSBhbnN3ZXIgaXMgbmVhcmx5IHplcm8uJm5ic3A7Jm5ic3A7IEkgZmluZCB0 aGlzDQogdW5mb3J0dW5hdGUgYW5kIGZydXN0cmF0aW5nLCAmbmJzcDtidXQgdHJ1ZS4mbmJz cDsmbmJzcDsgSSBhbmQgYSBmZXcgb3RoZXJzIGFyZSB0cnlpbmcgdG8gY2hhbmdlIHRoaXMg YW5kIGV2YW5nZWxpemUgSVB2NiwgYnV0IHdlIGFyZSBwdXNoaW5nIHJvcGVzIHVwIGhpbGxz IGluIHRoZXNlIGVudmlyb25tZW50cy4mbmJzcDsmbmJzcDsmbmJzcDsgTW9zdCBsYXJnZSBl bnRlcnByaXNlcyB3YW50IHRvIGF2b2lkIElQdjYgYXMgbG9uZyBhcyBwb3NzaWJsZSBhbmQg bG9vayBmb3IgZXhjdXNlcyB0byBkbw0KIHNvLiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBmdWxseSByZWNvZ25pemUg dGhhdCB0aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZHJhZnQs ICZuYnNwO21heSBiZSBjb25zaWRlcmVkIGVsZW1lbnRhcnksICZuYnNwO3RyaXZpYWwsICZu YnNwO29yIGV2ZW4gdW5uZWNlc3NhcnkgaW4gSUVURiBjaXJjbGVzLCBidXQNCiBJIGNhbiBn dWFyYW50ZWUgeW91IHRoYXQgdGhlIHByZXBvbmRlcmFuY2Ugb2YgbmV0d29yayB0ZWNobmlj aWFucyBpbiZuYnNwOyB0aGUgY29ycG9yYXRlIHdvcmxkIGRvIG5vdCBldmVuIGtub3cgdGhl c2UgcHJvdG9jb2xzIGV4aXN0LCBtdWNoIGxlc3MgdW5kZXJzdGFuZCB0aGUgcG90ZW50aWFs IGRhbWFnZSB0aGV5IGNhbiBpbmZsaWN0LiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgc3VzcGljaW9uIHJlZ2FyZGlu ZyDigJxIb3N0aW5nIENvbXBhbmllc+KAnSwmbmJzcDsgaXMgdGhhdCB0aGVpciBJUHY2IGtu b3dsZWRnZSBsZXZlbHMgbGllIHNvbWV3aGVyZSBhYm92ZSB0aGUgZGVhcnRoIG9mIGNvcnBv cmF0ZSBBbWVyaWNhLCBidXQgd2VsbCBiZWxvdyB0aGUga25vd2xlZGdlDQogbGV2ZWwgb2Yg dGhvc2UgaW52b2x2ZWQgaW4gSUVURi4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGVyZWZvcmUsIEkgYmVsaWV2ZSB0aGF0IGluZm9ybWF0aW9uIGFuZCBhZHZpY2UsIHN1 Y2ggYXMgY29udGFpbmVkIGluIHRoaXMgZHJhZnQsIHdpbGwgYmUgdmVyeSBoZWxwZnVsIHRv IHRob3NlIG5vdCBwcm9maWNpZW50IGluIElQdjYgYW5kIGhlbmNlIHBvc2l0aXZlIHRvDQog dGhlIGNhdXNlIG9mIHByb21vdGluZyBJUHY2IGRlcGxveW1lbnQuJm5ic3A7IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmFsaW5pIEVsa2lu czxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgU2VwdGVtYmVyIDIwLCAyMDE0IDc6MjUg UE08YnI+DQo8Yj5Ubzo8L2I+IE5pY2sgSGlsbGlhcmQ7IEFuZHJldyDwn5G9IFlvdXJ0Y2hl bmtvPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1lbGtpbnMtdjZvcHMtbXVsdGljYXN0LXZpcnR1 YWwtbm9kZXNAdG9vbHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZWxraW5zLXY2b3BzLW11bHRp Y2FzdC12aXJ0dWFsLW5vZGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5PbiAyMC8wOS8yMDE0IDE1OjE1LCBOYWxpbmkgRWxraW5zIHdy b3RlOjxicj4NCiZndDsgU2l0dWF0aW9uOiZuYnNwOyBub2RlIEEgaXMgb24gYSBzdWJuZXQg d2l0aCAyNSBvdGhlciBub2RlcyAoQi1aKTxicj4NCiZndDs8YnI+DQomZ3Q7IDEuJm5ic3A7 IE5vZGUgQSBzZW5kcyAxMCBJQ01QIHBpbmcgcmVxdWVzdHMgdG8gRkYwMjo6MTxicj4NCiZn dDsgMi4mbmJzcDsgTm9kZXMgQiB0aHJvdWdoIFogc2VuZCBOb2RlIEEgYmFjayBJQ01QIDEw IHBpbmcgcmVwbGllcyBlYWNoPGJyPg0KJmd0Ozxicj4NCiZndDsgSW1wYWN0OiB3aXRoIHZl cnkgbGl0dGxlIHdvcmsgYnkgTm9kZSBBLCBoZSBoYXMgbWFkZSBCIC0gWiBkbyB3b3JrICZh bXA7PGJyPg0KJmd0OyBjcmVhdGVkIG5ldHdvcmsgY29uZ2VzdGlvbiB3aXRoIDI1MCYjNDM7 IHBhY2tldHMuPGJyPg0KPGJyPg0KJmd0O0lmIHRoZSBob3N0aW5nIHByb3ZpZGVyIGhhcyBh bnkgc2Vuc2UsIHRoaXMgd2lsbCBjb3VudCB0b3dhcmRzIG5vZGUgQSdzIDxicj4NCiZndDti YW5kd2lkdGggYWxsb2NhdGlvbiBhbmQgaWYgdGhleSBwZXJzaXN0IGluIGRvaW5nIHRoaXMs IHRoZXkgd2lsbCBlbmQgdXAgPGJyPg0KJmd0O3dpdGggYSBsYXJnZSBiaWxsIGFzIHdlbGwg YXMgaGF2aW5nIHRyYXNoZWQgdGhlaXIgY29ubmVjdGl2aXR5Ljxicj4NCjxicj4NCiZndDtU aGUgbGVzc29uIGlzIHRoYXQgaWYgeW91IHNob290IHlvdXJzZWxmIGluIHRoZSBmb290LCBp dCB3aWxsIGh1cnQuJm5ic3A7IElmIDxicj4NCiZndDt5b3VyIG5ldHdvcmsgZGVzaWduIGlz IHN1Y2ggdGhhdCBzaG9vdGluZyB5b3Vyc2VsZiBpbiB0aGUgZm9vdCBjYXVzZXMgb3RoZXIg PGJyPg0KJmd0O2hvc3RzIHRvIGJlIHNob3QgaW4gdGhlIGZvb3QsIHRoZW4geW91ciBuZXR3 b3JrIGRlc2lnbiBtYXkgaGF2ZSBhIHByb2JsZW0uPGJyPg0KPGJyPg0KJmd0O0lmIHlvdSBh cmUgYSBjb21tZXJjaWFsIGhvc3RpbmcgcHJvdmlkZXIgd2hvIHByb3ZpZGVzIHRoaXJkIHBh cnR5IHNoYXJlZCA8YnI+DQomZ3Q7dGVuYW5jeSBuZXR3b3JrcyB3aGljaCB1c2UgdGhpcyBk ZXNpZ24sIHRoZW4geW91IHNob3VsZCBleHBlY3QgcHJvYmxlbXMgb2YgPGJyPg0KJmd0O3Ro aXMgc29ydC48YnI+DQo8YnI+DQomZ3Q7TW9zdCBob3N0aW5nIHByb3ZpZGVycyBrbm93IHRo ZXNlIHRoaW5ncyBhbmQgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIElFVEYgPGJyPg0KJmd0 O3RvIHJlbWluZCB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlYWxseT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5TbyB0aGVuLCBhcmUgeW91IHNheWluZyB0aGF0IHRoZSBob3N0aW5nIGNvbXBhbnkg ZXhhbXBsZSB3ZSBnYXZlIHdhcyBmb3IgYSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnBhcnRpY3VsYXJseSBpZ25v cmFudCZuYnNwO29yIGluY29tcGV0ZW50IGZpcm0/ICZuYnNwOyBUaGF0IG1vc3QgaG9zdGlu ZyBwcm92aWRlcnMgb2YgSVB2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnNlcnZpY2VzIGFuZCBtb3N0IGVuZCB1c2VyIGVu dGVycHJpc2VzIChiZWNhdXNlIG91ciBkcmFmdCBpcyBmb3IgdGhlbSBhcyB3ZWxsKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PmFyZSBxdWl0ZSB3ZWxsIGF3YXJlIG9mIHRoZSBwb3RlbnRpYWwgZHJhd2JhY2tzIGFuZCBp bXBsaWNhdGlvbnMgb2YgSVB2NiBsaW5rLWxvY2FsJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+YW5kIG11bHRpY2Fz dCZuYnNwO3RyYWZmaWMgaW4gdGhlIGRlc2lnbiBvZiB0aGVpciBzdWJuZXRzIG9yIGJyb2Fk Y2FzdCBkb21haW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkFuZCwgZnVydGhlcm1vcmUgdGFrZSBzdWNoIHRyYWZmaWMg YW5kIC8gb3IgdGhlIG5lZWQgZm9yIGlzb2xhdGlvbiBvZiBub2RlcyBmb3I8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5zZWN1 cml0eSBvciZuYnNwO3JlZ3VsYXRvcnkgcHVycG9zZXMgaW50byBhY2NvdW50IHdoZW4gZG9p bmcgdGhlaXIgbmV0d29yayBkZXNpZ24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW5kLCBiYXNpY2Fs bHksIHRoZSBpc3N1ZXMgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGJyaW5nIHVwIGFyZSBxdWl0 ZSB3ZWxsIGtub3duJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dG8gZXZlcnlvbmUuICZuYnNwOyZuYnNwO1lvdSBj b3VsZCBiZSByaWdodCAoYnV0IEkgYW0gYmV0dGluZyBhZ2FpbnN0IGl0ISkuICZuYnNwOyAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5NYXliZSBteSBjby1hdXRob3IsIHdobyZuYnNwO3dv cmtzIGZvciBhIGxhcmdlIGVuZC11c2VyIGVudGVycHJpc2UsIGFuZCB3aG9zZSZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPm9yZ2FuaXphdGlvbiBpcyB0cnlpbmcgdG8mbmJzcDtpbXBsZW1lbnQgSVB2NiwmbmJz cDtjYW4gY2hpbWUgaW4gYW5kIGxldCB1cyBrbm93IGhvdyZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPndlbGwga25v d24gdGhlc2UgaXNzdWVzJm5ic3A7YXJlIGluIGhpcyBvd24gb3JnYW5pemF0aW9uIGFuZCB0 aG9zZSBoZSBzcGVha3MgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5yZWd1bGFybHkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWF5 YmUgb3RoZXIgZW50ZXJwcmlzZSBjdXN0b21lcnMgb24gdGhlIGxpc3QgY2FuIHNwZWFrIGFz IHdlbGwuICZuYnNwO1dvdWxkIGxvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj50byBoZWFyIGZyb20gdGhlbS4gJm5ic3A7 SGF2aW5nIHNhaWQgdGhhdCwgcHJvYmFibHkgaWYgdGhleSBhcmUgb24gdGhpcyBlbWFpbCBs aXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPnRoZXkgYXJlIHByb2JhYmx5IG9yZGVycyBvZiBtYWduaXR1ZGUgbW9yZSBz b3BoaXN0aWNhdGVkIHRoYW4gbW9zdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGNhbiBhbHNvIHRh a2UgYW4gaW5mb3JtYWwgcG9sbC4gJm5ic3A7IEkgY2FuIGNhbGwgMiAtMyBvdGhlciBob3N0 aW5nIGNvbXBhbmllcyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnRvIHNlZSB3aGF0IHRoZWlyIElQdjYgYWRkcmVz c2luZyZuYnNwO3N0cnVjdHVyZSBpcyAmYW1wOyBsZXQgeW91IGFsbCBrbm93LiAmbmJzcDsg SSBjYW4gYWxzbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPmNhbGwmbmJzcDs1IC0gMTAgbGFyZ2UgZW50ZXJwcmlzZSZuYnNw O2NvbXBhbmllcyBpbiB0aGUgVVMgKEZvcnR1bmUgNTAwICZhbXA7IGxhcmdlIGZlZGVyYWwm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5hZ2VuY2llcyAmYW1wOyZuYnNwO3RoZSBsaWtlKSB0byB0ZWxsIHlvdSBp ZiB0aGV5IHRha2Ugc3VjaCB0aGluZ3MgaW50byBjb25zaWRlcmF0aW9uLiAmbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5BIGZldyB5ZWFycyBhZ28sIEkgY29tcGlsZWQgSVB2NiBh ZGRyZXNzaW5nIHBsYW5zIChzdWJuZXQgc3RydWN0dXJlLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPm5hbWluZyBjb252ZW50 aW9ucywgZXRjKSBmcm9tIDYgLSA3IHVuaXZlcnNpdGllcyAoY29tbWVyY2lhbCBlbnRpdGll cyB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Z2VuZXJhbGx5IG5vdCBzcGVhayBwdWJsaWNseSBhYm91dCBob3cgdGhl eSBkbyB0aGluZ3MpLiAmbmJzcDsgSSBjYW4gdGVsbCB5b3UgdGhlcmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj53ZXJlIG5v IHN1Y2ggY29uc2lkZXJhdGlvbnMgaW4gdGhlaXIgcGxhbnMuICZuYnNwO0kgY2FuIGdvIGJh Y2sgYW5kIGFzayB0aGVtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+aWYgdGhleSB3aWxsIGFsbG93IG1lIHRvIGRpc3RyaWJ1 dGUgdGhlaXIgcGxhbnMgcHVibGljbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ieXF0ZmQyODQ5NCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGwgdGhpcyB3 aWxsIHRha2UgbWUgYSBmZXcgZGF5cywgc28gbWF5YmUgd2UgY2FuIHBpY2sgdXAgdGhlIGRp c2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9InlxdGZk Mjg0OTQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+b24gV2VkIC8gVGh1cnMgb2YgbmV4dCB3 ZWVrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXF0ZmQyODQ5 NCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9InlxdGZkMjg0OTQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ SSBiZWxpZXZlIHRoYXQgZ3VpZGFuY2Ugb24gbmV0d29yayBkZXNpZ24gaXMgbmVlZGVkIGZv ciBlbmQtdXNlciBzaXRlcyAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJ5cXRmZDI4NDk0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmluY2x1ZGluZyBob3N0 aW5nIGNvbXBhbmllcy4gJm5ic3A7Jm5ic3A7VGhhdCB3YXMgdGhlIHJlYXNvbiBmb3Igb3Vy IGRyYWZ0LiAmbmJzcDtJZiBJIGFtJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJ5cXRmZDI4NDk0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPndyb25n IGFuZCBubyBzdWNoIGd1aWRhbmNlJm5ic3A7aXMgbmVlZGVkLCB0aGVuIEkgd2lsbCBiZSBx dWlldCBhbmQgd2l0aGRyYXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9InlxdGZkMjg0OTQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dGhlIGRyYWZ0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXF0ZmQyODQ5NCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9InlxdGZkMjg0OTQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TmFsaW5pPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0KCgo8 QlI+CjxodG1sPgogPHA+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11 bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5p Y2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5n LCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHBy b2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWls IG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRo ZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuPC9wPgogPHA+ Qmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdv cmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5k ZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2Np YXRpb24uPC9wPgogIDwvaHRtbD4KCg== --_000_4FC37E442D05A748896589E468752CAA0CCCAF4BPWN401EA160entc_-- From nobody Sun Sep 21 11:00:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394751A0336 for ; Sun, 21 Sep 2014 11:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.387 X-Spam-Level: X-Spam-Status: No, score=-113.387 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btB4HJAGyS_P for ; Sun, 21 Sep 2014 11:00:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34661A0183 for ; Sun, 21 Sep 2014 11:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=931; q=dns/txt; s=iport; t=1411322407; x=1412532007; h=date:from:message-id:to:subject:cc; bh=GOWp874INSmXioCUmxMxtLvo/C5c/BD4luqrJWInnho=; b=Mqjs7B577ojHKhLpNW/82aXD29t9b7DAoQlYtB5m9635p3hdKY72h9yz QqbZBH5Gvk00tqiE+5IZchIYmWgB7929zlAFTmzLQQHy7eRcH8IStL7CV PocB+GUvKVoRNGiipGY7xBdO/7WC8w9l9WBANbPRq9AoZMq5Anv29o59Y Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgIAAARH1StJA2D/2dsb2JhbABggw5TWLhTAZESh01/FgF5hQM8NIkeAQ3DHQEXjyQRAVAdhDUFi0WKSohoilOJHoQBgVuBOwEBAQ X-IronPort-AV: E=Sophos;i="5.04,566,1406592000"; d="scan'208";a="356978008" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 21 Sep 2014 18:00:05 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8LI057F014667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2014 18:00:05 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s8LI03J4021623; Sun, 21 Sep 2014 11:00:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s8LI03jP021622; Sun, 21 Sep 2014 11:00:03 -0700 Date: Sun, 21 Sep 2014 11:00:03 -0700 From: fred@cisco.com Message-Id: <201409211800.s8LI03jP021622@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qbCKMvEoKG_V9mBjijY6xoVCOoU Subject: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 18:00:09 -0000 On this draft, we have something of a special case. We discussed the draft and sent it to the IESG a year ago. In IETF Last Call, several comments were raised, and the document returned to the working group. A year later, my understanding is that the comments have finally been resolved, although one of the persons who commented continues to object to the use of PCP, and one of the persons, although specifically polled in private email, has not responded publicly or privately. Hence, I want to run an another single week WGLC on http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile. Please read it now. If you have comments of any kind, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Mon Sep 22 00:50:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555FA1A1A58 for ; Mon, 22 Sep 2014 00:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.185 X-Spam-Level: * X-Spam-Status: No, score=1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 GjCFBMMxEf9Z for ; Mon, 22 Sep 2014 00:50:56 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1571A1A5A for ; Mon, 22 Sep 2014 00:50:54 -0700 (PDT) Received: from 10.236.62.154 (EHLO OPE10HT06.tp.gk.corp.tepenet) ([10.236.62.154]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id CNG60428; Mon, 22 Sep 2014 09:50:48 +0200 (CEST) From: Kossut Tomasz - Hurt To: "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC Thread-Index: AQHP1c5FRU77DNlQL0+cQlxqo/LYH5wMwqjg Date: Mon, 22 Sep 2014 07:50:47 +0000 Message-ID: References: <201409211800.s8LI03jP021622@irp-lnx1.cisco.com> In-Reply-To: <201409211800.s8LI03jP021622@irp-lnx1.cisco.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.9.22.70019:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, __ANY_URI, __URI_NO_WWW, __CP_URI_IN_BODY, __FRAUD_CONTACT, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __FORWARDED_MSG, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1800_1899, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0201.541FD4D9.001D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0201.541FD4D9.001D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8e0b6b31f92819ddabb8fd5de65e4dca Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/koIImCYDdHmRp0djhBDNxiV_YpE Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile 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: Mon, 22 Sep 2014 07:50:57 -0000 Hi, The" roaming profile" should allow to configure different APN name.=20 Possibility of using different APN name in "roaming profile" opens new sche= mes for ipv4 fallback. Regards, tk C_REC#13: Because of potential operational deficiencies to be experienced in some roaming situations, the cellular host must be able to be configured with a home IP profile and a roaming IP profile. The aim of the roaming profile is to limit the PDP type(s) requested by the cellular host when out of the home network. Note, distinct PDP type(s) can be configured for home and roaming cases. -----Original Message----- From: fred@cisco.com [mailto:fred@cisco.com]=20 Sent: Sunday, September 21, 2014 8:00 PM To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC On this draft, we have something of a special case. We discussed the draft = and sent it to the IESG a year ago. In IETF Last Call, several comments wer= e raised, and the document returned to the working group. A year later, my = understanding is that the comments have finally been resolved, although one= of the persons who commented continues to object to the use of PCP, and on= e of the persons, although specifically polled in private email, has not re= sponded publicly or privately. Hence, I want to run an another single week WGLC on http://tools.ietf.org/h= tml/draft-ietf-v6ops-mobile-device-profile. =20 Please read it now. If you have comments of any kind, please post your comm= ents to the list. We are looking specifically for comments on the importance of the document = as well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to make. From nobody Mon Sep 22 01:09:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7B1A1A5F for ; Mon, 22 Sep 2014 01:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 0hsNbDRb2gcT for ; Mon, 22 Sep 2014 01:09:02 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851741A1A5C for ; Mon, 22 Sep 2014 01:09:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6B58DA6; Mon, 22 Sep 2014 10:09:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1411373340; bh=tRwUTXXMQkWRmEeO/ihy6Q+eGH0vfPieg8spg3KFkeY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BXyPcdDZRztMfojLbtQLYxha1Hd6UUbIlmB8TQN2XfQJ17B8fii5TAZ83BXbVduKq 4rI/7ll1eOsj5U1DeuX/6GC+TayjaRgJnoOpktZxJcid6HR96kiDXuEkZqgts+ZvzN 0Vcqanco4msfZeUmkpXkjpum9MZ8Q110kwoju+GE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 66FE3A5; Mon, 22 Sep 2014 10:09:00 +0200 (CEST) Date: Mon, 22 Sep 2014 10:09:00 +0200 (CEST) From: Mikael Abrahamsson To: Nalini Elkins In-Reply-To: <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> Message-ID: References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> <1411255504.4053.YahooMailNeo@web125102.mail.ne1.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; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OCj_PTzhedyODDQTsnDIAXbRbYo Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 08:09:04 -0000 On Sat, 20 Sep 2014, Nalini Elkins wrote: > So then, are you saying that the hosting company example we gave was for a > particularly ignorant or incompetent firm? That most hosting providers of IPv6 No, I think the general thinking is that they're of average ignorance and competency, which doesn't say much. The general advice both for IPv4 and IPv6 is not to put a huge amount of nodes in the same L2 domain. This has been true for 30 years, that's why IP replaced the L2 bridged protocols or lots-of-years-ago. If you're putting 284 nodes in the same broadcast domain, you're asking for trouble. My advice is to separate customers into separate L2 domains, or make sure your L2 infrastructure has some L3 functionality, for instance private-vlan or other filtering. So while your draft describes a problem that might be there, asking for nodes to not respond to link-local FF0x::1 ICMP ECHO REQUEST isn't the correct solution. Btw, how does the data center you've done testing on implement BCP38 so that the customers can't originate packets for addresses they do not "own"? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 22 01:34:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EB21A0052 for ; Mon, 22 Sep 2014 01:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcWgErpRw2zJ for ; Mon, 22 Sep 2014 01:34:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA751A004D for ; Mon, 22 Sep 2014 01:33:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B069D22C1E9; Mon, 22 Sep 2014 10:33:55 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A03BB23807B; Mon, 22 Sep 2014 10:33:55 +0200 (CEST) Received: from omfedm08.si.francetelecom.fr by omfedm08.si.francetelecom.fr with queue id 201287-34; Mon, 22 Sep 2014 08:33:55 GMT Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 82E6123806C; Mon, 22 Sep 2014 10:33:55 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.127]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 10:33:55 +0200 From: To: Kossut Tomasz - Hurt , "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC Thread-Index: AQHP1c5FRU77DNlQL0+cQlxqo/LYH5wMwqjggAAQRWA= Date: Mon, 22 Sep 2014 08:33:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933006BD38@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201409211800.s8LI03jP021622@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.22.52121 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XvJ8KfMNG3o01WUqEhAE-VBRRIo Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile 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: Mon, 22 Sep 2014 08:34:05 -0000 Hi Tomasz, Thank you for the comment. The current text does not prevent that but in order to avoid any misinterpr= etation of the text, I made the current change: OLD: out of the home network. Note, distinct PDP type(s) can be configured for home and roaming cases. NEW: out of the home network. Note that distinct PDP type(s) and APN(s) can be configured for home and roaming cases.=20 ^^^^^^^^^^ Better? Cheers, Med >-----Message d'origine----- >De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Kossut Tomasz - >Hurt >Envoy=E9=A0: lundi 22 septembre 2014 09:51 >=C0=A0: fred@cisco.com; v6ops@ietf.org >Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC > >Hi, > >The" roaming profile" should allow to configure different APN name. >Possibility of using different APN name in "roaming profile" opens new >schemes for ipv4 fallback. >Regards, >tk > >C_REC#13: Because of potential operational deficiencies to be > experienced in some roaming situations, the cellular host > must be able to be configured with a home IP profile and a > roaming IP profile. The aim of the roaming profile is to > limit the PDP type(s) requested by the cellular host when > out of the home network. Note, distinct PDP type(s) can > be configured for home and roaming cases. > >-----Original Message----- >From: fred@cisco.com [mailto:fred@cisco.com] >Sent: Sunday, September 21, 2014 8:00 PM >To: v6ops@ietf.org >Subject: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC > >On this draft, we have something of a special case. We discussed the draft >and sent it to the IESG a year ago. In IETF Last Call, several comments >were raised, and the document returned to the working group. A year later, >my understanding is that the comments have finally been resolved, although >one of the persons who commented continues to object to the use of PCP, an= d >one of the persons, although specifically polled in private email, has not >responded publicly or privately. > >Hence, I want to run an another single week WGLC on >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile. >Please read it now. If you have comments of any kind, 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 nobody Mon Sep 22 07:54:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4DB1A1AF3 for ; Mon, 22 Sep 2014 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.185 X-Spam-Level: * X-Spam-Status: No, score=1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 I7_G8DyqyX65 for ; Mon, 22 Sep 2014 07:54:16 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02691A1ABA for ; Mon, 22 Sep 2014 07:54:11 -0700 (PDT) Received: from 10.236.62.151 (EHLO OPE10HT01.tp.gk.corp.tepenet) ([10.236.62.151]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id CNH85492; Mon, 22 Sep 2014 16:54:06 +0200 (CEST) From: Kossut Tomasz - Hurt To: BOUCADAIR Mohamed IMT/OLN , "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC Thread-Index: AQHP1c5FRU77DNlQL0+cQlxqo/LYH5wMwqjggAAQRWCAACzwQA== Date: Mon, 22 Sep 2014 14:52:54 +0000 Message-ID: References: <201409211800.s8LI03jP021622@irp-lnx1.cisco.com> <787AE7BB302AE849A7480A190F8B933006BD38@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933006BD38@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2014.9.22.140622:17:7.944, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, __ANY_URI, __URI_NO_PATH, __CP_URI_IN_BODY, __FRAUD_CONTACT, __SUBJ_ALPHA_NEGATE, __FORWARDED_MSG, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0204.5420380F.0067, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0204.5420380F.0067, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8e0b6b31f92819ddabb8fd5de65e4dca Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g1c4dcCU-zIS1zIxznL7ETaHDIg Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile 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: Mon, 22 Sep 2014 14:54:18 -0000 IPv6 transition is booming in mobile networks therefore removing limits aro= und APN is crucial=20 Regards, TK -----Original Message----- From: BOUCADAIR Mohamed IMT/OLN [mailto:mohamed.boucadair@orange.com]=20 Sent: Monday, September 22, 2014 10:34 AM To: Kossut Tomasz - Hurt; fred@cisco.com; v6ops@ietf.org Subject: RE: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC Hi Tomasz, Thank you for the comment. The current text does not prevent that but in order to avoid any misinterpr= etation of the text, I made the current change: OLD: out of the home network. Note, distinct PDP type(s) can be configured for home and roaming cases. NEW: out of the home network. Note that distinct PDP type(s) and APN(s) can be configured for home and roaming cases.=20 ^^^^^^^^^^ Better? Cheers, Med >-----Message d'origine----- >De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Kossut Tomasz=20 >- Hurt Envoy=E9=A0: lundi 22 septembre 2014 09:51 =C0=A0: fred@cisco.com;= =20 >v6ops@ietf.org Objet=A0: Re: [v6ops]=20 >draft-ietf-v6ops-mobile-device-profile WGLC > >Hi, > >The" roaming profile" should allow to configure different APN name. >Possibility of using different APN name in "roaming profile" opens new=20 >schemes for ipv4 fallback. >Regards, >tk > >C_REC#13: Because of potential operational deficiencies to be > experienced in some roaming situations, the cellular host > must be able to be configured with a home IP profile and a > roaming IP profile. The aim of the roaming profile is to > limit the PDP type(s) requested by the cellular host when > out of the home network. Note, distinct PDP type(s) can > be configured for home and roaming cases. > >-----Original Message----- >From: fred@cisco.com [mailto:fred@cisco.com] >Sent: Sunday, September 21, 2014 8:00 PM >To: v6ops@ietf.org >Subject: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC > >On this draft, we have something of a special case. We discussed the=20 >draft and sent it to the IESG a year ago. In IETF Last Call, several=20 >comments were raised, and the document returned to the working group. A=20 >year later, my understanding is that the comments have finally been=20 >resolved, although one of the persons who commented continues to object=20 >to the use of PCP, and one of the persons, although specifically polled=20 >in private email, has not responded publicly or privately. > >Hence, I want to run an another single week WGLC on=20 >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile. >Please read it now. If you have comments of any kind, please post your=20 >comments to the list. > >We are looking specifically for comments on the importance of the=20 >document as well as its content. If you have read the document and=20 >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 nobody Mon Sep 22 08:26:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0B1A1AF5 for ; Mon, 22 Sep 2014 08:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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.786, 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 O6JlNVXJvpUt for ; Mon, 22 Sep 2014 08:26:37 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11EC1A1B35 for ; Mon, 22 Sep 2014 08:26:35 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rd18so2338414iec.19 for ; Mon, 22 Sep 2014 08:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VhEFbtT22xc1W9gICOhpZMCKJeNN/ynP8qO4rG4LCys=; b=oObohEchM65wrAn67RY/AQHEKxbMg4+FeiGLj7huDlwd0C2ZNUFDLQZulSX57DHb6G NGXLClzQ/iXqOeJeymoO09XQMcWmxXbcG+7oWYhS6SZ7/i1OD7SIdxj+uY3qbAg2n2q7 eNnn9AQVLN7iF+leqRLAKJRzXdWV3NCU/PA4vv8tXVyCEYlF4xbUfDXNcH4v4zzErMxy fRTzihpUpNGK4Wi7RzaOPiDhdQOtO5ZyMKOUPwEuD2jaB77rO21mJPHGw/2HjD/iIjMg bF/zD/k30Tz0YbA3jW10o1l/uvSbFVdGdYL5z+F0KYQGhomP8rBvAeToPtpgwi4tW7+t PHmg== 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=VhEFbtT22xc1W9gICOhpZMCKJeNN/ynP8qO4rG4LCys=; b=fW8HV4CO2+pCIFt7vg5S/+oW22pvFKYHirk158NCeJjAhB7+q0VCTV+okEUHmliQLK ur/e8W2AXNa02cuAoJAzU7+ov4TH4zSAY54aarO0jRoaq03HMCDFJy4dfr0uwauoLHnw DABlUxO8usPhA04mbP89442KUMKFVOyu9FzvCXaUK+yx9TMVF3u0PugbiLhmrgsxVu/m jQmeMwuw1M/+VEDqyf2ln6IX98I9SGSWm8FJZzcl914BHSHXZ1BksCcZzLc9TNxdjnXv MtPPJTZLufVdCBl/zWQYG9IQT0tEyLQrw2BLcmSaX1a8/nsDm/X9z5wktwxRG/higS5d dicg== X-Gm-Message-State: ALoCoQml4salSlqY/dtsKmNwIgRQfGDtPLsgfRPe3Q1M9438OjaTsHqSszgoVcTBQX2DlqB7YYwB X-Received: by 10.50.79.129 with SMTP id j1mr14942786igx.47.1411399595259; Mon, 22 Sep 2014 08:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Mon, 22 Sep 2014 08:26:15 -0700 (PDT) In-Reply-To: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Tue, 23 Sep 2014 00:26:15 +0900 Message-ID: To: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org Content-Type: multipart/alternative; boundary=089e011609fc8332500503a9139c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tn-UJptTALt_EHKdlmkerU4tOfI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 15:26:42 -0000 --089e011609fc8332500503a9139c Content-Type: text/plain; charset=UTF-8 On Fri, Sep 19, 2014 at 8:47 PM, wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please > take a look at it and comment. > What's the use case for this draft? To date, the primary deployment of 464xlat has been in 3GPP (i.e., cellular) networks. In general, these networks do not support DHCPv6. In fact, the fact that 464xlat did not need DHCP was one of the main reasons that the industry went with 464xlat and not something better like DS-Lite or MAP. (464xlat is pretty much the worst.) If you can depend on DHCPv6, there's very little reason to use 464xlat at all. There are much better transition mechanisms available. --089e011609fc8332500503a9139c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 19, 2014 at 8:47 PM, <fred@cisco.com> wrote:
A new draft has been posted, at http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. P= lease take a look at it and comment.

Wh= at's the use case for this draft?

To date, the= primary deployment of 464xlat has been in 3GPP (i.e., cellular) networks. = In general, these networks do not support DHCPv6. In fact, the fact that 46= 4xlat did not need DHCP was one of the main reasons that the industry went = with 464xlat and not something better like DS-Lite or MAP. (464xlat is pret= ty much the worst.)

If you can depend on DHCPv6, t= here's very little reason to use 464xlat at all. There are much better = transition mechanisms available.
--089e011609fc8332500503a9139c-- From nobody Mon Sep 22 08:56:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4A51A1B24 for ; Mon, 22 Sep 2014 08:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=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 z267A71hMXKa for ; Mon, 22 Sep 2014 08:56:20 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF201A00AE for ; Mon, 22 Sep 2014 08:56:20 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C186925D37C7; Mon, 22 Sep 2014 15:56:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C1790C7700C; Mon, 22 Sep 2014 15:56:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id NxmVvTiaLHck; Mon, 22 Sep 2014 15:56:15 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0A678C76FD1; Mon, 22 Sep 2014 15:56:09 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Bjoern A. Zeeb" In-Reply-To: Date: Mon, 22 Sep 2014 15:56:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_aM1GWTnACgyHig84yNiYQPAS2g Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 15:56:22 -0000 On 22 Sep 2014, at 15:26 , Lorenzo Colitti wrote: > On Fri, Sep 19, 2014 at 8:47 PM, wrote: > A new draft has been posted, at = http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. = Please take a look at it and comment. >=20 > What's the use case for this draft? >=20 > To date, the primary deployment of 464xlat has been in 3GPP (i.e., = cellular) networks. In general, these networks do not support DHCPv6. In = fact, the fact that 464xlat did not need DHCP was one of the main = reasons that the industry went with 464xlat and not something better = like DS-Lite or MAP. (464xlat is pretty much the worst.) >=20 > If you can depend on DHCPv6, there's very little reason to use 464xlat = at all. There are much better transition mechanisms available. What can I do to my v4-only binary-only socket applications on my = IPv6-only kernel unixy machine? Yes, does exist. A good xlat464 implementation might save my day.=20 =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From nobody Mon Sep 22 09:48:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBAC1A1A60 for ; Mon, 22 Sep 2014 09:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKxGZShDD8F5 for ; Mon, 22 Sep 2014 09:48:54 -0700 (PDT) Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by ietfa.amsl.com (Postfix) with SMTP id 126E91A0203 for ; Mon, 22 Sep 2014 09:48:53 -0700 (PDT) Received: (qmail 53869 messnum 6771129 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 22 Sep 2014 16:48:52 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail11.svc.cra.dublin.eircom.net (qp 53869) with SMTP; 22 Sep 2014 16:48:52 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id uGoo1o00i0mJ9Tz01Gor00; Mon, 22 Sep 2014 17:48:52 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Mon, 22 Sep 2014 17:48:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1298C58D-F3FF-49AD-899A-A3647B0E2A5D@eircom.net> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NO1QoR8WJ2Ka6DfgWui7-c2fPqA Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 16:48:57 -0000 On 22 Sep 2014, at 16:26, Lorenzo Colitti wrote: > , the fact that 464xlat did not need DHCP was one of the main reasons = that the industry went with 464xlat and not something better like = DS-Lite or MAP. (464xlat is pretty much the worst.) >=20 > If you can depend on DHCPv6, there's very little reason to use 464xlat = at all. There are much better transition mechanisms available. I think it depends on the version of MAP. I=92d group 464xlat with MAP-T = and DS-Lite with MAP-E, the former translating headers and the latter = encapsulating. AFAIK DPI for IPv4 in IPv6 traffic is not supported by my GGSN/PGW = vendor.=20 In 3GPP Mobile 464xlat is a good, proven solution. DS-Lite goes back to = a central AFTR inheriting the limitations of NAT44.=20 BR=20 Ross From nobody Mon Sep 22 09:52:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCEC1A1B0F for ; Mon, 22 Sep 2014 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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.786, 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 WFBWd5OpaOdp for ; Mon, 22 Sep 2014 09:52:37 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3205E1A0203 for ; Mon, 22 Sep 2014 09:52:37 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id a3so3948313oib.41 for ; Mon, 22 Sep 2014 09:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Y1toIneL/ciN3ZHC+GOijY8MG3HodcqKdQI+/9OfDD4=; b=Vln194HYZDrwTdsROZte94N0pLpTOY94GPQOrwNxP5oN4brJiR9qXu5woHmf3TkM1g /W691qm71LqAUqJb4TLVekwmJ/48G7aQ48RUhH6yLyJc8CqkRrcsdJ4OQqd6Ge9kCNh+ dJVavJbDbAyrRTA9xO8Vq6utELf8lckiRK4t81LMJdP+QnWUoqjzHIUkRJZBjJUKsybd fqHbiP1zUkTS4pOz6MdknBGHkIH74KWbA3M2z96+3+71PpqMxyORoGHJMPBsxZ9dwTRH i4t4WxsIvlhMLo45XkxT6yd5fPXFGlhVEa19jjAm7QRhNXa9Ab6AKH0S44YqLbEvJTSK CaZg== 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=Y1toIneL/ciN3ZHC+GOijY8MG3HodcqKdQI+/9OfDD4=; b=DXCXgYV3lQrvNHZjxQlAzL2j4zS6jZA02WcfKOWFUDXaDT05JpSrmeJ5FLh2Hi7GsE xyqEZZC9rCMTqQ/20pbIgsCY0IDiwVFjo6OO8scYhh+53n3Az00JeC/JPx5yOeKXVJiX +GiSXMS70zh2xQPWZ+Xppo3Yk7s+nCkJ3vgkmq/s6lXvMzD6aA15Rxg79IkXC/WJYy4/ Sf98DMeMrnFMIxATGDkHntJUjarkZdzdBGSgitA6eFMYy5vywiwajnNvGMPTa09diVqk Z8HBxKC3OZFkJdVdZNqaQEtIW4nQk8LxEl9/uMjwh8/ADlNjvksvUfqdcrky8nf/rb8J Fomg== X-Gm-Message-State: ALoCoQmad+28EoJF52tOnPFzEiKbfP3cC9AV34gcpvA8FeLZmISyWOdEt/OfBVAqbVd6LquNevVM X-Received: by 10.182.126.233 with SMTP id nb9mr28106410obb.46.1411404756571; Mon, 22 Sep 2014 09:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.109.168 with HTTP; Mon, 22 Sep 2014 09:52:16 -0700 (PDT) In-Reply-To: References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Tue, 23 Sep 2014 01:52:16 +0900 Message-ID: To: "Bjoern A. Zeeb" Content-Type: multipart/alternative; boundary=001a11c1e550268bcf0503aa47f8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DR8DZo62GtH5hvpZ2xKlzPQd7nM Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 16:52:38 -0000 --001a11c1e550268bcf0503aa47f8 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 12:56 AM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > What can I do to my v4-only binary-only socket applications on my > IPv6-only kernel unixy machine? Yes, does exist. > A good xlat464 implementation might save my day. > But you don't need DHCPv6, you can just use DNS64? --001a11c1e550268bcf0503aa47f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 23, 2014 at 12:56 AM, Bjoern A. Zeeb <bzeeb-lists@li= sts.zabbadoz.net> wrote:
W= hat can I do to my v4-only binary-only socket applications on my IPv6-only = kernel unixy machine?=C2=A0 Yes, does exist.
A good xlat464 implementation might save my day.

<= /div>
But you don't need DHCPv6, you can just use DNS64?=C2=A0
--001a11c1e550268bcf0503aa47f8-- From nobody Mon Sep 22 10:55:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B961A1A60 for ; Mon, 22 Sep 2014 10:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcW0ukPWBHkf for ; Mon, 22 Sep 2014 10:55:52 -0700 (PDT) Received: from nm7-vm3.bullet.mail.ne1.yahoo.com (nm7-vm3.bullet.mail.ne1.yahoo.com [98.138.91.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062AD1A1B19 for ; Mon, 22 Sep 2014 10:55:51 -0700 (PDT) Received: from [98.138.100.115] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 22 Sep 2014 17:55:51 -0000 Received: from [98.138.89.174] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 22 Sep 2014 17:55:51 -0000 Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 22 Sep 2014 17:55:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 293661.52438.bm@omp1030.mail.ne1.yahoo.com Received: (qmail 80663 invoked by uid 60001); 22 Sep 2014 17:55:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411408551; bh=kMZvgLi367ZqHhDrknWEMT5c1Zm6b83jfUOWVX1Rqas=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4MXN8AOfkwB8l/mqsM6GNCcD5WnZe6fw0be3nntLBwoVQAsJxwoAPsTIavfK1pIKUyEtyzGE/UwQJ4Fgx0bs1eP/zvax/WF98d4luex0vc+9fTy6K63+xLbONk963aLw2rCgXBzZow3t89oywSUxg9MN6hJVo2jbikEhZWV3Iok= X-YMail-OSG: Pdb5ZHUVM1ko22TeL5O7kQ4xNiag6CVn98BUdbTNXhest3A j._.m29fAmGPBf1CBTlx8.YHzx.U8AdwwL5pSGcK2NugneyM._jQZHWFCl4o b0LhEHiEzKNNjdfq7Gg0Dzusdmfx3fNA9TYGVjWt3daX.l9fhE79jgwbFPxz PsmkUaaI3i4TtyKYiryibXaXIoQiIlpnHja2PVxywkorC8XzxVOENJEWeWVg 32fz3LDRhxvyBYCU1z7.72dDx2QnXl2bC_gSDNJEJbT8SEhhTBVKCixZbQdX oWcDs2SyfxwcMskWKO5o7u6kz5KrGa7mWfPMBQwdGd7WEP9hadsy1bx.gHWH VmSllN6T1pdOAjwEhPBw.E_yTQYhLWqbn5nQ.4PXptWigwq.Y1_WmF1zqMyf l2QFdHrl.c0tKqaAR9mRt12bDZY8nybFUb3guQ_fjzska9bSFO1xUgESN2so xuJBFSo0BqwTT95USterr8RswMLxA6llYjiiYI9M0OnZ0dDwauE8p3zdeBC5 GNHHAbkePXqW.ZAmG4iznM3GUFtiGtFH.UvwryGzgctPEyg-- Received: from [50.185.72.13] by web125104.mail.ne1.yahoo.com via HTTP; Mon, 22 Sep 2014 10:55:50 PDT X-Rocket-MIMEInfo: 002.001, CgpPbiBTYXQsIDIwIFNlcCAyMDE0LCBOYWxpbmkgRWxraW5zIHdyb3RlOgoKPj4gU28gdGhlbiwgYXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUgaG9zdGluZyBjb21wYW55IGV4YW1wbGUgd2UgZ2F2ZSB3YXMgZm9yIGEgCj4.IHBhcnRpY3VsYXJseSBpZ25vcmFudCBvciBpbmNvbXBldGVudCBmaXJtPyAgIFRoYXQgbW9zdCBob3N0aW5nIHByb3ZpZGVycyBvZiBJUHY2Cgo.Tm8sIEkgdGhpbmsgdGhlIGdlbmVyYWwgdGhpbmtpbmcgaXMgdGhhdCB0aGV5J3JlIG9mIGF2ZXJhZ2UgaWdub3JhbmNlIGFuZCAKPmNvbXABMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> Message-ID: <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> Date: Mon, 22 Sep 2014 10:55:50 -0700 From: Nalini Elkins To: Mikael Abrahamsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qhcbmcZ_L-_7YCz9R1Fxyiq9oFk Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:55:53 -0000 On Sat, 20 Sep 2014, Nalini Elkins wrote: >> So then, are you saying that the hosting company example we gave was for a >> particularly ignorant or incompetent firm? That most hosting providers of IPv6 >No, I think the general thinking is that they're of average ignorance and >competency, which doesn't say much. >The general advice both for IPv4 and IPv6 is not to put a huge amount of >nodes in the same L2 domain. This has been true for 30 years, that's why >IP replaced the L2 bridged protocols or lots-of-years-ago. >If you're putting 284 nodes in the same broadcast domain, you're asking >for trouble. My advice is to separate customers into separate L2 domains, >or make sure your L2 infrastructure has some L3 functionality, for >instance private-vlan or other filtering. It is an interesting question of whether 284 is too many or not. I think I prefer to start using a term "administrative domain" (or some such) where those are the nodes that are under a single control for business or security reasons. So, "administrative domain" (AD) and "broadcast domain" (BD) should be the same. For example, if I have three virtual servers (or nodes), then that is my administrative and broadcast domain. If I have a 1,000 nodes under my control, then that is how many that should be in my AD and BD. IPv6 allows for large subnets so why not? But, if I have only 1 node, then having more than one node in my BD is too much. >So while your draft describes a problem that might be there, asking for >nodes to not respond to link-local FF0x::1 ICMP ECHO REQUEST isn't the >correct solution. Possibly not. We wanted to raise the issue. BTW, Pings, as you know, are the precursor to much malicious activity. It is something that someone with ill intent is liable to do readily. And, it provides a huge amount of data on other nodes in a broadcast domain. >Btw, how does the data center you've done testing on implement BCP38 so >that the customers can't originate packets for addresses they do not "own"? No idea. I can try spoofing packets for other prefixes and for my servers. Interestingly, enough, from BCP38 is: "The one MAC address that all devices share in common in normal operation is the media broadcast, or FF:FF:FF:FF:FF:FF. In this case, a device will take the packet and send an interrupt for processing. Thus, a flood of these broadcast frames will consume all available resources on an end-system [9]. It is perhaps prudent that system administrators should consider ensuring that their border routers do not allow directed broadcast packets to be forwarded through their routers as a default." On Linux, I believe when you do a PING, it is continuous until intentionally stopped. So, doing a Ping to FF02::1 from a Linux machine will create havoc without having ill intent. That is, accidentally. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 22 12:22:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706A91A1BAA for ; Mon, 22 Sep 2014 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 yBJhkQf3YKYI for ; Mon, 22 Sep 2014 12:21:54 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 90C501A1B46 for ; Mon, 22 Sep 2014 12:21:53 -0700 (PDT) Received: (qmail 70308 invoked from network); 22 Sep 2014 19:21:51 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Sep 2014 19:21:51 -0000 Date: Mon, 22 Sep 2014 21:21:51 +0200 (CEST) Message-Id: <20140922.212151.41703956.sthaug@nethelp.no> To: nalini.elkins@insidethestack.com From: sthaug@nethelp.no In-Reply-To: <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> References: <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dY59kfdXYjnEHvzT6-VNNkgdQ3w Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 19:22:02 -0000 > It is an interesting question of whether 284 is too many or not. I > think I prefer to start using a term "administrative domain" (or some such) > where those are the nodes that are under a single control for business > or security reasons. > > So, "administrative domain" (AD) and "broadcast domain" (BD) should be the same. > For example, if I have three virtual servers (or nodes), then that is my > administrative and broadcast domain. > > If I have a 1,000 nodes under my control, then that is how many that > should be in my AD and BD. IPv6 allows for large subnets so why not? If you are putting 1000 nodes in the same broadcast domain, you are deliberately ignoring painful lessons which have been learned by many network engineers. > On Linux, I believe when you do a PING, it is continuous until intentionally stopped. So, doing a Ping to FF02::1 from a > Linux machine will create havoc without having ill intent. That is, accidentally. On all the Linux boxes I just tried this on, I get: sthaug@server% ping6 ff02::1 connect: Invalid argument Steinar Haug, AS 2116 From nobody Mon Sep 22 12:43:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08351A1B1B for ; Mon, 22 Sep 2014 12:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 bBrA-fuGLXOL for ; Mon, 22 Sep 2014 12:43:09 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEF31A1AFF for ; Mon, 22 Sep 2014 12:43:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway2.nyi.internal (Postfix) with ESMTP id 04E8C2E67 for ; Mon, 22 Sep 2014 15:43:08 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 22 Sep 2014 15:43:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=X3GqqHSIo+1l4qyR3kwHf7aFilY=; b=Mtu4w 1khUL7y+39Hb/QpxoT6xRjV95EkYiLogZmBeImaiL6bcs7nRR7n62ODbe+AsYt1V 7lNbu4EwiqP1MLTj3Rt9l4EL2AVuPH315Cf3YNHNWj2+Voh+qj9ypM5zBimcxR4q CefV+GUMLSJorLz1M4WvlVaG8eulwjBaFdTNh8= Received: by web1.nyi.internal (Postfix, from userid 99) id B0DBBF008E1; Mon, 22 Sep 2014 15:43:07 -0400 (EDT) Message-Id: <1411414987.4185178.170473277.2FA81688@webmail.messagingengine.com> X-Sasl-Enc: SH0Y1lAjgc5zs/uyzErjmmFvWGMPkLWDbjNth0HShe4F 1411414987 From: Bill Cerveny To: sthaug@nethelp.no, nalini.elkins@insidethestack.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b5aef30d Date: Mon, 22 Sep 2014 15:43:07 -0400 In-Reply-To: <20140922.212151.41703956.sthaug@nethelp.no> References: <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> <20140922.212151.41703956.sthaug@nethelp.no> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LHBWLZCZX42IuoLgQWIp8znSnpk Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 19:43:10 -0000 On Mon, Sep 22, 2014, at 03:21 PM, sthaug@nethelp.no wrote: > > On all the Linux boxes I just tried this on, I get: > > sthaug@server% ping6 ff02::1 > connect: Invalid argument > Try specifying the interface, such as: ping6 -I eth0 ff02::1 Bill Cerveny > Steinar Haug, AS 2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 22 12:56:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688261A1B39 for ; Mon, 22 Sep 2014 12:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 s2msbQM4cgv6 for ; Mon, 22 Sep 2014 12:56:18 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 4C7641A1B35 for ; Mon, 22 Sep 2014 12:56:17 -0700 (PDT) Received: (qmail 70635 invoked from network); 22 Sep 2014 19:56:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Sep 2014 19:56:16 -0000 Date: Mon, 22 Sep 2014 21:56:16 +0200 (CEST) Message-Id: <20140922.215616.71157602.sthaug@nethelp.no> To: v6ops@wjcerveny.com From: sthaug@nethelp.no In-Reply-To: <1411414987.4185178.170473277.2FA81688@webmail.messagingengine.com> References: <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> <20140922.212151.41703956.sthaug@nethelp.no> <1411414987.4185178.170473277.2FA81688@webmail.messagingengine.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rZzBSUlnJY09NmP-EZrMV47SSJ4 Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Sep 2014 19:56:20 -0000 > > On all the Linux boxes I just tried this on, I get: > > > > sthaug@server% ping6 ff02::1 > > connect: Invalid argument > > > > Try specifying the interface, such as: ping6 -I eth0 ff02::1 Or in my case, using the -I option to specify source address: -I interface address Set source address to specified interface address. Argument may be numeric IP address or name of device. When pinging IPv6 link-local address this option is required. Since an extra option is required, the risk of somebody doing this by accident is significantly reduced. Steinar Haug, AS 2116 From nobody Mon Sep 22 23:18:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC9F1A02FC for ; Mon, 22 Sep 2014 23:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3UbGDW0P-rR for ; Mon, 22 Sep 2014 23:18:18 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120B91A02EA for ; Mon, 22 Sep 2014 23:18:17 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 23 Sep 2014 08:18:14 +0200 X-IronPort-AV: E=Sophos;i="5.04,578,1406584800"; d="scan'208";a="535163638" Received: from he111494.emea1.cds.t-internal.com ([10.206.92.97]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 23 Sep 2014 08:18:14 +0200 Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE111494.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 23 Sep 2014 08:18:14 +0200 From: To: Date: Tue, 23 Sep 2014 08:18:10 +0200 Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: Ac/T/4shh25YvyMtRrahuG1NI2nadgCXa0iw Message-ID: <88CAA5385EB5404392BF93106C8C53F892495A838A@HE111507.emea1.cds.t-internal.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> In-Reply-To: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xpvlb6Z2sLwqQFskDiN6g9LqEmo Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Sep 2014 06:18:21 -0000 Hello *, > A new draft has been posted, at http://tools.ietf.org/html/draft-wang-v6o= ps-xlat-prefix-discovery. Please=20 > take a look at it and comment. Some comments on this draft: * The discovery via DNS64 (RFC7050) in the scenarios where 464XLAT is being= used works pretty well. What are the scenarios where the RFC7050 mechanism= s do not work well, and XLAT prefix discovery needs to be done via DHCPv6? * NAT64 and 464XLAT are currently mainly used in mobile environments. What = would be the "vehicle" to get DHCPv6 based NAT64 prefix distribution into t= he mobile standards/mobile devices? * Will the presence of the DHCPv6 PLATPREFIX option in messages from the DH= CPv6 server implicitly tell the device that the access network is IPv6-only= and no effort has to be made for a native IPv4-only connectivity? * I believe it would be good to also allow the PLATPREFIX option during sta= teless DHCPv6 when the IPv6 address itself has been obtained via RA/SLAAC. * This document only discusses about obtaining the NAT64 prefix for CLAT. H= owever, it is also necessary if the end device has a local DNS64 (to locall= y prefer native generation of the packets in IPv6 instead of generating the= m with IPv4 and translating them into IPv6 via CLAT). Holger From nobody Mon Sep 22 23:38:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA971A0352 for ; Mon, 22 Sep 2014 23:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, 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 1Bdsu2u8yMIE for ; Mon, 22 Sep 2014 23:38:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C091A02FC for ; Mon, 22 Sep 2014 23:38:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8FB05A8; Tue, 23 Sep 2014 08:38:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1411454294; bh=iJ9Q1myhlmeGot2ryZvkSqQJMHZadJGNIu6SYVpeUe0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=cMiKO9y4Dr+8XALvOxW7yj+hB/AEtVZJld3wFSS7NhbodRckNp+0MtN+OD8wTxClM g7C5cD56d6zed/9tsGkxMUwV1w36PMABHAQ4x6l2Miu/4bivt7v5hztkbsYI5NxyHg wINbT+6bN5CSyv/AHAjbUtBlPeq9IxPodSSbAeuE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 87884A7; Tue, 23 Sep 2014 08:38:14 +0200 (CEST) Date: Tue, 23 Sep 2014 08:38:14 +0200 (CEST) From: Mikael Abrahamsson To: Nalini Elkins In-Reply-To: <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> Message-ID: References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411408550.77000.YahooMailNeo@web125104.mail.ne1.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0QLVSDBTs2Ux9w1DnmyOOK4oe28 Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Sep 2014 06:38:19 -0000 On Mon, 22 Sep 2014, Nalini Elkins wrote: > If I have a 1,000 nodes under my control, then that is how many that > should be in my AD and BD. IPv6 allows for large subnets so why not? Because it's a bad idea. IPv4 allows for subnetting at /22 for your 1000 nodes, that doesn't mean it's a good idea. > Possibly not. We wanted to raise the issue. BTW, Pings, as you know, > are the precursor to much malicious activity. It is something that No, I don't know that. ICMP PINGs are an essential diagnostic tool. > someone with ill intent is liable to do readily. And, it provides > a huge amount of data on other nodes in a broadcast domain. I don't believe in security by obscurity. I believe in real security. > "The one MAC address that all devices share in common in normal > operation is the media broadcast, or FF:FF:FF:FF:FF:FF. In this case, a > device will take the packet and send an interrupt for processing. Thus, > a flood of these broadcast frames will consume all available resources > on an end-system [9]. It is perhaps prudent that system administrators > should consider ensuring that their border routers do not allow directed > broadcast packets to be forwarded through their routers as a default." ... and this is exactly what happened in 1997 when smurf attacks were stopped by this exact feature. "no ip directed-broadcast" on Cisco routers. You can still ping the broadcast address from the router itself, it just won't allow remote pings to work as it won't forward packets to the network broadcast IP address. Exactly the same way it works in IPv6 because Link local addresses aren't reachable from another interface and aren't forwarded between interfaces. > On Linux, I believe when you do a PING, it is continuous until > intentionally stopped. So, doing a Ping to FF02::1 from a Linux machine > will create havoc without having ill intent. That is, accidentally. Absolutely, and it's all due to the decision to put a lot of nodes in the same L2 domain which has been known for 20-30 years to be bad design and can cause the exact problems you're describing. If you ping the network broadcast address on IPv4 you get the exact same thing, I don't see why you blame IPv6 for this? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 23 01:53:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307BB1A6F6F for ; Tue, 23 Sep 2014 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuFCDQXGqYW4 for ; Tue, 23 Sep 2014 01:53:06 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5991A6F60 for ; Tue, 23 Sep 2014 01:53:05 -0700 (PDT) Received: from [85.158.137.35:44240] by server-3.bemta-3.messagelabs.com id E1/33-22751-0F431245; Tue, 23 Sep 2014 08:53:04 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-3.tower-134.messagelabs.com!1411462383!29946073!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29449 invoked from network); 23 Sep 2014 08:53:03 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-3.tower-134.messagelabs.com with SMTP; 23 Sep 2014 08:53:03 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Tue, 23 Sep 2014 09:55:32 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 09:52:51 +0100 From: "Heatley, Nick" To: Ross Chandler , Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+Lt72jTbGJ9EemkbZAEwE9WpwNOlWAgAAXC4CAARbR4A== Date: Tue, 23 Sep 2014 08:52:51 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303BB7E12@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <1298C58D-F3FF-49AD-899A-A3647B0E2A5D@eircom.net> In-Reply-To: <1298C58D-F3FF-49AD-899A-A3647B0E2A5D@eircom.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ec4LJjvcgu77NWHAcp3kKo__E7I Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Sep 2014 08:53:08 -0000 Agree, encapsulation messes with with 3GPP policy and charging, translati= on is in keeping with 3GPP architecture. Lorenzo, what do you see as the advantages MAP-T would have over 464xlat?= Regards, Nick -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ross Chandler Sent: 22 September 2014 17:49 To: Lorenzo Colitti Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org= =20WG Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery On 22 Sep 2014, at 16:26, Lorenzo Colitti wrote: > , the fact that 464xlat did not need DHCP was one of the main reasons t= hat the industry went with 464xlat and not something better like DS-Lite = or MAP. (464xlat is pretty much the worst.) >=20 > If you can depend on DHCPv6, there's very little reason to use 464xlat = at all. There are much better transition mechanisms available. I think it depends on the version of MAP. I'd group 464xlat with MAP-T an= d DS-Lite with MAP-E, the former translating headers and the latter encap= sulating. AFAIK DPI for IPv4 in IPv6 traffic is not supported by my GGSN/PGW vendor= .=20 In 3GPP Mobile 464xlat is a good, proven solution. DS-Lite goes back to = a central AFTR inheriting the limitations of NAT44.=20 BR=20 Ross _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW From nobody Tue Sep 23 05:06:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBD41A802D for ; Tue, 23 Sep 2014 05:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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.786, 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 fJEC049ViX1M for ; Tue, 23 Sep 2014 05:06:17 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A311A7D85 for ; Tue, 23 Sep 2014 05:06:16 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar1so8873012iec.7 for ; Tue, 23 Sep 2014 05:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1EXc3dVP7ybdAC7bO5AwH/5mu0eCepcrwxQZLnAw4LA=; b=I9YmSkUzzoXIa0fCSx05hG5FjIOYNOXnvIGTLJJ9UGN17UW5DIaJTB43zsUVI5OvTZ SCkHTfP3u1/WAOgdHNnxvvvoZebIqqWDLo5ZQ7//vgfuqFAtIPFLs/Hy5yYlYbDJS9JO wWtP9ZVwdFbeO3XI3UF+tXG+eEiHTmlFS/igLCnG1QhDOdR1pl9Owxa+YS07V7a80Wbq kLIP7wfp5M8AAXFwBLkg9GJqZMzqVBgobeqFOK0rLiQEaFpEBk31nMMr11CqcUydGY+w k8v10tbQdBED00WTkWRR/7KqLVpX2SiW5FILvM+IF6LY+/27A0eE7LRv/SgORaEElyub uoEg== 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=1EXc3dVP7ybdAC7bO5AwH/5mu0eCepcrwxQZLnAw4LA=; b=BFUF8G06RUOr/SsCfDMI1UQr9ROZGx+GFzlGuaayfzhZEeyrJAWYiUwpVFyAqFb5U0 gT1xchgvCJjRVs6I3jTHkhCV283mp6XKHPs+mp3+dD2gMvJ1WWgFhsTq3K4OlQO5EKnE b/YZO+GFGiT0TEXzCZJt9tXIgnm1X1d8HJRUqBDM++Ukr4j5ZGI4MNkQogSqEiL+EG1n Ryq+wZXNBdHr3eb+EVAxp8Dlo9T51z6vxkN5ej62AcYZCo5WScG6srC+HK/jkIr+eZKy 3MmNotqGeZ1kgREQRw/4Mhhvkm2YS708ixgmRJwVBrUpW0ex49clKgZt+TUuWUpCUohI 6GWA== X-Gm-Message-State: ALoCoQlIXczTXPxyOQWEJsSW8kihqtnA3aD/b+pMFSETVv91qeROKfnHazYLnh0PPiwBSvb0qtDq X-Received: by 10.50.80.116 with SMTP id q20mr21723180igx.22.1411473976200; Tue, 23 Sep 2014 05:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Tue, 23 Sep 2014 05:05:56 -0700 (PDT) In-Reply-To: <6536E263028723489CCD5B6821D4B21303BB7E12@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <1298C58D-F3FF-49AD-899A-A3647B0E2A5D@eircom.net> <6536E263028723489CCD5B6821D4B21303BB7E12@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Tue, 23 Sep 2014 21:05:56 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=089e01536682f64a430503ba6483 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6BVWSafZcNsI-77YLdE_dtn3Dws Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Sep 2014 12:06:22 -0000 --089e01536682f64a430503ba6483 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 5:52 PM, Heatley, Nick wrote: > Agree, encapsulation messes with with 3GPP policy and charging, > translation is in keeping with 3GPP architecture. > Lorenzo, what do you see as the advantages MAP-T would have over 464xlat? > If you want real IPv4, MAP-T is more transparent, scales better, and does not require a big stateful NAT in the sky. In wired networks, I'd say it's better. For a mobile network where bandwidth is low and margins are high and there is already a big stateful NAT in the sky, the only real advantage is transparency. Given the typical state of IPv4 in mobile networks, even that advantage is moot. I think 464xlat is a perfect fit for mobile networks. My favourite feature is that it sounds so bad that developers want to get the hell away from it and onto native IPv6 as soon as they can :-) --089e01536682f64a430503ba6483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 23, 2014 at 5:52 PM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:
Agree, encapsulation me= sses with with 3GPP policy and charging, translation is in keeping with 3GP= P architecture.
Lorenzo, what do you see as the advantages MAP-T would have over 464xlat?

If you want real IPv4, MAP-T is more tra= nsparent, scales better, and does not require a big stateful NAT in the sky= . In wired networks, I'd say it's better.

= For a mobile network where bandwidth is low and margins are high and there = is already a big stateful NAT in the sky, the only real advantage is transp= arency. Given the typical state of IPv4 in mobile networks, even that advan= tage is moot.

I think 464xlat is a perfect fit for= mobile networks. My favourite feature is that it sounds so bad that develo= pers want to get the hell away from it and onto native IPv6 as soon as they= can :-)
--089e01536682f64a430503ba6483-- From nobody Tue Sep 23 05:12:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71ED1A1AB7 for ; Tue, 23 Sep 2014 05:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLLSNK9_-eh7 for ; Tue, 23 Sep 2014 05:11:55 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E151A1AA2 for ; Tue, 23 Sep 2014 05:11:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9993061; Tue, 23 Sep 2014 14:11:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1411474311; bh=cJ36jLLIWzE9qwPAdl9FlFrALZ+ZxDwIbk1vIqMsmg8=; b=a VrsXMUJLM1rhnKxjWzoqscJAYjS5TWGttgknZzwUUHZiKvtBKfBne0Zign9XJRSf rP+ETqZZWvXXUdiGCL87khtXaa/8wBcLQQZKDZnDrRQzla78bKjYUnXrInjvFbhs tv/utzhvs/VobB3C9JXwXZeenNJB89ic25UcSujWvM= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id robLcsnLp5xj; Tue, 23 Sep 2014 14:11:51 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 083235F; Tue, 23 Sep 2014 14:11:51 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1985.4\)) From: Sander Steffann In-Reply-To: Date: Tue, 23 Sep 2014 14:11:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7837A4AA-038D-4AB4-8689-8C200FBFBF75@steffann.nl> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <1298C58D-F3FF-49AD-899A-A3647B0E2A5D@eircom.net> <6536E263028723489CCD5B6821D4B21303BB7E12@UK30S005EXS06.EEAD.EEINT.CO.UK> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1985.4) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TbMujH1687_kAqCiYSPoUEBMin0 Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Sep 2014 12:11:57 -0000 > I think 464xlat is a perfect fit for mobile networks. My favourite = feature is that it sounds so bad that developers want to get the hell = away from it and onto native IPv6 as soon as they can :-) Best argument in favour of 464xlat that I ever heard! :) Sander From nobody Tue Sep 23 08:07:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52531A1AE7 for ; Tue, 23 Sep 2014 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.185 X-Spam-Level: * X-Spam-Status: No, score=1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 AtH8s2RyCWid for ; Tue, 23 Sep 2014 08:07:04 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B06B1A1AEC for ; Tue, 23 Sep 2014 08:07:03 -0700 (PDT) Received: from 10.236.62.155 (EHLO OPE10HT07.tp.gk.corp.tepenet) ([10.236.62.155]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id CNK84358; Tue, 23 Sep 2014 17:06:59 +0200 (CEST) From: Kossut Tomasz - Hurt To: "holger.metschulat@telekom.de" , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP1ybg2QaqUK+wBUeYyP5gg0YaTZwOxepQ Date: Tue, 23 Sep 2014 15:05:39 +0000 Message-ID: References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <88CAA5385EB5404392BF93106C8C53F892495A838A@HE111507.emea1.cds.t-internal.com> In-Reply-To: <88CAA5385EB5404392BF93106C8C53F892495A838A@HE111507.emea1.cds.t-internal.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.9.23.140918:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, __ANY_URI, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __FORWARDED_MSG, BODY_SIZE_1700_1799, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A090206.54218C93.014F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.54218C93.014F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b21e99559804b25f5713c1d1a2f2b032 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OF3_4PS41j5pdgwu6dBz3UUN-d8 Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Sep 2014 15:07:06 -0000 I think you can always set static clat config for devices you controlled, o= r implement CLAT on application level...why not?=20 -----Original Message----- From: holger.metschulat@telekom.de [mailto:holger.metschulat@telekom.de]=20 Sent: Tuesday, September 23, 2014 8:18 AM To: v6ops@ietf.org Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Hello *, > A new draft has been posted, at=20 > http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please= take a look at it and comment. Some comments on this draft: * The discovery via DNS64 (RFC7050) in the scenarios where 464XLAT is being= used works pretty well. What are the scenarios where the RFC7050 mechanism= s do not work well, and XLAT prefix discovery needs to be done via DHCPv6? * NAT64 and 464XLAT are currently mainly used in mobile environments. What = would be the "vehicle" to get DHCPv6 based NAT64 prefix distribution into t= he mobile standards/mobile devices? * Will the presence of the DHCPv6 PLATPREFIX option in messages from the DH= CPv6 server implicitly tell the device that the access network is IPv6-only= and no effort has to be made for a native IPv4-only connectivity? * I believe it would be good to also allow the PLATPREFIX option during sta= teless DHCPv6 when the IPv6 address itself has been obtained via RA/SLAAC. * This document only discusses about obtaining the NAT64 prefix for CLAT. H= owever, it is also necessary if the end device has a local DNS64 (to locall= y prefer native generation of the packets in IPv6 instead of generating the= m with IPv4 and translating them into IPv6 via CLAT). Holger From nobody Tue Sep 23 09:02:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40F1A8721 for ; Tue, 23 Sep 2014 09:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 CYvteLh43s2X for ; Tue, 23 Sep 2014 09:02:55 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C4B1A1B18 for ; Tue, 23 Sep 2014 09:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1120; q=dns/txt; s=iport; t=1411488176; x=1412697776; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=WcWhs0die4nFcB2wZoMlpB+2OY7jd99WLEUrq7t8adQ=; b=eWj/RZRDNul2w/HkzjxFw/Y+69b7F/7iY4NbqP3i75I8S7VHlPOit4tf vxJBmeBCUTHloT3mAx+a6ZC5MgB0vdwOiSvy4AgjNk18e+XFqsuzn4L2R bZpJAWNW/pkHd2SW+5QngwWOmlQ7t5gEUl73UyPHBZ3eEInuNQhSZQHEP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEIAFSYIVStJA2I/2dsb2JhbABggw5TVwTJVodNAYEMFgFxCYQDAQEBBDo0CwwGARkEAQELFAk5FAkJAQQOBQiINg3DUQEXjE+CVhEBHzENgyiBHQWRWoQ6iGmKT4kjgh+BQ2yBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,580,1406592000"; d="scan'208";a="80527278" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 23 Sep 2014 16:02:55 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8NG2sK7018286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Sep 2014 16:02:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.78]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 11:02:54 -0500 From: "Bernie Volz (volz)" To: "v6ops@ietf.org" Thread-Topic: FYI - DHC WGLC for draft-ietf-dhc-addr-registration-07.txt - Respond by Sept 29, 2014 Thread-Index: Ac/XR2BcSzSz23TWR2KI67J1Xv6uZA== Date: Tue, 23 Sep 2014 16:02:54 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B6A2F63@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HTPcMfnDwA0E-KTSXNy9x9CBtU0 Cc: "Dhc Chairs \(dhc-chairs@tools.ietf.org\)" Subject: [v6ops] FYI - DHC WGLC for draft-ietf-dhc-addr-registration-07.txt - Respond by Sept 29, 2014 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Sep 2014 16:02:58 -0000 Hi: Just in case anyone in v6ops that is not on the DHC WG mailing list has an = opinion on this work. Response so far has been very low from the dhc-wg. If you are not subscribed to the DHC WG mailing list, you can email Tomek a= nd myself (chairs). - Bernie & Tomek -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, September 15, 2014 9:12 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-07.txt - Respond= by Sept 29, 2014 Hi all, This message starts the DHC working group last call to advance "Registering= Self-generated IPv6 Addresses in DNS using DHCPv6", draft-ietf-dhc-addr-re= gistration-07, document as a Standards Track RFC. The authors believe that = this version is ready. The draft is available here: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-07 Please send your comments by September 29th, 2014. If you do not feel this = document should advance, please state your reasons why. There are no IPR claims reported at this time. - Tomek & Bernie From nobody Wed Sep 24 02:32:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8D21A6FBB for ; Wed, 24 Sep 2014 02:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 iyR4cGahCIs2 for ; Wed, 24 Sep 2014 02:32:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B121A1B6A for ; Wed, 24 Sep 2014 02:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1070; q=dns/txt; s=iport; t=1411551163; x=1412760763; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UkfFkE1oUHyk3hvotynDUwRyYwG6dd3QwsQ8MiRn7E8=; b=W8dFdQmhcqiIlwRi+vniHLvfIeJKzN1U00GyaWsxiLZHxQlz2gpXbb1e 615jwugr4Gj57G76N4KRbKgFrLAp4vxEzzA4SVaXLwJlOlH3HLb3LbRvv occxcPc9m7hgUB9jWD4K4QYyQmNF6JFtzKgoOSSAcCy9f+IzfxAEwgmCd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAF+PIlStJV2P/2dsb2JhbABfgw5TVwTKNAqHTQGBCBYBeoQDAQEBBAEBARpRFwQCAQgRBAEBCxkEBycLFAcBAQUDAQEEEwiINg3CSgEXj204BoMogR0FiwyGT4Q6iGmTc4IfgUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,588,1406592000"; d="scan'208";a="354644480" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP; 24 Sep 2014 09:32:43 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8O9Wg9j032638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Sep 2014 09:32:42 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.120]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 04:32:42 -0500 From: "Gunter Van de Velde (gvandeve)" To: "v6ops@ietf.org" Thread-Topic: Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers Thread-Index: Ac/X2IHCixEQiP9WSwO6zL/lhjHmPQAAV6zA Date: Wed, 24 Sep 2014 09:32:41 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.175.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PHg70qYRuR2q0rA_Pdj5KV2YQa0 Subject: [v6ops] FW: Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 09:32:45 -0000 Dear, OPSEC Chairs requested "Call for WG adoption" on draft-gont-opsec-ipv6-eh-f= iltering. Please voice your reflexions in OPSEC WG G/ -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Veld= e (gvandeve) Sent: 24 September 2014 11:28 To: opsec@ietf.org Subject: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv= 6 Packets Containing IPv6 Extension Headers Dear, =A0 Please find this request for WG adoption for "Recommendations on Filtering = of IPv6 Packets Containing IPv6 Extension Headers" The authors of the work explicitly asked for "Call for WG adoption" in its = current state.=20 =A0 Latest draft can be found at: http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02=A0 (1) Do you support for adopting the draft as OPSEC WG item? This call for WG adoption will end 8 October 2014. Kind Regards, OPSEC chairs _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From nobody Wed Sep 24 04:28:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25231A7022 for ; Wed, 24 Sep 2014 04:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.332 X-Spam-Level: ** X-Spam-Status: No, score=2.332 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_220=2.118, RP_MATCHES_RCVD=-0.786, 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 T5Q7NgE88lCN for ; Wed, 24 Sep 2014 04:28:01 -0700 (PDT) Received: from m15-25.126.com (m15-25.126.com [220.181.15.25]) by ietfa.amsl.com (Postfix) with ESMTP id 45D2F1A7020 for ; Wed, 24 Sep 2014 04:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=rl3qn 7p6kCiti69Me/flZ1OV8hOJUR07LaNSnRLokpI=; b=DnPY2VVojONcXu5wEWeVy r/NRnQHio5TAtpuQIuBekM9S09fwWJAjfIJVz0N+FBNcw/VQhiZLJon0e7ZYdAFZ v+Mru+wUVr0W66JA/A++VaCx7vex+l98BGgF/cFyBO8qzF+NFlUw6bluAeDvIwn2 6bO9u5SiPYXlX/ALa9R8yQ= Received: from lilishan48$126.com ( [166.111.68.231] ) by ajax-webmail-wmsvr25 (Coremail) ; Wed, 24 Sep 2014 19:27:56 +0800 (CST) X-Originating-IP: [166.111.68.231] Date: Wed, 24 Sep 2014 19:27:56 +0800 (CST) From: "Lishan Li" To: =?UTF-8?Q?Andrew_=F0=9F=91=BD__Yourtchenko?= X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140725(28226.6623) Copyright (c) 2002-2014 www.mailtech.cn 126com In-Reply-To: References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> X-CM-CTRLDATA: dT108mZvb3Rlcl9odG09Mjg0Mzo4MQ== Content-Type: multipart/alternative; boundary="----=_Part_362866_1804129728.1411558076561" MIME-Version: 1.0 Message-ID: <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> X-CM-TRANSID: GcqowGDJq0K9qiJUzTM4AA--.6136W X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbikR4QwVP7BDZxOwACsM X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5ZtRKggpMkRRRPjSeSKVW-97IgA Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 11:28:02 -0000 ------=_Part_362866_1804129728.1411558076561 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 RGVhciBBbmRyZXcsCgoKVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIGFuZCB0aGUgcmVmZXJlbmNl IHBvaW50ZXIuIEl0J3Mgb2YgZ3JlYXQgaGVscC4KCgpJIGFncmVlIHdpdGggeW91ciBpZGVhLiBC dXQgd2hhdCBJIGludGVuZGVkIHRvIG1lYW4gd2FzIHRoYXQgdGhlIG1lc3NhZ2UgZXhjaGFuZ2Ug b2YgRE5TNjQgaXMgImNvbXBsaWNhdGVkIiBub3QgImRpZmZpY3VsdCIuCkxlYXJuaW5nIHRoZSBJ UHY2IFByZWZpeCB1c2luZyBESENQdjYgbG9va3MgbGlrZSBsb3dlciBjb21wbGV4aXR5IGluIGNv bXBhcmlzb24uCgoKVGhlIG1haW4gcHVycG9zZSBvZiB0aGUgZHJhZnQgaXMgbm90IHN0ZWVyaW5n IHBlb3BsZSBhd2F5IGZyb20gRE5TNjQuIExlYXJuaW5nIHRoZSBJUHY2IHByZWZpeCB1c2luZyBE SENQdjYgaXMgc2ltcGxlCmFuZCBkaXJlY3QuIERIQ1B2NiBpcyBkZXNpZ25lZCB0byBwcm92aWRl IHZhcmlvdXMga2luZHMgb2YgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBpbiBhIGNlbnRyYWxs eSBtYW5hZ2VkIGZhc2hpb24uCgoKQmVzdCByZWdhcmRzLApMaXNoYW4gTGkKCgpBdCAyMDE0LTA5 LTIwIDAwOjQxOjE2LCAiQW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtvIiA8YXlvdXJ0Y2hAZ21haWwu Y29tPiB3cm90ZToKPkxvb2tzIGxpa2UgYSByZWZlcmVuY2UgdG8gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzA1MSNwYWdlLTE1Cj5jb3VsZCBiZSB1c2VmdWwsIGFzIHdlbGwgYXMgdGhl IG1vcmUgZGV0YWlsZWQgZGlzY3Vzc2lvbiBvZiB3aGF0Cj5mYWN0b3JzIGFyZSBwcmV2ZW50aW5n IGZyb20gdXNpbmcgdGhlIFJGQzcwNTAncyBtZXRob2QgPwo+Cj5UaGUgc2hvcnQgc2VudGVuY2Ug IkJ1dCBpdCBpcyBkaWZmaWN1bHQgYW5kIGRlcGVuZHMgb24gRE5TNjQiIHJhaXNlcwo+aW1tZWRp YXRlIHF1ZXN0aW9uczoKPgo+MSkgIml0IGlzIGRpZmZpY3VsdCIKPgo+TmVlZHMgdG8gYmUgcXVh bGlmaWVkL3JlYXNvbmVkLgo+Cj5DIGNvZGUgdG8gY3JlYXRlIGEgRE5TIHJlcXVlc3QgY2FuIGJl IGltcGxlbWVudGVkIGluIH4yMDAgbGluZXMsIGFuZAo+dGhlIGNvZGUgdG8gcGFyc2UgaXQgY2Fu IGJlIGRvbmUgaW4gfjMwMCBsaW5lcywgc28gZXZlbiBhIGhvc3QgdGhhdAo+ZG9lcyBub3QgdXNl IHRoZSBETlMgb3RoZXJ3aXNlIGNhbiBoYXZlIGEgbGlnaHR3ZWlnaHQgbW9kdWxlIGp1c3QgZm9y Cj50aGUgc2FrZSBvZiBnZXR0aW5nIGEgcHJlZml4LiBUaGF0IGhvc3QgYWxyZWFkeSBoYXMgdG8g aW1wbGVtZW50Cj5ESENQdjYgY2xpZW50LCB0aGlzIGRvZXMgbm90IGxvb2sgbGlrZSBhIGxvdCBv ZiBjb2RlIG5vciBhIGxvdCBvZgo+Y29tcGxleGl0eSBpbiBjb21wYXJpc29uLgo+Cj4yKSAicmVx dWlyZXMgRE5TNjQiCj4KPlRoaXMgaW4gaXRzZWxmIGNvdWxkIGJlIGEgdmFsaWQgY29uc2lkZXJh dGlvbiBmb3IgYSA0NjRYTEFUIGRlcGxveW1lbnQKPmNob29zZSB0byBub3QgdXNlIEROUzY0Lgo+ Cj5CdXQ6IHdoYXQgaXMgdGhlIGJlc3QgKnJlYWwtd29ybGQqIG9wZXJhdGlvbmFsIHByYWN0aWNl IHRvZGF5IC0gdG8gdXNlCj5ETlM2NCBvciBub3QgPwo+Cj5JZiB0aGUgcmVhbC13b3JsZCBwcmFj dGljZSBzaG93cyB0aGF0IEROUzY0IGlzIGhhcm1mdWwgaW4gNDY0WExBVAo+ZGVwbG95bWVudHMs IHRoaXMgc2hvdWxkIGJlIGRvY3VtZW50ZWQgYWNjb3JkaW5nbHkgLSBhbmQgdGhlbiB0aGVyZQo+ d291bGQgYmUgbm8gdW5jZXJ0YWludHkgYWJvdXQgdGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBhcHBy b2FjaC4KPgo+SWYgdGhlIGJlc3QgcHJhY3RpY2UgaXMgdG8gdXNlIEROUzY0IGFueXdheSwgdGhl biBkbyB3ZSB3YW50IHRvIHN0ZWVyCj5wZW9wbGUgYXdheSBmcm9tIGl0IGJ5IHByb3ZpZGluZyBh IG1ldGhvZCB0aGF0IGRvZXMgbm90IGRlcGVuZCBvbgo+RE5TNjQgPwo+Cj4tLWEKPgo+Cj4KPk9u IDkvMTkvMTQsIGZyZWRAY2lzY28uY29tIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6Cj4+IEEgbmV3 IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZCwgYXQKPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3ZlcnkuIFBsZWFzZQo+PiB0YWtlIGEg bG9vayBhdCBpdCBhbmQgY29tbWVudC4KPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPj4gdjZvcHMgbWFpbGluZyBsaXN0Cj4+IHY2b3BzQGlldGYu b3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMKPj4KPgo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPnY2b3BzIG1h aWxpbmcgbGlzdAo+djZvcHNAaWV0Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMK ------=_Part_362866_1804129728.1411558076561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+RGVhciBBbmRyZXcsPC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMgYW5kIHRoZSByZWZlcmVuY2UgcG9pbnRlci4g SXQncyBvZiBncmVhdCBoZWxwLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBhZ3JlZSB3aXRo IHlvdXIgaWRlYS4gQnV0IHdoYXQgSSBpbnRlbmRlZCB0byBtZWFuIHdhcyB0aGF0IHRoZSBtZXNz YWdlIGV4Y2hhbmdlIG9mIEROUzY0IGlzICJjb21wbGljYXRlZCIgbm90ICJkaWZmaWN1bHQiLjwv ZGl2PjxkaXY+TGVhcm5pbmcgdGhlIElQdjYgUHJlZml4IHVzaW5nIERIQ1B2NiBsb29rcyBsaWtl IGxvd2VyIGNvbXBsZXhpdHkgaW4gY29tcGFyaXNvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PlRoZSBtYWluIHB1cnBvc2Ugb2YgdGhlIGRyYWZ0IGlzIG5vdCBzdGVlcmluZyBwZW9wbGUgYXdh eSBmcm9tIEROUzY0LiBMZWFybmluZyB0aGUgSVB2NiBwcmVmaXggdXNpbmcgREhDUHY2IGlzIHNp bXBsZTwvZGl2PjxkaXY+YW5kIGRpcmVjdC4gREhDUHY2IGlzIGRlc2lnbmVkIHRvIHByb3ZpZGUg dmFyaW91cyBraW5kcyBvZiBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGluIGEgY2VudHJhbGx5 IG1hbmFnZWQgZmFzaGlvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJlc3QgcmVnYXJkcyw8 L2Rpdj48ZGl2Pkxpc2hhbiBMaTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxwcmU+QXQgMjAxNC0wOS0y MCAwMDo0MToxNiwgIkFuZHJldyDwn5G9ICBZb3VydGNoZW5rbyIgJmx0O2F5b3VydGNoQGdtYWls LmNvbSZndDsgd3JvdGU6CiZndDtMb29rcyBsaWtlIGEgcmVmZXJlbmNlIHRvIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzcwNTEjcGFnZS0xNQomZ3Q7Y291bGQgYmUgdXNlZnVsLCBhcyB3 ZWxsIGFzIHRoZSBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24gb2Ygd2hhdAomZ3Q7ZmFjdG9ycyBh cmUgcHJldmVudGluZyBmcm9tIHVzaW5nIHRoZSBSRkM3MDUwJ3MgbWV0aG9kID8KJmd0OwomZ3Q7 VGhlIHNob3J0IHNlbnRlbmNlICJCdXQgaXQgaXMgZGlmZmljdWx0IGFuZCBkZXBlbmRzIG9uIERO UzY0IiByYWlzZXMKJmd0O2ltbWVkaWF0ZSBxdWVzdGlvbnM6CiZndDsKJmd0OzEpICJpdCBpcyBk aWZmaWN1bHQiCiZndDsKJmd0O05lZWRzIHRvIGJlIHF1YWxpZmllZC9yZWFzb25lZC4KJmd0Owom Z3Q7QyBjb2RlIHRvIGNyZWF0ZSBhIEROUyByZXF1ZXN0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiB+ MjAwIGxpbmVzLCBhbmQKJmd0O3RoZSBjb2RlIHRvIHBhcnNlIGl0IGNhbiBiZSBkb25lIGluIH4z MDAgbGluZXMsIHNvIGV2ZW4gYSBob3N0IHRoYXQKJmd0O2RvZXMgbm90IHVzZSB0aGUgRE5TIG90 aGVyd2lzZSBjYW4gaGF2ZSBhIGxpZ2h0d2VpZ2h0IG1vZHVsZSBqdXN0IGZvcgomZ3Q7dGhlIHNh a2Ugb2YgZ2V0dGluZyBhIHByZWZpeC4gVGhhdCBob3N0IGFscmVhZHkgaGFzIHRvIGltcGxlbWVu dAomZ3Q7REhDUHY2IGNsaWVudCwgdGhpcyBkb2VzIG5vdCBsb29rIGxpa2UgYSBsb3Qgb2YgY29k ZSBub3IgYSBsb3Qgb2YKJmd0O2NvbXBsZXhpdHkgaW4gY29tcGFyaXNvbi4KJmd0OwomZ3Q7Mikg InJlcXVpcmVzIEROUzY0IgomZ3Q7CiZndDtUaGlzIGluIGl0c2VsZiBjb3VsZCBiZSBhIHZhbGlk IGNvbnNpZGVyYXRpb24gZm9yIGEgNDY0WExBVCBkZXBsb3ltZW50CiZndDtjaG9vc2UgdG8gbm90 IHVzZSBETlM2NC4KJmd0OwomZ3Q7QnV0OiB3aGF0IGlzIHRoZSBiZXN0ICpyZWFsLXdvcmxkKiBv cGVyYXRpb25hbCBwcmFjdGljZSB0b2RheSAtIHRvIHVzZQomZ3Q7RE5TNjQgb3Igbm90ID8KJmd0 OwomZ3Q7SWYgdGhlIHJlYWwtd29ybGQgcHJhY3RpY2Ugc2hvd3MgdGhhdCBETlM2NCBpcyBoYXJt ZnVsIGluIDQ2NFhMQVQKJmd0O2RlcGxveW1lbnRzLCB0aGlzIHNob3VsZCBiZSBkb2N1bWVudGVk IGFjY29yZGluZ2x5IC0gYW5kIHRoZW4gdGhlcmUKJmd0O3dvdWxkIGJlIG5vIHVuY2VydGFpbnR5 IGFib3V0IHRoZSByYXRpb25hbGUgZm9yIHRoaXMgYXBwcm9hY2guCiZndDsKJmd0O0lmIHRoZSBi ZXN0IHByYWN0aWNlIGlzIHRvIHVzZSBETlM2NCBhbnl3YXksIHRoZW4gZG8gd2Ugd2FudCB0byBz dGVlcgomZ3Q7cGVvcGxlIGF3YXkgZnJvbSBpdCBieSBwcm92aWRpbmcgYSBtZXRob2QgdGhhdCBk b2VzIG5vdCBkZXBlbmQgb24KJmd0O0ROUzY0ID8KJmd0OwomZ3Q7LS1hCiZndDsKJmd0OwomZ3Q7 CiZndDtPbiA5LzE5LzE0LCBmcmVkQGNpc2NvLmNvbSAmbHQ7ZnJlZEBjaXNjby5jb20mZ3Q7IHdy b3RlOgomZ3Q7Jmd0OyBBIG5ldyBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQsIGF0CiZndDsmZ3Q7IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlz Y292ZXJ5LiBQbGVhc2UKJmd0OyZndDsgdGFrZSBhIGxvb2sgYXQgaXQgYW5kIGNvbW1lbnQuCiZn dDsmZ3Q7CiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCiZndDsmZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdAomZ3Q7Jmd0OyB2Nm9wc0BpZXRmLm9y ZwomZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzCiZn dDsmZ3Q7CiZndDsKJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCiZndDt2Nm9wcyBtYWlsaW5nIGxpc3QKJmd0O3Y2b3BzQGlldGYub3JnCiZndDtodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzCjwvcHJlPjwvZGl2Pjxicj48 YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxzcGFuIGlkPSJuZXRlYXNlX21haWxfZm9v dGVyIj48L3NwYW4+PC9zcGFuPg== ------=_Part_362866_1804129728.1411558076561-- From nobody Wed Sep 24 04:38:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D6D1A702C for ; Wed, 24 Sep 2014 04:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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.786, 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 m-VnWKArguPh for ; Wed, 24 Sep 2014 04:37:51 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367681A70E2 for ; Wed, 24 Sep 2014 04:37:42 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn15so6329490igb.9 for ; Wed, 24 Sep 2014 04:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a4fVTgz3cS59PDriDrNKbkInWo5bBtqgiLKbVq3v1ZM=; b=ZfGTduzhL6jd69mp+QCQmXAuJVC02ZsVhT+YD5/XEfPfBtzR7dyrWIgid2mdoZs3fC yIF6qEHuks6wrFdjshCXxnUaSh8sMGo7uu6Km4h/ATAnsi0fvaZxYXzouNpb78MowrVN e8SVanUFIrc6zDzKGWXLlHvfmnw+H/gWTGy2BnJg1pg9EulcfuIqGEMv1H5qPCbhwkxL X2+Q3eogB1yvaogjVwqQVhlLp8pNjc0RthJhtKU3QChkzfsm5hrN56+rvXwExJ/pycHR ea94OylCdfWYVU6pUcfKd71oRmsH0JESuGO+u513xZ45hMyCOmzeXjWhV0VKw3ZTxnB/ gVeQ== 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=a4fVTgz3cS59PDriDrNKbkInWo5bBtqgiLKbVq3v1ZM=; b=c+mSRusH9e+LheDE0ksmwgHsSbA10zs6zuDVm52AJio8i7ek34jdYqNp84EAf8msxJ zaC8QCep1+WSYQjoozvGsRoTJZ9iPppUhcWAmhB0LKnVWFWoMG9P/wCZSbcRd0sVkE4m Kp02DlvuvGReVMpHnHeYuERcpvRJTdOsGjH9vzn804hFhL4hi8SwFe6nqr+5titn2/1t EqhoPNKHW30EA28KqtcKxl3gdhllLFk4actFPqoM9uG4HP9FJhk97ALo5ZqrvX9L90UQ GzZnrGX/TwyBimEGcKloZ7StU20pxgBKh8BgZxA+AJBTHc1BBzJbiQEm5PKhm2l+LmKg yrIQ== X-Gm-Message-State: ALoCoQmZ0mriInNYy7yDHFFuG5KFW6mCK5r1U6Oct+PcruxQVlBkWcq5JqBF8Jx6V79GKmWfQVnN X-Received: by 10.50.41.8 with SMTP id b8mr12025994igl.11.1411558661616; Wed, 24 Sep 2014 04:37:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Wed, 24 Sep 2014 04:37:20 -0700 (PDT) In-Reply-To: <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> From: Lorenzo Colitti Date: Wed, 24 Sep 2014 20:37:20 +0900 Message-ID: To: Lishan Li Content-Type: multipart/alternative; boundary=089e0116197a9b23460503ce1c53 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Y4csBkXMv9AjhE3ppEVqISSX8Bc Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 11:37:56 -0000 --089e0116197a9b23460503ce1c53 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 24, 2014 at 8:27 PM, Lishan Li wrote: > I agree with your idea. But what I intended to mean was that the message > exchange of DNS64 is "complicated" not "difficult". > Learning the IPv6 Prefix using DHCPv6 looks like lower complexity in > comparison. > Ok, but once you've learned the prefix using DHCPv6, what do you do with it? You still need a DNS64 unless you want to pump all the traffic through 464xlat, which is terrible for performance. --089e0116197a9b23460503ce1c53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 24, 2014 at 8:27 PM, Lishan Li <lilishan48@126.com>= wrote:
I agree with your idea. But what I intended to mean was that the mes= sage exchange of DNS64 is "complicated" not "difficult"= .
Learning the IPv6 Prefix using DHCPv6 looks like low= er complexity in comparison.

Ok= , but once you've learned the prefix using DHCPv6, what do you do with = it? You still need a DNS64 unless you want to pump all the traffic through = 464xlat, which is terrible for performance.
--089e0116197a9b23460503ce1c53-- From nobody Wed Sep 24 04:48:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710421A86E5 for ; Wed, 24 Sep 2014 04:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el6nY3hpSijk for ; Wed, 24 Sep 2014 04:47:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CCA1A6FFA for ; Wed, 24 Sep 2014 04:47:58 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 4B9A13744BD; Wed, 24 Sep 2014 13:47:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 208E0158086; Wed, 24 Sep 2014 13:47:57 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.39]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 13:47:54 +0200 From: To: Lishan Li Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP1+qkSMoumN5EFUufAVSagaPKqJwQKVzg Date: Wed, 24 Sep 2014 11:47:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008230C@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> In-Reply-To: <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008230COPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.12.190919 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fRO02HLQmz_LfTg2MmoqbFlcDXE Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 11:48:01 -0000 --_000_787AE7BB302AE849A7480A190F8B933008230COPEXCLILM23corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBMaXNoYW4sDQoNCkZXSVcsIEnigJltIG9uZSBvZiB0aGUgYXV0aG9ycyBvZiB0aGUgREhD UHY2IG9wdGlvbiBhbmFseXplZCBpbiBSRkM3MDUxLiBXZSBhYmFuZG9uZWQgdGhlIGRoY3B2NiB0 cmFjayBiZWNhdXNlIHRoZSByZWNvbW1lbmRhdGlvbiBvZiB0aGUgYmVoYXZlIHdnIGF0IHRoYXQg dGltZSBpcyB0aGUgaGV1cmlzdGljLWJhc2VkIGFwcHJvYWNoLg0KDQpBcyB5b3UgY2FuIHJlYWQg aW4gZG9jdW1lbnQgc2hlcGhlcmRlZCBmb3IgcmZjNzA1MCwgdGhlIHdnIGlzIGF3YXJlIG9mIHRo ZSBsaW1pdGF0aW9ucyBvZiB0aGUgc29sdXRpb24gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL3JmYzcwNTAvaGlzdG9yeS8pOg0KDQogICDigJxUaGUgZG9jdW1lbnQgc3BlY2lmaWVz IGEgaGV1cmlzdGljIHRoYXQgaXMgbm90IHBlcmZlY3QgYW5kIHNvIHNvbWUNCiAgICBwb2ludHMg d2VyZSByb3VnaCwgYnV0IHRoZSBjb25zdHJhaW50IGZvciB0aGlzIGRvY3VtZW50IHdhcyB0byBv cGVyYXRlDQogICAgd2l0aG91dCBjaGFuZ2VzIHRvIGNvZGUgKG9ubHkgY29uZmlndXJhdGlvbikg aW4gZXhpc3RpbmcgbmV0d29ya3MuDQogICAgR2l2ZW4gdGhhdCBjb25zdHJhaW50LCB0aGVyZSB3 YXMgc3Ryb25nIGNvbnNlbnN1cy4gIFJlbGF4aW5nIHRoZQ0KICAgIGNvbnN0cmFpbnQgd291bGQg YWxsb3cgb25lIHRvIGRvIGJldHRlciwgYW5kIHRoYXQgaXMgdGhlIGZvY3VzIG9mIGENCiAgICBk cmFmdCByZWNlbnRseSBzdWJtaXR0ZWQgdG8gdGhlIFBDUCBXRy7igJ0NCg0KU2luY2UgdGhlbiwg UkZDNzIyNSB3YXMgcHVibGlzaGVkIGJ5IHRoZSBwY3Agd2cuDQoNCkNoZWVycywNCk1lZA0KDQpE ZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBM aXNoYW4gTGkNCkVudm95w6kgOiBtZXJjcmVkaSAyNCBzZXB0ZW1icmUgMjAxNCAxMzoyOA0Kw4Ag OiBBbmRyZXcg8J+RvSBZb3VydGNoZW5rbw0KQ2MgOiBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJl Zml4LWRpc2NvdmVyeUB0b29scy5pZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcNCk9iamV0IDogUmU6 IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVy eQ0KDQpEZWFyIEFuZHJldywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIGFuZCB0aGUgcmVm ZXJlbmNlIHBvaW50ZXIuIEl0J3Mgb2YgZ3JlYXQgaGVscC4NCg0KSSBhZ3JlZSB3aXRoIHlvdXIg aWRlYS4gQnV0IHdoYXQgSSBpbnRlbmRlZCB0byBtZWFuIHdhcyB0aGF0IHRoZSBtZXNzYWdlIGV4 Y2hhbmdlIG9mIEROUzY0IGlzICJjb21wbGljYXRlZCIgbm90ICJkaWZmaWN1bHQiLg0KTGVhcm5p bmcgdGhlIElQdjYgUHJlZml4IHVzaW5nIERIQ1B2NiBsb29rcyBsaWtlIGxvd2VyIGNvbXBsZXhp dHkgaW4gY29tcGFyaXNvbi4NCg0KVGhlIG1haW4gcHVycG9zZSBvZiB0aGUgZHJhZnQgaXMgbm90 IHN0ZWVyaW5nIHBlb3BsZSBhd2F5IGZyb20gRE5TNjQuIExlYXJuaW5nIHRoZSBJUHY2IHByZWZp eCB1c2luZyBESENQdjYgaXMgc2ltcGxlDQphbmQgZGlyZWN0LiBESENQdjYgaXMgZGVzaWduZWQg dG8gcHJvdmlkZSB2YXJpb3VzIGtpbmRzIG9mIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaW4g YSBjZW50cmFsbHkgbWFuYWdlZCBmYXNoaW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpMaXNoYW4gTGkN Cg0KDQpBdCAyMDE0LTA5LTIwIDAwOjQxOjE2LCAiQW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtvIiA8 YXlvdXJ0Y2hAZ21haWwuY29tPG1haWx0bzpheW91cnRjaEBnbWFpbC5jb20+PiB3cm90ZToNCg0K Pkxvb2tzIGxpa2UgYSByZWZlcmVuY2UgdG8gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzA1MSNwYWdlLTE1DQoNCj5jb3VsZCBiZSB1c2VmdWwsIGFzIHdlbGwgYXMgdGhlIG1vcmUgZGV0 YWlsZWQgZGlzY3Vzc2lvbiBvZiB3aGF0DQoNCj5mYWN0b3JzIGFyZSBwcmV2ZW50aW5nIGZyb20g dXNpbmcgdGhlIFJGQzcwNTAncyBtZXRob2QgPw0KDQo+DQoNCj5UaGUgc2hvcnQgc2VudGVuY2Ug IkJ1dCBpdCBpcyBkaWZmaWN1bHQgYW5kIGRlcGVuZHMgb24gRE5TNjQiIHJhaXNlcw0KDQo+aW1t ZWRpYXRlIHF1ZXN0aW9uczoNCg0KPg0KDQo+MSkgIml0IGlzIGRpZmZpY3VsdCINCg0KPg0KDQo+ TmVlZHMgdG8gYmUgcXVhbGlmaWVkL3JlYXNvbmVkLg0KDQo+DQoNCj5DIGNvZGUgdG8gY3JlYXRl IGEgRE5TIHJlcXVlc3QgY2FuIGJlIGltcGxlbWVudGVkIGluIH4yMDAgbGluZXMsIGFuZA0KDQo+ dGhlIGNvZGUgdG8gcGFyc2UgaXQgY2FuIGJlIGRvbmUgaW4gfjMwMCBsaW5lcywgc28gZXZlbiBh IGhvc3QgdGhhdA0KDQo+ZG9lcyBub3QgdXNlIHRoZSBETlMgb3RoZXJ3aXNlIGNhbiBoYXZlIGEg bGlnaHR3ZWlnaHQgbW9kdWxlIGp1c3QgZm9yDQoNCj50aGUgc2FrZSBvZiBnZXR0aW5nIGEgcHJl Zml4LiBUaGF0IGhvc3QgYWxyZWFkeSBoYXMgdG8gaW1wbGVtZW50DQoNCj5ESENQdjYgY2xpZW50 LCB0aGlzIGRvZXMgbm90IGxvb2sgbGlrZSBhIGxvdCBvZiBjb2RlIG5vciBhIGxvdCBvZg0KDQo+ Y29tcGxleGl0eSBpbiBjb21wYXJpc29uLg0KDQo+DQoNCj4yKSAicmVxdWlyZXMgRE5TNjQiDQoN Cj4NCg0KPlRoaXMgaW4gaXRzZWxmIGNvdWxkIGJlIGEgdmFsaWQgY29uc2lkZXJhdGlvbiBmb3Ig YSA0NjRYTEFUIGRlcGxveW1lbnQNCg0KPmNob29zZSB0byBub3QgdXNlIEROUzY0Lg0KDQo+DQoN Cj5CdXQ6IHdoYXQgaXMgdGhlIGJlc3QgKnJlYWwtd29ybGQqIG9wZXJhdGlvbmFsIHByYWN0aWNl IHRvZGF5IC0gdG8gdXNlDQoNCj5ETlM2NCBvciBub3QgPw0KDQo+DQoNCj5JZiB0aGUgcmVhbC13 b3JsZCBwcmFjdGljZSBzaG93cyB0aGF0IEROUzY0IGlzIGhhcm1mdWwgaW4gNDY0WExBVA0KDQo+ ZGVwbG95bWVudHMsIHRoaXMgc2hvdWxkIGJlIGRvY3VtZW50ZWQgYWNjb3JkaW5nbHkgLSBhbmQg dGhlbiB0aGVyZQ0KDQo+d291bGQgYmUgbm8gdW5jZXJ0YWludHkgYWJvdXQgdGhlIHJhdGlvbmFs ZSBmb3IgdGhpcyBhcHByb2FjaC4NCg0KPg0KDQo+SWYgdGhlIGJlc3QgcHJhY3RpY2UgaXMgdG8g dXNlIEROUzY0IGFueXdheSwgdGhlbiBkbyB3ZSB3YW50IHRvIHN0ZWVyDQoNCj5wZW9wbGUgYXdh eSBmcm9tIGl0IGJ5IHByb3ZpZGluZyBhIG1ldGhvZCB0aGF0IGRvZXMgbm90IGRlcGVuZCBvbg0K DQo+RE5TNjQgPw0KDQo+DQoNCj4tLWENCg0KPg0KDQo+DQoNCj4NCg0KPk9uIDkvMTkvMTQsIGZy ZWRAY2lzY28uY29tPG1haWx0bzpmcmVkQGNpc2NvLmNvbT4gPGZyZWRAY2lzY28uY29tPG1haWx0 bzpmcmVkQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQo+PiBBIG5ldyBkcmFmdCBoYXMgYmVlbiBwb3N0 ZWQsIGF0DQoNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctdjZvcHMt eGxhdC1wcmVmaXgtZGlzY292ZXJ5LiBQbGVhc2UNCg0KPj4gdGFrZSBhIGxvb2sgYXQgaXQgYW5k IGNvbW1lbnQuDQoNCj4+DQoNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KDQo+PiB2Nm9wc0BpZXRmLm9y ZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQoNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMNCg0KPj4NCg0KPg0KDQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KPnY2b3BzIG1haWxpbmcgbGlzdA0KDQo+djZvcHNA aWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= --_000_787AE7BB302AE849A7480A190F8B933008230COPEXCLILM23corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIFN5bWJvbCI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg SFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD qWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVh ciBMaXNoYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RldJVywgSeKAmW0gb25lIG9m IHRoZSBhdXRob3JzIG9mIHRoZSBESENQdjYgb3B0aW9uIGFuYWx5emVkIGluIFJGQzcwNTEuIFdl IGFiYW5kb25lZCB0aGUgZGhjcHY2IHRyYWNrIGJlY2F1c2UgdGhlIHJlY29tbWVuZGF0aW9uIG9m IHRoZSBiZWhhdmUgd2cgYXQgdGhhdCB0aW1lIGlzIHRoZQ0KIGhldXJpc3RpYy1iYXNlZCBhcHBy b2FjaC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgeW91IGNhbiByZWFkIGluIGRv Y3VtZW50IHNoZXBoZXJkZWQgZm9yIHJmYzcwNTAsIHRoZSB3ZyBpcyBhd2FyZSBvZiB0aGUgbGlt aXRhdGlvbnMgb2YgdGhlIHNvbHV0aW9uICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9yZmM3MDUwL2hpc3RvcnkvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9yZmM3MDUwL2hpc3RvcnkvPC9hPik6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A74oCcVGhlIGRvY3VtZW50IHNwZWNpZmllcyBhIGhldXJpc3RpYyB0 aGF0IGlzIG5vdCBwZXJmZWN0IGFuZCBzbyBzb21lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IHBvaW50cyB3ZXJlIHJvdWdoLCBidXQgdGhlIGNvbnN0cmFpbnQgZm9yIHRoaXMgZG9jdW1l bnQgd2FzIHRvIG9wZXJhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgd2l0aG91dCBj aGFuZ2VzIHRvIGNvZGUgKG9ubHkgY29uZmlndXJhdGlvbikgaW4gZXhpc3RpbmcgbmV0d29ya3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdpdmVuIHRoYXQgY29uc3RyYWludCwgdGhl cmUgd2FzIHN0cm9uZyBjb25zZW5zdXMuJm5ic3A7IFJlbGF4aW5nIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyBjb25zdHJhaW50IHdvdWxkIGFsbG93IG9uZSB0byBkbyBiZXR0ZXIs IGFuZCB0aGF0IGlzIHRoZSBmb2N1cyBvZiBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGRyYWZ0IHJlY2VudGx5IHN1Ym1pdHRlZCB0byB0aGUgUENQIFdHLuKAnTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHRoZW4sIFJGQzcyMjUgd2FzIHB1Ymxpc2hlZCBieSB0aGUg cGNwIHdnLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZu YnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+ IExpc2hhbiBMaTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAyNCBzZXB0ZW1i cmUgMjAxNCAxMzoyODxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQW5kcmV3IDwvc3Bhbj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkgU3ltYm9sJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPvCfkb08L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWW91cnRjaGVua288YnI+DQo8Yj5DYyZu YnNwOzo8L2I+IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5QHRvb2xzLmll dGYub3JnOyB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9w c10gbmV3IGRyYWZ0OiBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBBbmRyZXcsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIGFuZCB0 aGUgcmVmZXJlbmNlIHBvaW50ZXIuIEl0J3Mgb2YgZ3JlYXQgaGVscC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5JIGFncmVlIHdpdGggeW91ciBpZGVhLiBCdXQgd2hhdCBJIGludGVu ZGVkIHRvIG1lYW4gd2FzIHRoYXQgdGhlIG1lc3NhZ2UgZXhjaGFuZ2Ugb2YgRE5TNjQgaXMgJnF1 b3Q7Y29tcGxpY2F0ZWQmcXVvdDsgbm90ICZxdW90O2RpZmZpY3VsdCZxdW90Oy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5MZWFybmluZyB0aGUgSVB2NiBQcmVmaXgg dXNpbmcgREhDUHY2IGxvb2tzIGxpa2UgbG93ZXIgY29tcGxleGl0eSBpbiBjb21wYXJpc29uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBtYWluIHB1cnBvc2Ugb2YgdGhlIGRy YWZ0IGlzIG5vdCBzdGVlcmluZyBwZW9wbGUgYXdheSBmcm9tIEROUzY0LiBMZWFybmluZyB0aGUg SVB2NiBwcmVmaXggdXNpbmcgREhDUHY2IGlzIHNpbXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPmFuZCBkaXJlY3QuIERIQ1B2NiBpcyBkZXNpZ25lZCB0byBwcm92 aWRlIHZhcmlvdXMga2luZHMgb2YgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBpbiBhIGNlbnRy YWxseSBtYW5hZ2VkIGZhc2hpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QmVz dCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkxpc2hh biBMaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkF0IDIwMTQtMDktMjAgMDA6NDE6MTYsICZxdW90O0FuZHJldyA8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj7wn5G9PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7IFlvdXJ0Y2hlbmtvJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YXlvdXJ0Y2hAZ21h aWwuY29tIj5heW91cnRjaEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7TG9va3MgbGlrZSBh IHJlZmVyZW5jZSB0byA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDUx I3BhZ2UtMTUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwNTEjcGFnZS0xNTwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m Z3Q7Y291bGQgYmUgdXNlZnVsLCBhcyB3ZWxsIGFzIHRoZSBtb3JlIGRldGFpbGVkIGRpc2N1c3Np b24gb2Ygd2hhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDtmYWN0b3JzIGFyZSBwcmV2ZW50aW5nIGZyb20gdXNpbmcgdGhlIFJGQzcw NTAncyBtZXRob2QgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7VGhlIHNob3J0IHNlbnRlbmNlICZxdW90O0J1dCBp dCBpcyBkaWZmaWN1bHQgYW5kIGRlcGVuZHMgb24gRE5TNjQmcXVvdDsgcmFpc2VzPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O2ltbWVk aWF0ZSBxdWVzdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsxKSAmcXVvdDtpdCBpcyBkaWZmaWN1bHQmcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0O05lZWRzIHRvIGJlIHF1YWxpZmllZC9yZWFzb25lZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0O0MgY29kZSB0byBjcmVhdGUgYSBETlMgcmVxdWVzdCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4g fjIwMCBsaW5lcywgYW5kPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0O3RoZSBjb2RlIHRvIHBhcnNlIGl0IGNhbiBiZSBkb25lIGluIH4z MDAgbGluZXMsIHNvIGV2ZW4gYSBob3N0IHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7ZG9lcyBub3QgdXNlIHRoZSBETlMgb3Ro ZXJ3aXNlIGNhbiBoYXZlIGEgbGlnaHR3ZWlnaHQgbW9kdWxlIGp1c3QgZm9yPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O3RoZSBzYWtl IG9mIGdldHRpbmcgYSBwcmVmaXguIFRoYXQgaG9zdCBhbHJlYWR5IGhhcyB0byBpbXBsZW1lbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m Z3Q7REhDUHY2IGNsaWVudCwgdGhpcyBkb2VzIG5vdCBsb29rIGxpa2UgYSBsb3Qgb2YgY29kZSBu b3IgYSBsb3Qgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Y29tcGxleGl0eSBpbiBjb21wYXJpc29uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Mikg JnF1b3Q7cmVxdWlyZXMgRE5TNjQmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O1RoaXMgaW4gaXRzZWxmIGNv dWxkIGJlIGEgdmFsaWQgY29uc2lkZXJhdGlvbiBmb3IgYSA0NjRYTEFUIGRlcGxveW1lbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 Y2hvb3NlIHRvIG5vdCB1c2UgRE5TNjQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtCdXQ6IHdoYXQgaXMgdGhlIGJl c3QgKnJlYWwtd29ybGQqIG9wZXJhdGlvbmFsIHByYWN0aWNlIHRvZGF5IC0gdG8gdXNlPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O0RO UzY0IG9yIG5vdCA/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtJZiB0aGUgcmVhbC13b3JsZCBwcmFjdGljZSBzaG93 cyB0aGF0IEROUzY0IGlzIGhhcm1mdWwgaW4gNDY0WExBVDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtkZXBsb3ltZW50cywgdGhpcyBz aG91bGQgYmUgZG9jdW1lbnRlZCBhY2NvcmRpbmdseSAtIGFuZCB0aGVuIHRoZXJlPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O3dvdWxk IGJlIG5vIHVuY2VydGFpbnR5IGFib3V0IHRoZSByYXRpb25hbGUgZm9yIHRoaXMgYXBwcm9hY2gu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDtJZiB0aGUgYmVzdCBwcmFjdGljZSBpcyB0byB1c2UgRE5TNjQgYW55d2F5 LCB0aGVuIGRvIHdlIHdhbnQgdG8gc3RlZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7cGVvcGxlIGF3YXkgZnJvbSBpdCBieSBwcm92 aWRpbmcgYSBtZXRob2QgdGhhdCBkb2VzIG5vdCBkZXBlbmQgb248bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7RE5TNjQgPzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7LS1hPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O09uIDkvMTkvMTQsIDxh IGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+ZnJlZEBjaXNjby5jb208L2E+ICZsdDs8YSBo cmVmPSJtYWlsdG86ZnJlZEBjaXNjby5jb20iPmZyZWRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OyZndDsgQSBuZXcgZHJhZnQgaGFzIGJlZW4gcG9zdGVkLCBhdDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgt ZGlzY292ZXJ5Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLXY2b3BzLXhs YXQtcHJlZml4LWRpc2NvdmVyeTwvYT4uIFBsZWFzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7IHRha2UgYSBsb29rIGF0IGl0 IGFuZCBjb21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0O3Y2b3BzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933008230COPEXCLILM23corpor_-- From nobody Wed Sep 24 05:24:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931E21A0024 for ; Wed, 24 Sep 2014 05:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.032 X-Spam-Level: ** X-Spam-Status: No, score=2.032 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_220=2.118, RP_MATCHES_RCVD=-0.786, 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 cBqrn0lSWuwK for ; Wed, 24 Sep 2014 05:24:29 -0700 (PDT) Received: from m15-57.126.com (m15-57.126.com [220.181.15.57]) by ietfa.amsl.com (Postfix) with ESMTP id ADD121A0040 for ; Wed, 24 Sep 2014 05:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=qdhC4 y5ior3ZwltpkmzXorelhTEqI2dtJ6xTW4n798A=; b=lRXa9y1MpADJzhL0MNP+Z QgQiJ7LUHCnQL0MaIMHpJTQtpWoC6W6TkyIgaPKNv8J+awpMD3dGnszgybTRsIhg PJBDpTsMEk+WxECmCHGLT8V+UhNizxW9KEKWIwngnJcUeFbbVehJ+q8f/i5BvM6V HyEqPrbKqk4Uk8aHuLeETA= Received: from lilishan48$126.com ( [166.111.68.231] ) by ajax-webmail-wmsvr57 (Coremail) ; Wed, 24 Sep 2014 20:24:20 +0800 (CST) X-Originating-IP: [166.111.68.231] Date: Wed, 24 Sep 2014 20:24:20 +0800 (CST) From: "Lishan Li" To: "Lorenzo Colitti" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140725(28226.6623) Copyright (c) 2002-2014 www.mailtech.cn 126com In-Reply-To: References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> X-CM-CTRLDATA: lNsDrmZvb3Rlcl9odG09MjM5MTo4MQ== Content-Type: multipart/alternative; boundary="----=_Part_772792_2059390381.1411561460000" MIME-Version: 1.0 Message-ID: <51ed3cc4.30780.148a79e9121.Coremail.lilishan48@126.com> X-CM-TRANSID: OcqowABn0rL1tyJUw6d2AA--.2194W X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbi6wYRwU0vWKqWJQACsc X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3_zdnQSSwXGRrVcVPWklaZ37cCU Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 12:24:30 -0000 ------=_Part_772792_2059390381.1411561460000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 IERlYXIgTG9yZW56bywKClRoYW5rcyBhIGxvdCBmb3IgeW91ciBjb21tZW50cyBhbmQgZXhwbGFu YXRpb24gb2YgNDY0eGxhdCwgd2hpY2ggZG9lcyBoZWxwIG1lIHRvIHVuZGVyc3RhbmQgaXQgbW9y ZSBwcmVjaXNlbHkuIAoKQXMgZm9yIHRoaXMgY29tbWVudDoKCj5PaywgYnV0IG9uY2UgeW91J3Zl IGxlYXJuZWQgdGhlIHByZWZpeCB1c2luZyBESENQdjYsIHdoYXQgZG8geW91IGRvIHdpdGggaXQ/ IFlvdSBzdGlsbCBuZWVkIGEgRE5TNjQgdW5sZXNzIHlvdSB3YW50IHRvIHB1bXAgYWxsIHRoZSB0 cmFmZmljIHRocm91Z2ggNDY0eGxhdCwgd2hpY2ggaXMgdGVycmlibGUgZm9yIHBlcmZvcm1hbmNl LgoKV2hhdCBkbyB5b3UgbWVhbiBieSDigJxhbGwgdGhlIHRyYWZmaWPigJ0/IEZyb20gbXkgcmVh ZGluZyBvZiBSRkM2ODc3LCBhbGwgdGhlIElQdjQgdHJhZmZpYyBzaG91bGQgZ28gdGhyb3VnaCA0 NjR4bGF0IGJ1dCBhbGwgdGhlIHY2IHRyYWZmaWMgc2hvdWxkIGdvIG5hdGl2ZSB2NiAocGxlYXNl IGNvcnJlY3QgbWUgaWYgSeKAmW0gd3JvbmcsIHRoYW5rcyEpLiBPdXIgcHJvcG9zYWwgZGlkbuKA mXQgaW50ZW50IHRvIGNoYW5nZSB0aGF04oCmIAoKVGhhbmtzIQoKTGlzaGFuIExpCgoK5ZyoIDIw MTQtMDktMjQgMTk6Mzc6MjDvvIwiTG9yZW56byBDb2xpdHRpIiA8bG9yZW56b0Bnb29nbGUuY29t PiDlhpnpgZPvvJoKCk9uIFdlZCwgU2VwIDI0LCAyMDE0IGF0IDg6MjcgUE0sIExpc2hhbiBMaSA8 bGlsaXNoYW40OEAxMjYuY29tPiB3cm90ZToKCkkgYWdyZWUgd2l0aCB5b3VyIGlkZWEuIEJ1dCB3 aGF0IEkgaW50ZW5kZWQgdG8gbWVhbiB3YXMgdGhhdCB0aGUgbWVzc2FnZSBleGNoYW5nZSBvZiBE TlM2NCBpcyAiY29tcGxpY2F0ZWQiIG5vdCAiZGlmZmljdWx0Ii4KCkxlYXJuaW5nIHRoZSBJUHY2 IFByZWZpeCB1c2luZyBESENQdjYgbG9va3MgbGlrZSBsb3dlciBjb21wbGV4aXR5IGluIGNvbXBh cmlzb24uCgoKT2ssIGJ1dCBvbmNlIHlvdSd2ZSBsZWFybmVkIHRoZSBwcmVmaXggdXNpbmcgREhD UHY2LCB3aGF0IGRvIHlvdSBkbyB3aXRoIGl0PyBZb3Ugc3RpbGwgbmVlZCBhIEROUzY0IHVubGVz cyB5b3Ugd2FudCB0byBwdW1wIGFsbCB0aGUgdHJhZmZpYyB0aHJvdWdoIDQ2NHhsYXQsIHdoaWNo IGlzIHRlcnJpYmxlIGZvciBwZXJmb3JtYW5jZS4= ------=_Part_772792_2059390381.1411561460000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+Jm5ic3A7RGVhciZuYnNwO0xvcmVuem8sPGJyPjxicj5U aGFua3MmbmJzcDthJm5ic3A7bG90Jm5ic3A7Zm9yJm5ic3A7eW91ciZuYnNwO2NvbW1lbnRzJm5i c3A7YW5kJm5ic3A7ZXhwbGFuYXRpb24mbmJzcDtvZiZuYnNwOzQ2NHhsYXQsJm5ic3A7d2hpY2gm bmJzcDtkb2VzJm5ic3A7aGVscCZuYnNwO21lJm5ic3A7dG8mbmJzcDt1bmRlcnN0YW5kJm5ic3A7 aXQmbmJzcDttb3JlJm5ic3A7cHJlY2lzZWx5LiZuYnNwOzxicj48YnI+QXMmbmJzcDtmb3ImbmJz cDt0aGlzJm5ic3A7Y29tbWVudDo8YnI+PGJyPiZndDtPaywmbmJzcDtidXQmbmJzcDtvbmNlJm5i c3A7eW91J3ZlJm5ic3A7bGVhcm5lZCZuYnNwO3RoZSZuYnNwO3ByZWZpeCZuYnNwO3VzaW5nJm5i c3A7REhDUHY2LCZuYnNwO3doYXQmbmJzcDtkbyZuYnNwO3lvdSZuYnNwO2RvJm5ic3A7d2l0aCZu YnNwO2l0PyZuYnNwO1lvdSZuYnNwO3N0aWxsJm5ic3A7bmVlZCZuYnNwO2EmbmJzcDtETlM2NCZu YnNwO3VubGVzcyZuYnNwO3lvdSZuYnNwO3dhbnQmbmJzcDt0byZuYnNwO3B1bXAmbmJzcDthbGwm bmJzcDt0aGUmbmJzcDt0cmFmZmljJm5ic3A7dGhyb3VnaCZuYnNwOzQ2NHhsYXQsJm5ic3A7d2hp Y2gmbmJzcDtpcyZuYnNwO3RlcnJpYmxlJm5ic3A7Zm9yJm5ic3A7cGVyZm9ybWFuY2UuPGJyPjxi cj5XaGF0Jm5ic3A7ZG8mbmJzcDt5b3UmbmJzcDttZWFuJm5ic3A7YnkmbmJzcDvigJxhbGwmbmJz cDt0aGUmbmJzcDt0cmFmZmlj4oCdPyZuYnNwO0Zyb20mbmJzcDtteSZuYnNwO3JlYWRpbmcmbmJz cDtvZiZuYnNwO1JGQzY4NzcsJm5ic3A7YWxsJm5ic3A7dGhlJm5ic3A7SVB2NCZuYnNwO3RyYWZm aWMmbmJzcDtzaG91bGQmbmJzcDtnbyZuYnNwO3Rocm91Z2gmbmJzcDs0NjR4bGF0Jm5ic3A7YnV0 Jm5ic3A7YWxsJm5ic3A7dGhlJm5ic3A7djYmbmJzcDt0cmFmZmljJm5ic3A7c2hvdWxkJm5ic3A7 Z28mbmJzcDtuYXRpdmUmbmJzcDt2NiZuYnNwOyhwbGVhc2UmbmJzcDtjb3JyZWN0Jm5ic3A7bWUm bmJzcDtpZiZuYnNwO0nigJltJm5ic3A7d3JvbmcsJm5ic3A7dGhhbmtzISkuJm5ic3A7T3VyJm5i c3A7cHJvcG9zYWwmbmJzcDtkaWRu4oCZdCZuYnNwO2ludGVudCZuYnNwO3RvJm5ic3A7Y2hhbmdl Jm5ic3A7dGhhdOKApiZuYnNwOzxicj48YnI+VGhhbmtzITxicj48L2Rpdj48ZGl2Pkxpc2hhbiBM aTwvZGl2Pjxicj48YnI+5ZyoIDIwMTQtMDktMjQgMTk6Mzc6MjDvvIwiTG9yZW56byBDb2xpdHRp IiAmbHQ7bG9yZW56b0Bnb29nbGUuY29tJmd0OyDlhpnpgZPvvJo8YnI+IDxibG9ja3F1b3RlIGlk PSJpc1JlcGx5Q29udGVudCIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAw cHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPjxkaXYgZGlyPSJsdHIi PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2Vk LCBTZXAgMjQsIDIwMTQgYXQgODoyNyBQTSwgTGlzaGFuIExpIDxzcGFuIGRpcj0ibHRyIj4mbHQ7 PGEgaHJlZj0ibWFpbHRvOmxpbGlzaGFuNDhAMTI2LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpbGlz aGFuNDhAMTI2LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2Nv bG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+PHNwYW4g c3R5bGU9ImxpbmUtaGVpZ2h0OjEuNyI+SSBhZ3JlZSB3aXRoIHlvdXIgaWRlYS4gQnV0IHdoYXQg SSBpbnRlbmRlZCB0byBtZWFuIHdhcyB0aGF0IHRoZSBtZXNzYWdlIGV4Y2hhbmdlIG9mIEROUzY0 IGlzICJjb21wbGljYXRlZCIgbm90ICJkaWZmaWN1bHQiLjwvc3Bhbj48YnI+PC9kaXY+PGRpdj5M ZWFybmluZyB0aGUgSVB2NiBQcmVmaXggdXNpbmcgREhDUHY2IGxvb2tzIGxpa2UgbG93ZXIgY29t cGxleGl0eSBpbiBjb21wYXJpc29uLjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48 L2Rpdj48ZGl2Pk9rLCBidXQgb25jZSB5b3UndmUgbGVhcm5lZCB0aGUgcHJlZml4IHVzaW5nIERI Q1B2Niwgd2hhdCBkbyB5b3UgZG8gd2l0aCBpdD8gWW91IHN0aWxsIG5lZWQgYSBETlM2NCB1bmxl c3MgeW91IHdhbnQgdG8gcHVtcCBhbGwgdGhlIHRyYWZmaWMgdGhyb3VnaCA0NjR4bGF0LCB3aGlj aCBpcyB0ZXJyaWJsZSBmb3IgcGVyZm9ybWFuY2UuPC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+Cjwv YmxvY2txdW90ZT48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNlZm9vdGVyIj48c3Bh biBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bhbj4= ------=_Part_772792_2059390381.1411561460000-- From nobody Wed Sep 24 05:30:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8C1A0063 for ; Wed, 24 Sep 2014 05:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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.786, 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 JlfxHANCZOUY for ; Wed, 24 Sep 2014 05:30:35 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C4E1A005D for ; Wed, 24 Sep 2014 05:30:35 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar1so8525290iec.11 for ; Wed, 24 Sep 2014 05:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jvx8Q4hef8FDZh3iS7wirrXgNFRvmNOSr+SxgmXybD0=; b=Z9525HlO11O0WRF4zDZ8R6HMb1kbp28APJrG8/KcJbuGj+3g/U2ndDCROZsBYV3ipL zQP+mIylq6iIvPKXRTtzWWolSaoko4ZtAG0579cHeyTtQoPPMMMBhGBnQqKIHx1zZosX 12fZj743r2zQQh/1I2RbAIOMLPBNZPozK263v3mIc4K7DZf+TkYbumqkSvXWic1ZbaNP QmDnJmw2b2/8tpgYCM6zp4gR85VlmF/fuit75VkHhJbdmjLlcNJQ0MIpaiAarsgX4i+p INIpF/i9iJ1C1UHwy4nZ4S3fYyFBkw6F60+719tWfdb78d5SHjWH1lQjio9pzbwiSY5Z nP2g== 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=Jvx8Q4hef8FDZh3iS7wirrXgNFRvmNOSr+SxgmXybD0=; b=U+xtalhNaD22ejPtBGPBxuldA8475qznRkkaONgegVwQ3I9rU4d1KAwX3Kmt4bXm5O bPhq+Jx+GeUVN26bEePT6ugh/LjZPSQszSbxlWHe6S3AQVRsbOvlWpFFVkr1+YZ36mMP CI4zD3NYcGrt/0X4I+t+ulq2ReikG2c66eulFyZqFZF0tDL21bV8OtbG4N7qN4/Aw8PC cbYZIRqrekEotWaYG/t7P1MWfwHJRohpKLjpT5n9nT4s6SJWS+EFaEZlEtydWHCvpNRU wBz9Peez66So0q8gqb8WL6aA3XgcPqbUBWF7yvt3Eo/IO89SEpdKJwL4jn6w0YdyEDt7 JTWg== X-Gm-Message-State: ALoCoQk2sSHwFFrgWL2CSNf839hlyWAlqaf0AukAu3uVa5fXrdXKjmwI4uP5ofZIDuBcwWxE+ske X-Received: by 10.43.165.133 with SMTP id mw5mr10518903icc.35.1411561834534; Wed, 24 Sep 2014 05:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Wed, 24 Sep 2014 05:30:14 -0700 (PDT) In-Reply-To: <51ed3cc4.30780.148a79e9121.Coremail.lilishan48@126.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <51ed3cc4.30780.148a79e9121.Coremail.lilishan48@126.com> From: Lorenzo Colitti Date: Wed, 24 Sep 2014 21:30:14 +0900 Message-ID: To: Lishan Li Content-Type: multipart/alternative; boundary=001a11c254c8ba03e70503ced906 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pusz6xuMXGBxIfUNs2brwc-aUCo Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 12:30:37 -0000 --001a11c254c8ba03e70503ced906 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 24, 2014 at 9:24 PM, Lishan Li wrote: > > What do you mean by =E2=80=9Call the traffic=E2=80=9D? From my reading of= RFC6877, all the IPv4 traffic should go through 464xlat but all the v6 tra= ffic should go native v6 (please correct me if I=E2=80=99m wrong, thanks!).= Our proposal didn=E2=80=99t intent to change that=E2=80=A6 > All traffic to an IPv4 server, e.g., to the vast majority of websites and cloud providers. - Using 464xlat / NAT64 / DNS64, traffic to an IPv4 server will use native IPv6 and then NAT64 - Withoug DNS64, traffic to an IPv4 server will IPv4 and then 464xlat and then NAT64 --001a11c254c8ba03e70503ced906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 24, 2014 at 9:24 PM, Lishan Li <lilishan48@126.com>= wrote:
What=C2=A0do=C2=A0you=C2=A0mean=C2= =A0by=C2=A0=E2=80=9Call=C2=A0the=C2=A0traffic=E2=80=9D?=C2=A0From=C2=A0my= =C2=A0reading=C2=A0of=C2=A0RFC6877,=C2=A0all=C2=A0the=C2=A0IPv4=C2=A0traffi= c=C2=A0should=C2=A0go=C2=A0through=C2=A0464xlat=C2=A0but=C2=A0all=C2=A0the= =C2=A0v6=C2=A0traffic=C2=A0should=C2=A0go=C2=A0native=C2=A0v6=C2=A0(please= =C2=A0correct=C2=A0me=C2=A0if=C2=A0I=E2=80=99m=C2=A0wrong,=C2=A0thanks!).= =C2=A0Our=C2=A0proposal=C2=A0didn=E2=80=99t=C2=A0intent=C2=A0to=C2=A0change= =C2=A0that=E2=80=A6=C2=A0

A= ll traffic to an IPv4 server, e.g., to the vast majority of websites and cl= oud providers.

- Using 464xlat / NAT64 / DNS64, tr= affic to an IPv4 server will use native IPv6 and then NAT64
- Wit= houg DNS64, traffic to an IPv4 server will IPv4 and then 464xlat and then N= AT64
--001a11c254c8ba03e70503ced906-- From nobody Wed Sep 24 05:34:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C068C1A006B for ; Wed, 24 Sep 2014 05:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.032 X-Spam-Level: ** X-Spam-Status: No, score=2.032 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_220=2.118, RP_MATCHES_RCVD=-0.786, 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 LeB45XSB1omC for ; Wed, 24 Sep 2014 05:34:12 -0700 (PDT) Received: from m15-57.126.com (m15-57.126.com [220.181.15.57]) by ietfa.amsl.com (Postfix) with ESMTP id 913201A006A for ; Wed, 24 Sep 2014 05:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=uu3yl TQ1l+i3qilg4wvpjG2uI8gaFCyw6waBgpEv28w=; b=Q4MFBqd7vXlOpp/Ut61Yv ZTnkLZNisRmpdw4ktRxwKMGSdgGHkQrNUI/JaUPOsqHVb0KaIH8n9EnH1280Be/I 3YsBTQEcy+g9IPFbn2ZnbXGPUZiwQWqWNEJS81H6hyJ4HaQ3ZlaVvbNMysTPebfz Bch+F8M01rKa8yrkACAZxA= Received: from lilishan48$126.com ( [166.111.68.231] ) by ajax-webmail-wmsvr57 (Coremail) ; Wed, 24 Sep 2014 20:34:04 +0800 (CST) X-Originating-IP: [166.111.68.231] Date: Wed, 24 Sep 2014 20:34:04 +0800 (CST) From: "Lishan Li" To: mohamed.boucadair@orange.com X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140725(28226.6623) Copyright (c) 2002-2014 www.mailtech.cn 126com In-Reply-To: <787AE7BB302AE849A7480A190F8B933008230C@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <787AE7BB302AE849A7480A190F8B933008230C@OPEXCLILM23.corporate.adroot.infra.ftgroup> X-CM-CTRLDATA: SU/2ZGZvb3Rlcl9odG09MTUyMDM6ODE= Content-Type: multipart/alternative; boundary="----=_Part_774998_859608242.1411562044686" MIME-Version: 1.0 Message-ID: <6941a308.30992.148a7a77d0e.Coremail.lilishan48@126.com> X-CM-TRANSID: OcqowABHsbE8uiJUAqt2AA--.2459W X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbi6wURwU0vWKr1dQACss X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NfuyNWo7OaNMy37C2hKAGwsD6Sw Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 12:34:13 -0000 ------=_Part_774998_859608242.1411562044686 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 RGVhciBNZWQgYW5kIGFsbCwKCk1hbnkgdGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24hIFRoaXMg ZG9lcyBhIGxvdCBvZiBnb29kIHRvIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHdob2xlIDQ2NHhs YXQvYmVoYXZlIHN0b3J5IChhbmQgc29ycnkgZm9yIG1pc3NpbmcgdGhhdCBwYXJ0KS4gVGhlIHJl YXNvbiBmb3IgdGhpcyBkcmFmdCBpcyB0aGF0IHdlIGZvdW5kIHRoZSBSRkMocykgYWxsb3dzIGEg c2Vjb25kIG1ldGhvZCBmb3IgcHJlZml4IGRpc2NvdmVyeSBhbmQgd2UgdGhvdWdodCBESENQIG1p Z2h0IGJlIGFuIG9wdGlvbiBoZXJlLiAKCk5vdyBJIGdldCB0aGUgd2hvbGUgcGljdHVyZSBhbmQg d2lsbCBkbyBzb21lIHJlc2VhcmNoIG9uIHRoZSByZWxhdGVkIFJGQ3MuIAoKVGhhbmtzIGFnYWlu IQoKQmVzdCByZWdhcmRzLAoKTGlzaGFuIExpCgoK5ZyoIDIwMTQtMDktMjQgMTk6NDc6NTTvvIxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIOWGmemBk++8mgoKCkRlYXIgTGlzaGFuLAoKIAoK RldJVywgSeKAmW0gb25lIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBESENQdjYgb3B0aW9uIGFuYWx5 emVkIGluIFJGQzcwNTEuIFdlIGFiYW5kb25lZCB0aGUgZGhjcHY2IHRyYWNrIGJlY2F1c2UgdGhl IHJlY29tbWVuZGF0aW9uIG9mIHRoZSBiZWhhdmUgd2cgYXQgdGhhdCB0aW1lIGlzIHRoZSBoZXVy aXN0aWMtYmFzZWQgYXBwcm9hY2guCgogCgpBcyB5b3UgY2FuIHJlYWQgaW4gZG9jdW1lbnQgc2hl cGhlcmRlZCBmb3IgcmZjNzA1MCwgdGhlIHdnIGlzIGF3YXJlIG9mIHRoZSBsaW1pdGF0aW9ucyBv ZiB0aGUgc29sdXRpb24gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzcwNTAv aGlzdG9yeS8pOgoKIAoKICAg4oCcVGhlIGRvY3VtZW50IHNwZWNpZmllcyBhIGhldXJpc3RpYyB0 aGF0IGlzIG5vdCBwZXJmZWN0IGFuZCBzbyBzb21lCgogICAgcG9pbnRzIHdlcmUgcm91Z2gsIGJ1 dCB0aGUgY29uc3RyYWludCBmb3IgdGhpcyBkb2N1bWVudCB3YXMgdG8gb3BlcmF0ZQoKICAgIHdp dGhvdXQgY2hhbmdlcyB0byBjb2RlIChvbmx5IGNvbmZpZ3VyYXRpb24pIGluIGV4aXN0aW5nIG5l dHdvcmtzLgoKICAgIEdpdmVuIHRoYXQgY29uc3RyYWludCwgdGhlcmUgd2FzIHN0cm9uZyBjb25z ZW5zdXMuICBSZWxheGluZyB0aGUKCiAgICBjb25zdHJhaW50IHdvdWxkIGFsbG93IG9uZSB0byBk byBiZXR0ZXIsIGFuZCB0aGF0IGlzIHRoZSBmb2N1cyBvZiBhCgogICAgZHJhZnQgcmVjZW50bHkg c3VibWl0dGVkIHRvIHRoZSBQQ1AgV0cu4oCdCgogCgpTaW5jZSB0aGVuLCBSRkM3MjI1IHdhcyBw dWJsaXNoZWQgYnkgdGhlIHBjcCB3Zy4KCiAKCkNoZWVycywKCk1lZAoKIAoKRGUgOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTGlzaGFuIExpCkVu dm95w6kgOiBtZXJjcmVkaSAyNCBzZXB0ZW1icmUgMjAxNCAxMzoyOArDgCA6IEFuZHJldyDwn5G9 IFlvdXJ0Y2hlbmtvCkNjIDpkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeUB0 b29scy5pZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcKT2JqZXQgOiBSZTogW3Y2b3BzXSBuZXcgZHJh ZnQ6IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5CgogCgpEZWFyIEFuZHJl dywKCiAKClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyBhbmQgdGhlIHJlZmVyZW5jZSBwb2ludGVy LiBJdCdzIG9mIGdyZWF0IGhlbHAuCgogCgpJIGFncmVlIHdpdGggeW91ciBpZGVhLiBCdXQgd2hh dCBJIGludGVuZGVkIHRvIG1lYW4gd2FzIHRoYXQgdGhlIG1lc3NhZ2UgZXhjaGFuZ2Ugb2YgRE5T NjQgaXMgImNvbXBsaWNhdGVkIiBub3QgImRpZmZpY3VsdCIuCgpMZWFybmluZyB0aGUgSVB2NiBQ cmVmaXggdXNpbmcgREhDUHY2IGxvb2tzIGxpa2UgbG93ZXIgY29tcGxleGl0eSBpbiBjb21wYXJp c29uLgoKIAoKVGhlIG1haW4gcHVycG9zZSBvZiB0aGUgZHJhZnQgaXMgbm90IHN0ZWVyaW5nIHBl b3BsZSBhd2F5IGZyb20gRE5TNjQuIExlYXJuaW5nIHRoZSBJUHY2IHByZWZpeCB1c2luZyBESENQ djYgaXMgc2ltcGxlCgphbmQgZGlyZWN0LiBESENQdjYgaXMgZGVzaWduZWQgdG8gcHJvdmlkZSB2 YXJpb3VzIGtpbmRzIG9mIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaW4gYSBjZW50cmFsbHkg bWFuYWdlZCBmYXNoaW9uLgoKIAoKQmVzdCByZWdhcmRzLAoKTGlzaGFuIExpCgogCgpBdCAyMDE0 LTA5LTIwIDAwOjQxOjE2LCAiQW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtvIiA8YXlvdXJ0Y2hAZ21h aWwuY29tPiB3cm90ZToKPkxvb2tzIGxpa2UgYSByZWZlcmVuY2UgdG8gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzA1MSNwYWdlLTE1Cj5jb3VsZCBiZSB1c2VmdWwsIGFzIHdlbGwgYXMg dGhlIG1vcmUgZGV0YWlsZWQgZGlzY3Vzc2lvbiBvZiB3aGF0Cj5mYWN0b3JzIGFyZSBwcmV2ZW50 aW5nIGZyb20gdXNpbmcgdGhlIFJGQzcwNTAncyBtZXRob2QgPwo+IAo+VGhlIHNob3J0IHNlbnRl bmNlICJCdXQgaXQgaXMgZGlmZmljdWx0IGFuZCBkZXBlbmRzIG9uIEROUzY0IiByYWlzZXMKPmlt bWVkaWF0ZSBxdWVzdGlvbnM6Cj4gCj4xKSAiaXQgaXMgZGlmZmljdWx0Igo+IAo+TmVlZHMgdG8g YmUgcXVhbGlmaWVkL3JlYXNvbmVkLgo+IAo+QyBjb2RlIHRvIGNyZWF0ZSBhIEROUyByZXF1ZXN0 IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiB+MjAwIGxpbmVzLCBhbmQKPnRoZSBjb2RlIHRvIHBhcnNl IGl0IGNhbiBiZSBkb25lIGluIH4zMDAgbGluZXMsIHNvIGV2ZW4gYSBob3N0IHRoYXQKPmRvZXMg bm90IHVzZSB0aGUgRE5TIG90aGVyd2lzZSBjYW4gaGF2ZSBhIGxpZ2h0d2VpZ2h0IG1vZHVsZSBq dXN0IGZvcgo+dGhlIHNha2Ugb2YgZ2V0dGluZyBhIHByZWZpeC4gVGhhdCBob3N0IGFscmVhZHkg aGFzIHRvIGltcGxlbWVudAo+REhDUHY2IGNsaWVudCwgdGhpcyBkb2VzIG5vdCBsb29rIGxpa2Ug YSBsb3Qgb2YgY29kZSBub3IgYSBsb3Qgb2YKPmNvbXBsZXhpdHkgaW4gY29tcGFyaXNvbi4KPiAK PjIpICJyZXF1aXJlcyBETlM2NCIKPiAKPlRoaXMgaW4gaXRzZWxmIGNvdWxkIGJlIGEgdmFsaWQg Y29uc2lkZXJhdGlvbiBmb3IgYSA0NjRYTEFUIGRlcGxveW1lbnQKPmNob29zZSB0byBub3QgdXNl IEROUzY0Lgo+IAo+QnV0OiB3aGF0IGlzIHRoZSBiZXN0ICpyZWFsLXdvcmxkKiBvcGVyYXRpb25h bCBwcmFjdGljZSB0b2RheSAtIHRvIHVzZQo+RE5TNjQgb3Igbm90ID8KPiAKPklmIHRoZSByZWFs LXdvcmxkIHByYWN0aWNlIHNob3dzIHRoYXQgRE5TNjQgaXMgaGFybWZ1bCBpbiA0NjRYTEFUCj5k ZXBsb3ltZW50cywgdGhpcyBzaG91bGQgYmUgZG9jdW1lbnRlZCBhY2NvcmRpbmdseSAtIGFuZCB0 aGVuIHRoZXJlCj53b3VsZCBiZSBubyB1bmNlcnRhaW50eSBhYm91dCB0aGUgcmF0aW9uYWxlIGZv ciB0aGlzIGFwcHJvYWNoLgo+IAo+SWYgdGhlIGJlc3QgcHJhY3RpY2UgaXMgdG8gdXNlIEROUzY0 IGFueXdheSwgdGhlbiBkbyB3ZSB3YW50IHRvIHN0ZWVyCj5wZW9wbGUgYXdheSBmcm9tIGl0IGJ5 IHByb3ZpZGluZyBhIG1ldGhvZCB0aGF0IGRvZXMgbm90IGRlcGVuZCBvbgo+RE5TNjQgPwo+IAo+ LS1hCj4gCj4gCj4gCj5PbiA5LzE5LzE0LCBmcmVkQGNpc2NvLmNvbSA8ZnJlZEBjaXNjby5jb20+ IHdyb3RlOgo+PiBBIG5ldyBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQsIGF0Cj4+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5LiBQ bGVhc2UKPj4gdGFrZSBhIGxvb2sgYXQgaXQgYW5kIGNvbW1lbnQuCj4+IAo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiB2Nm9wcyBtYWlsaW5nIGxp c3QKPj4gdjZvcHNAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcwo+PiAKPiAKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj52Nm9wcyBtYWlsaW5nIGxpc3QKPnY2b3BzQGlldGYub3JnCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzCgog ------=_Part_774998_859608242.1411562044686 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+RGVhciZuYnNwO01lZCZuYnNwO2FuZCZuYnNwO2FsbCw8 YnI+PGJyPk1hbnkmbmJzcDt0aGFua3MmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtpbmZvcm1hdGlv biEmbmJzcDtUaGlzJm5ic3A7ZG9lcyZuYnNwO2EmbmJzcDtsb3QmbmJzcDtvZiZuYnNwO2dvb2Qm bmJzcDt0byZuYnNwO215Jm5ic3A7dW5kZXJzdGFuZGluZyZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 d2hvbGUmbmJzcDs0NjR4bGF0L2JlaGF2ZSZuYnNwO3N0b3J5Jm5ic3A7KGFuZCZuYnNwO3NvcnJ5 Jm5ic3A7Zm9yJm5ic3A7bWlzc2luZyZuYnNwO3RoYXQmbmJzcDtwYXJ0KS4mbmJzcDtUaGUmbmJz cDtyZWFzb24mbmJzcDtmb3ImbmJzcDt0aGlzJm5ic3A7ZHJhZnQmbmJzcDtpcyZuYnNwO3RoYXQm bmJzcDt3ZSZuYnNwO2ZvdW5kJm5ic3A7dGhlJm5ic3A7UkZDKHMpJm5ic3A7YWxsb3dzJm5ic3A7 YSZuYnNwO3NlY29uZCZuYnNwO21ldGhvZCZuYnNwO2ZvciZuYnNwO3ByZWZpeCZuYnNwO2Rpc2Nv dmVyeSZuYnNwO2FuZCZuYnNwO3dlJm5ic3A7dGhvdWdodCZuYnNwO0RIQ1AmbmJzcDttaWdodCZu YnNwO2JlJm5ic3A7YW4mbmJzcDtvcHRpb24mbmJzcDtoZXJlLiZuYnNwOzxicj48YnI+Tm93Jm5i c3A7SSZuYnNwO2dldCZuYnNwO3RoZSZuYnNwO3dob2xlJm5ic3A7cGljdHVyZSZuYnNwO2FuZCZu YnNwO3dpbGwmbmJzcDtkbyZuYnNwO3NvbWUmbmJzcDtyZXNlYXJjaCZuYnNwO29uJm5ic3A7dGhl Jm5ic3A7cmVsYXRlZCZuYnNwO1JGQ3MuJm5ic3A7PGJyPjxicj5UaGFua3MmbmJzcDthZ2FpbiE8 YnI+PGJyPkJlc3QmbmJzcDtyZWdhcmRzLDxicj48L2Rpdj48ZGl2Pkxpc2hhbiBMaTwvZGl2Pjxk aXY+PC9kaXY+PGRpdiBpZD0iZGl2TmV0ZWFzZU1haWxDYXJkIj48L2Rpdj48ZGl2Pjxicj48L2Rp dj7lnKggMjAxNC0wOS0yNCAxOTo0Nzo1NO+8jG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20g 5YaZ6YGT77yaPGJyPiA8YmxvY2txdW90ZSBpZD0iaXNSZXBseUNvbnRlbnQiIHN0eWxlPSJQQURE SU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNj Y2MgMXB4IHNvbGlkIj4KCgoKPHN0eWxlPjwhLS0KCl9mb250LWZhY2UKCXtmb250LWZhbWlseTpD YWxpYnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQpfZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6VGFob21hOwoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQpfZm9udC1m YWNlCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg NDt9Cl9mb250LWZhY2UKCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsKCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30KCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXpl OjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsK CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30KcHJlCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0 eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7CgltYXJnaW46MGNtOwoJbWFyZ2luLWJv dHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjEwLjBwdDsKCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQpzcGFuLlByZm9ybWF0SFRNTENhcgoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg SFRNTCBDYXIiOwoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIjsKCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30Kc3Bhbi5FbWFpbFN0eWxlMTkK CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsKCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Cgljb2xvcjojMUY0OTdEO30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9Cl9wYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0OwoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQpkaXYuV29yZFNlY3Rpb24xCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPgoKCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgTGlz aGFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5GV0lXLCBJ4oCZbSBvbmUgb2YgdGhlIGF1 dGhvcnMgb2YgdGhlIERIQ1B2NiBvcHRpb24gYW5hbHl6ZWQgaW4gUkZDNzA1MS4gV2UgYWJhbmRv bmVkIHRoZSBkaGNwdjYgdHJhY2sgYmVjYXVzZSB0aGUgcmVjb21tZW5kYXRpb24gb2YgdGhlIGJl aGF2ZSB3ZyBhdCB0aGF0IHRpbWUgaXMgdGhlCiBoZXVyaXN0aWMtYmFzZWQgYXBwcm9hY2guIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyB5b3UgY2FuIHJlYWQgaW4gZG9jdW1lbnQgc2hl cGhlcmRlZCBmb3IgcmZjNzA1MCwgdGhlIHdnIGlzIGF3YXJlIG9mIHRoZSBsaW1pdGF0aW9ucyBv ZiB0aGUgc29sdXRpb24gKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L3JmYzcwNTAvaGlzdG9yeS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzcw NTAvaGlzdG9yeS88L2E+KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A74oCcVGhlIGRvY3VtZW50IHNwZWNpZmllcyBhIGhldXJpc3RpYyB0aGF0IGlzIG5vdCBw ZXJmZWN0IGFuZCBzbyBzb21lPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgcG9pbnRzIHdl cmUgcm91Z2gsIGJ1dCB0aGUgY29uc3RyYWludCBmb3IgdGhpcyBkb2N1bWVudCB3YXMgdG8gb3Bl cmF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGhvdXQgY2hhbmdlcyB0byBjb2Rl IChvbmx5IGNvbmZpZ3VyYXRpb24pIGluIGV4aXN0aW5nIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEdpdmVuIHRoYXQgY29uc3RyYWludCwgdGhlcmUgd2FzIHN0cm9uZyBj b25zZW5zdXMuJm5ic3A7IFJlbGF4aW5nIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbnN0cmFpbnQgd291bGQgYWxsb3cgb25lIHRvIGRvIGJldHRlciwgYW5kIHRoYXQgaXMgdGhl IGZvY3VzIG9mIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdCByZWNlbnRseSBz dWJtaXR0ZWQgdG8gdGhlIFBDUCBXRy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2lu Y2UgdGhlbiwgUkZDNzIyNSB3YXMgcHVibGlzaGVkIGJ5IHRoZSBwY3Agd2cuCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4KPGRpdj4KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dCjxiPkRl IGxhIHBhcnQgZGU8L2I+IExpc2hhbiBMaTxicj4KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNy ZWRpIDI0IHNlcHRlbWJyZSAyMDE0IDEzOjI4PGJyPgo8Yj7DgCZuYnNwOzo8L2I+IEFuZHJldyA8 L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7wn5G9 PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFlvdXJ0Y2hlbmtv PGJyPgo8Yj5DYyZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC13YW5nLXY2b3BzLXhs YXQtcHJlZml4LWRpc2NvdmVyeUB0b29scy5pZXRmLm9yZyI+ZHJhZnQtd2FuZy12Nm9wcy14bGF0 LXByZWZpeC1kaXNjb3ZlcnlAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4KPGI+T2JqZXQmbmJzcDs6PC9iPiBS ZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292 ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIEFuZHJldyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMgYW5kIHRoZSBy ZWZlcmVuY2UgcG9pbnRlci4gSXQncyBvZiBncmVhdCBoZWxwLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+Cjxk aXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkkgYWdyZWUgd2l0aCB5b3VyIGlkZWEuIEJ1dCB3aGF0IEkgaW50ZW5kZWQgdG8gbWVh biB3YXMgdGhhdCB0aGUgbWVzc2FnZSBleGNoYW5nZSBvZiBETlM2NCBpcyAiY29tcGxpY2F0ZWQi IG5vdCAiZGlmZmljdWx0Ii48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5M ZWFybmluZyB0aGUgSVB2NiBQcmVmaXggdXNpbmcgREhDUHY2IGxvb2tzIGxpa2UgbG93ZXIgY29t cGxleGl0eSBpbiBjb21wYXJpc29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBtYWlu IHB1cnBvc2Ugb2YgdGhlIGRyYWZ0IGlzIG5vdCBzdGVlcmluZyBwZW9wbGUgYXdheSBmcm9tIERO UzY0LiBMZWFybmluZyB0aGUgSVB2NiBwcmVmaXggdXNpbmcgREhDUHY2IGlzIHNpbXBsZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmFuZCBkaXJlY3QuIERIQ1B2NiBpcyBk ZXNpZ25lZCB0byBwcm92aWRlIHZhcmlvdXMga2luZHMgb2YgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbiBpbiBhIGNlbnRyYWxseSBtYW5hZ2VkIGZhc2hpb24uPG86cD48L286cD48L3NwYW4+PC9w Pgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pkxpc2hhbiBMaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5BdCAyMDE0LTA5LTIwIDAwOjQxOjE2LCAiQW5kcmV3IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPvCfkb08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsgWW91cnRjaGVua28iICZsdDs8YSBocmVmPSJtYWlsdG86YXlvdXJ0Y2hAZ21haWwuY29tIj5h eW91cnRjaEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtMb29rcyBsaWtlIGEgcmVmZXJlbmNl IHRvIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwNTEjcGFnZS0xNSI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA1MSNwYWdlLTE1PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O2NvdWxkIGJl IHVzZWZ1bCwgYXMgd2VsbCBhcyB0aGUgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9uIG9mIHdoYXQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDtmYWN0b3JzIGFyZSBwcmV2ZW50aW5nIGZyb20gdXNpbmcgdGhlIFJGQzcwNTAncyBtZXRob2Qg PzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0O1RoZSBzaG9ydCBzZW50ZW5jZSAiQnV0IGl0IGlzIGRpZmZpY3VsdCBhbmQg ZGVwZW5kcyBvbiBETlM2NCIgcmFpc2VzPG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7aW1tZWRpYXRlIHF1ZXN0aW9uczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsxKSAiaXQgaXMgZGlmZmljdWx0IjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPgo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O05lZWRzIHRvIGJlIHF1YWxpZmllZC9y ZWFzb25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDtDIGNvZGUgdG8gY3JlYXRlIGEgRE5TIHJlcXVlc3QgY2FuIGJl IGltcGxlbWVudGVkIGluIH4yMDAgbGluZXMsIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O3RoZSBjb2RlIHRvIHBhcnNlIGl0IGNh biBiZSBkb25lIGluIH4zMDAgbGluZXMsIHNvIGV2ZW4gYSBob3N0IHRoYXQ8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtkb2VzIG5vdCB1 c2UgdGhlIEROUyBvdGhlcndpc2UgY2FuIGhhdmUgYSBsaWdodHdlaWdodCBtb2R1bGUganVzdCBm b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZndDt0aGUgc2FrZSBvZiBnZXR0aW5nIGEgcHJlZml4LiBUaGF0IGhvc3QgYWxyZWFkeSBoYXMg dG8gaW1wbGVtZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7REhDUHY2IGNsaWVudCwgdGhpcyBkb2VzIG5vdCBsb29rIGxpa2UgYSBs b3Qgb2YgY29kZSBub3IgYSBsb3Qgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtjb21wbGV4aXR5IGluIGNvbXBhcmlzb24uPG86cD48 L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7MikgInJlcXVpcmVzIEROUzY0IjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O1RoaXMgaW4gaXRzZWxmIGNvdWxk IGJlIGEgdmFsaWQgY29uc2lkZXJhdGlvbiBmb3IgYSA0NjRYTEFUIGRlcGxveW1lbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtjaG9v c2UgdG8gbm90IHVzZSBETlM2NC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtCdXQ6IHdoYXQgaXMgdGhlIGJlc3QgKnJl YWwtd29ybGQqIG9wZXJhdGlvbmFsIHByYWN0aWNlIHRvZGF5IC0gdG8gdXNlPG86cD48L286cD48 L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7RE5TNjQgb3Ig bm90ID88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDtJZiB0aGUgcmVhbC13b3JsZCBwcmFjdGljZSBzaG93cyB0aGF0IERO UzY0IGlzIGhhcm1mdWwgaW4gNDY0WExBVDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O2RlcGxveW1lbnRzLCB0aGlzIHNob3VsZCBiZSBk b2N1bWVudGVkIGFjY29yZGluZ2x5IC0gYW5kIHRoZW4gdGhlcmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDt3b3VsZCBiZSBubyB1bmNl cnRhaW50eSBhYm91dCB0aGUgcmF0aW9uYWxlIGZvciB0aGlzIGFwcHJvYWNoLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 O0lmIHRoZSBiZXN0IHByYWN0aWNlIGlzIHRvIHVzZSBETlM2NCBhbnl3YXksIHRoZW4gZG8gd2Ug d2FudCB0byBzdGVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0O3Blb3BsZSBhd2F5IGZyb20gaXQgYnkgcHJvdmlkaW5nIGEgbWV0aG9k IHRoYXQgZG9lcyBub3QgZGVwZW5kIG9uPG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7RE5TNjQgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0Oy0tYTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0O09uIDkvMTkvMTQsIDxhIGhyZWY9Im1haWx0bzpmcmVkQGNp c2NvLmNvbSI+ZnJlZEBjaXNjby5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZEBjaXNj by5jb20iPmZyZWRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w cmU+CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyBBIG5ldyBkcmFmdCBo YXMgYmVlbiBwb3N0ZWQsIGF0PG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeSI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3Zlcnk8L2E+ LiBQbGVhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDsmZ3Q7IHRha2UgYSBsb29rIGF0IGl0IGFuZCBjb21tZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDs8bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m Z3Q7Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0Bp ZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O3Y2b3BzIG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KCgo8L2Jsb2Nr cXVvdGU+PC9kaXY+PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHNwYW4gaWQ9 Im5ldGVhc2VfbWFpbF9mb290ZXIiPjwvc3Bhbj48L3NwYW4+ ------=_Part_774998_859608242.1411562044686-- From nobody Wed Sep 24 05:44:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD9F1A00B7 for ; Wed, 24 Sep 2014 05:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.035 X-Spam-Level: X-Spam-Status: No, score=-4.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoo39tUBDNNH for ; Wed, 24 Sep 2014 05:44:24 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BACD1A0097 for ; Wed, 24 Sep 2014 05:44:23 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP; 24 Sep 2014 14:44:02 +0200 X-IronPort-AV: E=Sophos;i="5.04,589,1406584800"; d="scan'208,217";a="667521658" Received: from he113495.emea1.cds.t-internal.com ([10.206.92.152]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 24 Sep 2014 14:44:02 +0200 Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE113495.emea1.cds.t-internal.com ([10.206.92.152]) with mapi; Wed, 24 Sep 2014 14:44:01 +0200 From: To: , Date: Wed, 24 Sep 2014 14:44:00 +0200 Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: Ac/X8pBoGVgQPyH1RjGRtb5ILFYIYQAAdb3Q Message-ID: <88CAA5385EB5404392BF93106C8C53F892495A8D0E@HE111507.emea1.cds.t-internal.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <51ed3cc4.30780.148a79e9121.Coremail.lilishan48@126.com> In-Reply-To: <51ed3cc4.30780.148a79e9121.Coremail.lilishan48@126.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_88CAA5385EB5404392BF93106C8C53F892495A8D0EHE111507emea1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Pr79MQFHiihCg6n0kKz4Jyn1JMg Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 12:44:27 -0000 --_000_88CAA5385EB5404392BF93106C8C53F892495A8D0EHE111507emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCmFsbCB0aGUgdHJhZmZpYyBnZW5lcmF0ZWQgYnkgYW4gSVB2NC1vbmx5IGFwcGxp Y2F0aW9uLCBnb2luZyB0byBhbiBJUHY0IG9yIER1YWwgU3RhY2sgc2VydmVyLCBzaG91bGQgZ28g dGhyb3VnaCBDTEFUK1BMQVQuDQoNCkJ1dCwgYWxsIHRoZSB0cmFmZmljIGdlbmVyYXRlZCBieSBh IER1YWwgU3RhY2sgYXBwbGljYXRpb24sIGdvaW5nIHRvIGFuIElQdjQgc2VydmVyLCBzaG91bGQg bm90IGdvIHRocm91Z2ggQ0xBVCwgb25seSBQTEFULCB0aHVzLCB0aGUgYXBwbGljYXRpb24gc2hv dWxkIGdlbmVyYXRlIHRoZSBJUHY2IHBhY2tldHMgdGFyZ2V0ZWQgYXQgdGhlIFBMQVQgZm9yIDYt PjQgdHJhbnNsYXRpb24gZGlyZWN0bHkgKHNlZSB0aGUgdGFibGUgYXQgdGhlIGVuZCBvZiBzZWN0 aW9uIDcuMiBvZiBSRkMgNjg3NykuIFNpbmNlIENMQVQgdXN1YWxseSBydW5zIG9uIGEgbG93KGVy KS1wZXJmb3JtYW5jZSBlbmQgZGV2aWNlLCBpdHMgdXNlIHNob3VsZCBiZSBhdm9pZGUgaWYgcG9z c2libGUuIEFuZCwgYnkgdG9kYXksIHRoaXMgdHlwZSBvZiB0cmFmZmljIGlzIHRoZSB2YXN0IG1h am9yaXR5IGFzIGZhciBhcyBJIGNhbiBqdWRnZS4NCg0KSWYgeW91IGRvbuKAmXQgaGF2ZSBhIERO UzY0IChsb2NhdGVkIGVpdGhlciBhdCB0aGUgcHJvdmlkZXIsIG9yIGxvY2FsbHkpLCB0aGUgbGF0 dGVyIGNhbm5vdCBiZSBhY2hpZXZlZC4NCg0KSG9sZ2VyDQpWb246IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gTGlzaGFuIExpDQpHZXNlbmRldDog TWl0dHdvY2gsIDI0LiBTZXB0ZW1iZXIgMjAxNCAxNDoyNA0KQW46IExvcmVuem8gQ29saXR0aQ0K Q2M6IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5QHRvb2xzLmlldGYub3Jn OyB2Nm9wc0BpZXRmLm9yZyBXRw0KQmV0cmVmZjogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFm dC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeQ0KDQogRGVhciBMb3JlbnpvLA0KDQpU aGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMgYW5kIGV4cGxhbmF0aW9uIG9mIDQ2NHhsYXQs IHdoaWNoIGRvZXMgaGVscCBtZSB0byB1bmRlcnN0YW5kIGl0IG1vcmUgcHJlY2lzZWx5Lg0KDQpB cyBmb3IgdGhpcyBjb21tZW50Og0KDQo+T2ssIGJ1dCBvbmNlIHlvdSd2ZSBsZWFybmVkIHRoZSBw cmVmaXggdXNpbmcgREhDUHY2LCB3aGF0IGRvIHlvdSBkbyB3aXRoIGl0PyBZb3Ugc3RpbGwgbmVl ZCBhIEROUzY0IHVubGVzcyB5b3Ugd2FudCB0byBwdW1wIGFsbCB0aGUgdHJhZmZpYyB0aHJvdWdo IDQ2NHhsYXQsIHdoaWNoIGlzIHRlcnJpYmxlIGZvciBwZXJmb3JtYW5jZS4NCg0KV2hhdCBkbyB5 b3UgbWVhbiBieSDigJxhbGwgdGhlIHRyYWZmaWPigJ0/IEZyb20gbXkgcmVhZGluZyBvZiBSRkM2 ODc3LCBhbGwgdGhlIElQdjQgdHJhZmZpYyBzaG91bGQgZ28gdGhyb3VnaCA0NjR4bGF0IGJ1dCBh bGwgdGhlIHY2IHRyYWZmaWMgc2hvdWxkIGdvIG5hdGl2ZSB2NiAocGxlYXNlIGNvcnJlY3QgbWUg aWYgSeKAmW0gd3JvbmcsIHRoYW5rcyEpLiBPdXIgcHJvcG9zYWwgZGlkbuKAmXQgaW50ZW50IHRv IGNoYW5nZSB0aGF04oCmDQoNClRoYW5rcyENCkxpc2hhbiBMaQ0KDQoNCuWcqCAyMDE0LTA5LTI0 IDE5OjM3OjIw77yMIkxvcmVuem8gQ29saXR0aSIgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86 bG9yZW56b0Bnb29nbGUuY29tPj4g5YaZ6YGT77yaDQoNCk9uIFdlZCwgU2VwIDI0LCAyMDE0IGF0 IDg6MjcgUE0sIExpc2hhbiBMaSA8bGlsaXNoYW40OEAxMjYuY29tPG1haWx0bzpsaWxpc2hhbjQ4 QDEyNi5jb20+PiB3cm90ZToNCkkgYWdyZWUgd2l0aCB5b3VyIGlkZWEuIEJ1dCB3aGF0IEkgaW50 ZW5kZWQgdG8gbWVhbiB3YXMgdGhhdCB0aGUgbWVzc2FnZSBleGNoYW5nZSBvZiBETlM2NCBpcyAi Y29tcGxpY2F0ZWQiIG5vdCAiZGlmZmljdWx0Ii4NCkxlYXJuaW5nIHRoZSBJUHY2IFByZWZpeCB1 c2luZyBESENQdjYgbG9va3MgbGlrZSBsb3dlciBjb21wbGV4aXR5IGluIGNvbXBhcmlzb24uDQoN Ck9rLCBidXQgb25jZSB5b3UndmUgbGVhcm5lZCB0aGUgcHJlZml4IHVzaW5nIERIQ1B2Niwgd2hh dCBkbyB5b3UgZG8gd2l0aCBpdD8gWW91IHN0aWxsIG5lZWQgYSBETlM2NCB1bmxlc3MgeW91IHdh bnQgdG8gcHVtcCBhbGwgdGhlIHRyYWZmaWMgdGhyb3VnaCA0NjR4bGF0LCB3aGljaCBpcyB0ZXJy aWJsZSBmb3IgcGVyZm9ybWFuY2UuDQoNCg== --_000_88CAA5385EB5404392BF93106C8C53F892495A8D0EHE111507emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPURFIGxpbms9Ymx1 ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPmFsbCB0aGUgdHJhZmZpYyBnZW5lcmF0ZWQgYnkgYW4gSVB2NC1vbmx5IGFwcGxpY2F0aW9u LCBnb2luZyB0byBhbiBJUHY0IG9yIER1YWwgU3RhY2sgc2VydmVyLCBzaG91bGQgZ28gdGhyb3Vn aCBDTEFUK1BMQVQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QnV0 LCBhbGwgdGhlIHRyYWZmaWMgZ2VuZXJhdGVkIGJ5IGEgRHVhbCBTdGFjayBhcHBsaWNhdGlvbiwg Z29pbmcgdG8gYW4gSVB2NCBzZXJ2ZXIsIHNob3VsZCBub3QgZ28gdGhyb3VnaCBDTEFULCBvbmx5 IFBMQVQsIHRodXMsIHRoZSBhcHBsaWNhdGlvbiBzaG91bGQgZ2VuZXJhdGUgdGhlIElQdjYgcGFj a2V0cyB0YXJnZXRlZCBhdCB0aGUgUExBVCBmb3IgNi0mZ3Q7NCB0cmFuc2xhdGlvbiBkaXJlY3Rs eSAoc2VlIHRoZSB0YWJsZSBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gNy4yIG9mIFJGQyA2ODc3KS4g U2luY2UgQ0xBVCB1c3VhbGx5IHJ1bnMgb24gYSBsb3coZXIpLXBlcmZvcm1hbmNlIGVuZCBkZXZp Y2UsIGl0cyB1c2Ugc2hvdWxkIGJlIGF2b2lkZSBpZiBwb3NzaWJsZS4gQW5kLCBieSB0b2RheSwg dGhpcyB0eXBlIG9mIHRyYWZmaWMgaXMgdGhlIHZhc3QgbWFqb3JpdHkgYXMgZmFyIGFzIEkgY2Fu IGp1ZGdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIHlvdSBk b27igJl0IGhhdmUgYSBETlM2NCAobG9jYXRlZCBlaXRoZXIgYXQgdGhlIHByb3ZpZGVyLCBvciBs b2NhbGx5KSwgdGhlIGxhdHRlciBjYW5ub3QgYmUgYWNoaWV2ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SG9sZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Wb246PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIDxi PkltIEF1ZnRyYWcgdm9uIDwvYj5MaXNoYW4gTGk8YnI+PGI+R2VzZW5kZXQ6PC9iPiBNaXR0d29j aCwgMjQuIFNlcHRlbWJlciAyMDE0IDE0OjI0PGJyPjxiPkFuOjwvYj4gTG9yZW56byBDb2xpdHRp PGJyPjxiPkNjOjwvYj4gZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3ZlcnlAdG9v bHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnIFdHPGJyPjxiPkJldHJlZmY6PC9iPiBSZTogW3Y2 b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4m bmJzcDtEZWFyJm5ic3A7TG9yZW56byw8YnI+PGJyPlRoYW5rcyZuYnNwO2EmbmJzcDtsb3QmbmJz cDtmb3ImbmJzcDt5b3VyJm5ic3A7Y29tbWVudHMmbmJzcDthbmQmbmJzcDtleHBsYW5hdGlvbiZu YnNwO29mJm5ic3A7NDY0eGxhdCwmbmJzcDt3aGljaCZuYnNwO2RvZXMmbmJzcDtoZWxwJm5ic3A7 bWUmbmJzcDt0byZuYnNwO3VuZGVyc3RhbmQmbmJzcDtpdCZuYnNwO21vcmUmbmJzcDtwcmVjaXNl bHkuJm5ic3A7PGJyPjxicj5BcyZuYnNwO2ZvciZuYnNwO3RoaXMmbmJzcDtjb21tZW50Ojxicj48 YnI+Jmd0O09rLCZuYnNwO2J1dCZuYnNwO29uY2UmbmJzcDt5b3UndmUmbmJzcDtsZWFybmVkJm5i c3A7dGhlJm5ic3A7cHJlZml4Jm5ic3A7dXNpbmcmbmJzcDtESENQdjYsJm5ic3A7d2hhdCZuYnNw O2RvJm5ic3A7eW91Jm5ic3A7ZG8mbmJzcDt3aXRoJm5ic3A7aXQ/Jm5ic3A7WW91Jm5ic3A7c3Rp bGwmbmJzcDtuZWVkJm5ic3A7YSZuYnNwO0ROUzY0Jm5ic3A7dW5sZXNzJm5ic3A7eW91Jm5ic3A7 d2FudCZuYnNwO3RvJm5ic3A7cHVtcCZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO3RyYWZmaWMmbmJz cDt0aHJvdWdoJm5ic3A7NDY0eGxhdCwmbmJzcDt3aGljaCZuYnNwO2lzJm5ic3A7dGVycmlibGUm bmJzcDtmb3ImbmJzcDtwZXJmb3JtYW5jZS48YnI+PGJyPldoYXQmbmJzcDtkbyZuYnNwO3lvdSZu YnNwO21lYW4mbmJzcDtieSZuYnNwO+KAnGFsbCZuYnNwO3RoZSZuYnNwO3RyYWZmaWPigJ0/Jm5i c3A7RnJvbSZuYnNwO215Jm5ic3A7cmVhZGluZyZuYnNwO29mJm5ic3A7UkZDNjg3NywmbmJzcDth bGwmbmJzcDt0aGUmbmJzcDtJUHY0Jm5ic3A7dHJhZmZpYyZuYnNwO3Nob3VsZCZuYnNwO2dvJm5i c3A7dGhyb3VnaCZuYnNwOzQ2NHhsYXQmbmJzcDtidXQmbmJzcDthbGwmbmJzcDt0aGUmbmJzcDt2 NiZuYnNwO3RyYWZmaWMmbmJzcDtzaG91bGQmbmJzcDtnbyZuYnNwO25hdGl2ZSZuYnNwO3Y2Jm5i c3A7KHBsZWFzZSZuYnNwO2NvcnJlY3QmbmJzcDttZSZuYnNwO2lmJm5ic3A7SeKAmW0mbmJzcDt3 cm9uZywmbmJzcDt0aGFua3MhKS4mbmJzcDtPdXImbmJzcDtwcm9wb3NhbCZuYnNwO2RpZG7igJl0 Jm5ic3A7aW50ZW50Jm5ic3A7dG8mbmJzcDtjaGFuZ2UmbmJzcDt0aGF04oCmJm5ic3A7PGJyPjxi cj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5MaXNoYW4gTGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48YnI+PGJyPjwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiTVMgR290aGljIjtjb2xv cjpibGFjayc+5ZyoPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gMjAxNC0wOS0yNCAxOTozNzoy MDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiTVMgR290 aGljIjtjb2xvcjpibGFjayc+77yMPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mcXVvdDtMb3Jl bnpvIENvbGl0dGkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20i PmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseToiTVMgR290aGljIjtjb2xvcjpibGFjayc+5YaZ6YGT77yaPC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPk9uIFdlZCwg U2VwIDI0LCAyMDE0IGF0IDg6MjcgUE0sIExpc2hhbiBMaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxp bGlzaGFuNDhAMTI2LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpbGlzaGFuNDhAMTI2LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5JIGFncmVlIHdpdGggeW91ciBpZGVhLiBCdXQgd2hhdCBJ IGludGVuZGVkIHRvIG1lYW4gd2FzIHRoYXQgdGhlIG1lc3NhZ2UgZXhjaGFuZ2Ugb2YgRE5TNjQg aXMgJnF1b3Q7Y29tcGxpY2F0ZWQmcXVvdDsgbm90ICZxdW90O2RpZmZpY3VsdCZxdW90Oy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPkxlYXJuaW5nIHRoZSBJUHY2IFByZWZpeCB1c2luZyBESENQdjYgbG9va3MgbGlr ZSBsb3dlciBjb21wbGV4aXR5IGluIGNvbXBhcmlzb24uPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPk9rLCBidXQgb25jZSB5b3UndmUgbGVhcm5lZCB0aGUgcHJlZml4IHVz aW5nIERIQ1B2Niwgd2hhdCBkbyB5b3UgZG8gd2l0aCBpdD8gWW91IHN0aWxsIG5lZWQgYSBETlM2 NCB1bmxlc3MgeW91IHdhbnQgdG8gcHVtcCBhbGwgdGhlIHRyYWZmaWMgdGhyb3VnaCA0NjR4bGF0 LCB3aGljaCBpcyB0ZXJyaWJsZSBmb3IgcGVyZm9ybWFuY2UuPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48 L2h0bWw+ --_000_88CAA5385EB5404392BF93106C8C53F892495A8D0EHE111507emea1_-- From nobody Wed Sep 24 05:51:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320FA1A00BB for ; Wed, 24 Sep 2014 05:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnGzcdRBpHBf for ; Wed, 24 Sep 2014 05:51:34 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36ED01A00B7 for ; Wed, 24 Sep 2014 05:51:34 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1000] (port=48867 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XWm2Z-0000uI-5v; Wed, 24 Sep 2014 14:51:27 +0200 Message-ID: <5422BE4E.1040601@fud.no> Date: Wed, 24 Sep 2014 14:51:26 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Lorenzo Colitti , Lishan Li References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/q2D1tCc-e3olLMe5jHmgrNz8OXY Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 12:51:36 -0000 * Lorenzo Colitti > Ok, but once you've learned the prefix using DHCPv6, what do you do with > it? You still need a DNS64 unless you want to pump all the traffic > through 464xlat, which is terrible for performance. AIUI, Orange Poland has opted to use 464XLAT without DNS64 (see http://www.data.proidea.org.pl/plnog/12edycja/day2/track4/01_ipv6_implementation.pdf slides 7 and 8). Presumably they hard code the PLAT prefix in their handsets to make this work. A DHCPv6 option would allow their handset to dynamically discover the PLAT prefix instead. Tore From nobody Wed Sep 24 06:03:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D51A00B6 for ; Wed, 24 Sep 2014 06:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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.786, 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 n6bKQO9iI8_8 for ; Wed, 24 Sep 2014 06:03:41 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019681A00BB for ; Wed, 24 Sep 2014 06:02:38 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id tp5so6155066ieb.27 for ; Wed, 24 Sep 2014 06:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SQVkO5SS72bR03uDbB1zKWNVtq4RuxoFFjLNK8vaAmw=; b=C74LghVg94KcFo71P4+4itopSb1IbWLFL8EK4TdQdnquKfvWk8W3+mNuiNyiYabekV 8VdxiUC2nohDsFmPXfjHskrp8A1IKLIcOItU0yMzFbjZogI+jnRSyWFchoP+vqFuXQRW k2cQANZ19EvdWYgrDk666IuOD21cC/xDLn2qPqcrydIF0zgGD1MP3txPwQ5uS0RBAnWA BxHsqqhL4J/FY7uK6bl+4Pa8JeyNqZuskaNtQs2+39bEwl7EH20KBwZ3PatUd7DQUu4e DP2IE6hmhx2YQgeoRVekyeW1DR1LjTbO6oFK+I1UI1c2Xv4qTNzQvt7uU4GBSSXVakzW wNjg== 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=SQVkO5SS72bR03uDbB1zKWNVtq4RuxoFFjLNK8vaAmw=; b=mCQ49IZTfOjp/5xjjo82aOlb+X8nKKPvSFiUv/+mcwMO6xZ8INBC3k+OlIeEl4QaL5 DrOdRHCAra2RiFfNIk578cbR9bYI6qR3p41VdcvxFLTPmVEn0sO0Gaqe4MXesfpwKSrd xSsicTHD8veMOhV2HnHNw9kkXCrX6s0Xbf00X04vhJ/unt+M3Ud3uSo9i3oV4bFl2DC+ Nt79DPgRpQ4Aa0lx310D+UqX96D1Rd+rzNuqrQ85rRcPlYWDSjpOPOvddltX0hpr3KFS 4vMgfZOVsUrJJTOIs0kk51RmuEchS5SkKwp3A9i63HXM8pA65eGZuGUtcxUO7HJPW3jz G0Jw== X-Gm-Message-State: ALoCoQmcPAi7042Zz6GHpwkR2KJqMTAXNpGurDQkzbA3cbgGlS13NfXD/0cj+aQZv037bKUUiMLj X-Received: by 10.50.4.9 with SMTP id g9mr12366758igg.42.1411563758317; Wed, 24 Sep 2014 06:02:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Wed, 24 Sep 2014 06:02:18 -0700 (PDT) In-Reply-To: <5422BE4E.1040601@fud.no> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> From: Lorenzo Colitti Date: Wed, 24 Sep 2014 22:02:18 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=001a11c3184e64b2250503cf4c22 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lN826eIZXRVF6-PFQACxgVhuePw Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 13:03:42 -0000 --001a11c3184e64b2250503cf4c22 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 24, 2014 at 9:51 PM, Tore Anderson wrote: > > Ok, but once you've learned the prefix using DHCPv6, what do you do with > > it? You still need a DNS64 unless you want to pump all the traffic > > through 464xlat, which is terrible for performance. > > AIUI, Orange Poland has opted to use 464XLAT without DNS64 (see > > http://www.data.proidea.org.pl/plnog/12edycja/day2/track4/01_ipv6_implementation.pdf > slides 7 and 8). Presumably they hard code the PLAT prefix in their > handsets to make this work. A DHCPv6 option would allow their handset to > dynamically discover the PLAT prefix instead. > Orange Poland is a 3GPP network, and 3GPP networks usually do not support DHCP. Also, you don't need DHCP for that. All you need to do is have your DNS server return appropriate answers to AAAA queries for "ipv4only.arpa". Having spent a fair bit of time on the Android clat daemon, I don't know why you would want to use it without DNS64. I wasn't able to find a reason for that (or even a confirmation that this is what they are doing) in the slides. Do you know what they are doing, and why? --001a11c3184e64b2250503cf4c22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 24, 2014 at 9:51 PM, Tore Anderson <tore@fud.no> wrote:
> Ok, but once you've learned the= prefix using DHCPv6, what do you do with
> it? You still need a DNS64 unless you want to pump all the traffic
> through 464xlat, which is terrible for performance.

AIUI, Orange Poland has opted to use 464XLAT without DNS64 (see
http://www.data.proidea.org.pl/plno= g/12edycja/day2/track4/01_ipv6_implementation.pdf
slides 7 and 8). Presumably they hard code the PLAT prefix in their
handsets to make this work. A DHCPv6 option would allow their handset to dynamically discover the PLAT prefix instead.

Orange Poland is a 3GPP network, and 3GPP networks usually do not su= pport DHCP.

Also, you don't need DHCP for = that. All you need to do is have your DNS server return appropriate answers= to AAAA queries for "ipv4only.arpa".

Ha= ving spent a fair bit of time on the Android clat daemon, I don't know = why you would want to use it without DNS64. I wasn't able to find a rea= son for that (or even a confirmation that this is what they are doing) in t= he slides. Do you know what they are doing, and why?
--001a11c3184e64b2250503cf4c22-- From nobody Wed Sep 24 06:38:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460F91A00D7 for ; Wed, 24 Sep 2014 06:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjjnnlPMAAm3 for ; Wed, 24 Sep 2014 06:38:10 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB12A1A00D0 for ; Wed, 24 Sep 2014 06:38:09 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail11.telekom.de with ESMTP; 24 Sep 2014 15:38:07 +0200 X-IronPort-AV: E=Sophos;i="5.04,589,1406584800"; d="scan'208,217";a="140487543" Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 24 Sep 2014 15:38:06 +0200 Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 24 Sep 2014 15:38:06 +0200 From: To: , Date: Wed, 24 Sep 2014 15:38:05 +0200 Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: Ac/X+AvIbkfn3yLdQw+IKHJlXSPAFwAA/mtg Message-ID: <88CAA5385EB5404392BF93106C8C53F892498C6B37@HE111507.emea1.cds.t-internal.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_88CAA5385EB5404392BF93106C8C53F892498C6B37HE111507emea1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fs8dv2sHPkG7qwtpX-v95pCrC0w Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 13:38:12 -0000 --_000_88CAA5385EB5404392BF93106C8C53F892498C6B37HE111507emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCj4gSGF2aW5nIHNwZW50IGEgZmFpciBiaXQgb2YgdGltZSBvbiB0aGUgQW5kcm9p ZCBjbGF0IGRhZW1vbiwgSSBkb24ndCBrbm93IHdoeSB5b3Ugd291bGQgd2FudCB0byB1c2UgaXQg d2l0aG91dCBETlM2NC4gSSB3YXNuJ3QgYWJsZSB0byA+IGZpbmQgYSByZWFzb24gZm9yIHRoYXQg KG9yIGV2ZW4gYSBjb25maXJtYXRpb24gdGhhdCB0aGlzIGlzIHdoYXQgdGhleSBhcmUgZG9pbmcp IGluIHRoZSBzbGlkZXMuIERvIHlvdSBrbm93IHdoYXQgdGhleSBhcmUgZG9pbmcsIGFuZCB3aHk/ DQoNCkkgY2Fu4oCZdCBzcGVhayBmb3IgdGhlbSwgYnV0IGZvciBhIG1vYmlsZSBwcm92aWRlciBw cm92aWRpbmcgRHVhbCBTdGFjayBzZXJ2aWNlcyBhbmQgSVB2Ni1vbmx5IHNlcnZpY2VzLCBpdCBp cyBoYXJkIHRvIGRlY2lkZSBhdCB0aGUgRE5TIHdoZXRoZXIgYSBkdWFsIFN0YWNrIEhvc3QgaXMg YXNraW5nICg9bm8gRE5TNjQgdG8gYmUgZG9uZSkgb3IgYSBzaW5nbGUgSVB2NiBzdGFjayBob3N0 IGlzIGFza2luZyAoPUROUzY0IG5lZWRzIHRvIGJlIGRvbmUpLg0KDQpPbmUgc29sdXRpb24gd291 bGQgYmUgdG8gaGF2ZSBkaWZmZXJlbnQgY2xpZW50IElQdjYgYWRkcmVzcyByYW5nZXMgZm9yIER1 YWwgU3RhY2sgaG9zdHMgYW5kIElQdjYtb25seSBob3N0cy4gQW5vdGhlciB0aGluZyB3b3VsZCBi ZSB0byBoYW5kIG91dCB0byB0aGUgRHVhbCBTdGFjayBob3N0cyBvbmx5IGFuIElQdjQgRE5TIHJl c29sdmVyIGFkZHJlc3MsIHNvIHRoZSBETlMgcmVzb2x2ZXIga25vd3MgdGhhdCBhbGwgcXVlcmll cyB0aGF0IGNvbWUgdmlhIElQdjYgdHJhbnNwb3J0IGFyZSBmcm9tIElQdjYtb25seSBob3N0cy4g QW5vdGhlciBzb2x1dGlvbiBpcyB0byBoYXJkIGNvZGUgdGhlIFBMQVQgcHJlZml4IGludG8gY2xh dGQsIHNvIHlvdXIgRE5TIGRvZXNu4oCZdCBuZWVkIHRvIGRvIHRoZSBhYm92ZSBzZXBhcmF0aW9u IG9mIHF1ZXJpZXMuDQoNCkhvbGdlcg0K --_000_88CAA5385EB5404392BF93106C8C53F892498C6B37HE111507emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt YXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjk3NzY4NjExMDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTUxNzA0MDQzOCAxODcxODc1MTkyIDY3NTY3NjE5IDY3NTY3NjIxIDY3 NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTE7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCglj b2xvcjojMUY0OTdEO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1ERSBsaW5rPWJsdWUgdmxpbms9cHVycGxl PjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxkaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9RU4t R0I+SGF2aW5nIHNwZW50IGEgZmFpciBiaXQgb2YgdGltZSBvbiB0aGUgQW5kcm9pZCBjbGF0IGRh ZW1vbiwgSSBkb24ndCBrbm93IHdoeSB5b3Ugd291bGQgd2FudCB0byB1c2UgaXQgd2l0aG91dCBE TlM2NC4gSSB3YXNuJ3QgYWJsZSB0byA8c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OyA8 L3NwYW4+ZmluZCBhIHJlYXNvbiBmb3IgdGhhdCAob3IgZXZlbiBhIGNvbmZpcm1hdGlvbiB0aGF0 IHRoaXMgaXMgd2hhdCB0aGV5IGFyZSBkb2luZykgaW4gdGhlIHNsaWRlcy4gPC9zcGFuPkRvIHlv dSBrbm93IHdoYXQgdGhleSBhcmUgZG9pbmcsIGFuZCB3aHk/PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGNhbuKAmXQgc3BlYWsgZm9y IHRoZW0sIGJ1dCBmb3IgYSBtb2JpbGUgcHJvdmlkZXIgcHJvdmlkaW5nIER1YWwgU3RhY2sgc2Vy dmljZXMgYW5kIElQdjYtb25seSBzZXJ2aWNlcywgaXQgaXMgaGFyZCB0byBkZWNpZGUgYXQgdGhl IEROUyB3aGV0aGVyIGEgZHVhbCBTdGFjayBIb3N0IGlzIGFza2luZyAoPW5vIEROUzY0IHRvIGJl IGRvbmUpIG9yIGEgc2luZ2xlIElQdjYgc3RhY2sgaG9zdCBpcyBhc2tpbmcgKD1ETlM2NCBuZWVk cyB0byBiZSBkb25lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5P bmUgc29sdXRpb24gd291bGQgYmUgdG8gaGF2ZSBkaWZmZXJlbnQgY2xpZW50IElQdjYgYWRkcmVz cyByYW5nZXMgZm9yIER1YWwgU3RhY2sgaG9zdHMgYW5kIElQdjYtb25seSBob3N0cy4gQW5vdGhl ciB0aGluZyB3b3VsZCBiZSB0byBoYW5kIG91dCB0byB0aGUgRHVhbCBTdGFjayBob3N0cyBvbmx5 IGFuIElQdjQgRE5TIHJlc29sdmVyIGFkZHJlc3MsIHNvIHRoZSBETlMgcmVzb2x2ZXIga25vd3Mg dGhhdCBhbGwgcXVlcmllcyB0aGF0IGNvbWUgdmlhIElQdjYgdHJhbnNwb3J0IGFyZSBmcm9tIElQ djYtb25seSBob3N0cy4gQW5vdGhlciBzb2x1dGlvbiBpcyB0byBoYXJkIGNvZGUgdGhlIFBMQVQg cHJlZml4IGludG8gY2xhdGQsIHNvIHlvdXIgRE5TIGRvZXNu4oCZdCBuZWVkIHRvIGRvIHRoZSBh Ym92ZSBzZXBhcmF0aW9uIG9mIHF1ZXJpZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SG9sZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_88CAA5385EB5404392BF93106C8C53F892498C6B37HE111507emea1_-- From nobody Wed Sep 24 08:23:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB41A01AE for ; Wed, 24 Sep 2014 08:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3ruzwc8ah04 for ; Wed, 24 Sep 2014 08:23:41 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0185F1A0231 for ; Wed, 24 Sep 2014 08:23:32 -0700 (PDT) Received: from [2a02:fe0:c410:3c30::1] (port=52326 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XWoPe-00049P-JD; Wed, 24 Sep 2014 17:23:26 +0200 Message-ID: <5422E1EE.7020202@fud.no> Date: Wed, 24 Sep 2014 17:23:26 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dFux1bQjv-7nGIgEEfBE5RFUJbM Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 15:23:44 -0000 * Lorenzo Colitti: > Orange Poland is a 3GPP network, and 3GPP networks usually do not > support DHCP. True, for now at least. It was just an example though, it could just as easily have been a wireline ISP that puts a CLAT in their CPEs and runs dual-stack on the LAN segments. I mentioned Orange Poland specifically because they're an *actual* example of a network that uses 464XLAT without DNS64. See http://www.ietf.org/mail-archive/web/v6ops/current/msg19619.html for the confirmation you asked about below. > Also, you don't need DHCP for that. All you need to do is have your DNS > server return appropriate answers to AAAA queries for "ipv4only.arpa". Good point. > Having spent a fair bit of time on the Android clat daemon, I don't know > why you would want to use it without DNS64. I wasn't able to find a > reason for that (or even a confirmation that this is what they are > doing) in the slides. Do you know what they are doing, and why? As to the why, slide 7 says: «CLAT+DNS64 - problems with apps where ipv4 literals&domain names are used». I can easily think of one example; FTP. If an IPv6-only FTP client is speaking to an IPv4-only FTP server through a single layer of translation (NAT64/PLAT), it won't work. The client won't know what to do with the literal IPv4 addresses the server asks it to connect to for the data connection. With dual translation (CLAT+PLAT), it will work. ALGs in the PLAT could help, but not if encryption is being used (e.g., FTP/TLS). In general, dual translation looks more like native IPv4 to the applications, so it might result in slightly fewer interoperability problems than single translation. Tore From nobody Wed Sep 24 08:33:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC81A015F for ; Wed, 24 Sep 2014 08:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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.786, 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 fycnWvxRueHL for ; Wed, 24 Sep 2014 08:33:15 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01BC1A00B9 for ; Wed, 24 Sep 2014 08:33:14 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id hn15so6726915igb.16 for ; Wed, 24 Sep 2014 08:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QqPzH0vV4Fz1afG1PV6PkCskYkrjhLsa0eaZ/0hb+0s=; b=S9vsVj9UKlaeWoBPOJNwgCjpVIoiuekFpde38GbU1MNSjfoYWHJt4zYYfQCxs//fB1 /JqvzJugb9SrPkt6WdCsToqcND0kQFKLoKJ7b0C0mBCziWXdfs+jA0rkLsHSxHde34G/ aduWOA4wsevK/KjCg5B1VsuCK5q75uRaACd2cs4LLCOis4z8ZVG+tJKmpnsjczRe1KEF MAa8Ktx+tSPfKA9FBaar4l4pv5GTEjjFLSqYexE8mrdThafiSgPMkcDDFs5dHCAFwTP3 KGaVka5XXSH9vh+AJwiPxrvtoQR2L7VcU0ijbACxLlEAP9N87T7JhSekLaVKY0opT9Pq QjKw== 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=QqPzH0vV4Fz1afG1PV6PkCskYkrjhLsa0eaZ/0hb+0s=; b=WrqKUVmH07MEB2410eW9P+3p+FYlKsOkyWWc55va5rNMXPnMDgEnEopJ12kGxVMDQ8 8sjo/zqpc4TJkXSPK40YoFrCYUPcQv1p2H56hlFg7ZjeN63RvHOFRmPcmFb5OxztA4U1 xCV91vemrlf0D/Fa6xTzyHmaoUvuVPalTAETyRBmdp8Ty6CW0PSo1ecU6w6ANpOWO1pm zUns4IXqfPG9qzzCgiSAcjni9jZrbIZP/2WQCRWE56BNO2+zxrz2mCiV3Pmhz7ZMbSHi FPmFI5cM01iaZbTeAWHmBkRmkvmpGRiZ1VLysugyGjHpk0cEToHVyeLVSMCZNJlwDq8I NGRg== X-Gm-Message-State: ALoCoQm+ECnqSPm1+PI6hPJJ8M6NjYJZnWFp+eljCt2AGtbTgEUlKexC/9v5tC2VU1VjPCBEPgbO X-Received: by 10.43.94.7 with SMTP id bw7mr10141996icc.26.1411572794411; Wed, 24 Sep 2014 08:33:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Wed, 24 Sep 2014 08:32:54 -0700 (PDT) In-Reply-To: <5422E1EE.7020202@fud.no> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> From: Lorenzo Colitti Date: Thu, 25 Sep 2014 00:32:54 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=bcaec51827acfc719a0503d166ea Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rmbUHrUmgkehX8eHZrv0hZNELAw Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 15:33:16 -0000 --bcaec51827acfc719a0503d166ea Content-Type: text/plain; charset=UTF-8 On Thu, Sep 25, 2014 at 12:23 AM, Tore Anderson wrote: > > Orange Poland is a 3GPP network, and 3GPP networks usually do not > > support DHCP. > > True, for now at least. It was just an example though, it could just as > easily have been a wireline ISP that puts a CLAT in their CPEs and runs > dual-stack on the LAN segments. > But in that case, why wouldn't you use MAP? It provides much better IPv4 connectivity, it's stateless, it scales better... > I can easily think of one example; FTP. If an IPv6-only FTP client is > speaking to an IPv4-only FTP server through a single layer of > translation (NAT64/PLAT), it won't work. The client won't know what to > do with the literal IPv4 addresses the server asks it to connect to for > the data connection. With dual translation (CLAT+PLAT), it will work. > ALGs in the PLAT could help, but not if encryption is being used (e.g., > FTP/TLS) > Not sure I understand what you mean here. Did you mean "the server won't know what to do with the literal IPv6 address the client asks it to connect to"? --bcaec51827acfc719a0503d166ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 25, 2014 at 12:23 AM, Tore Anderson <tore@fud.no> wrote:=
> Orange Poland is a= 3GPP network, and 3GPP networks usually do not
> support DHCP.

True, for now at least. It was just an example though, it could just= as
easily have been a wireline ISP that puts a CLAT in their CPEs and runs
dual-stack on the LAN segments.

But in = that case, why wouldn't you use MAP? It provides much better IPv4 conne= ctivity, it's stateless, it scales better...
=C2=A0
I can easily think of one example; FTP. If an IP= v6-only FTP client is
speaking to an IPv4-only FTP server through a single layer of
translation (NAT64/PLAT), it won't work. The client won't know what= to
do with the literal IPv4 addresses the server asks it to connect to for
the data connection. With dual translation (CLAT+PLAT), it will work.
ALGs in the PLAT could help, but not if encryption is being used (e.g.,
FTP/TLS)

Not sure I understand what you= mean here. Did you mean "the server won't know what to do with th= e literal IPv6 address the client asks it to connect to"?
<= /div>
--bcaec51827acfc719a0503d166ea-- From nobody Wed Sep 24 10:08:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021781A01F4 for ; Wed, 24 Sep 2014 10:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_-NtMKfVIwJ for ; Wed, 24 Sep 2014 10:08:01 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E561E1A0264 for ; Wed, 24 Sep 2014 10:07:38 -0700 (PDT) Received: from [2a02:fe0:c410:3c30::1] (port=52587 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XWq2K-0007KU-57; Wed, 24 Sep 2014 19:07:28 +0200 Message-ID: <5422FA4F.3080003@fud.no> Date: Wed, 24 Sep 2014 19:07:27 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uHj9tdyFczHe3lHnxJfO--9bhoE Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 17:08:05 -0000 * Lorenzo Colitti > But in that case, why wouldn't you use MAP? It provides much better IPv4 > connectivity, it's stateless, it scales better... Maybe you already have boxes already capable of NAT64 lying around, and no room on your budgets for new MAP boxes? I don't know...you could say the same thing about DS-Lite, but people are deploying that, too. So it wouldn't surprise me in the least if someone were to put a CLAT in a CPE, either. > Not sure I understand what you mean here. Did you mean "the server won't > know what to do with the literal IPv6 address the client asks it to > connect to"? Looked a bit more into it, and I think FTP was a poor example. It works when the client is on IPv6. It's worse if the client is on IPv4 and accessing an IPv6 server through SIIT; but it works again with if you use dual translation so the server thinks it's on IPv4 too. Anyway, I suppose it would be better to ask the Orange Poland guys, they should know best which specific application problems they ran into with 464XLAT+DNS64 that caused them to forego DNS64. Tore From nobody Wed Sep 24 12:40:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594021A036A for ; Wed, 24 Sep 2014 12:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_F0DU--a65Y for ; Wed, 24 Sep 2014 12:40:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938C91A036B for ; Wed, 24 Sep 2014 12:40:09 -0700 (PDT) Received: from [128.9.184.210] ([128.9.184.210]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8OJd3Mm002199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Sep 2014 12:39:03 -0700 (PDT) Message-ID: <54231DD7.9040005@isi.edu> Date: Wed, 24 Sep 2014 12:39:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" , "v6ops@ietf.org" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FAj3vB5rd-KbaFHkHroZuNlmQwo Subject: Re: [v6ops] FW: Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Sep 2014 19:40:11 -0000 I am concerned about V6OPS advice that effectively deprecates IPv6 capabilities in a BCP. IMO, if these are significant security or performance issues, they should be reviewed within INTAREA as updates to the IPv6 spec. To do this in a BCP undermines the spec without updating it. Some other comments: The advice sections in this doc fail to use RFC2119-style recommendations. In some cases, lower-case is used, and in other cases odd phrasing is used that avoids RFC2119 keywords. If this is indeed advice in the form of a BCP, the actual advice should be provided in RFC2119-style format. Also, the term "intermediate systems" is used in a NOTE and is not defined; this doc should clearly identify the type of systems that it is intended for (e.g., routers). Joe On 9/24/2014 2:32 AM, Gunter Van de Velde (gvandeve) wrote: > Dear, > > OPSEC Chairs requested "Call for WG adoption" on draft-gont-opsec-ipv6-eh-filtering. > > Please voice your reflexions in OPSEC WG > > G/ > > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Velde (gvandeve) > Sent: 24 September 2014 11:28 > To: opsec@ietf.org > Subject: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers > > Dear, > > Please find this request for WG adoption for "Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers" > The authors of the work explicitly asked for "Call for WG adoption" in its current state. > > Latest draft can be found at: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02 > > (1) Do you support for adopting the draft as OPSEC WG item? > > This call for WG adoption will end 8 October 2014. > > Kind Regards, > OPSEC chairs > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 24 14:42:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014AC1A02EB for ; Wed, 24 Sep 2014 14:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-tzp7bVH7S8 for ; Wed, 24 Sep 2014 14:42:01 -0700 (PDT) Received: from nm20-vm3.bullet.mail.ne1.yahoo.com (nm20-vm3.bullet.mail.ne1.yahoo.com [98.138.91.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006361A0144 for ; Wed, 24 Sep 2014 14:42:00 -0700 (PDT) Received: from [98.138.100.112] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 24 Sep 2014 21:42:00 -0000 Received: from [98.138.87.12] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 24 Sep 2014 21:42:00 -0000 Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP; 24 Sep 2014 21:42:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 46319.83091.bm@omp1012.mail.ne1.yahoo.com Received: (qmail 18775 invoked by uid 60001); 24 Sep 2014 21:42:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411594920; bh=MFeM49i088rRloWSO1L433EpEIK5dcZdLHih976kmeM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AAfT6ef+htIkSYAfB7lr51krp4AeRj2GTAydNb8m3hHYWtM2nXge6NuNVntJp4mhsolJ4kgNBVT+fA2tc69oOQ1Q9ez/mYQ/NdyObE2tclwMoLhrncjPqHoB7T1Ts3qKsl3iAI+t4neo0br0U5oK1aoMTMpDFpvTKYlVdmM2W/I= X-YMail-OSG: bVPzqbAVM1nMidaBwAGnH6Fcvgid6V61Ffr8zx0HLKs1xzN 98.CI_iwtiYMZOMA9QxSGytKnmJaEewysoYoJ2UtUkqkfKNI18AByHxse5hQ eWKtsZMqjy17pf_94d1LBuObQdHuEjwsFloBvRtpzJGKhGuZG1.hkqTS2Jn6 ZrdJHpFnmUzNPAXzYBV8_a3.Gzi_i3IT0u_0.kaXzzBpKzJ3cwxLQhoEInnH AfYjOC.YSQQ58837p.8q2N5QJGC8OWncD8VpUa_0gzi3uZT91o7rvI5qUhg5 bEH8r0MRIzv7hQa7.XyQkz2cAE8x.txTg4w1uPtDUSYKb.toStRfKt.i3Qoj ZgkKxu2dDPKBFqPiGCHTUMUrA6wrnjmfsCC7O3i4TYB.IEunx8fZKE8ScpZv 5i8o47qBeSk2t3ZXNkbFn7XZ0YqC_ff9BAmOHbAMKRtAxQVk04VOvQKotP9x C2sbD8hZPrC1CpyphKWEeDbQEMfjZw_8dn7RSRaOaLU9UqdbXqo585rgitcG m6S1wr1hDjmDVvgrg3HZ.Is4ZLReq10AEom_MXTZukEVbdXsm Received: from [24.130.244.175] by web125103.mail.ne1.yahoo.com via HTTP; Wed, 24 Sep 2014 14:41:59 PDT X-Rocket-MIMEInfo: 002.001, Cgo.PiBJZiBJIGhhdmUgYSAxLDAwMCBub2RlcyB1bmRlciBteSBjb250cm9sLCB0aGVuIHRoYXQgaXMgaG93IG1hbnkgdGhhdCAKPj4gc2hvdWxkIGJlIGluIG15IEFEIGFuZCBCRC4gIElQdjYgYWxsb3dzIGZvciBsYXJnZSBzdWJuZXRzIHNvIHdoeSBub3Q_Cgo.QmVjYXVzZSBpdCdzIGEgYmFkIGlkZWEuIElQdjQgYWxsb3dzIGZvciBzdWJuZXR0aW5nIGF0IC8yMiBmb3IgeW91ciAxMDAwIAo.bm9kZXMsIHRoYXQgZG9lc24ndCBtZWFuIGl0J3MgYSBnb29kIGlkZWEuCgpUaGlzIG5lZWRzIGEgbG90IG1vcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> Message-ID: <1411594919.36798.YahooMailNeo@web125103.mail.ne1.yahoo.com> Date: Wed, 24 Sep 2014 14:41:59 -0700 From: Nalini Elkins To: Mikael Abrahamsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DcbaHXHI8ICggARb0p3ryy9_zUw Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 21:42:03 -0000 >> If I have a 1,000 nodes under my control, then that is how many that >> should be in my AD and BD. IPv6 allows for large subnets so why not? >Because it's a bad idea. IPv4 allows for subnetting at /22 for your 1000 >nodes, that doesn't mean it's a good idea. This needs a lot more discussion. It is a much more complex topic than can be handled in a few sentences. We will do another draft (will have to be for the Dallas IETF as time is getting short now for Hawaii) on node isolation and subnetting. We can discuss at much longer length then. If you would be willing to, we would certainly appreciate some private feedback in advance of our posting. We can send you our draft as we have it. >> On Linux, I believe when you do a PING, it is continuous until >> intentionally stopped. So, doing a Ping to FF02::1 from a Linux machine >> will create havoc without having ill intent. That is, accidentally. >Absolutely, and it's all due to the decision to put a lot of nodes in the >same L2 domain which has been known for 20-30 years to be bad design and >can cause the exact problems you're describing. If you ping the network >broadcast address on IPv4 you get the exact same thing, I don't see why >you blame IPv6 for this? I am not blaming IPv6. In fact, I am an IPv6 bigot and have been preaching conversion to IPv6 for quite a few years. (I might add, much to the dismay of those who have been cornered by me at various events!) What we want to do is to point out where the pitfalls might be in the migration to IPv6 so that people who implement will have as smooth a path as possible so that adoption becomes widespread. Nalini From nobody Wed Sep 24 22:50:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717C31A6F32 for ; Wed, 24 Sep 2014 22:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syup4e7rSIBt for ; Wed, 24 Sep 2014 22:50:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CA91A6F2E for ; Wed, 24 Sep 2014 22:50:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XX1wp-00025v-Jc; Thu, 25 Sep 2014 05:50:36 +0000 Date: Thu, 25 Sep 2014 14:50:33 +0900 Message-ID: From: Randy Bush To: Nalini Elkins In-Reply-To: <1411594919.36798.YahooMailNeo@web125103.mail.ne1.yahoo.com> References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com> <541DB824.7080408@foobar.org> <1411255504.4053.YahooMailNeo@web125102.mail.ne1.yahoo.com> <1411408550.77000.YahooMailNeo@web125104.mail.ne1.yahoo.com> <1411594919.36798.YahooMailNeo@web125103.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EdaASPln4iEumRp7LJBQRrUtirk Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org, V6 Ops List Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 05:50:44 -0000 >>> If I have a 1,000 nodes under my control, then that is how many that >>> should be in my AD and BD. IPv6 allows for large subnets so why not? >> Because it's a bad idea. IPv4 allows for subnetting at /22 for your 1000 >> nodes, that doesn't mean it's a good idea. > This needs a lot more discussion. discussion is not what is lacking. in fact, isn't this a repeat of the same discussion you had last time? we have decades of too much tragic experience of layer two not scaling well. as mikael said, it is a bad idea. do not do it. do not design for it. randy From nobody Wed Sep 24 23:56:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1FF1A6FD1 for ; Wed, 24 Sep 2014 23:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 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.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6GAFij1SyZY for ; Wed, 24 Sep 2014 23:56:08 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0C81A6FB8 for ; Wed, 24 Sep 2014 23:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3968; q=dns/txt; s=iport; t=1411628167; x=1412837767; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=88XaZwANgulr0JIe+28mLvCNK3mUPJcJF7zn9HPQHr4=; b=PTnjSuBFNPZVUjVy3+3b+ZaOV2Nl9R0Zr6T2WeQRROpA9BHv5yO/U3s+ +WifCAm+XtVZmXQOsMxWtDKxJNEsEvjc9Q2UzpTNW/yyTPZIZ3KggEolc Nu+tpA8e2NVPssunzljPfvzX6GxOBYSouoAPuWmch5/k7gZLuEv8Qq7rr w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJy7I1StJA2K/2dsb2JhbABWCg6DAFNXBMo+CodOAYEGFgF6hAMBAQEDAQEBARpRCwUHBAIBCBEEAQEBIwQHJwsUCQgBAQQOBQ6IKAgNwxABF49CXAcGgyiBHQWRXoIKgUtlhwmBYZNzgh+BA0BsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,595,1406592000"; d="asc'?scan'208";a="81088461" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP; 25 Sep 2014 06:56:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8P6u6pu013760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 06:56:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 01:56:06 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers Thread-Index: Ac/X2IHCixEQiP9WSwO6zL/lhjHmPQ== Date: Thu, 25 Sep 2014 06:56:06 +0000 Message-ID: <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> In-Reply-To: <54231DD7.9040005@isi.edu> 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=_054325FC-0B16-47A4-9A7E-124F45168ACD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iygOZY0lZY3c_rmxTPxItR4Phic Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 06:56:10 -0000 --Apple-Mail=_054325FC-0B16-47A4-9A7E-124F45168ACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For the record, Opsec is considering adopting the draft, not v6ops; = Gunter asked v6ops to chime in on the discussion in opsec. The author = has been asking both sets of chairs, and I haven=92t seen the = groundswell of support, or even comment, that would lead in the = direction of v6ops adoption. I personally share your concerns; if we = want to deprecate parts of RFC 2460, I think we need to do that in 6man. = What v6ops or opsec would be chartered to do is give advice. Personally, = deprecating the use of extension headers, whether in fact or in effect, = seems like a very bad idea. Pointing out issues with them has value. I=92m working on a spec right now that uses an extension option. If you = deprecate the header, I=92m just going to have to reinvent it. Not a = great idea. On Sep 24, 2014, at 12:39 PM, Joe Touch wrote: > I am concerned about V6OPS advice that effectively deprecates IPv6 > capabilities in a BCP. IMO, if these are significant security or > performance issues, they should be reviewed within INTAREA as updates = to > the IPv6 spec. >=20 > To do this in a BCP undermines the spec without updating it. >=20 > Some other comments: >=20 > The advice sections in this doc fail to use RFC2119-style > recommendations. In some cases, lower-case is used, and in other cases > odd phrasing is used that avoids RFC2119 keywords. >=20 > If this is indeed advice in the form of a BCP, the actual advice = should > be provided in RFC2119-style format. >=20 > Also, the term "intermediate systems" is used in a NOTE and is not > defined; this doc should clearly identify the type of systems that it = is > intended for (e.g., routers). >=20 > Joe >=20 > On 9/24/2014 2:32 AM, Gunter Van de Velde (gvandeve) wrote: >> Dear, >>=20 >> OPSEC Chairs requested "Call for WG adoption" on = draft-gont-opsec-ipv6-eh-filtering. >>=20 >> Please voice your reflexions in OPSEC WG >>=20 >> G/ >>=20 >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van = de Velde (gvandeve) >> Sent: 24 September 2014 11:28 >> To: opsec@ietf.org >> Subject: [OPSEC] Call for WG adoption - Recommendations on Filtering = of IPv6 Packets Containing IPv6 Extension Headers >>=20 >> Dear, >>=20 >> Please find this request for WG adoption for "Recommendations on = Filtering of IPv6 Packets Containing IPv6 Extension Headers" >> The authors of the work explicitly asked for "Call for WG adoption" = in its current state.=20 >>=20 >> Latest draft can be found at: >> http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02=20 >>=20 >> (1) Do you support for adopting the draft as OPSEC WG item? >>=20 >> This call for WG adoption will end 8 October 2014. >>=20 >> Kind Regards, >> OPSEC chairs >>=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_054325FC-0B16-47A4-9A7E-124F45168ACD 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 iD8DBQFUI7yFbjEdbHIsm0MRAqV+AJ9sVU6BrpXI2CcmCxg8I7bFXFt+AgCfT6o4 dJQQGsAP9nGlq3nrzKHgN78= =fo+/ -----END PGP SIGNATURE----- --Apple-Mail=_054325FC-0B16-47A4-9A7E-124F45168ACD-- From nobody Thu Sep 25 01:33:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5E51A02ED for ; Thu, 25 Sep 2014 01:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVqtBSR-eKYJ for ; Thu, 25 Sep 2014 01:33:41 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.138]) by ietfa.amsl.com (Postfix) with ESMTP id AE0781A030F for ; Thu, 25 Sep 2014 01:33:40 -0700 (PDT) Received: from [85.158.136.35:56918] by server-2.bemta-5.messagelabs.com id DB/D0-31832-363D3245; Thu, 25 Sep 2014 08:33:39 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-11.tower-125.messagelabs.com!1411633967!34788933!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19316 invoked from network); 25 Sep 2014 08:32:47 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-11.tower-125.messagelabs.com with SMTP; 25 Sep 2014 08:32:47 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Thu, 25 Sep 2014 09:43:56 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 09:32:28 +0100 From: "Heatley, Nick" To: Tore Anderson , Lorenzo Colitti , "Metschulat, Holger (holger.metschulat@telekom.de)" Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+Lt72jTbGJ9EemkbZAEwE9WpwImE0AgAeEHACAAAKhAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaaoCAAQsxMA== Date: Thu, 25 Sep 2014 08:32:28 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> In-Reply-To: <5422FA4F.3080003@fud.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UmTsPmCs9dy6NgQDCUCiBn8jp8E Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 08:33:43 -0000 There appear to be two schools of thought around the NAT64 in the 464xlat= : 1. run NAT64 as dumb as possible, don't look to use ALGs, prefer double t= ranslations to hide upper layer issues 2. try to achieve parity between NAT64 and NAT44 in terms of ALGs and ses= sion helpers supported, then allow single translations over double transl= ations If you are in the 2nd camp then you will happily allow DNS64, and use CLA= T only for literals. Otherwise you aim to use the CLAT rather than DNS64. Holger gave a scenario behind camp1 thinking - a mixed environment of dua= l stack / IPv6-only devices. However looking deeper, does it further depends if you have public IPv4 o= r private IPv4 for the dual stack. If you are in camp 1, absence of DNS64, and you use public IPv4 you may a= void NAT altogether on the IPv4 dual stack path (otherwise synthesised IP= v6 destinations will take pref over IPv4). (=3D> enough public IPv4 for dual stack cellular devices, lucky you!) If you accept that your dual stack devices will be using private IPv4 the= n it really is down to whether the NAT64 path from DNS64 can match NAT44 = IMHO. (i.e. has your NAT64 vendor written those ALGs yet...) BTW here is some background on FTP over 464xlat that Ross and I debated: https://code.google.com/p/android/issues/detail?id=3D71835 I am happy with FTP now that we modified the behaviour of our NAT64 firew= all (allow PASV over IPv6 transport).=20 The other aspect in the mix is the existence of pre-RFC2428 FTP servers (= some 50% of internet FTP servers allegedly), which makes FTP quite specia= l and interesting for translation behaviour. I guess I am in camp 2, I believe my NAT64 is as good as my NAT44 (with t= he proviso that testing is ongoing...), and you will never solve complex = or higher layer issues, like active FTP, without resorting to ALGs. Until someone shows why NAT64 cannot equal NAT44 in service experience, I= =20am placing my bets on NAT64 ALGs.=20 I welcome comments on NAT64 security and upper layer protocol concerns he= re, happy to test. BR Nick -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore Anderson Sent: 24 September 2014 18:07 To: Lorenzo Colitti Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org= =20WG Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery * Lorenzo Colitti > But in that case, why wouldn't you use MAP? It provides much better=20 > IPv4 connectivity, it's stateless, it scales better... Maybe you already have boxes already capable of NAT64 lying around, and n= o room on your budgets for new MAP boxes? I don't know...you could say th= e same thing about DS-Lite, but people are deploying that, too. So it wou= ldn't surprise me in the least if someone were to put a CLAT in a CPE, ei= ther. > Not sure I understand what you mean here. Did you mean "the server=20 > won't know what to do with the literal IPv6 address the client asks it = > to connect to"? Looked a bit more into it, and I think FTP was a poor example. It works w= hen the client is on IPv6. It's worse if the client is on IPv4 and access= ing an IPv6 server through SIIT; but it works again with if you use dual = translation so the server thinks it's on IPv4 too. Anyway, I suppose it would be better to ask the Orange Poland guys, they = should know best which specific application problems they ran into with 464XLAT+DNS64 that caused them to forego DNS64. Tore _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW From nobody Thu Sep 25 01:41:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D01A1AD9 for ; Thu, 25 Sep 2014 01:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3Va_FZwpJ-G for ; Thu, 25 Sep 2014 01:41:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F741A1A8A for ; Thu, 25 Sep 2014 01:41:26 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id BE65B2646E4; Thu, 25 Sep 2014 10:41:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 96DBD238080; Thu, 25 Sep 2014 10:41:24 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.39]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 10:41:22 +0200 From: To: "Heatley, Nick" , Tore Anderson , Lorenzo Colitti , "Metschulat, Holger (holger.metschulat@telekom.de)" Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+Lt72jTbGJ9EemkbZAEwE9WpwImE0AgAeEHACAAAKhAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaaoCAAQsxMIAACfAg Date: Thu, 25 Sep 2014 08:41:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330084114@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.24.93919 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_rGKKnncKcVKflkSJu-XpDca5Yc Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 08:41:28 -0000 Hi Nick, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Heatley, Nick >Envoy=E9=A0: jeudi 25 septembre 2014 10:32 >=C0=A0: Tore Anderson; Lorenzo Colitti; Metschulat, Holger >(holger.metschulat@telekom.de) >Cc=A0: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.o= rg >WG >Objet=A0: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery > >Until someone shows why NAT64 cannot equal NAT44 in service experience, I >am placing my bets on NAT64 ALGs. [Med] Seems like you would agree with the conclusions in http://tools.ietf.= org/html/rfc6889=20 From nobody Thu Sep 25 02:36:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBCC1A1B91 for ; Thu, 25 Sep 2014 02:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jTPtBBHrogJ for ; Thu, 25 Sep 2014 02:36:33 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 83C581A1A8A for ; Thu, 25 Sep 2014 02:36:33 -0700 (PDT) Received: from [85.158.139.3:64602] by server-1.bemta-5.messagelabs.com id 4C/40-17892-022E3245; Thu, 25 Sep 2014 09:36:32 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-16.tower-90.messagelabs.com!1411637749!38761567!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26032 invoked from network); 25 Sep 2014 09:35:49 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-16.tower-90.messagelabs.com with SMTP; 25 Sep 2014 09:35:49 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Thu, 25 Sep 2014 10:47:04 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 10:35:37 +0100 From: "Heatley, Nick" To: "mohamed.boucadair@orange.com" , "Tore Anderson" , Lorenzo Colitti , "Metschulat, Holger (holger.metschulat@telekom.de)" Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+Lt72jTbGJ9EemkbZAEwE9WpwImE0AgAeEHACAAAKhAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaaoCAAQsxMIAACfAggAAN+HA= Date: Thu, 25 Sep 2014 09:35:36 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303BBB03A@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B9330084114@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330084114@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JYPoPXdbCYKshoDtrrAp_e1jjx8 Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 09:36:35 -0000 I didn't even know that doc existed :-) I always thought that something was missing! Thanks for the steer! -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: 25 September 2014 09:41 To: Heatley, Nick; Tore Anderson; Lorenzo Colitti; Metschulat, Holger (ho= lger.metschulat@telekom.de) Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org= =20WG Subject: RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Hi Nick, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Heatley, Nick= =20 >Envoy=E9=A0: jeudi 25 septembre 2014 10:32 =C0=A0: Tore Anderson; Lorenz= o=20 >Colitti; Metschulat, Holger >(holger.metschulat@telekom.de) >Cc=A0: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org;=20 >v6ops@ietf.org WG Objet=A0: Re: [v6ops] new draft:=20 >draft-wang-v6ops-xlat-prefix-discovery > >Until someone shows why NAT64 cannot equal NAT44 in service experience, = >I am placing my bets on NAT64 ALGs. [Med] Seems like you would agree with the conclusions in http://tools.iet= f.org/html/rfc6889=20 NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW From nobody Thu Sep 25 02:40:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F91A6F02 for ; Thu, 25 Sep 2014 02:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbsM_No3IaLI for ; Thu, 25 Sep 2014 02:40:32 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D891A03A8 for ; Thu, 25 Sep 2014 02:40:31 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP; 25 Sep 2014 11:40:10 +0200 X-IronPort-AV: E=Sophos;i="5.04,595,1406584800"; d="scan'208,217";a="140932839" Received: from he111493.emea1.cds.t-internal.com ([10.206.92.96]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 25 Sep 2014 11:40:09 +0200 Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE111493.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 25 Sep 2014 11:40:09 +0200 From: To: , Date: Thu, 25 Sep 2014 11:40:09 +0200 Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: Ac/YDOxuXMJTCsJ7TYS8ik/PnP8fKQAlfwvA Message-ID: <88CAA5385EB5404392BF93106C8C53F892498C6E93@HE111507.emea1.cds.t-internal.com> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_88CAA5385EB5404392BF93106C8C53F892498C6E93HE111507emea1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Miz3OD4W7BeFqtqtk4GsICrUzds Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 09:40:35 -0000 --_000_88CAA5385EB5404392BF93106C8C53F892498C6E93HE111507emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Vm9uOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9u IExvcmVuem8gQ29saXR0aQ0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAyNC4gU2VwdGVtYmVyIDIwMTQg MTc6MzMNCkFuOiBUb3JlIEFuZGVyc29uDQpDYzogZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZp eC1kaXNjb3ZlcnlAdG9vbHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnIFdHDQpCZXRyZWZmOiBS ZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292 ZXJ5DQoNCj4gTm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gaGVyZS4gRGlkIHlv dSBtZWFuICJ0aGUgc2VydmVyIHdvbid0IGtub3cgd2hhdCB0byBkbyB3aXRoIHRoZSBsaXRlcmFs IElQdjYgYWRkcmVzcyB0aGUgY2xpZW50IGFza3MNCj4gaXQgdG8gY29ubmVjdCB0byI/DQoNCk5v LCBUb3JlIG1lYW50IHRoZSBJUHY0IGFkZHJlc3MgdGhhdCB0aGUgRlRQIHNlcnZlciB3aWxsIHJl dHVybiBhZnRlciB0aGUgY2xpZW50IGlzc3VlZCB0aGUgUEFTViBjb21tYW5kLiBIb3dldmVyLCBh biBJUHY2IGNsaWVudCB3aWxsIG5ldmVyIHVzZSB0aGUgUEFTViBjb21tYW5kLg0KDQpJbiBwYXNz aXZlIEZUUCB3aXRoIElQdjYsIHRoZSBJUHY2IGNsaWVudCB3aWxsIG5vdCB1c2UgdGhlIFBBU1Yg Y29tbWFuZCwgYnV0IHRoZSBFUFNWIGNvbW1hbmQuIFRoaXMgd2lsbCBub3QgcmV0dXJuIHRoZSBh ZGRyZXNzIG9mIHRoZSBzZXJ2ZXIsIGJ1dCBqdXN0IHRoZSBwb3J0IG51bWJlciAoc2VlIFJGQzI0 MjggYW5kIFJGQzYzODQpOg0KDQokIGxmdHAgLWQgZnRwLm1hdGhlbWF0aWsudHUtZGFybXN0YWR0 LmRlPGZ0cDovL2Z0cC5tYXRoZW1hdGlrLnR1LWRhcm1zdGFkdC5kZT4gIyA8LS0gdGhpcyBpcyBh biBJUHY0LW9ubHkgRlRQIHNlcnZlcg0KbGZ0cCBmdHAubWF0aGVtYXRpay50dS1kYXJtc3RhZHQu ZGU6fj4gbHMNCi0tLS0gQ29ubmVjdGluZyB0byBmdHAubWF0aGVtYXRpay50dS1kYXJtc3RhZHQu ZGUgKDY0OmZmOWI6OjgyNTM6MjFhKSBwb3J0IDIxDQpgbHMnIGF0IDAgW0Nvbm5lY3RpbmcuLi5d DQo8LS0tIDIyMCBQcm9GVFBEIDEuMy4zYSBTZXJ2ZXIgKGZ0cC5tYXRoZW1hdGlrLnR1LWRhcm1z dGFkdC5kZSkgWzEzMC44My4yLjI2XQ0KLi4uDQotLS0+IEVQU1YNCjwtLS0gMjI5IEVudGVyaW5n IEV4dGVuZGVkIFBhc3NpdmUgTW9kZSAofHx8Mzk5MDB8KQ0KLS0tLSBDb25uZWN0aW5nIGRhdGEg c29ja2V0IHRvICg2NDpmZjliOjo4MjUzOjIxYSkgcG9ydCAzOTkwMA0KLS0tLSBEYXRhIGNvbm5l Y3Rpb24gZXN0YWJsaXNoZWQNCi4uLg0KDQpTbyB0aGUgRlRQIEFMRyBvbiB0aGUgTkFUNjQgYm94 IHdpbGwgaGF2ZSB0byB0cmFuc2xhdGUgZnJvbSBFUFNWIHRvIFBBU1YgdmljZSB2ZXJzYSBpZiB0 aGUgSVB2NC1vbmx5IEZUUCBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgRVBTViBjb21t YW5kIG5hdGl2ZWx5Lg0KDQpIb2xnZXINCg0K --_000_88CAA5385EB5404392BF93106C8C53F892498C6E93HE111507emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYzODkyMTkwOTsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTgzNjk4NjUzMCAxMDc3MzQwOTM0IDY3NTY3NjE5 IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3 NTY3NjIxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t PjwvaGVhZD48Ym9keSBsYW5nPURFIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHY2b3BzIFttYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZ10gPGI+SW0gQXVmdHJhZyB2b24gPC9iPkxvcmVuem8gQ29saXR0aTxicj48 Yj5HZXNlbmRldDo8L2I+IE1pdHR3b2NoLCAyNC4gU2VwdGVtYmVyIDIwMTQgMTc6MzM8YnI+PGI+ QW46PC9iPiBUb3JlIEFuZGVyc29uPGJyPjxiPkNjOjwvYj4gZHJhZnQtd2FuZy12Nm9wcy14bGF0 LXByZWZpeC1kaXNjb3ZlcnlAdG9vbHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnIFdHPGJyPjxi PkJldHJlZmY6PC9iPiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXdhbmctdjZvcHMteGxh dC1wcmVmaXgtZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7IDwv c3Bhbj48c3BhbiBsYW5nPUVOLUdCPk5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFu IGhlcmUuIERpZCB5b3UgbWVhbiAmcXVvdDt0aGUgc2VydmVyIHdvbid0IGtub3cgd2hhdCB0byBk byB3aXRoIHRoZSBsaXRlcmFsIElQdjYgYWRkcmVzcyB0aGUgY2xpZW50IGFza3M8c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OyA8L3Nw YW4+PHNwYW4gbGFuZz1FTi1HQj5pdCB0byBjb25uZWN0IHRvJnF1b3Q7PzxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Tm8sIFRvcmUgbWVhbnQgdGhlIElQdjQgYWRkcmVzcyB0aGF0IHRoZSBGVFAgc2VydmVy IHdpbGwgcmV0dXJuIGFmdGVyIHRoZSBjbGllbnQgaXNzdWVkIHRoZSBQQVNWIGNvbW1hbmQuIEhv d2V2ZXIsIGFuIElQdjYgY2xpZW50IHdpbGwgbmV2ZXIgdXNlIHRoZSBQQVNWIGNvbW1hbmQuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW4gcGFzc2l2ZSBGVFAgd2l0 aCBJUHY2LCB0aGUgSVB2NiBjbGllbnQgd2lsbCBub3QgdXNlIHRoZSBQQVNWIGNvbW1hbmQsIGJ1 dCB0aGUgRVBTViBjb21tYW5kLiBUaGlzIHdpbGwgbm90IHJldHVybiB0aGUgYWRkcmVzcyBvZiB0 aGUgc2VydmVyLCBidXQganVzdCB0aGUgcG9ydCBudW1iZXIgKHNlZSBSRkMyNDI4IGFuZCBSRkM2 Mzg0KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4kIGxmdHAgLWQg PGEgaHJlZj0iZnRwOi8vZnRwLm1hdGhlbWF0aWsudHUtZGFybXN0YWR0LmRlIj5mdHAubWF0aGVt YXRpay50dS1kYXJtc3RhZHQuZGU8L2E+ICMgPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPsOf PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4gdGhpcyBpcyBhbiBJUHY0 LW9ubHkgRlRQIHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPmxmdHAgZnRwLm1hdGhlbWF0aWsudHUt ZGFybXN0YWR0LmRlOn4mZ3Q7IGxzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS0tLSBDb25uZWN0aW5nIHRvIGZ0cC5t YXRoZW1hdGlrLnR1LWRhcm1zdGFkdC5kZSAoNjQ6ZmY5Yjo6ODI1MzoyMWEpIHBvcnQgMjE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5gbHMnIGF0IDAgW0Nvbm5lY3RpbmcuLi5dPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jmx0Oy0tLSAyMjAgUHJvRlRQRCAxLjMuM2EgU2VydmVyIChmdHAubWF0aGVtYXRpay50dS1kYXJt c3RhZHQuZGUpIFsxMzAuODMuMi4yNl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4uLi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4tLS0mZ3Q7IEVQU1Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbHQ7LS0tIDIyOSBFbnRlcmluZyBF eHRlbmRlZCBQYXNzaXZlIE1vZGUgKHx8fDM5OTAwfCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLS0tIENv bm5lY3RpbmcgZGF0YSBzb2NrZXQgdG8gKDY0OmZmOWI6OjgyNTM6MjFhKSBwb3J0IDM5OTAwPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+LS0tLSBEYXRhIGNvbm5lY3Rpb24gZXN0YWJsaXNoZWTCoMKgwqDCoMKg wqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+Li4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+U28gdGhlIEZUUCBBTEcgb24gdGhlIE5BVDY0IGJveCB3aWxsIGhhdmUgdG8gdHJh bnNsYXRlIGZyb20gRVBTViB0byBQQVNWIHZpY2UgdmVyc2EgaWYgdGhlIElQdjQtb25seSBGVFAg c2VydmVyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIEVQU1YgY29tbWFuZCBuYXRpdmVseS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib2xnZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_88CAA5385EB5404392BF93106C8C53F892498C6E93HE111507emea1_-- From nobody Thu Sep 25 04:00:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339AD1A02EA for ; Thu, 25 Sep 2014 04:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z7EGGzgnugK for ; Thu, 25 Sep 2014 04:00:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F82E1A6F6F for ; Thu, 25 Sep 2014 04:00:25 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 800501B869C; Thu, 25 Sep 2014 13:00:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 5160FC8069; Thu, 25 Sep 2014 13:00:23 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.39]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 13:00:23 +0200 From: To: "Heatley, Nick" , Tore Anderson , Lorenzo Colitti , "Metschulat, Holger (holger.metschulat@telekom.de)" Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+Lt72jTbGJ9EemkbZAEwE9WpwImE0AgAeEHACAAAKhAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaaoCAAQsxMIAACfAggAAN+HCAABjEgA== Date: Thu, 25 Sep 2014 11:00:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330084354@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B9330084114@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303BBB03A@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303BBB03A@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.25.74221 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EtSAo1pa8eRf1SQ2zCBZ_Mqaddg Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 11:00:28 -0000 Re-, Now you are ;-) Another document that I recommend to read is: Issues with IP Address Sharin= g (http://tools.ietf.org/html/rfc6269). This one discusses issues common to= all address sharing scheme including NAT44, NAT64, DS-Lite, MAP-*, etc. Cheers, Med >-----Message d'origine----- >De=A0: Heatley, Nick [mailto:nick.heatley@ee.co.uk] >Envoy=E9=A0: jeudi 25 septembre 2014 11:36 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Tore Anderson; Lorenzo Colitti; Metschu= lat, >Holger (holger.metschulat@telekom.de) >Cc=A0: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.o= rg >WG >Objet=A0: RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery > >I didn't even know that doc existed :-) >I always thought that something was missing! >Thanks for the steer! > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: 25 September 2014 09:41 >To: Heatley, Nick; Tore Anderson; Lorenzo Colitti; Metschulat, Holger >(holger.metschulat@telekom.de) >Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org >WG >Subject: RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery > >Hi Nick, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Heatley, Nick >>Envoy=E9=A0: jeudi 25 septembre 2014 10:32 =C0=A0: Tore Anderson; Lorenzo >>Colitti; Metschulat, Holger >>(holger.metschulat@telekom.de) >>Cc=A0: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; >>v6ops@ietf.org WG Objet=A0: Re: [v6ops] new draft: >>draft-wang-v6ops-xlat-prefix-discovery >> >>Until someone shows why NAT64 cannot equal NAT44 in service experience, >>I am placing my bets on NAT64 ALGs. > >[Med] Seems like you would agree with the conclusions in >http://tools.ietf.org/html/rfc6889 From nobody Thu Sep 25 07:33:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3A21A7004; Thu, 25 Sep 2014 07:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt7-zQ5CR6l0; Thu, 25 Sep 2014 07:33:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589891A7003; Thu, 25 Sep 2014 07:33:37 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8PEWHLU013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 07:32:27 -0700 (PDT) Message-ID: <54242773.9040005@isi.edu> Date: Thu, 25 Sep 2014 07:32:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> In-Reply-To: <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IAeRwlUDp7sDDUg9i1RD9V2-9_U Cc: "'opsec@ietf.org'" , "v6ops@ietf.org" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 14:33:39 -0000 Hi, all, On 9/24/2014 11:56 PM, Fred Baker (fred) wrote: > For the record, Opsec is considering adopting the draft, not v6ops; I'm including both groups in this response. > Gunter asked v6ops to chime in on the discussion in opsec. The author > has been asking both sets of chairs, and I haven’t seen the > groundswell of support, or even comment, that would lead in the > direction of v6ops adoption. When a doc is "shopped around", that tells me it's not ready for anything. The ADs should determine where a doc belongs and should alert related WGs at that time - and during WGLC. > I personally share your concerns; if we > want to deprecate parts of RFC 2460, I think we need to do that in > 6man. I disagree. This is a significant change to the IPv6 spec; the 6man charter excludes those: --- The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications.... > What v6ops or opsec would be chartered to do is give advice. Agreed. IMO, advice should be limited to explaining cases that fall under MAY or SHOULD in other documents. Anything that overrides a MUST or MUST NOT needs to happen in the WG chartered to update the original doc; AFAICT, that's only INTAREA in this case (if not, it's certainly not *OPS or *MAN). Joe From nobody Thu Sep 25 07:59:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A901A0172 for ; Thu, 25 Sep 2014 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqktNc3bClfg for ; Thu, 25 Sep 2014 07:59:10 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4FD1A0123 for ; Thu, 25 Sep 2014 07:59:10 -0700 (PDT) Received: from [186.137.80.27] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XXAVb-0002dt-JC; Thu, 25 Sep 2014 16:59:03 +0200 Message-ID: <54242DAA.8000404@si6networks.com> Date: Thu, 25 Sep 2014 11:58:50 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "Fred Baker (fred)" , Joe Touch References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> In-Reply-To: <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/t1BrSF0LQonXkR3RuTUwyYnjKME Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 14:59:12 -0000 Fred, On 09/25/2014 03:56 AM, Fred Baker (fred) wrote: > For the record, Opsec is considering adopting the draft, not v6ops; > Gunter asked v6ops to chime in on the discussion in opsec. The author > has been asking both sets of chairs, That's not correct. You've been mixing up three related -- but different -- I-Ds. The I-D opsec is being polled about has never been discussed outside of opsec, and we have never asked anyone else other than the opsec chairs to poll the wg they chair for adoption. The I-D we did ask you to poll v6ops about was draft-gont-v6ops-ipv6-ehs-in-real-world which, while kind of related, is certainly not the I-D opsec is being polled about. > and I haven’t seen the > groundswell of support, or even comment, that would lead in the > direction of v6ops adoption. As noted, we did not even announce it here, as far as I can recall. > I personally share your concerns; if we > want to deprecate parts of RFC 2460, I think we need to do that in > 6man. What v6ops or opsec would be chartered to do is give advice. > Personally, deprecating the use of extension headers, whether in fact > or in effect, seems like a very bad idea. Pointing out issues with > them has value. May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate anything? It's actually the other way around. It tries to get IPv6 EHs passed along. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 25 08:39:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338221A7022; Thu, 25 Sep 2014 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN89EBFtrWYE; Thu, 25 Sep 2014 08:39:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D2A1A010C; Thu, 25 Sep 2014 08:39:44 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s8PFcnLP024876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 08:39:03 -0700 (PDT) Message-ID: <5424370B.8080900@isi.edu> Date: Thu, 25 Sep 2014 08:38:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> In-Reply-To: <54242DAA.8000404@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iOpEDFMSOhu_pZYg00HR2qZI2WQ Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 15:39:45 -0000 On 9/25/2014 7:58 AM, Fernando Gont wrote: ... > May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate > anything? In every statement where an existing IPv6 required capability is changed. E.g.: - demotes requirements to "SHOULDS" (most x.x.x.5 sections). - deprecates the flags in HBH options intended to declare how an option is handled when not known by providing advice specific to each option type that does not consider the flag setting Joe From nobody Thu Sep 25 08:46:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139BF1A7006; Thu, 25 Sep 2014 08:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS0PXezegrAP; Thu, 25 Sep 2014 08:45:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1D11A0174; Thu, 25 Sep 2014 08:45:59 -0700 (PDT) Received: from [186.137.80.27] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XXBEv-000320-MX; Thu, 25 Sep 2014 17:45:53 +0200 Message-ID: <542438A8.60801@si6networks.com> Date: Thu, 25 Sep 2014 12:45:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242773.9040005@isi.edu> In-Reply-To: <54242773.9040005@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/L_MEXnWFdQsvQHDCm_x2gQ-J1Rs Cc: "'opsec@ietf.org'" , "v6ops@ietf.org" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 15:46:02 -0000 On 09/25/2014 11:32 AM, Joe Touch wrote: > On 9/24/2014 11:56 PM, Fred Baker (fred) wrote: >> For the record, Opsec is considering adopting the draft, not v6ops; > > I'm including both groups in this response. > >> Gunter asked v6ops to chime in on the discussion in opsec. The author >> has been asking both sets of chairs, and I haven’t seen the >> groundswell of support, or even comment, that would lead in the >> direction of v6ops adoption. > > When a doc is "shopped around", that tells me it's not ready for > anything. The ADs should determine where a doc belongs and should alert > related WGs at that time - and during WGLC. The document has never been "shopped around". Please see my response to Fred. >> What v6ops or opsec would be chartered to do is give advice. > > Agreed. IMO, advice should be limited to explaining cases that fall > under MAY or SHOULD in other documents. > > Anything that overrides a MUST or MUST NOT needs to happen in the WG > chartered to update the original doc; AFAICT, that's only INTAREA in > this case (if not, it's certainly not *OPS or *MAN). Could you please point out which part of this I-D overrides a MUST or SHOULD? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 25 08:53:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA311A8033; Thu, 25 Sep 2014 08:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC_cwdGF9Khy; Thu, 25 Sep 2014 08:52:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EEB1A802D; Thu, 25 Sep 2014 08:52:55 -0700 (PDT) Received: from [186.137.80.27] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XXBLf-000348-54; Thu, 25 Sep 2014 17:52:51 +0200 Message-ID: <54243A4B.9010704@si6networks.com> Date: Thu, 25 Sep 2014 12:52:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> In-Reply-To: <5424370B.8080900@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WEqJajueLtepLdm0kwUyHtaM7x0 Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 15:52:57 -0000 On 09/25/2014 12:38 PM, Joe Touch wrote: > On 9/25/2014 7:58 AM, Fernando Gont wrote: > ... >> May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate >> anything? > > In every statement where an existing IPv6 required capability is changed. > > E.g.: > - demotes requirements to "SHOULDS" (most x.x.x.5 sections). They are lowercase shoulds. And not protocol changes, but operational advice. > - deprecates the flags in HBH options intended to declare how an option > is handled when not known by providing advice specific to each option > type that does not consider the flag setting The advice in this I-D essentially mimics RFC7045 for options. That was the intent. Am I missing something? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 25 09:13:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D5E1A0174; Thu, 25 Sep 2014 09:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 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.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SreNxZY2wGLL; Thu, 25 Sep 2014 09:13:31 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D711A00CF; Thu, 25 Sep 2014 09:13:31 -0700 (PDT) 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 s8PGDDTl018905; Thu, 25 Sep 2014 17:13:13 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s8PGDDTl018905 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1411661594; bh=FEx6rIWAov1cZxOVmqa+Tq4hh3s=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=z6XYsnKueO9f+kp4FG7YFmzUe2FJsSmL46xjh1ZjafhNegrdcpPLYsgbC60UkBuzJ IsiMfG+xuX41K/U3m8Va/vAylaznPSSwI4VGa0jbNwU/lrFNEA6Ws91jEBEN4k13f0 q5V4iLmS6XzntThxlIZyUUfbkN5erOOaT49QE54s= 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 q8OHDD0935009884b2 ret-id none; Thu, 25 Sep 2014 17:13:14 +0100 Received: from [IPv6:2001:630:d0:ed04:4dbb:aa55:d289:997b] ([IPv6:2001:630:d0:ed04:4dbb:aa55:d289:997b]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s8PGDBlB002853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Sep 2014 17:13:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <54243A4B.9010704@si6networks.com> Date: Thu, 25 Sep 2014 17:13:10 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <285EA688-C29C-475F-9CA0-D0BAB1678A2F@ecs.soton.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q8OHDD093500988400; tid=q8OHDD0935009884b2; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s8PGDDTl018905 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dzCcnpFSwKJFhlZkbBQwMsJZJVg Cc: "v6ops@ietf.org" , "opsec@ietf.org" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 16:13:33 -0000 On 25 Sep 2014, at 16:52, Fernando Gont wrote: > On 09/25/2014 12:38 PM, Joe Touch wrote: >>=20 >>=20 >> In every statement where an existing IPv6 required capability is = changed. >>=20 >> E.g.: >> - demotes requirements to "SHOULDS" (most x.x.x.5 sections). >=20 > They are lowercase shoulds. And not protocol changes, but operational > advice. >=20 >> - deprecates the flags in HBH options intended to declare how an = option >> is handled when not known by providing advice specific to each option >> type that does not consider the flag setting >=20 > The advice in this I-D essentially mimics RFC7045 for options. That = was > the intent. Am I missing something? Hi, I would say that putting forward operational recommendations in a style = similar to RFC4890, which does not use RFC2119 language, is both = appropriate and useful. I agree that were there specific protocol changes then of course these = should be run through 6man (most likely) to update existing RFCs. There are many drafts that fall between v6ops and opsec, where the scope = is IPv6 operational security practices. Tim= From nobody Thu Sep 25 09:40:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC59C1A870C; Thu, 25 Sep 2014 09:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egp2VRayAcN1; Thu, 25 Sep 2014 09:40:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B4A1A8708; Thu, 25 Sep 2014 09:40:35 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s8PGdqVA016992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 09:40:02 -0700 (PDT) Message-ID: <5424455A.7040501@isi.edu> Date: Thu, 25 Sep 2014 09:39:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> In-Reply-To: <54243A4B.9010704@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rRzkZODm2TBP0q0k1m6WBYn5Tbo Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 16:40:36 -0000 On 9/25/2014 8:52 AM, Fernando Gont wrote: > On 09/25/2014 12:38 PM, Joe Touch wrote: >> On 9/25/2014 7:58 AM, Fernando Gont wrote: >> ... >>> May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate >>> anything? >> >> In every statement where an existing IPv6 required capability is changed. >> >> E.g.: >> - demotes requirements to "SHOULDS" (most x.x.x.5 sections). > > They are lowercase shoulds. And not protocol changes, but operational > advice. I see no utility to a BCP that makes operational recommendations without qualifying them in RFC2119 language. Further, this doc does not explicitly indicate the distinction between upper and lowercase of the RFC2119 terms. IMO, except for use in discussion prose, those terms need to be avoided at all cost except where used in their RFC2119 sense. >> - deprecates the flags in HBH options intended to declare how an option >> is handled when not known by providing advice specific to each option >> type that does not consider the flag setting > > The advice in this I-D essentially mimics RFC7045 for options. That was > the intent. Am I missing something? The places where you provide contradictory advice, notably (from 7045): RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers. However, intermediate forwarding nodes SHOULD NOT do this, since that might cause them to inadvertently discard traffic using a recently standardised extension header not yet recognised by the intermediate node. The exceptions to this rule are discussed next. Joe From nobody Thu Sep 25 11:58:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E861A0315; Thu, 25 Sep 2014 11:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGwGJ6d3yVQg; Thu, 25 Sep 2014 11:58:25 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13781A02D6; Thu, 25 Sep 2014 11:58:24 -0700 (PDT) Received: from [186.137.80.27] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XXEF8-0003sk-DQ; Thu, 25 Sep 2014 20:58:18 +0200 Message-ID: <542465BB.7050404@si6networks.com> Date: Thu, 25 Sep 2014 15:58:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> In-Reply-To: <5424455A.7040501@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z_ouPowzzCfGWVW3QJx3mW4sxZs Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 18:58:27 -0000 On 09/25/2014 01:39 PM, Joe Touch wrote: >>> In every statement where an existing IPv6 required capability is changed. >>> >>> E.g.: >>> - demotes requirements to "SHOULDS" (most x.x.x.5 sections). >> >> They are lowercase shoulds. And not protocol changes, but operational >> advice. > > I see no utility to a BCP that makes operational recommendations without > qualifying them in RFC2119 language. Yes, the document track should be changed to Informational, as suggested by Brian. > Further, this doc does not explicitly indicate the distinction between > upper and lowercase of the RFC2119 terms. It's the uppercase that are special, not the lowercase. There's a single bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. >>> - deprecates the flags in HBH options intended to declare how an option >>> is handled when not known by providing advice specific to each option >>> type that does not consider the flag setting >> >> The advice in this I-D essentially mimics RFC7045 for options. That was >> the intent. Am I missing something? > > The places where you provide contradictory advice, notably (from 7045): > > RFC 2460 requires destination hosts to discard packets containing > unrecognised extension headers. However, intermediate forwarding > nodes SHOULD NOT do this, since that might cause them to > inadvertently discard traffic using a recently standardised extension > header not yet recognised by the intermediate node. The exceptions > to this rule are discussed next. Looks like you've decided to ignore the next paragraph, which says: If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. This means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers. and also ignore the Security Considerations, which says: These changes do not affect a firewall's ability to filter out traffic containing unwanted or suspect extension headers, if configured to do so. However, the changes do require firewalls to be capable of permitting any or all extension headers, if configured to do so. The default configurations are intended to allow normal use of any standard extension header, avoiding the connectivity issues described in Sections 1 and 2.1. draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* a default policy or the like (and this is pretty clear in the Intro). So it doesn't go against RFC7045. For instance, that was the main/sole goal of the latest rev of the I-D Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 25 13:24:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D6E1A0350; Thu, 25 Sep 2014 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFthsqOhqc-Q; Thu, 25 Sep 2014 13:24:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023E81A0337; Thu, 25 Sep 2014 13:24:49 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8PKOBh8026649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 13:24:11 -0700 (PDT) Message-ID: <542479EB.1010406@isi.edu> Date: Thu, 25 Sep 2014 13:24:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> In-Reply-To: <542465BB.7050404@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QUSeZRa7cmpGUx5UdkhSBp6ZtiE Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 20:24:51 -0000 On 9/25/2014 11:58 AM, Fernando Gont wrote: > On 09/25/2014 01:39 PM, Joe Touch wrote: ... >> Further, this doc does not explicitly indicate the distinction between >> upper and lowercase of the RFC2119 terms. > > It's the uppercase that are special, not the lowercase. There's a single > bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. The doc needs to remove the definition of 2119 language, and IMO also needs to add a statement that no use of those terms is intended in the 2119 sense. When both are used (both 2119-sense and not), I use the following text to make the distinction explicit: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. >>>> - deprecates the flags in HBH options intended to declare how an option >>>> is handled when not known by providing advice specific to each option >>>> type that does not consider the flag setting >>> >>> The advice in this I-D essentially mimics RFC7045 for options. That was >>> the intent. Am I missing something? >> >> The places where you provide contradictory advice, notably (from 7045): >> >> RFC 2460 requires destination hosts to discard packets containing >> unrecognised extension headers. However, intermediate forwarding >> nodes SHOULD NOT do this, since that might cause them to >> inadvertently discard traffic using a recently standardised extension >> header not yet recognised by the intermediate node. The exceptions >> to this rule are discussed next. > > Looks like you've decided to ignore the next paragraph, which says: > > If a forwarding node discards a packet containing a standard IPv6 > extension header, it MUST be the result of a configurable policy and > not just the result of a failure to recognise such a header. This > means that the discard policy for each standard type of extension > header MUST be individually configurable. The default configuration > SHOULD allow all standard extension headers. The term "standard" in that paragraph refers to a specific set of extensions defined in RFC2460 - i.e., those that are deemed mandatory to support. Your doc refers to other extensions that were not defined in RFC2460, and for which that paragraph does not apply. > and also ignore the Security Considerations, which says: > > These changes do not affect a firewall's ability to filter out > traffic containing unwanted or suspect extension headers, if > configured to do so. However, the changes do require firewalls to be > capable of permitting any or all extension headers, if configured to > do so. The default configurations are intended to allow normal use > of any standard extension header, avoiding the connectivity issues > described in Sections 1 and 2.1. The recommendations in your document are to have a default that overrides the security considerations in RFC2460. Your doc would have to say something like "when the following attack is noticed,..." or "in the following specific use case...". > draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* > a default policy or the like (and this is pretty clear in the Intro). So > it doesn't go against RFC7045. For instance, that was the main/sole goal > of the latest rev of the I-D Advice that doesn't give a specific context is advice to override a default, IMO. You need a lot more context to explain when and/or where such overrides are relevant. Joe From nobody Thu Sep 25 13:26:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834E41A0350; Thu, 25 Sep 2014 13:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9FppEeAaSLc; Thu, 25 Sep 2014 13:26:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186CA1A01D6; Thu, 25 Sep 2014 13:26:29 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8PKPcBU026789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 13:25:38 -0700 (PDT) Message-ID: <54247A42.4040400@isi.edu> Date: Thu, 25 Sep 2014 13:25:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> <542479EB.1010406@isi.edu> In-Reply-To: <542479EB.1010406@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0cj8KTnR3coaL5-AOCHwoN0azH4 Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 20:26:30 -0000 PS - I have a day job, and this isn't it. If others care about this doc, I encourage them to speak up. In its current form, I don't support its adoption by any WG. Joe On 9/25/2014 1:24 PM, Joe Touch wrote: > > > On 9/25/2014 11:58 AM, Fernando Gont wrote: >> On 09/25/2014 01:39 PM, Joe Touch wrote: > ... >>> Further, this doc does not explicitly indicate the distinction between >>> upper and lowercase of the RFC2119 terms. >> >> It's the uppercase that are special, not the lowercase. There's a single >> bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. > > The doc needs to remove the definition of 2119 language, and IMO also > needs to add a statement that no use of those terms is intended in the > 2119 sense. > > When both are used (both 2119-sense and not), I use the following text > to make the distinction explicit: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC-2119 [RFC2119]. > > In this document, these words will appear with that interpretation > only when in ALL CAPS. Lower case uses of these words are not to be > interpreted as carrying RFC-2119 significance. > >>>>> - deprecates the flags in HBH options intended to declare how an option >>>>> is handled when not known by providing advice specific to each option >>>>> type that does not consider the flag setting >>>> >>>> The advice in this I-D essentially mimics RFC7045 for options. That was >>>> the intent. Am I missing something? >>> >>> The places where you provide contradictory advice, notably (from 7045): >>> >>> RFC 2460 requires destination hosts to discard packets containing >>> unrecognised extension headers. However, intermediate forwarding >>> nodes SHOULD NOT do this, since that might cause them to >>> inadvertently discard traffic using a recently standardised extension >>> header not yet recognised by the intermediate node. The exceptions >>> to this rule are discussed next. >> >> Looks like you've decided to ignore the next paragraph, which says: >> >> If a forwarding node discards a packet containing a standard IPv6 >> extension header, it MUST be the result of a configurable policy and >> not just the result of a failure to recognise such a header. This >> means that the discard policy for each standard type of extension >> header MUST be individually configurable. The default configuration >> SHOULD allow all standard extension headers. > > The term "standard" in that paragraph refers to a specific set of > extensions defined in RFC2460 - i.e., those that are deemed mandatory to > support. > > Your doc refers to other extensions that were not defined in RFC2460, > and for which that paragraph does not apply. > >> and also ignore the Security Considerations, which says: >> >> These changes do not affect a firewall's ability to filter out >> traffic containing unwanted or suspect extension headers, if >> configured to do so. However, the changes do require firewalls to be >> capable of permitting any or all extension headers, if configured to >> do so. The default configurations are intended to allow normal use >> of any standard extension header, avoiding the connectivity issues >> described in Sections 1 and 2.1. > > The recommendations in your document are to have a default that > overrides the security considerations in RFC2460. Your doc would have to > say something like "when the following attack is noticed,..." or "in the > following specific use case...". > >> draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* >> a default policy or the like (and this is pretty clear in the Intro). So >> it doesn't go against RFC7045. For instance, that was the main/sole goal >> of the latest rev of the I-D > > Advice that doesn't give a specific context is advice to override a > default, IMO. You need a lot more context to explain when and/or where > such overrides are relevant. > > Joe > From nobody Thu Sep 25 13:30:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4A41A0365; Thu, 25 Sep 2014 13:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAWmym-9DkIx; Thu, 25 Sep 2014 13:30:39 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3DB1A035B; Thu, 25 Sep 2014 13:30:38 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lf10so11552993pab.8 for ; Thu, 25 Sep 2014 13:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IcMzd9CfzD+QoDE599L+WSH5wrWeVw5wtVHduifKYd8=; b=GBceejyYB39Am54sUkPU0K0lO8YeoZ92mg6Hg4uDpZTuIuWlVYDomV+OISxKV0SS2x jemxM4Y/GLh57F4m9pBRYWJvUxq9SwV6WDbnuIaQ7DfoZjiB5BwNShV9X3948HEIAtAv f/AML6gP1F90b8SUaJfY61L8oU/v6x2kpAh3OyUDoS6nSF4mehUbgYQ/72t6k6U4bLLU QAe65ZXr7FXpvtFNDhcdLC7R52YJQzx3N4D4koggzPdYEk4Mx8HOc6OdDzPKHzv4SYoU LxI8NdUjAXnr0gMW8tG0rzZfgl+ga84XxsziR7k9zU1vKIVvXKx/c77QnmxgNnuyoBAe 4UWQ== X-Received: by 10.68.76.35 with SMTP id h3mr23636665pbw.66.1411677038728; Thu, 25 Sep 2014 13:30:38 -0700 (PDT) Received: from [192.168.178.23] (99.201.69.111.dynamic.snap.net.nz. [111.69.201.99]) by mx.google.com with ESMTPSA id ah7sm2966739pbd.52.2014.09.25.13.30.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 13:30:37 -0700 (PDT) Message-ID: <54247B72.7040700@gmail.com> Date: Fri, 26 Sep 2014 08:30:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> In-Reply-To: <5424455A.7040501@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4SSb9LuaHrRKUbwy3Lru05TIGfg Cc: Fernando Gont , "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 20:30:41 -0000 I've given my views of this draft on the appropriate list, but... On 26/09/2014 04:39, Joe Touch wrote: ... > I see no utility to a BCP that makes operational recommendations without > qualifying them in RFC2119 language. Why? The word "should" is a perfectly clear word in the English language. RFC 2119 qualifies its meaning in a particular way, but there's nothing in the IETF process that requires us to use that qualification. > Further, this doc does not explicitly indicate the distinction between > upper and lowercase of the RFC2119 terms. Huh? It cites RFC 2119 in the prescribed words, which make it clear that "SHOULD" is a qualified version of "should". It's quite common for RFCs to use both. (The only word that can be problematic in that way is "may" - I have take to using "might" to avoid the ambiguity in "may".) > IMO, except for use in > discussion prose, those terms need to be avoided at all cost except > where used in their RFC2119 sense. Why? RFC 2119 is perfectly clear about how it qualifies normal usage. Brian From nobody Thu Sep 25 14:18:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A970E1A19E8; Thu, 25 Sep 2014 14:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpM5zO7Iu1lq; Thu, 25 Sep 2014 14:18:19 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2AB1A19E5; Thu, 25 Sep 2014 14:18:19 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s8PLHpL8012170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 14:17:51 -0700 (PDT) Message-ID: <5424867F.6060201@isi.edu> Date: Thu, 25 Sep 2014 14:17:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Brian E Carpenter References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <54247B72.7040700@gmail.com> In-Reply-To: <54247B72.7040700@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xUP3BWTA0zo9M6Rj_LLuwEN7Bug Cc: Fernando Gont , "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 21:18:20 -0000 On 9/25/2014 1:30 PM, Brian E Carpenter wrote: > I've given my views of this draft on the appropriate list, but... > > On 26/09/2014 04:39, Joe Touch wrote: > ... >> I see no utility to a BCP that makes operational recommendations without >> qualifying them in RFC2119 language. > > Why? The word "should" is a perfectly clear word in the English language. > RFC 2119 qualifies its meaning in a particular way, but there's nothing > in the IETF process that requires us to use that qualification. If this issued as a BCP, there should be recommendations in RFC2119 language. A BCP with no such recommendations doesn't explain current practice sufficiently, IMO. >> Further, this doc does not explicitly indicate the distinction between >> upper and lowercase of the RFC2119 terms. > > Huh? It cites RFC 2119 in the prescribed words, which make it clear > that "SHOULD" is a qualified version of "should". It's quite common for > RFCs to use both. (The only word that can be problematic in that way > is "may" - I have take to using "might" to avoid the ambiguity in > "may".) Once you cite RFC2119, you're saying that the key words used have special meaning. There's nothing in RFC2119 that requires them to be capitalized; the use of capitals is mentioned only in the abstract: These words are often capitalized. Often. Not exclusively. IMO, if you want to mix 2119 and non-2119 it is necessary to be explicit in how to tell the difference. >> IMO, except for use in >> discussion prose, those terms need to be avoided at all cost except >> where used in their RFC2119 sense. > > Why? RFC 2119 is perfectly clear about how it qualifies normal usage. I found only text that defines their use as exclusively having special meaning: This document defines these words as they should be interpreted in IETF documents. Can you point to where you found the doc to say otherwise? Joe From nobody Thu Sep 25 15:56:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4461A0041; Thu, 25 Sep 2014 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 4Rx2Gcy_qJub; Thu, 25 Sep 2014 15:56:30 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306E51A00B9; Thu, 25 Sep 2014 15:56:29 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id y13so11538734pdi.1 for ; Thu, 25 Sep 2014 15:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YQb27irJwK+WFDWj+to3rmgEh0PXGRZoUphi2jA1Y0A=; b=b33vEARn4gAC3QR8Ra+VY07s38w4k1F27N5Ht+Ph5AAXIOLzSDjOJmNXB7z/CU5CFF tOodVHOgRXGRkbWI6LINPjpU907GAEz7f6bTMFr2qTwyDnTR2ubRXbPzXBz47vQ5y0zm 8SL7E6BkuWmTwMmaNaCHa2OAg14a3CBafTXwmceNDJbu6YoRhvgQHcZIq3v4+IwkbheT fGprYLWBFTycuDA6HtONwsliqHobPlj+wXhFi0xbEgmu/BBApF1pS3stFu6z+CqjacpH wuKkqEXoS0VqAvZsM9Jt39g51tM2YAR9tiksIhS2GyVvEpKtRFWidB/V4gniyzUOk1Xw PPyQ== X-Received: by 10.68.183.68 with SMTP id ek4mr24746659pbc.54.1411685789658; Thu, 25 Sep 2014 15:56:29 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id ds14sm3155815pdb.20.2014.09.25.15.56.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 15:56:28 -0700 (PDT) Message-ID: <54249DA2.8050509@gmail.com> Date: Fri, 26 Sep 2014 10:56:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <54247B72.7040700@gmail.com> <5424867F.6060201@isi.edu> In-Reply-To: <5424867F.6060201@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b9R0G6sdss0wr7GJAhik-UgScOc Cc: Fernando Gont , "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Sep 2014 22:56:31 -0000 I agree it would have been better if RFC 2119 had specified upper case letters. Apart from that, I have said all I plan to say on this topic. Brian On 26/09/2014 09:17, Joe Touch wrote: > > On 9/25/2014 1:30 PM, Brian E Carpenter wrote: >> I've given my views of this draft on the appropriate list, but... >> >> On 26/09/2014 04:39, Joe Touch wrote: >> ... >>> I see no utility to a BCP that makes operational recommendations without >>> qualifying them in RFC2119 language. >> Why? The word "should" is a perfectly clear word in the English language. >> RFC 2119 qualifies its meaning in a particular way, but there's nothing >> in the IETF process that requires us to use that qualification. > > If this issued as a BCP, there should be recommendations in RFC2119 > language. A BCP with no such recommendations doesn't explain current > practice sufficiently, IMO. > >>> Further, this doc does not explicitly indicate the distinction between >>> upper and lowercase of the RFC2119 terms. >> Huh? It cites RFC 2119 in the prescribed words, which make it clear >> that "SHOULD" is a qualified version of "should". It's quite common for >> RFCs to use both. (The only word that can be problematic in that way >> is "may" - I have take to using "might" to avoid the ambiguity in >> "may".) > > Once you cite RFC2119, you're saying that the key words used have > special meaning. There's nothing in RFC2119 that requires them to be > capitalized; the use of capitals is mentioned only in the abstract: > > These words are often capitalized. > > Often. Not exclusively. IMO, if you want to mix 2119 and non-2119 it is > necessary to be explicit in how to tell the difference. > >>> IMO, except for use in >>> discussion prose, those terms need to be avoided at all cost except >>> where used in their RFC2119 sense. >> Why? RFC 2119 is perfectly clear about how it qualifies normal usage. > > I found only text that defines their use as exclusively having special > meaning: > > This document defines these words as they should be > interpreted in IETF documents. > > Can you point to where you found the doc to say otherwise? > > Joe > From nobody Fri Sep 26 04:47:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF381A1B3D for ; Fri, 26 Sep 2014 04:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 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.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBgk_A57IGHs for ; Fri, 26 Sep 2014 04:47:04 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178FA1A1B16 for ; Fri, 26 Sep 2014 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=135; q=dns/txt; s=iport; t=1411732024; x=1412941624; h=date:from:message-id:to:subject:cc; bh=Spr5dnxpDPjso+XT+ei3hBDI4ijvvsspkhyFCNCwOos=; b=Gb693AbqIAzrYzDmUOsqtguQ0FhdjVOJ+HPVHO3c4Iw4aGU4zb/Z+/rz HECbQINWLu5q8d79kWQOFG38y/EURRbTjKW3NaLv/8DijIPRKgXuAUkiE n5bvo9hdc0sI/x3uy8rhq5FvR8dL/y7A2wkidcBN/jjJIQdLJI9aq87oZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIJANlQJVStJA2G/2dsb2JhbABggw5TWLlvAZBYh0UJgQkWAXuFAzw0iR4BDcBNGJAeHYQ1BYtPik6Ia5N4hAODFgEBAQ X-IronPort-AV: E=Sophos;i="5.04,604,1406592000"; d="scan'208";a="81520930" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP; 26 Sep 2014 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8QBl2Ag005154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2014 11:47:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s8QBl23o025536; Fri, 26 Sep 2014 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s8QBl1PL025532; Fri, 26 Sep 2014 04:47:01 -0700 Date: Fri, 26 Sep 2014 04:47:01 -0700 From: fred@cisco.com Message-Id: <201409261147.s8QBl1PL025532@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8Yr4CWau0g9asCo8pCMuJrHIhEE Cc: draft-ybai-v6ops-ipv6-for-openstack@tools.ietf.org Subject: [v6ops] new draft: draft-ybai-v6ops-ipv6-for-openstack X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Sep 2014 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ybai-v6ops-ipv6-for-openstack. Please take a look at it and comment. From nobody Fri Sep 26 05:18:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631031A1B5E for ; Fri, 26 Sep 2014 05:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.735 X-Spam-Level: * X-Spam-Status: No, score=1.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3, 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 8seE59TPXPM4 for ; Fri, 26 Sep 2014 05:18:05 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A891A1A61 for ; Fri, 26 Sep 2014 05:18:04 -0700 (PDT) Received: from 10.236.62.137 (EHLO OPE10HT03.tp.gk.corp.tepenet) ([10.236.62.137]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id CDF55313; Fri, 26 Sep 2014 14:17:38 +0200 (CEST) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_1_-_Hurt?= To: "Heatley, Nick" , Tore Anderson , Lorenzo Colitti , "Metschulat, Holger (holger.metschulat@telekom.de)" Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+IfJWdndvPc0W8NTzcZ4VQIJwIh4kAgAeEHQCAAAKgAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaa4CAAQJyAIAB8XFw Date: Fri, 26 Sep 2014 12:17:35 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.9.26.111221:17:8.510, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __URI_NO_PATH, ECARD_KNOWN_DOMAINS, __FRAUD_CONTACT_ADDY_B, __CP_NOT_1, __SUBJ_ALPHA_NEGATE, __LINES_OF_YELLING, SUPERLONG_LINE, __FORWARDED_MSG, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, WEBMAIL_SOURCE, MULTIPLE_RCPTS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0205.54255963.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0205.54255963.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b21e99559804b25f5713c1d1a2f2b032 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Yb46JhKApMAwFLieHhTlVKus8fo Cc: "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , "v6ops@ietf.org WG" , Kossut Tomasz - Hurt Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Sep 2014 12:18:07 -0000 OPL use APN IPv6-only for all services we have, but some mobile operators u= se different APN for tethering. Why ? if we apply the architecture CLAT+PLAT+DNS we can achieve quality of servic= e like in DS, with DNS64 NOT. BR, Mcz -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Heatley, Nick Sent: Thursday, September 25, 2014 10:32 AM To: Tore Anderson; Lorenzo Colitti; Metschulat, Holger (holger.metschulat@t= elekom.de) Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org W= G Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery There appear to be two schools of thought around the NAT64 in the 464xlat: 1. run NAT64 as dumb as possible, don't look to use ALGs, prefer double tra= nslations to hide upper layer issues 2. try to achieve parity between NAT64= and NAT44 in terms of ALGs and session helpers supported, then allow singl= e translations over double translations If you are in the 2nd camp then you will happily allow DNS64, and use CLAT = only for literals. Otherwise you aim to use the CLAT rather than DNS64. Holger gave a scenario behind camp1 thinking - a mixed environment of dual = stack / IPv6-only devices. However looking deeper, does it further depends if you have public IPv4 or = private IPv4 for the dual stack. If you are in camp 1, absence of DNS64, and you use public IPv4 you may avo= id NAT altogether on the IPv4 dual stack path (otherwise synthesised IPv6 d= estinations will take pref over IPv4). (=3D> enough public IPv4 for dual stack cellular devices, lucky you!) If yo= u accept that your dual stack devices will be using private IPv4 then it re= ally is down to whether the NAT64 path from DNS64 can match NAT44 IMHO. (i.= e. has your NAT64 vendor written those ALGs yet...) BTW here is some background on FTP over 464xlat that Ross and I debated: https://code.google.com/p/android/issues/detail?id=3D71835 I am happy with FTP now that we modified the behaviour of our NAT64 firewal= l (allow PASV over IPv6 transport).=20 The other aspect in the mix is the existence of pre-RFC2428 FTP servers (so= me 50% of internet FTP servers allegedly), which makes FTP quite special an= d interesting for translation behaviour. I guess I am in camp 2, I believe my NAT64 is as good as my NAT44 (with the= proviso that testing is ongoing...), and you will never solve complex or h= igher layer issues, like active FTP, without resorting to ALGs. Until someone shows why NAT64 cannot equal NAT44 in service experience, I a= m placing my bets on NAT64 ALGs.=20 I welcome comments on NAT64 security and upper layer protocol concerns here= , happy to test. BR Nick -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore Anderson Sent: 24 September 2014 18:07 To: Lorenzo Colitti Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org W= G Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery * Lorenzo Colitti > But in that case, why wouldn't you use MAP? It provides much better > IPv4 connectivity, it's stateless, it scales better... Maybe you already have boxes already capable of NAT64 lying around, and no = room on your budgets for new MAP boxes? I don't know...you could say the sa= me thing about DS-Lite, but people are deploying that, too. So it wouldn't = surprise me in the least if someone were to put a CLAT in a CPE, either. > Not sure I understand what you mean here. Did you mean "the server=20 > won't know what to do with the literal IPv6 address the client asks it=20 > to connect to"? Looked a bit more into it, and I think FTP was a poor example. It works whe= n the client is on IPv6. It's worse if the client is on IPv4 and accessing = an IPv6 server through SIIT; but it works again with if you use dual transl= ation so the server thinks it's on IPv4 too. Anyway, I suppose it would be better to ask the Orange Poland guys, they sh= ould know best which specific application problems they ran into with 464XLAT+DNS64 that caused them to forego DNS64. Tore _______________________________________________ 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 per= son(s). If you are not the intended recipient, notify the sender immediate= ly, delete this email from your system and do not disclose or use for any p= urpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s 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, Hertfords= hire, AL10 9BW _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 26 07:19:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43C1A88E2; Fri, 26 Sep 2014 07:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRsCCheKOP9k; Fri, 26 Sep 2014 07:19:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D062B1A88E8; Fri, 26 Sep 2014 07:19:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140926141915.13561.66044.idtracker@ietfa.amsl.com> Date: Fri, 26 Sep 2014 07:19:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YqgR-jLROihnUm26VwwZpfaghLw Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-13.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 14:19:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-13.txt Pages : 20 Date : 2014-09-26 Abstract: This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 26 13:25:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539BD1A6F64 for ; Fri, 26 Sep 2014 13:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl50XMN7iE_C for ; Fri, 26 Sep 2014 13:25:21 -0700 (PDT) Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by ietfa.amsl.com (Postfix) with SMTP id 812A41A01D5 for ; Fri, 26 Sep 2014 13:25:20 -0700 (PDT) Received: (qmail 22829 messnum 1759339 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 26 Sep 2014 20:25:17 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail12.svc.cra.dublin.eircom.net (qp 22829) with SMTP; 26 Sep 2014 20:25:17 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id vwRD1o00Z0mJ9Tz01wRG2g; Fri, 26 Sep 2014 21:25:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> Date: Fri, 26 Sep 2014 21:25:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> To: =?utf-8?Q?Czerwonka_Micha=C5=82_1_-_Hurt?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Cjd2fwczpFKCDpRXUfcXC6OAdQ8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Sep 2014 20:25:22 -0000 On 26 Sep 2014, at 13:17, Czerwonka Micha=C5=82 1 - Hurt = wrote: > OPL use APN IPv6-only for all services we have, but some mobile = operators use different APN for tethering. Why ? Cynical hat on. It is a way of claiming an unlimited data plan while = blocking the main way of downloading a lot. Ross From nobody Sat Sep 27 20:47:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FE21A01D0 for ; Sat, 27 Sep 2014 20:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.836 X-Spam-Level: X-Spam-Status: No, score=0.836 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, 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 5GWYQ3CJYy0S for ; Sat, 27 Sep 2014 20:47:47 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22721A0188 for ; Sat, 27 Sep 2014 20:47:46 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id tp5so12858601ieb.13 for ; Sat, 27 Sep 2014 20:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pIfOrp7r4Z8+3ykLIztdofY/vUDecNM6AZDvYwvCUAA=; b=dnwKPoRwrMrQB20zLCOYf7XWAk7NTIEHZaN/WU0rJYh+3wmCZ+9oDUy+k6Kn7xrXKh R/L5TzHURKJyW0omac6/1qqANR8p1nQnCvrXiCsS1REu8SP1u64VtYZMolm0dkP5Zo+3 ftPre053OczfWHKLbO4BEdMDSjPkJ2cala9lo7jSEW+UgEKrMnPENmVf7bOQHJvv9lE8 +psBLcKWkvFqdRkLHc2MbFw+ff8L0JsAh5MHkpnfO5e3/zt7JQc3mlWo1RaRz8M0OKxa mkGsn/yj9uTN2RnmjnH0vnweOe/Y1MbCHOMR+C1QHutNdO3mJxIZK/tRG+JaC9yIGLoc GX6A== 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=pIfOrp7r4Z8+3ykLIztdofY/vUDecNM6AZDvYwvCUAA=; b=LO7QdK7oDS+E5RsPydS4bZKDX/xNd+fjxmPE7iATbCMx47XlxnEL0dpcaufzl+zv4H 9/tizWeCU5aunblHX8f2Ac80qB+gZk1DmVebNh07lPMS3+lZvjOMmh1CcTOxnFGyyUH0 U9pFBlzDpNgIqZ04iDAVTGxqO1pTWoT58JJCcqsmclKHA0NEs50qo0qDn3Lqqz2YFikx Y/ZJ/lMNjhAS4R+h34KsImm+X15nNiNaB5NR2gAMRgjwpEtIwqIOlpmPdJxdC/Wy+r/w sgb+xHQCv++X3Or0THkSKeQluxBkYokR0Uet/xge3j20XAs0FJSZX4V7tG1XYMc/41y5 vqJg== X-Gm-Message-State: ALoCoQmMUKGgmDGXaQbI68HZlnfkSIh6krcE2VLG4rVmyVuvCNmQ5i0kdRHDXGgOCr9uCrVUJqMi X-Received: by 10.50.66.36 with SMTP id c4mr25738092igt.48.1411876065886; Sat, 27 Sep 2014 20:47:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Sat, 27 Sep 2014 20:47:25 -0700 (PDT) In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> From: Lorenzo Colitti Date: Sun, 28 Sep 2014 12:47:25 +0900 Message-ID: To: =?UTF-8?Q?Czerwonka_Micha=C5=82_1_=2D_Hurt?= Content-Type: multipart/alternative; boundary=001a1134cc1e5fed3005041803f1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5PH-TpQvWVFhthWryRq2o8iy4z8 Cc: "v6ops@ietf.org WG" , "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 03:47:50 -0000 --001a1134cc1e5fed3005041803f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you provide examples of what does not work with DNS64? In fact, that would be useful to document in an informational document. On Fri, Sep 26, 2014 at 9:17 PM, Czerwonka Micha=C5=82 1 - Hurt < Michal.Czerwonka1@orange.com> wrote: > OPL use APN IPv6-only for all services we have, but some mobile operators > use different APN for tethering. Why ? > > if we apply the architecture CLAT+PLAT+DNS we can achieve quality of > service like in DS, with DNS64 NOT. > > BR, > Mcz > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Heatley, Nick > Sent: Thursday, September 25, 2014 10:32 AM > To: Tore Anderson; Lorenzo Colitti; Metschulat, Holger ( > holger.metschulat@telekom.de) > Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org > WG > Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery > > There appear to be two schools of thought around the NAT64 in the 464xlat= : > 1. run NAT64 as dumb as possible, don't look to use ALGs, prefer double > translations to hide upper layer issues 2. try to achieve parity between > NAT64 and NAT44 in terms of ALGs and session helpers supported, then allo= w > single translations over double translations > > If you are in the 2nd camp then you will happily allow DNS64, and use CLA= T > only for literals. > Otherwise you aim to use the CLAT rather than DNS64. > > Holger gave a scenario behind camp1 thinking - a mixed environment of dua= l > stack / IPv6-only devices. > However looking deeper, does it further depends if you have public IPv4 o= r > private IPv4 for the dual stack. > If you are in camp 1, absence of DNS64, and you use public IPv4 you may > avoid NAT altogether on the IPv4 dual stack path (otherwise synthesised > IPv6 destinations will take pref over IPv4). > (=3D> enough public IPv4 for dual stack cellular devices, lucky you!) If = you > accept that your dual stack devices will be using private IPv4 then it > really is down to whether the NAT64 path from DNS64 can match NAT44 IMHO. > (i.e. has your NAT64 vendor written those ALGs yet...) > > BTW here is some background on FTP over 464xlat that Ross and I debated: > https://code.google.com/p/android/issues/detail?id=3D71835 > I am happy with FTP now that we modified the behaviour of our NAT64 > firewall (allow PASV over IPv6 transport). > The other aspect in the mix is the existence of pre-RFC2428 FTP servers > (some 50% of internet FTP servers allegedly), which makes FTP quite speci= al > and interesting for translation behaviour. > > I guess I am in camp 2, I believe my NAT64 is as good as my NAT44 (with > the proviso that testing is ongoing...), and you will never solve complex > or higher layer issues, like active FTP, without resorting to ALGs. > Until someone shows why NAT64 cannot equal NAT44 in service experience, I > am placing my bets on NAT64 ALGs. > I welcome comments on NAT64 security and upper layer protocol concerns > here, happy to test. > BR > Nick > > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore Anderson > Sent: 24 September 2014 18:07 > To: Lorenzo Colitti > Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org > WG > Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery > > * Lorenzo Colitti > > > But in that case, why wouldn't you use MAP? It provides much better > > IPv4 connectivity, it's stateless, it scales better... > > Maybe you already have boxes already capable of NAT64 lying around, and n= o > room on your budgets for new MAP boxes? I don't know...you could say the > same thing about DS-Lite, but people are deploying that, too. So it > wouldn't surprise me in the least if someone were to put a CLAT in a CPE, > either. > > > Not sure I understand what you mean here. Did you mean "the server > > won't know what to do with the literal IPv6 address the client asks it > > to connect to"? > > Looked a bit more into it, and I think FTP was a poor example. It works > when the client is on IPv6. It's worse if the client is on IPv4 and > accessing an IPv6 server through SIIT; but it works again with if you use > dual translation so the server thinks it's on IPv4 too. > > Anyway, I suppose it would be better to ask the Orange Poland guys, they > should know best which specific application problems they ran into with > 464XLAT+DNS64 that caused them to forego DNS64. > > Tore > > _______________________________________________ > 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 us= e > 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 attachment= s > are free from any virus, but it remains your responsibility to ensure tha= t > 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 > --001a1134cc1e5fed3005041803f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you provide examples of what does not work with DNS64?=

In fact, that would be useful to document in an informa= tional document.

On Fri, Sep 26, 2014 at 9:17 PM, Czerwonka Micha=C5=82 1 - Hurt = <Michal.Czerwonka1@orange.com> wrote:
OPL use APN IPv6-only for all services we have, but = some mobile operators use different APN for tethering. Why ?

if we apply the architecture CLAT+PLAT+DNS we can achieve quality of servic= e like in DS, with DNS64 NOT.

BR,
Mcz


-----Original Message-----
From: v6ops [mailto:v6ops-bounces= @ietf.org] On Behalf Of Heatley, Nick
Sent: Thursday, September 25, 2014 10:32 AM
To: Tore Anderson; Lorenzo Colitti; Metschulat, Holger (holger.metschulat@telekom.de)
Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

There appear to be two schools of thought around the NAT64 in the 464xlat:<= br> 1. run NAT64 as dumb as possible, don't look to use ALGs, prefer double= translations to hide upper layer issues 2. try to achieve parity between N= AT64 and NAT44 in terms of ALGs and session helpers supported, then allow s= ingle translations over double translations

If you are in the 2nd camp then you will happily allow DNS64, and use CLAT = only for literals.
Otherwise you aim to use the CLAT rather than DNS64.

Holger gave a scenario behind camp1 thinking - a mixed environment of dual = stack / IPv6-only devices.
However looking deeper, does it further depends if you have public IPv4 or = private IPv4 for the dual stack.
If you are in camp 1, absence of DNS64, and you use public IPv4 you may avo= id NAT altogether on the IPv4 dual stack path (otherwise synthesised IPv6 d= estinations will take pref over IPv4).
(=3D> enough public IPv4 for dual stack cellular devices, lucky you!) If= you accept that your dual stack devices will be using private IPv4 then it= really is down to whether the NAT64 path from DNS64 can match NAT44 IMHO. = (i.e. has your NAT64 vendor written those ALGs yet...)

BTW here is some background on FTP over 464xlat that Ross and I debated: https://code.google.com/p/android/issues/detail?id=3D71835
I am happy with FTP now that we modified the behaviour of our NAT64 firewal= l (allow PASV over IPv6 transport).
The other aspect in the mix is the existence of pre-RFC2428 FTP servers (so= me 50% of internet FTP servers allegedly), which makes FTP quite special an= d interesting for translation behaviour.

I guess I am in camp 2, I believe my NAT64 is as good as my NAT44 (with the= proviso that testing is ongoing...), and you will never solve complex or h= igher layer issues, like active FTP, without resorting to ALGs.
Until someone shows why NAT64 cannot equal NAT44 in service experience, I a= m placing my bets on NAT64 ALGs.
I welcome comments on NAT64 security and upper layer protocol concerns here= , happy to test.
BR
Nick



-----Original Message-----
From: v6ops [mailto:v6ops-bounces= @ietf.org] On Behalf Of Tore Anderson
Sent: 24 September 2014 18:07
To: Lorenzo Colitti
Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

* Lorenzo Colitti

> But in that case, why wouldn't you use MAP? It provides much bette= r
> IPv4 connectivity, it's stateless, it scales better...

Maybe you already have boxes already capable of NAT64 lying around, and no = room on your budgets for new MAP boxes? I don't know...you could say th= e same thing about DS-Lite, but people are deploying that, too. So it would= n't surprise me in the least if someone were to put a CLAT in a CPE, ei= ther.

> Not sure I understand what you mean here. Did you mean "the serve= r
> won't know what to do with the literal IPv6 address the client ask= s it
> to connect to"?

Looked a bit more into it, and I think FTP was a poor example. It works whe= n the client is on IPv6. It's worse if the client is on IPv4 and access= ing an IPv6 server through SIIT; but it works again with if you use dual tr= anslation so the server thinks it's on IPv4 too.

Anyway, I suppose it would be better to ask the Orange Poland guys, they sh= ould know best which specific application problems they ran into with
464XLAT+DNS64 that caused them to forego DNS64.

Tore

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named per= son(s).=C2=A0 If you are not the intended recipient, notify the sender imme= diately, 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 legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you.

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

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

--001a1134cc1e5fed3005041803f1-- From nobody Sun Sep 28 05:03:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA281A1A6B; Sun, 28 Sep 2014 05:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzm_j746FYGq; Sun, 28 Sep 2014 05:02:50 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560891A1A52; Sun, 28 Sep 2014 05:02:49 -0700 (PDT) Received: from [201.221.226.50] (helo=[192.168.102.57]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XYDBV-0007ld-HP; Sun, 28 Sep 2014 14:02:39 +0200 Message-ID: <5424A425.7060407@si6networks.com> Date: Thu, 25 Sep 2014 20:24:21 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> <542479EB.1010406@isi.edu> In-Reply-To: <542479EB.1010406@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IswTy3eIZTvPahmIfQDDOXqT1bc Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 12:02:53 -0000 Hi, Joe, On 09/25/2014 05:24 PM, Joe Touch wrote: > On 9/25/2014 11:58 AM, Fernando Gont wrote: >> On 09/25/2014 01:39 PM, Joe Touch wrote: > ... >>> Further, this doc does not explicitly indicate the distinction between >>> upper and lowercase of the RFC2119 terms. >> >> It's the uppercase that are special, not the lowercase. There's a single >> bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. > > The doc needs to remove the definition of 2119 language, and IMO also > needs to add a statement that no use of those terms is intended in the > 2119 sense. [...] FWIW, I have no issues adding such a description if deemed necessary. However, if anything, this is easily fixable, and certainly not a show-stopper. >>> The places where you provide contradictory advice, notably (from 7045): >>> >>> RFC 2460 requires destination hosts to discard packets containing >>> unrecognised extension headers. However, intermediate forwarding >>> nodes SHOULD NOT do this, since that might cause them to >>> inadvertently discard traffic using a recently standardised extension >>> header not yet recognised by the intermediate node. The exceptions >>> to this rule are discussed next. >> >> Looks like you've decided to ignore the next paragraph, which says: >> >> If a forwarding node discards a packet containing a standard IPv6 >> extension header, it MUST be the result of a configurable policy and >> not just the result of a failure to recognise such a header. This >> means that the discard policy for each standard type of extension >> header MUST be individually configurable. The default configuration >> SHOULD allow all standard extension headers. > > The term "standard" in that paragraph refers to a specific set of > extensions defined in RFC2460 - i.e., those that are deemed mandatory to > support. > > Your doc refers to other extensions that were not defined in RFC2460, > and for which that paragraph does not apply. That's not correct. NPlease see Section 1.1 of RFC7045, which says: In this document, "standard" IPv6 extension headers are those specified in detail by IETF Standards Actions [RFC5226]. "Experimental" extension headers include those defined by any Experimental RFC and the header values 253 and 254 defined by [RFC3692] and [RFC4727] when used as experimental extension headers. "Defined" extension headers are the "standard" extension headers plus the "experimental" ones. >> and also ignore the Security Considerations, which says: >> >> These changes do not affect a firewall's ability to filter out >> traffic containing unwanted or suspect extension headers, if >> configured to do so. However, the changes do require firewalls to be >> capable of permitting any or all extension headers, if configured to >> do so. The default configurations are intended to allow normal use >> of any standard extension header, avoiding the connectivity issues >> described in Sections 1 and 2.1. > > The recommendations in your document are to have a default that > overrides the security considerations in RFC2460. Nope. Please check Section 2.2 of our I-D, which says: The advice provided in this document is only meant to guide an operator in configuring forwarding devices, and is *not* to be interpreted as advice regarding default configuration settings for network devices. That is, this document provides advice with respect to operational configurations, but does not change the implementation defaults required by [RFC7045] and [draft-gont-6man-ipv6-opt-transmit]. i.e., our recommendations shouldn't be used as "default configurations" of any devices. >> draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* >> a default policy or the like (and this is pretty clear in the Intro). So >> it doesn't go against RFC7045. For instance, that was the main/sole goal >> of the latest rev of the I-D > > Advice that doesn't give a specific context is advice to override a > default, IMO. You need a lot more context to explain when and/or where > such overrides are relevant. If you look closely at the I-D, it is essentially a "default allow", modulo HBH, in which case we provide recommendations 8a few options) well within RFC7045. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Sep 28 11:00:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995F91A0371 for ; Sun, 28 Sep 2014 11:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 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.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai62AhpvQ68Y for ; Sun, 28 Sep 2014 11:00:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450641A036C for ; Sun, 28 Sep 2014 11:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1933; q=dns/txt; s=iport; t=1411927207; x=1413136807; h=date:from:message-id:to:subject:cc; bh=Rjc/XIcr1CvyjPCv0rj8Zn3wWVoNG0LaCyobbvaqZyY=; b=KVZWVk42A8mYnu6BagIbqheLm1phhVDYzhJ6UlYbEeUq4R0F8ztQejJr BkLdH980/aSzwRwcddaUg1pMo5lmU7Xnb8vu2oQ6fcz4PYZxNq/zpeueY euXtYcOt6thN99HmXAX/GxoqJr1lcV+wzkcqmEbZg/CyEYJ2lIJXH4WH2 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncIAG5MKFStJA2G/2dsb2JhbABggw5TWLk4AZBbh0x9FgF7hHgLPDSJHgENvwABF5AeHYQ1BYtPilCIa5N7hAODFgEBAQ X-IronPort-AV: E=Sophos;i="5.04,615,1406592000"; d="scan'208";a="358929619" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 28 Sep 2014 18:00:06 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8SI06Vi004575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2014 18:00:06 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s8SI05LB021730; Sun, 28 Sep 2014 11:00:05 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s8SI04lU021725; Sun, 28 Sep 2014 11:00:04 -0700 Date: Sun, 28 Sep 2014 11:00:04 -0700 From: fred@cisco.com Message-Id: <201409281800.s8SI04lU021725@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SvSZS_jYlFoaJ6wyQMlamTrWXfY Subject: [v6ops] Please file your new drafts (and updates) now X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 18:00:08 -0000 Please file your new drafts, targeting IETF 91, in the coming two weeks. The drop-dead date for new drafts is 27 October, a month hence. You will recall, however, that for IETF 90, we didn't have enough time to have the working group react to new drafts. The chairs would like to have that amount of time. So please file drafts now and beat the rush at 5:00 Eastern on 27 October. As usual, we expect the agenda to include updated working group drafts and other drafts filed or updated since the last meeting that have received supportive commentary on the mailing list. This is our current status: IESG: Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis Exiting WGLC; on its way to IESG: Working Group Document updated since IETF: Sep 18 draft-ietf-v6ops-design-choices Sep 26 draft-ietf-v6ops-mobile-device-profile Individual Submission updated since IETF: Aug 24 draft-v6ops-pmtud-ecmp-problem Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world Sep 15 draft-anderson-v6ops-siit-dc Sep 15 draft-anderson-v6ops-siit-dc-2xlat Sep 18 draft-elkins-v6ops-multicast-virtual-nodes Sep 18 draft-wang-v6ops-xlat-prefix-discovery Sep 25 draft-ybai-v6ops-ipv6-for-openstack Working Group Document NOT updated since IETF: Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem Jul 4 draft-ietf-v6ops-ula-usage-recommendations Individual Submission NOT updated since IETF: Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node Jul 3 draft-liu-v6ops-running-multiple-prefixes Jul 4 draft-sun-v6ops-xlat-multi Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x Jul 20 draft-wang-v6ops-flow-label-refelction Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops From nobody Sun Sep 28 22:57:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB101A02DF; Sun, 28 Sep 2014 22:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqALdSIbFukM; Sun, 28 Sep 2014 22:57:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE051A029E; Sun, 28 Sep 2014 22:57:25 -0700 (PDT) Received: from [192.168.1.2] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8T5v2NC022054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 28 Sep 2014 22:57:11 -0700 (PDT) Message-ID: <5428F4AF.3090405@isi.edu> Date: Sun, 28 Sep 2014 22:57:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> <542479EB.1010406@isi.edu> <5424A425.7060407@si6networks.com> In-Reply-To: <5424A425.7060407@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2o9sQrx9iU53VU5WquamNVkSOAs Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" Subject: Re: [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 05:57:26 -0000 On 9/25/2014 4:24 PM, Fernando Gont wrote: ... > Nope. Please check Section 2.2 of our I-D, which says: > > The advice provided in this document is only meant to guide an > operator in configuring forwarding devices, and is *not* to be > interpreted as advice regarding default configuration settings for > network devices. ... > i.e., our recommendations shouldn't be used as "default configurations" > of any devices. So these are not defaults... ... > If you look closely at the I-D, it is essentially a "default allow", except that they are. Esp. two of the specific recommendations. Perhaps this most clearly highlights the reason I don't see the utility or purpose in this doc. Operational recommendations should be explained in the context of existing standards, and only where they deviate from them in a specific operational context. Joe From nobody Mon Sep 29 21:51:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16301A0146 for ; Mon, 29 Sep 2014 21:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HXDXEYczW1E for ; Mon, 29 Sep 2014 21:51:07 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9751A0145 for ; Mon, 29 Sep 2014 21:51:07 -0700 (PDT) Received: from [186.134.2.155] (helo=[192.168.1.6]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XYpOw-0006A3-DC; Tue, 30 Sep 2014 06:51:03 +0200 Message-ID: <542A36AC.9030203@gont.com.ar> Date: Tue, 30 Sep 2014 01:50:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VwC03ftYEVitrIHOrXDl9wKtmTE Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Sep 2014 04:51:09 -0000 Folks, Earlier in September we published a revision of our I-D "IPv6 Extension Headers in the Real World" (). At this point in time, we're interested in knowing whether our I-D is of value for the IPv6 ops community, such that we can decide whether to continue working/improving it. Additionally, if there's anything you think we've missed in the document, we'd like to hear from you. Overall, our I-D is meant to provide a reality-check with respect to the issues surrounding IPv6 Extension Headers and their use on the public Internet. More specifically, its goals are: 1) Provide data regarding support of IPv6 EHs in the real world. This is interesting data to refer people to (e.g., folks developing protocols) regarding the extent to which IPv6 EHs are usable on the public Internet (at least with web, mail, and name servers). 2) Summarize the issues associated with IPv6 EHs (performance, security, etc.) This is of use for folks concerned with the issues surrounding IPv6 EHs, and covers practical issues. 3) Summarizes the implications of the aforementioned filtering. For example, if you're designing a protocol that is meant to work on the public Internet, you may want to provide some fall-back mechanism that does not employ IPv6 EHs. Yet another of the implications is the security issue that has been discussed on-list: if e.g. IPv6 fragments are dropped and you can be tricked into generating them, you may be subject to a DoS attack. 4) Flag possible further work Here we try to flag areas where the further work may be needed, such as adding fall-back mechanisms to some existing protocols, or avoiding the use of IPv6 EHs where possible. 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