From nobody Sun Aug 3 11:00: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 3EB471A0AFE for ; Sun, 3 Aug 2014 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.002 X-Spam-Level: X-Spam-Status: No, score=-113.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IXHASH_X1=1.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUEZJ-L4V52z for ; Sun, 3 Aug 2014 11:00:21 -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 B0BBD1A0B03 for ; Sun, 3 Aug 2014 11:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1407088823; x=1408298423; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=RRJBESG6l6+dJ2/xahzdQ3gyBWHbjC1iuxpGTIFnVjc855lszqrsTcuS KRfmpeqOGgmh4NEU32xqpRmfxXZz5oKVm12qW8CNL31i/1g+eQFjrWVCK UcFf0f429wke+X+DVgSy/07dEeORttCTpmMXtWJ4DHSaAK6VqbSWvUT5u 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAEN43lOtJV2S/2dsb2JhbABagw2zHwGhbYEIFneEJ1w8NIkiAcVQF49MHYQ1BYsPpVaDbQ X-IronPort-AV: E=Sophos;i="5.01,793,1400025600"; d="scan'208";a="66173137" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 03 Aug 2014 18:00:09 +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 s73I07Jm000305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2014 18:00:07 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 s73I06ZS028058; Sun, 3 Aug 2014 11:00:06 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s73I04VG028053; Sun, 3 Aug 2014 11:00:04 -0700 Date: Sun, 3 Aug 2014 11:00:04 -0700 From: fred@cisco.com Message-Id: <201408031800.s73I04VG028053@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bEbonbd10WPJIEE7lNlhD3R-v-4 Subject: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis 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, 03 Aug 2014 18:00:24 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From nobody Sun Aug 3 18:08: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 570BB1B27DC; Sun, 3 Aug 2014 18:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEmHkCHFNxPo; Sun, 3 Aug 2014 18:07:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F41B27DE; Sun, 3 Aug 2014 18:07:55 -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.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> Date: Sun, 03 Aug 2014 18:07:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K_kC0W1zwe1b3O9Yfl4HNA4n5AM Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Mon, 04 Aug 2014 01:07:59 -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-02.txt Pages : 16 Date : 2014-08-03 Abstract: This document identifies a set of failure cases that may be encountered by an IPv6-enabled mobile customers in roaming scenarios. The investigations on those failed cases reveal the causes in order to notice improper configurations, equipment's incomplete functions or inconsistent IPv6 introduction strategy. 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 3 18: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 7FA2B1B27DE for ; Sun, 3 Aug 2014 18:12: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 UKRMfO7dnIJD for ; Sun, 3 Aug 2014 18:12:00 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795D71B27DB for ; Sun, 3 Aug 2014 18:12:00 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so8326506qga.1 for ; Sun, 03 Aug 2014 18:11:59 -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 :content-type; bh=CXM3Ckh4yDaAKeRuMqPqFEh7kLaTnuhbtKzWmu5N/Ks=; b=hAd7jqH/BBL0zCiLhH2ZD4IMziCZtYb29td56El8T1I3erqTdO0xFqppNUGifEecoo chcrwsgt5SwX0JH1fgFYO3L+zfgDaf/l82kEf2pGjzzJaHhoLqwuj8B59eKacgYNQTlL wmsL8pt8IDylZH3Zx/hZVxqmrFzzTj0qL26NKbQXpeEbhbdf787hlzs305PfyaurhLvG XS4vWWA/brf/+HyD7r1KQAcINdBH22cUYFrbjKxMKty2XTP7P3UWXstz+iOyA8BVpFfg irelhaZQHP7cU5QXDiKuE8wITc7PNS/WJb4Kov9PaIYycd9aix/8a18DNoFKeJ1uH0bU ifww== MIME-Version: 1.0 X-Received: by 10.224.123.8 with SMTP id n8mr32132795qar.40.1407114719551; Sun, 03 Aug 2014 18:11:59 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Sun, 3 Aug 2014 18:11:59 -0700 (PDT) In-Reply-To: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> Date: Mon, 4 Aug 2014 09:11:59 +0800 Message-ID: From: GangChen To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/s432hGsX5QqhFfWx2grnLOSTDGc Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Mon, 04 Aug 2014 01:12:02 -0000 WG, We have uploaded the new draft according to the comments received so far. Please kindly check. Many thanks Gang 2014-08-04 9:07 GMT+08:00, internet-drafts@ietf.org : > > 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-02.txt > Pages : 16 > Date : 2014-08-03 > > Abstract: > This document identifies a set of failure cases that may be > encountered by an IPv6-enabled mobile customers in roaming scenarios. > The investigations on those failed cases reveal the causes in order > to notice improper configurations, equipment's incomplete functions > or inconsistent IPv6 introduction strategy. > > > 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-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Mon Aug 4 01:52: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 D35A31B286C for ; Mon, 4 Aug 2014 01:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC1tJXGSDQ59 for ; Mon, 4 Aug 2014 01:52:20 -0700 (PDT) Received: from jabiru.ens-lyon.fr (jabiru.ens-lyon.fr [140.77.51.2]) by ietfa.amsl.com (Postfix) with ESMTP id 265FC1A000C for ; Mon, 4 Aug 2014 01:52:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id 46D9D1EB0FC; Mon, 4 Aug 2014 10:52:18 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at ens-lyon.fr Received: from jabiru.ens-lyon.fr ([127.0.0.1]) by localhost (jabiru.ens-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKDcvYNXFiLR; Mon, 4 Aug 2014 10:52:16 +0200 (CEST) Received: from localhost (second.degre.polyno.me [91.224.149.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by jabiru.ens-lyon.fr (Postfix) with ESMTPSA id 9745C1EB10B; Mon, 4 Aug 2014 10:46:04 +0200 (CEST) Date: Mon, 4 Aug 2014 17:45:59 +0900 From: Baptiste Jonglez To: Michel Gosse Message-ID: <20140804084559.GC16623@ens-lyon.fr> References: <00cb01cfabe9$fc3c3e90$f4b4bbb0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline In-Reply-To: <00cb01cfabe9$fc3c3e90$f4b4bbb0$@upperside.fr> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-zGzzE-xCIT37prMdHauOYguexQ Cc: v6ops@ietf.org Subject: Re: [v6ops] V6 World 2015: CFP deadline extension X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 08:52:23 -0000 --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2014 at 01:32:45PM +0200, Michel Gosse wrote: > The fifth Edition of V6 World will take place in Paris from 17 to 18 Marc= h, > 2015.=20 >=20 >=20 > The agenda will cover in particular SDN, Segment Routing/Spring, V6 in Da= ta > Centers and XLAT464 Deployments issues. > =20 > The call for proposals deadline has been extended to August 22, 2014. > =20 > More info: > http://www.uppersideconferences.com/v6world2015/v6world2015cfp.html The entrance fee for the 2014 edition was =E2=82=AC2,490, which seems pretty expensive to me. Not every organisation can afford this amount. For instance, I'm part of a non-profit that would love to discuss experience of IPv6 deployement, but such a high price is completely prohibitive. Or maybe I didn't read this page correctly? https://www.uppersideconferences.org/mpls2014/mpls2014registration_materi= als.html Baptiste --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJT30hHAAoJEGB4mfgsWgTW4acP/1ONxwSYglkOPaTiHndZL+2L sY/Yr8VqVSQVucDyLYiIesVGYMdZlkhGoN/l34+AMGAyeMtDREBf7P7aL5U2qeSE MqYSqWVvRUBXrN1I+07DSEV0ucbtYDcpaw3+qCiu2pb7QlvrBmkI+Wtg9jhUyGBg 6DDZbvAnVFLdd1LMcYwkdbUyv5ggp8YOfE8DRTIzeLBIVAgUWrDt5+ThiU4Ra8RK +fo9zKp27UXBE/yjCxvCgvGpGLEf/79Ooe5G0N9Kceoxvcg4D7GtM53kxP2rWffr cLu9tXxBi5d+OJ1fR7RoP6oWaPa01JfhJcQeWSHwv3ZPNY7Y7pqg0RaqcEH9sfBE u3HkdRWKLSCrCMyfQTppHZY1zHN2MRXOKFyFcfi6ZzeBqtmGgFea0VY+WOPtDc4r jy8vzq5d0EBFkAC6L7bUzyacZ/QPZobkmvyFeblosugGafn1r70fss1KtQf52IYb R1ZhdkvPpsDGrA6iRy56WJie0LAUcnVLLDfyj53Agch1/jpPvL3DT11F3rjIQ92c sNO9q67UeISNVtMCnA7Nc7z4LXK9Ra5LhW5aGPjS+VNZbEq0rrLOj2KmxhDc9VKS gknsIWg5IeLaEhGfcjE6mm9fB8Tb9sJ5sMdeHmkAnIfo8KPApj+/7783jyxU5cZx D/ukMsnMzmW5yGvMrJSB =Z0Lp -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From nobody Mon Aug 4 01:56: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 CFDBD1A000C for ; Mon, 4 Aug 2014 01:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbEm9te1sAf7 for ; Mon, 4 Aug 2014 01:56:29 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD7B1B28D0 for ; Mon, 4 Aug 2014 01:56:29 -0700 (PDT) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 3026F1003AF19; Mon, 4 Aug 2014 08:58:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1407142684; bh=2sgpF1UAwHMEKIhpnum6Ft8PrTe4kVxwn2pD6J6d4Bo=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=RYAIbDOc0migWtRve/o+w1t2OYQONYEz5mkY/Yw1odaLooVIH/wz7cdDt+zdq9mBD QlrJddazuVMBWkrXIzjITbRceUIpoXZSVxzunA+xKq17iYLbsXvjFZ/c6Er+I7exe5 Fy4bw6L23fadkMC4V0baTWW5JeFbE9hKpt3mLC+25GC55zF3u9ItQwEkzj5hIwTd4V SrbZTxqSePnrohc3PriQ/C2msjb363ysmZxHRjRb/bMPmgYB+N8Q8m3AYQJ+vuWoGG 9vZ0qdVdvXHFdxOB8jhivp6x+a5E2SQC1PRa3tpaotrgyEDh3UVofyvL1pAkcAQ56j 5K2U1QHyMPDvA== Message-ID: <53DF4ABC.8000800@massar.ch> Date: Mon, 04 Aug 2014 10:56:28 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Baptiste Jonglez , Michel Gosse References: <00cb01cfabe9$fc3c3e90$f4b4bbb0$@upperside.fr> <20140804084559.GC16623@ens-lyon.fr> In-Reply-To: <20140804084559.GC16623@ens-lyon.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Uys8zTqKH-i2QGQ_JiZk5GbSM4k Cc: v6ops@ietf.org Subject: Re: [v6ops] V6 World 2015: CFP deadline extension X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 08:56:32 -0000 On 2014-08-04 10:45, Baptiste Jonglez wrote: > On Wed, Jul 30, 2014 at 01:32:45PM +0200, Michel Gosse wrote: >> The fifth Edition of V6 World will take place in Paris from 17 to 18 March, >> 2015. >> >> >> The agenda will cover in particular SDN, Segment Routing/Spring, V6 in Data >> Centers and XLAT464 Deployments issues. >> >> The call for proposals deadline has been extended to August 22, 2014. >> >> More info: >> http://www.uppersideconferences.com/v6world2015/v6world2015cfp.html > > The entrance fee for the 2014 edition was €2,490, which seems pretty > expensive to me. Not every organisation can afford this amount. For > instance, I'm part of a non-profit that would love to discuss experience > of IPv6 deployement, but such a high price is completely prohibitive. > > Or maybe I didn't read this page correctly? > > https://www.uppersideconferences.org/mpls2014/mpls2014registration_materials.html You didn't. You are forgetting the extra 499 EUR in VAT for that ticket. I am wondering a bit though why v6ops @ IETF is getting commercial conference announcements. Isn't the only on-topic conference the one that the IETF organizes itself? Greets, Jeroen From nobody Mon Aug 4 09:19: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 146801A03FF for ; Mon, 4 Aug 2014 09:19:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fPO9LIohWCh for ; Mon, 4 Aug 2014 09:19:13 -0700 (PDT) Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id 3DBB41B2B93 for ; Mon, 4 Aug 2014 09:19:05 -0700 (PDT) Received: (qmail 86681 messnum 12627610 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 4 Aug 2014 16:19:03 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail06.svc.cra.dublin.eircom.net (qp 86681) with SMTP; 4 Aug 2014 16:19:03 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id agJz1o02M0mJ9Tz01gK3Jb; Mon, 04 Aug 2014 17:19:03 +0100 From: Ross Chandler Content-Type: multipart/alternative; boundary="Apple-Mail=_4F9EE34D-AAE2-4B8E-957A-BEF3846AE976" Message-Id: <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 4 Aug 2014 17:18:56 +0100 References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> To: v6ops@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/X5JSmGXotrDP-nxygfptjgTQ7Fc Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Mon, 04 Aug 2014 16:19:16 -0000 --Apple-Mail=_4F9EE34D-AAE2-4B8E-957A-BEF3846AE976 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 4 Aug 2014, at 02:11, GangChen wrote: > WG, >=20 > We have uploaded the new draft according to the comments received so = far. > Please kindly check. >=20 > Many thanks >=20 > Gang Hi All, IMHO the main utility of this draft is to create a point of reference to = the gap in=20 the standards created by the introduction of support for dual-stack over = a single=20 radio bearer in separate 3GPP Releases for PDP/PDN context creation.=20 To that end I=92d like it to have clearer recommendations on how to = close that gap. e.g. New HLR/HSS functionality to by default restrict the sending = PDP-Ext-Type/IPv4v6=20 with a whitelist of known good networks. Also the complement the default = allow sending=20 of PDP-Ext-Type/IPv4v6 with a network blacklist. Section 7, discussions, says =93dual-stack deployment is recommended in = most cases=94. Is that still the consensus position? Going straight to single-stack = IPv6 is looking very viable now when the UE supports a method of providing translated IPv4 access over = the IPv6 PDP/PDN=20 connection.=20 Ross =20 =20= --Apple-Mail=_4F9EE34D-AAE2-4B8E-957A-BEF3846AE976 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 4 Aug 2014, at 02:11, GangChen = <phdgang@gmail.com> = wrote:

WG,

We have uploaded the = new draft according to the comments received so far.
Please kindly = check.

Many = thanks

Gang

Hi = All,

IMHO the main utility of this draft is to = create a point of reference to the gap in 
the standards = created by the introduction of support for dual-stack over a = single 
radio bearer in separate 3GPP Releases for = PDP/PDN context creation. 
To that end I=92d like it to = have clearer recommendations on how to close that = gap.

e.g. New HLR/HSS functionality to by = default restrict the sending PDP-Ext-Type/IPv4v6 
with a = whitelist of known good networks. Also the complement the default allow = sending 
of PDP-Ext-Type/IPv4v6 with a network = blacklist.

Section 7, discussions,  says = =93dual-stack deployment is recommended in most cases=94.
Is = that still the consensus position?  Going straight to single-stack = IPv6 is looking very viable now
when the UE supports a method = of providing translated IPv4 access over the IPv6 = PDP/PDN 
connection. 

Ross



 
&nbs= p;
= --Apple-Mail=_4F9EE34D-AAE2-4B8E-957A-BEF3846AE976-- From nobody Mon Aug 4 09:31: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 EF9CF1A0081 for ; Mon, 4 Aug 2014 09:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yaiu1s8mZbbm for ; Mon, 4 Aug 2014 09:31:05 -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 777201A040F for ; Mon, 4 Aug 2014 09:31:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63FFCA3; Mon, 4 Aug 2014 18:31:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1407169863; bh=Ke0MWFhM+jPPzvHSeuL+HJVS1zzVmWCabawXLZHoaQg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hr3XLbbSkce7e6smvprGPxdB9UZp4ESAMaVuMum59Ud9373te59LfgdN4u0YWnViN r+vQ0k83twhoMQ1Z33prwCtWl/Md+7QwEwZ/3kFj3GxLmMDl2IX6vAwgz2p1+02goj L8rFGjNfgMGhlXrnuXVjb+Qc/dYzWpwQmAlY2JKY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 57CFFA2; Mon, 4 Aug 2014 18:31:03 +0200 (CEST) Date: Mon, 4 Aug 2014 18:31:03 +0200 (CEST) From: Mikael Abrahamsson To: Ross Chandler In-Reply-To: <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> Message-ID: References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-855693784-1407169863=:7929" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/R9xNyOqUz06fMoCyLQ-NsPU2ZUA Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Mon, 04 Aug 2014 16:31:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-855693784-1407169863=:7929 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 4 Aug 2014, Ross Chandler wrote: > IMHO the main utility of this draft is to create a point of reference to the gap in > the standards created by the introduction of support for dual-stack over a single > radio bearer in separate 3GPP Releases for PDP/PDN context creation. > To that end I’d like it to have clearer recommendations on how to close that gap. My opinion is not that any part of the standard is the problem, but rather buggy implementations. > e.g. New HLR/HSS functionality to by default restrict the sending > PDP-Ext-Type/IPv4v6 with a whitelist of known good networks. Also the > complement the default allow sending of PDP-Ext-Type/IPv4v6 with a > network blacklist. These are operational requriements, and I fully support putting them in some kind of document, but the question is if it's really "roaming analysis" anymore. The language would need to be very careful not to make any recommendations then (?), but rather suggest possible ways of working around the problems seen. > Section 7, discussions, says “dual-stack deployment is recommended in most cases”. > Is that still the consensus position? Going straight to single-stack IPv6 is looking very viable now > when the UE supports a method of providing translated IPv4 access over the IPv6 PDP/PDN > connection. I don't think there is consensus here. The draft could point out pros and cons with each approach. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-855693784-1407169863=:7929-- From nobody Mon Aug 4 09:52: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 5B7531A0028; Mon, 4 Aug 2014 09:52: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 QfNSVs8E-STz; Mon, 4 Aug 2014 09:52:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95B1A0029; Mon, 4 Aug 2014 09:51: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.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804165158.22803.46646.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 09:51:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IU9uHirzwI1dx_pbL0sipV7scTM Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-clatip-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:52: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 : IPv4 Service Continuity Prefix Author : Cameron Byrne Filename : draft-ietf-v6ops-clatip-04.txt Pages : 5 Date : 2014-08-04 Abstract: DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-clatip-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-clatip-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 4 09:55: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 5D18E1A0019 for ; Mon, 4 Aug 2014 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.502 X-Spam-Level: X-Spam-Status: No, score=-116.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEZfgIjCnoGz for ; Mon, 4 Aug 2014 09:55:46 -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 F33961A003A for ; Mon, 4 Aug 2014 09:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4072; q=dns/txt; s=iport; t=1407171346; x=1408380946; h=from:to:cc:subject:date:message-id:mime-version; bh=GBa8F3+LYEVTbvPk83vaefiwjUFR1rXSNiow0/efv1U=; b=WVUahjpkRiRi2nlNz0nDPUGaaWKuQduJLgxczmFdqCT1OI7kehlGT3iC SBCa4jl0AU0YnePCIgyd/vBG+dCUvgcPPwhaqPm1sgS7xP+HbfmQ9Nqul m1l1neSDmcCNofBUZ5Vc86rLrYPEtEgeTBWjIfapWl4LVwEqSj287ozmH I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFANS531OtJA2M/2dsb2JhbABbgw1SVwS0OpdxCodKgRIWd4QFBXkSASBgJwQOBQ4NiBMDEQ2+NAqGZhePTII/UySBHAWEfwKJdoQMgUkDhzeBVJMLg01sgUY X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="asc'?scan'208";a="66349516" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 04 Aug 2014 16:55:45 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s74GtjS1011262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 16:55:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 11:55:44 -0500 From: "Fred Baker (fred)" To: Ross Chandler Thread-Topic: Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8g== Date: Mon, 4 Aug 2014 16:55:43 +0000 Message-ID: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@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.115] Content-Type: multipart/signed; boundary="Apple-Mail=_5CCCF3C0-42F5-450E-9D71-E287622E7D6C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sr7DlWt7GxiOclkFL3kDL2uF5_8 Cc: IPv6 Ops WG , "tore.anderson@redpill-linpro.com" Subject: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:55:48 -0000 --Apple-Mail=_5CCCF3C0-42F5-450E-9D71-E287622E7D6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I changed the subject line. On Aug 4, 2014, at 9:18 AM, Ross Chandler wrote: > Section 7, discussions, says =93dual-stack deployment is recommended = in most cases=94. Is that still the consensus position? Going straight = to single-stack IPv6 is looking very viable now when the UE supports a = method of providing translated IPv4 access over the IPv6 PDP/PDN = connection.=20 I would agree that there are a number of operators moving in that = direction - DTAG Terastream, Google, Facebook, and several mobile = operators come quickly to mind. The number of operators that still don=92t= have a customer-facing IPv6 offering still dwarfs them, and the IETF = has not itself changed that position. So I would say that we have not = changed our fundamental consensus - and at the same time agree that it = isn=92t as steady as it once was. There are cracks in the glacier. Let me say this, though. The fundamental question that we have to = answer, if we want to change the consensus, is (1) how we safely move a = business from IPv4 to IPv6, shutting IPv4 down, and (2) how we deal with = the residual IPv4 Internet. As with 464xlat or softwire's MAP, the = latter comes down to some variation on translation and/or encapsulation. = What I would like to see - consider this an invitation to an operator or = an operator and a vendor that have implemented it and want to = collaborate - is: - a short draft, counterpart to RFC 6540, stating a change in the = operational consensus toward IPv6-only deployment - a practical approach on =93how to get there=94 (probably more than = one draft, addressing differing operational requirements) - a practical translation solution (possibly more than one draft) I still tend to think that dual stack is the most reasonable =93how to = get there=94 approach; you have to have a running IPv6 network to move = customers to before you can shut down the IPv4 network. The question is = how long IPv4 stays up once you have a viable IPv6 network. If someone = has a better idea, that is something to discuss. I=92m copying Tore, because I think = http://tools.ietf.org/html/draft-anderson-siit-dc might very well be = that =93practical translation solution=94 for at least some = environments. For an enclosed environment such as a data center, it = enables the implementation of an IPv6-only environment, maintains IPv4 = access to it, and maintains geolocation capabilities across that = translation. At the point where the business requirement for IPv4 = accessibility falls off, the translator simply becomes a vestigial = capability, as opposed to requiring a dramatic and costly change. That = seems pretty attractive. I=92d invite discussion on that and on the = draft (which is long expired, but Tore could resurrect it as = draft-anderson-v6ops-siit-dc if he wanted to). If it now has a consensus = behind it, publish as an RFC. We would also need recommendations for residential broadband, which John = Brzozowski might be in a position to make, and for enterprise networks, = which someone from Google or Facebook might be in a position to do, or = someone else. I=92ll channel Lorenzo, here. Lorenzo, correct me if I get this wrong. = We want any statement along these lines to come from someone that has = implemented it in their network.=20 --Apple-Mail=_5CCCF3C0-42F5-450E-9D71-E287622E7D6C 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 iD8DBQFT37sNbjEdbHIsm0MRAvrnAKDS/TMJJ/FW0YfGh7qFWCi8/bEZzgCgt6Wi ZNMPd5Tf6rkq9+PvL1j2n6c= =GSBp -----END PGP SIGNATURE----- --Apple-Mail=_5CCCF3C0-42F5-450E-9D71-E287622E7D6C-- From nobody Mon Aug 4 11: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 257F11A0103 for ; Mon, 4 Aug 2014 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJFqzliFfZbL for ; Mon, 4 Aug 2014 11:51:37 -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 08D3F1A00F2 for ; Mon, 4 Aug 2014 11:51:37 -0700 (PDT) Received: from cm-84.209.85.233.getinternet.no ([84.209.85.233]:58020 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XENM5-0001hK-3Q; Mon, 04 Aug 2014 20:51:33 +0200 Message-ID: <53DFD634.4020304@fud.no> Date: Mon, 04 Aug 2014 20:51:32 +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: "Fred Baker (fred)" References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> In-Reply-To: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b9cjLRryQ1c2sTUIJHEGfMIJprY Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:51:39 -0000 * Fred Baker (fred) > I’m copying Tore, because I think > http://tools.ietf.org/html/draft-anderson-siit-dc might very well be > that “practical translation solution” for at least some environments. > For an enclosed environment such as a data center, it enables the > implementation of an IPv6-only environment, maintains IPv4 access to > it, and maintains geolocation capabilities across that translation. > At the point where the business requirement for IPv4 accessibility > falls off, the translator simply becomes a vestigial capability, as > opposed to requiring a dramatic and costly change. That seems pretty > attractive. I’d invite discussion on that and on the draft (which is > long expired, but Tore could resurrect it as > draft-anderson-v6ops-siit-dc if he wanted to). If it now has a > consensus behind it, publish as an RFC. Eerily good timing... I just started working on this again today, as it happens. What I'm looking at now is two drafts, the one that's already there for a single-translation network-only implementation, plus another one describing an extension very similar to 464XLAT that would allow NAT-incompatible and/or IPv4-only applications to be used in an otherwise IPv6-only data centre. However one of the things I was unsure about when I initially submitted the draft was which WG was the most appropriate (sunset4 or v6ops). Following the off-list discussion you, Marc, and I had back in November 2013, I thought the conclusion was sunset4. But now I see you saying v6ops, so, uhm, now I'm no more certain than I initially was... I'm in two minds about it, myself. The draft doesn't really describe IPv6 operations per se, it deals more with the minimal backwards compatibility glue necessary to provide service to IPv4 only users. Score 1 for sunset4. On the other hand, an operator that wants to do IPv6 today absolutely must have some form of IPv4 compatibility glue for his offering to be commercially viable, thus, 1-1. Tore From nobody Mon Aug 4 12:08: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 02A7C1A0199 for ; Mon, 4 Aug 2014 12:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKYwFG7r5kdb for ; Mon, 4 Aug 2014 12:08:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE41E1A0145 for ; Mon, 4 Aug 2014 12:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3799; q=dns/txt; s=iport; t=1407179329; x=1408388929; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vkTsvMkviIvbGK8SCkzEa499ZmphdQWAYnck8iwvo44=; b=B39MYeLC9emX7IxtkHTRKnotbDHgnOxYYmArkflhcy+3IUmqi9dLEefL 36CVSLzYH1d5lGuYQpTzgFxq2OjYjAXNLpXRi7iWmsb4c813acUPv83a2 WF7XUzGKVP2HCEdFjTRQ/jlyY0rhfcBurRatdty1ui39d5PXpJVx6HGhv k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwJAKfZ31OtJV2Y/2dsb2JhbABbgw1SVwEDzDqHSgGBERZ3hAQBAQR0BRACAQhGMiUCBA4FDg0DiCQNxF8Xj0wHgy+BHAWTA4FJhzqBVJMLg01sgUY X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="asc'?scan'208";a="345025255" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 04 Aug 2014 19:08:48 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s74J8li3012882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 19:08:47 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 14:08:47 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsBeEe75V5M/qGUGXYlRZmCIJvA== Date: Mon, 4 Aug 2014 19:08:46 +0000 Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> In-Reply-To: <53DFD634.4020304@fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_E7D796A2-607F-4CB4-ABB3-DF9D47A2B2C1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aajmO-Sv2o3rfu6Nmcy2M91xEwo Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 19:08:51 -0000 --Apple-Mail=_E7D796A2-607F-4CB4-ABB3-DF9D47A2B2C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 4, 2014, at 11:51 AM, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> I=92m copying Tore, because I think >> http://tools.ietf.org/html/draft-anderson-siit-dc might very well be >> that =93practical translation solution=94 for at least some = environments. >> For an enclosed environment such as a data center, it enables the >> implementation of an IPv6-only environment, maintains IPv4 access to >> it, and maintains geolocation capabilities across that translation. >> At the point where the business requirement for IPv4 accessibility >> falls off, the translator simply becomes a vestigial capability, as >> opposed to requiring a dramatic and costly change. That seems pretty >> attractive. I=92d invite discussion on that and on the draft (which = is >> long expired, but Tore could resurrect it as >> draft-anderson-v6ops-siit-dc if he wanted to). If it now has a >> consensus behind it, publish as an RFC. >=20 > Eerily good timing... I just started working on this again today, as = it > happens. What I'm looking at now is two drafts, the one that's already > there for a single-translation network-only implementation, plus = another > one describing an extension very similar to 464XLAT that would allow > NAT-incompatible and/or IPv4-only applications to be used in an > otherwise IPv6-only data centre. >=20 > However one of the things I was unsure about when I initially = submitted > the draft was which WG was the most appropriate (sunset4 or v6ops). > Following the off-list discussion you, Marc, and I had back in = November > 2013, I thought the conclusion was sunset4. But now I see you saying > v6ops, so, uhm, now I'm no more certain than I initially was... >=20 > I'm in two minds about it, myself. The draft doesn't really describe > IPv6 operations per se, it deals more with the minimal backwards > compatibility glue necessary to provide service to IPv4 only users. > Score 1 for sunset4. On the other hand, an operator that wants to do > IPv6 today absolutely must have some form of IPv4 compatibility glue = for > his offering to be commercially viable, thus, 1-1. >=20 > Tore Copying my co-chair and the two sunset4 co-chairs. If sunset4 wants it, = so be it, from my perspective. It should not drop through the cracks, = though. My point in bringing this up is not that it is =93useful in an IPv6 = network=94 that might also be running IPv4 in parallel. It is that it = seems useful to me in moving toward and IPv6-*only* network. Ross = suggests that he sees conceptual movement - First they ignore you, then = they laugh at you, then they fight you, and then you win. We may, Ross = suggests, be approaching stage 4. It may be useful for us as a working = group to lay out the game plan for that movement - not just to document = IPv6 operational practice, but to help the IETF determine whether the = dual stack consensus has changed or is changing, and help operators = figure out how to turn IPv4 off without individually shooting their toes = off. This would be part of that game plan. --Apple-Mail=_E7D796A2-607F-4CB4-ABB3-DF9D47A2B2C1 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 iD8DBQFT39o8bjEdbHIsm0MRAuK7AJoCMCAEhcyNOvAq4peT8c4dgmNTvgCff4vq KRpqnAnjBHUnY9pFvY3fGyg= =zed+ -----END PGP SIGNATURE----- --Apple-Mail=_E7D796A2-607F-4CB4-ABB3-DF9D47A2B2C1-- From nobody Mon Aug 4 13:26: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 A2CFB1A02A0 for ; Mon, 4 Aug 2014 13:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gcg1CYGkFHjq for ; Mon, 4 Aug 2014 13:26:22 -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 3E8861A0201 for ; Mon, 4 Aug 2014 13:26:22 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so10213584pdj.40 for ; Mon, 04 Aug 2014 13:26:21 -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=NEMO2uGUZwTH+KymJ/PqPwLitioNtHyRlaR1SNMJLhk=; b=Ivlgo2SYNT+KdhsoWH4KGR7vt4JUyhoNXa3HIDvPWnr7DB7vxYPIh91QdC556p+31q YMo/FOffrHQ1L48KSiuKBT28DhO8XW+a2RP2ZbNmr33cEiLfCLcQKlr8rCXkDdqiRFjJ iSJTOVzbfiw8ROELzq955gHcMp5CjhEXf5wjkIDcn6U4g8y4jjok4RzG4yc4KgKpq4px 6rhG88ZRTZ4E/NJ4MR+qsJytUZty8Dus109iBkI6sbqpLIB0ylt6M43nQIaHu7LHlQLr 5UpyHOzHMSyP1O4z+1/HKlAmNpD5vYT9Sx5dokdOF6BEaa6uYeV8wLra2tK8LUmyRbXl m7YQ== X-Received: by 10.70.134.165 with SMTP id pl5mr15305071pdb.20.1407183981846; Mon, 04 Aug 2014 13:26:21 -0700 (PDT) Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id et1sm18366880pbc.39.2014.08.04.13.26.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 13:26:21 -0700 (PDT) Message-ID: <53DFEC6C.3010707@gmail.com> Date: Tue, 05 Aug 2014 08:26:20 +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: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AXiLau7gacR8pxINd3oGc2eDTnw Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:26:23 -0000 > My point in bringing this up is not that it is =E2=80=9Cuseful in an IP= v6 network=E2=80=9D that might also be running IPv4 in parallel. It is th= at it seems useful to me in moving toward and IPv6-*only* network. Ross s= uggests that he sees conceptual movement - First they ignore you, then th= ey laugh at you, then they fight you, and then you win. We may, Ross sugg= ests, be approaching stage 4. It may be useful for us as a working group = to lay out the game plan for that movement - not just to document IPv6 op= erational practice, but to help the IETF determine whether the dual stack= consensus has changed or is changing, and help operators figure out how = to turn IPv4 off without individually shooting their toes off. This would= be part of that game plan. Well, I think the operators that moved early into genuine dual stack operation have no reason to regret it. I'm a happy customer of one such. On the other hand it seems that other operators are of the opinion (probably unprovable) that providing the illusion of dual stack service to the customer over an IPv6 infrastructure is cheaper. In any case the customer ends up with NATted IPv4 service in most cases, so at user level it doesn't really matter. I think we should probably not express a preference either way. It seems like a decision for each operator to make individually. What we probably should do is stop inventing more solutions. (In parenthesis, I've never seen sunsetting IPv4 as a real problem. One day somebody will notice that there are no more IPv4 packets. But that is many years in the future.) Brian From nobody Mon Aug 4 14:03:48 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 AEA091A0100 for ; Mon, 4 Aug 2014 14:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.603 X-Spam-Level: X-Spam-Status: No, score=-112.603 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UcIevygKMz0 for ; Mon, 4 Aug 2014 14:03:44 -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 16F811A00F5 for ; Mon, 4 Aug 2014 14:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5688; q=dns/txt; s=iport; t=1407186224; x=1408395824; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=K+Eohx+QCQtoQnN4+YV3+3Nb+n7oS8btIWZ7BmtF5aQ=; b=B6PVOwGXTEVlE9RRRCTm0YHhtkqdjVG47VVyGblLMt4fGDmYqImrKJCF kE7Ge0zLf+TlqhFaavXcTyI05ZDcElYPWCvzfc7b2RohNKS7iNQPDjpMF aHToJQ/23nraTtrWTDmhYeTQYDWkoHiJgTcHMje71BHDcLoQS7zHPJd3S k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAPLz31OtJV2S/2dsb2JhbABbgw1SVwS0QJdwDodGAYETFneEBAEBAgKBCQIBCBguMiUCBBMJBQ2IJw2zFpESF49TgjhTJIEcBYR/jgSBSQOHN5Rfg01sAYFF X-IronPort-AV: E=Sophos;i="5.01,800,1400025600"; d="asc'?scan'208";a="344999962" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 04 Aug 2014 21:03:43 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s74L3hDG024601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Aug 2014 21:03:43 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 16:03:43 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsCeSe8T1QAQLPEel10XWwoKiqw== Date: Mon, 4 Aug 2014 21:03:42 +0000 Message-ID: <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> In-Reply-To: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@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.115] Content-Type: multipart/signed; boundary="Apple-Mail=_EC97437A-E8A5-4494-93E6-EFE690F336D5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xo9GahW7GYdRpfPv_MpkrW3ZbqM Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 21:03:46 -0000 --Apple-Mail=_EC97437A-E8A5-4494-93E6-EFE690F336D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Following up on my note of a bit ago. Let me walk though a bit more of = my line of reasoning by saying what question I would expect these drafts = to answer. On Aug 4, 2014, at 9:55 AM, Fred Baker (fred) wrote: > - a short draft, counterpart to RFC 6540, stating a change in the = operational consensus toward IPv6-only deployment The current consensus regarding dual stack transition is captured in = https://tools.ietf.org/html/rfc4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT=3D58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD) That is the third in a series; RFCs 1933 and 2893 looked at possible = transition plans and suggested the approach. In short, it suggests that = IPv6 be brought up in an operator=92s existing IPv4 network as =93ships = in the night=94, the two networks be operated together until the need = for IPv4 goes away, and the operator then turn off IPv4. The simplest and clearest statement I have seen of an alternative plan = is Pater Lothberg and Axel Clauberg=92s comments regarding what they = call =93Kaikaku for IP networks=94. See slide 5 of = https://ripe67.ripe.net/presentations/131-ripe2-2.pdf. In short, = operators are today running =93dual stack=94 on a variety of different = technologies, and doing so costs money. Peter and Axel are therefore = asking what it would take to make the hard choices, jettison unnecessary = costs, and dramatically simplify their service infrastructure. = =93IPv6-only=94 is part of that, but only part. The game plan is, = instead of bringing IPv6 up in the existing network and subsequently = convincing themselves to make other parts go away, to build a network = based on a very few fundamental building blocks (IPv6, DHCPv6, YANG, one = overlay technology, Metro Ethernet on the fastest fiber optics they can = find, one IGP, BGP, and as little else as they can convince themselves = they need), and then move customers to it. The older-and-more-expensive = network dies when it has no customers. That may be the most dramatic version, but what I see in 464xlat is = similar; the underlying infrastructure is dual stack, but the handsets = are one or the other and use separate sets of services. If the handsets = and services supporting them are all moved to the IPv6 service, nobody = will notice if IPv4 is turned off.=20 Facebook has been making some pretty public comments about their = movement toward IPv6-only; at first, their developers apparently pushed = back pretty hard against becoming version-agnostic, but now they = actually ask =93would anyone mind if I simply leave the IPv4 part of = this code out?=94. = http://www.internetsociety.org/deploy360/resources/case-study-facebook-mov= ing-to-an-ipv6-only-internal-network/ For the IETF to have this conversation, we pretty much need a draft that = makes a bold statement: =93the time is soon coming, or perhaps has = arrived, to turn IPv4 off.=94 I expect that bold statement to be = controversial, both on this list and during IETF Last Call. I expect it = to make the press. If we think we=92re ready for that conversation, = let=92s have it. Whenever we have it, we will need a draft to focus it. = If we=92re not ready for it, that=92s fine too. But how do we tell when = we=92re ready? > - a practical approach on =93how to get there=94 (probably more than = one draft, addressing differing operational requirements) You might listen to the first 35 seconds of = http://www.youtube.com/watch?v=3DkwFvJog2dMw, which was a seminal moment = in the speaker=92s presidency. =93We choose to go to the moon. We choose = to go to the moon in this decade... not because it is easy, but because = it is hard.=94 I see the draft I just spoke about as a similar vision = statement: =93we choose to turn IPv4 off...=94. Jack Kennedy=92s speech, delivered when I was ten, didn=92t get us to = the moon. We wouldn=92t have gotten there without it, though. What got = us to the moon was a lot of research, and a lot of very solid = engineering. We have, I think, done the research, built the products, = and tested them operationally. I=92m looking for that engineering in = these drafts. How do we get to the moon? The alternative is where Microsoft Azure finds itself now. They are out = of IPv4 address space and do not have a publicly announced IPv6 service. = To fill the gap, they are moving address space from Brazil to the US. = Now, lest someone think I=92m slamming them, I have little doubt that = they have a long term plan; it=92s just not in evidence at the moment. = But where they stand, if they don=92t have a plan, they=92re screwed. = They are only the most public of a long list of companies with that = problem... > - a practical translation solution (possibly more than one draft) I=92m also looking for solid engineering in this... --Apple-Mail=_EC97437A-E8A5-4494-93E6-EFE690F336D5 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 iD8DBQFT3/UsbjEdbHIsm0MRAubNAKDepSo+81NttCFfPk10/UzmoxAZ2wCfb3Ex BhNONUU8ZwnRm+QinErJAsI= =9sSh -----END PGP SIGNATURE----- --Apple-Mail=_EC97437A-E8A5-4494-93E6-EFE690F336D5-- From nobody Mon Aug 4 16:12: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 93B011A03E9 for ; Mon, 4 Aug 2014 16:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 973pcFwxBFCT for ; Mon, 4 Aug 2014 16:11:56 -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 EE8931A03D2 for ; Mon, 4 Aug 2014 16:11:55 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 3320A3493BA; Mon, 4 Aug 2014 23:11:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ED0CD160067; Mon, 4 Aug 2014 23:22:02 +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 BEC9B160066; Mon, 4 Aug 2014 23:22:02 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AAAEF1B7AB9F; Tue, 5 Aug 2014 09:11:51 +1000 (EST) To: "Fred Baker (fred)" From: Mark Andrews References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> In-reply-to: Your message of "Mon, 04 Aug 2014 21:03:42 +0000." <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> Date: Tue, 05 Aug 2014 09:11:51 +1000 Message-Id: <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HfnBEKI-eBNle5EPZw0chBp63vM Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 23:12:04 -0000 In message <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com>, "Fred Baker (fred) " writes: > > The alternative is where Microsoft Azure finds itself now. They are out > of IPv4 address space and do not have a publicly announced IPv6 service. > To fill the gap, they are moving address space from Brazil to the US. > Now, lest someone think I'm slamming them, I have little doubt that they > have a long term plan; it's just not in evidence at the moment. But where > they stand, if they don't have a plan, they're screwed. They are only the > most public of a long list of companies with that problem... Azure would still need the IPv4 addresses because the rest of the world as a whole has not moved to IPv6 yet. While datacenters may be able to move to IPv6 only internally there is still a external need for IPv4 addresses. IPv6 only gives some IPv4 address saving but not that much on the server side. We are still a long way from turning off IPv4 servers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 4 16:20: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 D07D11A0442 for ; Mon, 4 Aug 2014 16:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cmKp-t-0O75 for ; Mon, 4 Aug 2014 16:20:37 -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 106381A041B for ; Mon, 4 Aug 2014 16:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1602; q=dns/txt; s=iport; t=1407194437; x=1408404037; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Jp0BgpcZI+3csJzbNJfYaw2jL4hF6hZGkfn/oRatyZY=; b=AVkgg9T5fyDTF0mN5Irq7/YH0N+SfMghm3azYlXKaezyOZvodMdHMBN3 BxBTM/xEZO/lusW88Qt5fTXFl58OLEwQqZ5IsIMRT6rdRKhgPed1FESUO le6+Gr65UTNQ+3nnPie//gSgwX7HJmZoHH/oOFD/ctCAbFULCg1ijIbLf 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAPAU4FOtJV2S/2dsb2JhbABbgw2BKQTUBAGBExZ3hAQBAQMBeQULAgEIRjIlAgQOBQ6ILAjEOBePTAeDL4EcBZMDgUmHOpRfg01sgUY X-IronPort-AV: E=Sophos;i="5.01,801,1400025600"; d="asc'?scan'208";a="345074217" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 04 Aug 2014 23:20:29 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s74NKSTu004830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 23:20:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 18:20:28 -0500 From: "Fred Baker (fred)" To: Mark Andrews Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsDqtUGBahh696kmKcfws34zkeQ== Date: Mon, 4 Aug 2014 23:20:28 +0000 Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> In-Reply-To: <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_C23B07A8-4DAB-4F26-9EE5-20E5012325EA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZadGnAyl5oPSlPLOfc_b_0M3DRU Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 23:20:39 -0000 --Apple-Mail=_C23B07A8-4DAB-4F26-9EE5-20E5012325EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 4, 2014, at 4:11 PM, Mark Andrews wrote: > Azure would still need the IPv4 addresses because the rest of the > world as a whole has not moved to IPv6 yet. While datacenters may > be able to move to IPv6 only internally there is still a external > need for IPv4 addresses. IPv6 only gives some IPv4 address saving > but not that much on the server side. We are still a long way from > turning off IPv4 servers. That=92s sort of the point of Tore=92s document, with the exception that = you can indeed move IPv4 addresses to *only* the edge using his = mechanism. That said, if you have an IPv6-capable data center and are selling it as = a service to customers, that gives you a vehicle to discuss IPv6 with = the customers. =93I have a scarce resource that I can charge you for, = and a plentiful resource I can charge you for. Which would you like to = be charged for?" --Apple-Mail=_C23B07A8-4DAB-4F26-9EE5-20E5012325EA 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 iD8DBQFT4BU6bjEdbHIsm0MRAikYAJ4qzOcaH6K/EWDffNaXI6nnu9x9qQCgoXTn xQ/QJNn11KFLpShwwEmr7h8= =dlqo -----END PGP SIGNATURE----- --Apple-Mail=_C23B07A8-4DAB-4F26-9EE5-20E5012325EA-- From nobody Mon Aug 4 18:15: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 D8E901A0ACF for ; Mon, 4 Aug 2014 18:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.001, 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 ruoVLKFd6Gl7 for ; Mon, 4 Aug 2014 18:15:07 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2091A0ACD for ; Mon, 4 Aug 2014 18:15:07 -0700 (PDT) Received: from [192.168.1.62] (ip72-199-16-177.sd.sd.cox.net [72.199.16.177]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s751CnEu004133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 18:12:52 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s751CnEu004133 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407201174; bh=hKE37Tu1Se4zZUvls+rXtFjh8QM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F1wlOsg04mA4mSk/f0ftay8/nMC8/pyo5qrAltqq920mGnPlhzsHmzkK1FbMPjtY9 R0y4Jl0UxrehI58Q/jiH6UmrF4pcW2N/cELsTtfZ3+XQOGn/h6FUyidqWxR6fA8dYD GDXpVmw/Q2cQu07b77KoVyFgN0s5Qk1cKeiCkFO0= 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: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> Date: Mon, 4 Aug 2014 18:12:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F245536-5BBC-4E6E-AA7D-2B6F7C01F434@delong.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Aug 2014 18:12:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DFHoyo_fV73ZkjPFA_5fGdcp3OU Cc: IPv6 Ops WG , "tore.anderson@redpill-linpro.com" Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 01:15:12 -0000 On Aug 4, 2014, at 9:55 AM, Fred Baker (fred) wrote: > I changed the subject line. >=20 > On Aug 4, 2014, at 9:18 AM, Ross Chandler wrote: >> Section 7, discussions, says =93dual-stack deployment is recommended = in most cases=94. Is that still the consensus position? Going straight = to single-stack IPv6 is looking very viable now when the UE supports a = method of providing translated IPv4 access over the IPv6 PDP/PDN = connection.=20 >=20 > I would agree that there are a number of operators moving in that = direction - DTAG Terastream, Google, Facebook, and several mobile = operators come quickly to mind. The number of operators that still don=92t= have a customer-facing IPv6 offering still dwarfs them, and the IETF = has not itself changed that position. So I would say that we have not = changed our fundamental consensus - and at the same time agree that it = isn=92t as steady as it once was. There are cracks in the glacier. >=20 > Let me say this, though. The fundamental question that we have to = answer, if we want to change the consensus, is (1) how we safely move a = business from IPv4 to IPv6, shutting IPv4 down, and (2) how we deal with = the residual IPv4 Internet. As with 464xlat or softwire's MAP, the = latter comes down to some variation on translation and/or encapsulation. = What I would like to see - consider this an invitation to an operator or = an operator and a vendor that have implemented it and want to = collaborate - is: >=20 > - a short draft, counterpart to RFC 6540, stating a change in the = operational consensus toward IPv6-only deployment > - a practical approach on =93how to get there=94 (probably more than = one draft, addressing differing operational requirements) > - a practical translation solution (possibly more than one draft) >=20 > I still tend to think that dual stack is the most reasonable =93how to = get there=94 approach; you have to have a running IPv6 network to move = customers to before you can shut down the IPv4 network. The question is = how long IPv4 stays up once you have a viable IPv6 network. If someone = has a better idea, that is something to discuss. >=20 > I=92m copying Tore, because I think = http://tools.ietf.org/html/draft-anderson-siit-dc might very well be = that =93practical translation solution=94 for at least some = environments. For an enclosed environment such as a data center, it = enables the implementation of an IPv6-only environment, maintains IPv4 = access to it, and maintains geolocation capabilities across that = translation. At the point where the business requirement for IPv4 = accessibility falls off, the translator simply becomes a vestigial = capability, as opposed to requiring a dramatic and costly change. That = seems pretty attractive. I=92d invite discussion on that and on the = draft (which is long expired, but Tore could resurrect it as = draft-anderson-v6ops-siit-dc if he wanted to). If it now has a consensus = behind it, publish as an RFC. >=20 > We would also need recommendations for residential broadband, which = John Brzozowski might be in a position to make, and for enterprise = networks, which someone from Google or Facebook might be in a position = to do, or someone else. >=20 > I=92ll channel Lorenzo, here. Lorenzo, correct me if I get this wrong. = We want any statement along these lines to come from someone that has = implemented it in their network.=20 I believe that Dual Stack is still the best way forward in most cases = where there are existing IPv4 addresses. In the case where IPv4 addresses are unavailable, I think there is no = clear winner and it is very situational and subjective to choose an = appropriate translation/mapping solution for the given situation. = Ideally, we should be working as hard as possible to get to a point = where the solution to a lack of IPv4 addresses is clearly ideally IPv6 = only. Owen From nobody Mon Aug 4 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 B17FE1A0ACE for ; Mon, 4 Aug 2014 18:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, 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 gK2yOjYHHaA5 for ; Mon, 4 Aug 2014 18:39:31 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6E1A0AD6 for ; Mon, 4 Aug 2014 18:39:31 -0700 (PDT) Received: from [192.168.1.62] (ip72-199-16-177.sd.sd.cox.net [72.199.16.177]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s751ZJWZ004561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 18:35:20 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s751ZJWZ004561 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407202521; bh=fTmPwYP+/jYoZltLyW++YTsM4tE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ilWzz7Hl8/e7lrf3AIDkaLx2uE2xrx7WJolUeJ6S6vgX4NxAhfTR8TeHrepZR4TFV s0yX33971/aWIPCGmCRP+2+f/Wn+5TBoWn869JKy0tTD4L1qpM+/rlAl8JHyGO52MJ 3D+fTLUKLticJ7x64XtaJajjt5O2jpPDOUSCvDqA= 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: <53DFD634.4020304@fud.no> Date: Mon, 4 Aug 2014 18:35:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Aug 2014 18:35:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4lSVjSFsnCOG0v8nmnpJxjoCshQ Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 01:39:32 -0000 On Aug 4, 2014, at 11:51 AM, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> I=92m copying Tore, because I think >> http://tools.ietf.org/html/draft-anderson-siit-dc might very well be >> that =93practical translation solution=94 for at least some = environments. >> For an enclosed environment such as a data center, it enables the >> implementation of an IPv6-only environment, maintains IPv4 access to >> it, and maintains geolocation capabilities across that translation. >> At the point where the business requirement for IPv4 accessibility >> falls off, the translator simply becomes a vestigial capability, as >> opposed to requiring a dramatic and costly change. That seems pretty >> attractive. I=92d invite discussion on that and on the draft (which = is >> long expired, but Tore could resurrect it as >> draft-anderson-v6ops-siit-dc if he wanted to). If it now has a >> consensus behind it, publish as an RFC. >=20 > Eerily good timing... I just started working on this again today, as = it > happens. What I'm looking at now is two drafts, the one that's already > there for a single-translation network-only implementation, plus = another > one describing an extension very similar to 464XLAT that would allow > NAT-incompatible and/or IPv4-only applications to be used in an > otherwise IPv6-only data centre. >=20 > However one of the things I was unsure about when I initially = submitted > the draft was which WG was the most appropriate (sunset4 or v6ops). > Following the off-list discussion you, Marc, and I had back in = November > 2013, I thought the conclusion was sunset4. But now I see you saying > v6ops, so, uhm, now I'm no more certain than I initially was... >=20 > I'm in two minds about it, myself. The draft doesn't really describe > IPv6 operations per se, it deals more with the minimal backwards > compatibility glue necessary to provide service to IPv4 only users. > Score 1 for sunset4. On the other hand, an operator that wants to do > IPv6 today absolutely must have some form of IPv4 compatibility glue = for > his offering to be commercially viable, thus, 1-1. I would argue it doesn=92t really fit either group, but there=92s no = place better to put it. Really, it=92s about v4-life-support, but there=92s on IPv4-Life-Support = working group. (perhaps there should be). To my thinking, sunset4 is really about what we need to do to get ready = to turn off IPv4. A technology for continuing IPv4 in a v6-dominant world = really doesn=92t fit that mission. OTOH, this really is about continuing IPv4 operations, not v6ops, so it = doesn=92t fit that charter well, either. Of the two, I think it belongs more in v6ops than sunset4, simply = because it really has little (nothing) to do with getting rid of IPv4 and is the = opposite, if anything. Owen From nobody Mon Aug 4 19:09: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 BF94C1A0B07 for ; Mon, 4 Aug 2014 19:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, 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 NwgAGogXAS_I for ; Mon, 4 Aug 2014 19:09:06 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A4C6A1A0AFB for ; Mon, 4 Aug 2014 19:09:05 -0700 (PDT) Received: from [192.168.1.62] (ip72-199-16-177.sd.sd.cox.net [72.199.16.177]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s7527PIF006559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 19:07:27 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s7527PIF006559 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407204447; bh=RtAlDfvyGFPQlL/WzQGNTb4eEek=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ymqg1lIjrc5xWqTBpso64sFBLGQwj68bWDtrtph7FshyuzbqhvZoouXak5GtFjd8i 7eeM5EOE6yjmpsZvnMaLlaBF36rc70RR0OU0K/TkF8/iegFDz7mt1FQJUblsbXckor 94YHrDjd4ZHeZBsfwCQasIjoG3DpsTcOiyMelKio= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> Date: Mon, 4 Aug 2014 19:07:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <730B6260-C217-4927-AB68-9EBEDFDE9326@delong.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Aug 2014 19:07:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RHzlQJm-VLiYzzDPl8plye3m09I Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 02:09:07 -0000 On Aug 4, 2014, at 4:11 PM, Mark Andrews wrote: >=20 > In message <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com>, "Fred = Baker (fred) > " writes: >>=20 >> The alternative is where Microsoft Azure finds itself now. They are = out >> of IPv4 address space and do not have a publicly announced IPv6 = service. >> To fill the gap, they are moving address space from Brazil to the US. >> Now, lest someone think I'm slamming them, I have little doubt that = they >> have a long term plan; it's just not in evidence at the moment. But = where >> they stand, if they don't have a plan, they're screwed. They are only = the >> most public of a long list of companies with that problem... >=20 > Azure would still need the IPv4 addresses because the rest of the > world as a whole has not moved to IPv6 yet. While datacenters may > be able to move to IPv6 only internally there is still a external > need for IPv4 addresses. IPv6 only gives some IPv4 address saving > but not that much on the server side. We are still a long way from > turning off IPv4 servers. We may be a long way from turning the existing ones off. The address situation seems to suggest we may not be all that far from = not turning on very many more new ones, however. Owen From nobody Mon Aug 4 19:09: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 42B181A0B03 for ; Mon, 4 Aug 2014 19:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, 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 OC5K0KWt9qFF for ; Mon, 4 Aug 2014 19:09:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EDD051A0B0C for ; Mon, 4 Aug 2014 19:09:12 -0700 (PDT) Received: from [192.168.1.62] (ip72-199-16-177.sd.sd.cox.net [72.199.16.177]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s7528r0C006664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 19:08:54 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s7528r0C006664 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407204535; bh=bXxjQTw8Is5Bm6zfSOu6535Ox9g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=46/5i2P4DlVQDjuGzznaXlX4tFtmphp7LhHYf2tkIeaqknUWkj8RfjqWsDNzKqJ0E i40LKKMGP6ybgbkWCstnmCyXR+J+wiv0JPAmcjwc1EorVbHPwG3LM047bFqPhrOyc5 1SRZjTVDPHsbVp2rzKnI/wxdcy6/8CD/wsbBt9cU= 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: Date: Mon, 4 Aug 2014 19:08:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Aug 2014 19:08:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VGLSp7ydU3A0f8eDh6S7Ha0B4Q8 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 02:09:14 -0000 On Aug 4, 2014, at 4:20 PM, Fred Baker (fred) wrote: >=20 > On Aug 4, 2014, at 4:11 PM, Mark Andrews wrote: >=20 >> Azure would still need the IPv4 addresses because the rest of the >> world as a whole has not moved to IPv6 yet. While datacenters may >> be able to move to IPv6 only internally there is still a external >> need for IPv4 addresses. IPv6 only gives some IPv4 address saving >> but not that much on the server side. We are still a long way from >> turning off IPv4 servers. >=20 > That=92s sort of the point of Tore=92s document, with the exception = that you can indeed move IPv4 addresses to *only* the edge using his = mechanism. >=20 > That said, if you have an IPv6-capable data center and are selling it = as a service to customers, that gives you a vehicle to discuss IPv6 with = the customers. =93I have a scarce resource that I can charge you for, = and a plentiful resource I can charge you for. Which would you like to = be charged for?=94 FWIW, Hurricane Electric charges for IPv4. We do not charge for IPv6. We = apply ARIN compliant needs tests to all North American customer = allocations/assignments and appropriate RIPE/APNIC criteria in those = regions. Owen From nobody Mon Aug 4 20:10: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 63FA81B278F for ; Mon, 4 Aug 2014 20:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtCu1dlgtK0n for ; Mon, 4 Aug 2014 20:09:58 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021F31B27A1 for ; Mon, 4 Aug 2014 20:09:57 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so508987wiv.15 for ; Mon, 04 Aug 2014 20:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PtXqyKFOIT3OTZ4AMjKmsTzgLJ2qe+73XF7/M8FxZTM=; b=S0Gk9J++kkuM2LZSQxE/OvpYLAci7r+p1GzoZQdUt8nwM9yCpD6onE79HZKEMww2Kb 9Hxd5KdnGOGYjEvnHuecBXphmA8pBwxOJVHCGuLmioAD58fHMPyrmcSFIxd2Yct1x7eP AUodXTdLfh6t+3KOE5eeZcpl4GEDaTpNvoXkgyeGsYz/ZlYZav1s+PM0/bhABYZQl8h9 +NKOWeIi/g6qgc8LvoMzZAGDA1lrqNEvmI5KkLCjmyVgmFw128WWywP/MiiekcXuZxdv P6FoB+pqpXi0ewhFAiUETvzgqE9DkSyO2rhO+NZTXOFCq6gQfwrLMAQf3y1XqWxNO5Qi UK1A== MIME-Version: 1.0 X-Received: by 10.194.222.197 with SMTP id qo5mr1420011wjc.78.1407208196402; Mon, 04 Aug 2014 20:09:56 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:09:56 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:09:56 -0700 (PDT) In-Reply-To: <53DFEC6C.3010707@gmail.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> Date: Mon, 4 Aug 2014 20:09:56 -0700 Message-ID: From: Ca By To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c3a99aabf50b04ffd9304b Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Lv1ME_EqhcBHXTviCp5GiPs5LVY Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 03:10:00 -0000 --001a11c3a99aabf50b04ffd9304b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Aug 4, 2014 1:26 PM, "Brian E Carpenter" wrote: > > > > My point in bringing this up is not that it is =E2=80=9Cuseful in an IP= v6 network=E2=80=9D that might also be running IPv4 in parallel. It is that it= seems useful to me in moving toward and IPv6-*only* network. Ross suggests that he sees conceptual movement - First they ignore you, then they laugh at you, then they fight you, and then you win. We may, Ross suggests, be approaching stage 4. It may be useful for us as a working group to lay out the game plan for that movement - not just to document IPv6 operational practice, but to help the IETF determine whether the dual stack consensus has changed or is changing, and help operators figure out how to turn IPv4 off without individually shooting their toes off. This would be part of that game plan. > > Well, I think the operators that moved early into genuine dual > stack operation have no reason to regret it. I'm a happy customer > of one such. On the other hand it seems that other operators are of > the opinion (probably unprovable) that providing the illusion of dual > stack service to the customer over an IPv6 infrastructure is cheaper. > In any case the customer ends up with NATted IPv4 service in most > cases, so at user level it doesn't really matter. > > I think we should probably not express a preference either way. It > seems like a decision for each operator to make individually. What we > probably should do is stop inventing more solutions. > Why? I was told the same thing about 464xlat, we did not need another solution. If the ietf held the line against double translation i believe there would be exactly 1 ipv6 cellular provider in the world (verizon). With 464xlat, afaik, there are globally 3 cellular providers that offer default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ). It does not matter if the cat is white or black, it matters that it catches mice. CB > (In parenthesis, I've never seen sunsetting IPv4 as a real problem. > One day somebody will notice that there are no more IPv4 packets. But > that is many years in the future.) > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a11c3a99aabf50b04ffd9304b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 4, 2014 1:26 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
>
> > My point in bringing this up is not that it is =E2=80=9Cuseful in= an IPv6 network=E2=80=9D that might also be running IPv4 in parallel. It i= s that it seems useful to me in moving toward and IPv6-*only* network. Ross= suggests that he sees conceptual movement - First they ignore you, then th= ey laugh at you, then they fight you, and then you win. We may, Ross sugges= ts, be approaching stage 4. It may be useful for us as a working group to l= ay out the game plan for that movement - not just to document IPv6 operatio= nal practice, but to help the IETF determine whether the dual stack consens= us has changed or is changing, and help operators figure out how to turn IP= v4 off without individually shooting their toes off. This would be part of = that game plan.
>
> Well, I think the operators that moved early into genuine dual
> stack operation have no reason to regret it. I'm a happy customer<= br> > of one such. On the other hand it seems that other operators are of > the opinion (probably unprovable) that providing the illusion of dual<= br> > stack service to the customer over an IPv6 infrastructure is cheaper.<= br> > In any case the customer ends up with NATted IPv4 service in most
> cases, so at user level it doesn't really matter.
>
> I think we should probably not express a preference either way. It
> seems like a decision for each operator to make individually. What we<= br> > probably should do is stop inventing more solutions.
>

Why?

I was told the same thing about 464xlat, we did not need ano= ther solution. If the ietf held the line against double translation i belie= ve there would be exactly 1 ipv6 cellular provider in the world (verizon).<= /p>

With 464xlat, afaik, there are globally 3 cellular providers= that offer default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ)= .

It does not matter if the cat is white or black, it matters = that it catches mice.=C2=A0

CB

> (In parenthesis, I've never seen sunsetting IPv4 as= a real problem.
> One day somebody will notice that there are no more IPv4 packets. But<= br> > that is many years in the future.)
>
> =C2=A0 =C2=A0 Brian
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a11c3a99aabf50b04ffd9304b-- From nobody Mon Aug 4 20: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 0F9821B27D8 for ; Mon, 4 Aug 2014 20:25:21 -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 3r73Dhzv36Wv for ; Mon, 4 Aug 2014 20:25:19 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30B51B27B9 for ; Mon, 4 Aug 2014 20:25:18 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so496571pdb.17 for ; Mon, 04 Aug 2014 20:25:18 -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=tMawuvCvMZEkWNGEQaCzXUwN8xyN3ppvwmEhAVDsFXQ=; b=beWPwUd7ut0LqlAFDDY4JTJ83AAvsrQpGAJv8j7V7EmF6be4SdgAPZM3C5s9MBv4jJ p0WpQMF5Vc9WTi6lVXjpw6Z+KQAc/TLYIUR34jlm0M3HrJlA37mHS7c6RdSJbnFTtPFO WNvFn3Msu8cLiQIkLAy6u73EW2oOmwOQ+sOPSdouuEVvs2VQUCrtUL5jjUcYh1Abye8o DhbNS0d/ZsTcr7Pyd+D0DRlO3OCwE16i0gJFiIFE0EnxYkb6X5qZ8xe50xawV+FdV+O8 ujD+6kGb8uclmNv1H7PSFCe3RcX6fX3ztGRUsbVQpqyAk5/yCUCJPtK7iWcdhd5j5XSK h/FQ== X-Received: by 10.70.50.230 with SMTP id f6mr1053470pdo.84.1407209118508; Mon, 04 Aug 2014 20:25:18 -0700 (PDT) Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id oy12sm336310pbb.27.2014.08.04.20.25.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 20:25:17 -0700 (PDT) Message-ID: <53E04E9D.6060302@gmail.com> Date: Tue, 05 Aug 2014 15:25:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ca By References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wIZeIeDc9gB_lrO28i56-VnWsKI Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 03:25:21 -0000 On 05/08/2014 15:09, Ca By wrote: > On Aug 4, 2014 1:26 PM, "Brian E Carpenter" > wrote: >> >>> My point in bringing this up is not that it is =E2=80=9Cuseful in an = IPv6 > network=E2=80=9D that might also be running IPv4 in parallel. It is tha= t it seems > useful to me in moving toward and IPv6-*only* network. Ross suggests th= at > he sees conceptual movement - First they ignore you, then they laugh at= > you, then they fight you, and then you win. We may, Ross suggests, be > approaching stage 4. It may be useful for us as a working group to lay = out > the game plan for that movement - not just to document IPv6 operational= > practice, but to help the IETF determine whether the dual stack consens= us > has changed or is changing, and help operators figure out how to turn I= Pv4 > off without individually shooting their toes off. This would be part of= > that game plan. >> Well, I think the operators that moved early into genuine dual >> stack operation have no reason to regret it. I'm a happy customer >> of one such. On the other hand it seems that other operators are of >> the opinion (probably unprovable) that providing the illusion of dual >> stack service to the customer over an IPv6 infrastructure is cheaper. >> In any case the customer ends up with NATted IPv4 service in most >> cases, so at user level it doesn't really matter. >> >> I think we should probably not express a preference either way. It >> seems like a decision for each operator to make individually. What we >> probably should do is stop inventing more solutions. >> >=20 > Why? >=20 > I was told the same thing about 464xlat, we did not need another soluti= on. > If the ietf held the line against double translation i believe there wo= uld > be exactly 1 ipv6 cellular provider in the world (verizon). >=20 > With 464xlat, afaik, there are globally 3 cellular providers that offer= > default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ). OK, but beyond a certain point vendors will want to stop adding options and operators will want finite choices. We must be very close to that poi= nt now. > It does not matter if the cat is white or black, it matters that it cat= ches > mice. The pragmatist in me agrees with you. The former software team leader in me is stressed out with the choices. Brian >=20 > CB >=20 >> (In parenthesis, I've never seen sunsetting IPv4 as a real problem. >> One day somebody will notice that there are no more IPv4 packets. But >> that is many years in the future.) >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Aug 4 20:44: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 EE51E1B2803 for ; Mon, 4 Aug 2014 20:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFW6wZkiiPNs for ; Mon, 4 Aug 2014 20:44:42 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6639F1B2801 for ; Mon, 4 Aug 2014 20:44:42 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so320480wgh.18 for ; Mon, 04 Aug 2014 20:44: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=JfDnzKf3GnstxeCuoi/ZRtthDQViIpnvOi6CMBcicsw=; b=O74zq6Zc8IgqSBD93oL7GVXquP8a8FjptU+LxHmDJ/Gsj9jgl4VfnSKs1eW1P0LPH0 4peGV6ufxkZiTWI9uCaKXrZJ0PVP8rtZL3lPKTbqJaZzuzxeuhxH1jYrjqqd1ZTyIc4j vdM1NW2WRi8IvuR24aoOVbxTdfD9FgrDfirduVBFuju8PfSd8yhWNA7xLg3DY0yzAuUI uPm//RMfh5e17pWa1lH0F7rGviecdKPvfiYcsm3/69112JsL/zYLdfjCn+sUiph65wmR UXjG6tlEgXLBpd0JORBJ37dBliMMqTeGxeDwUDNd/pk8bkfxB2I9PLwEJaKGgWy/wScB 09TA== MIME-Version: 1.0 X-Received: by 10.180.187.141 with SMTP id fs13mr2464623wic.57.1407210280890; Mon, 04 Aug 2014 20:44:40 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:44:40 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:44:40 -0700 (PDT) In-Reply-To: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> Date: Mon, 4 Aug 2014 20:44:40 -0700 Message-ID: From: Ca By To: Fred Baker Content-Type: multipart/alternative; boundary=001a11c381e4eab63f04ffd9acb2 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IVn9a0Rzq40nvKUcWZqixYtRDmw Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 03:44:44 -0000 --001a11c381e4eab63f04ffd9acb2 Content-Type: text/plain; charset=UTF-8 Allow me to posit that the locus of internet growth is cloud, IoT, and mobile. Growth areas are important because they drive ip address demand. Public IPv4 as a unique host ID is dead and will never be used natively in these high growth edge networks. Cloud is near 100% nat, the public address is abstracted from the host. Look at AWS, they dont have a product that gives machines a public ip address from AWS of any sort at any cost. It is all NAT. My guess and Azure and Google are similar, but i dont know. IoT -- simply cant scale on ipv4. Mobile -- always has been ipv4 nat in most places, and now approaching all places. Even in old world DSL broadband like AT&T DSL, layer 2.75 is private ipv4 that moves the 6RD end to end on top. The bigger question is -- who thinks real public dual-stack on every node is viable for the timescale the ietf or edge network engineering operates at? Not T-Mobile US, not facebook, not at&t , not Amazon AWS, not Terastream. All these networks run at least 1 stack virtually (or relayed/proxied) and i doubt they see a path to real dual-stack. The better ietf i-d i would like to read is a post-mortem on why dual-stack failed in edge networks and what the ietf can learn from this failure. It likely has an economic and psychological theme. Don't get me wrong, the utopian dream of everyone turning ipv6 on over some period of time and ipv4 slipping off unnoticed into the sunset is great... But clearly just a dream. It did not and will not happen. The history of ipv6 transition will not involve a distinct period of time where a public ipv4 and ipv6 dual-stack internet happened. CB --001a11c381e4eab63f04ffd9acb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Allow me to posit that the locus of internet growth is cloud= , IoT, and mobile. Growth areas are important because they drive ip address= demand. Public IPv4 as a unique host ID is dead and will never be used nat= ively in these high growth edge networks.

Cloud is near 100% nat, the public address is abstracted fro= m the host. Look at AWS, they dont have a product that gives machines a pub= lic ip address from AWS of any sort at any cost. It is all NAT.=C2=A0 My gu= ess and Azure and Google are similar, but i dont know.

IoT -- simply cant scale on ipv4.

Mobile -- always has been ipv4 nat in most places, and now a= pproaching all places.

Even in old world DSL broadband like AT&T DSL, layer 2.7= 5 is private ipv4 that moves the 6RD end to end on top.

The bigger question is -- who thinks real=C2=A0 public dual-= stack on every node is viable for the timescale the ietf or edge network en= gineering operates at?=C2=A0 Not T-Mobile US, not facebook, not at&t , = not Amazon AWS, not Terastream. All these networks run at least 1 stack vir= tually (or relayed/proxied) and i doubt they see a path to real dual-stack.=

The better ietf i-d i would like to read is a post-mortem on= why dual-stack failed in edge networks and what the ietf can learn from th= is failure.=C2=A0 It likely has an economic and psychological theme.

Don't get me wrong, the utopian dream of everyone turnin= g ipv6 on over some period of time and ipv4 slipping off unnoticed into the= sunset is great... But clearly just a dream. It did not and will not happe= n.

The history of ipv6 transition will not involve a distinct p= eriod of time where a public ipv4 and ipv6 dual-stack internet happened.

CB

--001a11c381e4eab63f04ffd9acb2-- From nobody Mon Aug 4 20:59: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 CC3D21B280E for ; Mon, 4 Aug 2014 20:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3CCOn8hMJjW for ; Mon, 4 Aug 2014 20:59:46 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52451B2807 for ; Mon, 4 Aug 2014 20:59:45 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so6211693wib.2 for ; Mon, 04 Aug 2014 20:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AmQEVJIZI0M/p9vqzShvWJDvra+Kh53dA7U+NFr+eAw=; b=MPO9HTA1dKi3kb2uPA/NDHYrpCEI2mXTTDqVszlcVx1Dhww7vY8xaRIR3CagYQvrgD vlbE/rAkL1g8RErkWYgiRWLk6EFY0libi1CYOW8htm46bvqULZQecSSnTjWMdLUeqSC+ F3WkROfcOwZQ+DkeLq1HKf5MFA7RN47EWgkqZtshXlsNCQeWrYcaRTleRPnTME7fDnYM 6n/0GMdBO71rG6T+3opIHQZIS/C57JpjHhob9+KWQATjIHPJsv0QS0cIz/Fabea3zDaH g0A9fXxEu0vyFKdZiNCu7cA7wV4qurrv5jSSNWml/8cxikpOg6ugOcnJ97AFq2yAFWT8 e9nw== MIME-Version: 1.0 X-Received: by 10.180.187.141 with SMTP id fs13mr2541033wic.57.1407211184442; Mon, 04 Aug 2014 20:59:44 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:59:44 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:59:44 -0700 (PDT) In-Reply-To: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <28BBAD81-F9FE-43EB-BF49-E5B85C2AB218@cisco.com> <20140804231151.AAAEF1B7AB9F@rock.dv.isc.org> Date: Mon, 4 Aug 2014 20:59:44 -0700 Message-ID: From: Ca By To: Fred Baker Content-Type: multipart/alternative; boundary=001a11c381e4c5d51d04ffd9e27c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TsVnUd2dF7L8e9P-uur6S7TNNmc Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 03:59:48 -0000 --001a11c381e4c5d51d04ffd9e27c Content-Type: text/plain; charset=UTF-8 On Aug 4, 2014 8:44 PM, "Ca By" wrote: > > Allow me to posit that the locus of internet growth is cloud, IoT, and mobile. Growth areas are important because they drive ip address demand. Public IPv4 as a unique host ID is dead and will never be used natively in these high growth edge networks. > > Cloud is near 100% nat, the public address is abstracted from the host. Look at AWS, they dont have a product that gives machines a public ip address from AWS of any sort at any cost. It is all NAT. My guess and Azure and Google are similar, but i dont know. > > IoT -- simply cant scale on ipv4. > > Mobile -- always has been ipv4 nat in most places, and now approaching all places. > > Even in old world DSL broadband like AT&T DSL, layer 2.75 is private ipv4 that moves the 6RD end to end on top. > > The bigger question is -- who thinks real public dual-stack on every node is viable for the timescale the ietf or edge network engineering operates at? Not T-Mobile US, not facebook, not at&t , not Amazon AWS, not Terastream. All these networks run at least 1 stack virtually (or relayed/proxied) and i doubt they see a path to real dual-stack. > > The better ietf i-d i would like to read is a post-mortem on why dual-stack failed in edge networks and what the ietf can learn from this failure. It likely has an economic and psychological theme. > > Don't get me wrong, the utopian dream of everyone turning ipv6 on over some period of time and ipv4 slipping off unnoticed into the sunset is great... But clearly just a dream. It did not and will not happen. > > The history of ipv6 transition will not involve a distinct period of time where a public ipv4 and ipv6 dual-stack internet happened. > > CB Obligatory cross domain reference, although my wife says this theory is bogus and gets angry when i bring it up http://en.m.wikipedia.org/wiki/Punctuated_equilibrium --001a11c381e4c5d51d04ffd9e27c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 4, 2014 8:44 PM, "Ca By" <cb.list6@gmail.com> wrote:
>
> Allow me to posit that the locus of internet growth is cloud, IoT, and= mobile. Growth areas are important because they drive ip address demand. P= ublic IPv4 as a unique host ID is dead and will never be used natively in t= hese high growth edge networks.
>
> Cloud is near 100% nat, the public address is abstracted from the host= . Look at AWS, they dont have a product that gives machines a public ip add= ress from AWS of any sort at any cost. It is all NAT.=C2=A0 My guess and Az= ure and Google are similar, but i dont know.
>
> IoT -- simply cant scale on ipv4.
>
> Mobile -- always has been ipv4 nat in most places, and now approaching= all places.
>
> Even in old world DSL broadband like AT&T DSL, layer 2.75 is priva= te ipv4 that moves the 6RD end to end on top.
>
> The bigger question is -- who thinks real=C2=A0 public dual-stack on e= very node is viable for the timescale the ietf or edge network engineering = operates at?=C2=A0 Not T-Mobile US, not facebook, not at&t , not Amazon= AWS, not Terastream. All these networks run at least 1 stack virtually (or= relayed/proxied) and i doubt they see a path to real dual-stack.
>
> The better ietf i-d i would like to read is a post-mortem on why dual-= stack failed in edge networks and what the ietf can learn from this failure= .=C2=A0 It likely has an economic and psychological theme.
>
> Don't get me wrong, the utopian dream of everyone turning ipv6 on = over some period of time and ipv4 slipping off unnoticed into the sunset is= great... But clearly just a dream. It did not and will not happen.
>
> The history of ipv6 transition will not involve a distinct period of t= ime where a public ipv4 and ipv6 dual-stack internet happened.
>
> CB

Obligatory cross domain reference, although my wife says thi= s theory is bogus and gets angry when i bring it up

http://en.m.wikipedia.org/wiki/Punctuated_equilibrium

--001a11c381e4c5d51d04ffd9e27c-- From nobody Mon Aug 4 22:14: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 54ECC1B2848 for ; Mon, 4 Aug 2014 22:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY_Hk4j3U63T for ; Mon, 4 Aug 2014 22:14:27 -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 DEDF21B2841 for ; Mon, 4 Aug 2014 22:14:26 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=48772 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 1XEX4m-0006Bo-2h; Tue, 05 Aug 2014 07:14:20 +0200 Message-ID: <53E067DB.2000401@fud.no> Date: Tue, 05 Aug 2014 07:12:59 +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: Owen DeLong References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6BG7jFLxJm6hnM-9SJ_399A2Y-0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 05:14:30 -0000 * Owen DeLong > To my thinking, sunset4 is really about what we need to do to get > ready to turn off IPv4. A technology for continuing IPv4 in a > v6-dominant world really doesn’t fit that mission. The thing is that it allows an operator to completely turn of IPv4 in 99%+ of his infrastructure. All the network components inside the data centre, all the servers, all the software applications...here we're talking about tens of thousands of individual things, overall, and we're not even a particularly big shop. In contrast, the number of SIIT gateways we need you can count on one hand. So for me, it is really about turning off IPv4 - to the extent possible in today's IPv4-dominated Internet, leaving only behind the absolute minimum necessary, in an as optional role as possible (i.e., shutting it down won't impact the application stacks or service availability over IPv6). > OTOH, this really is about continuing IPv4 operations, not v6ops, so > it doesn’t fit that charter well, either. Yep, that's what I was thinking too. The draft doesn't really discuss the running IPv6 part, it just assumes that that's in place to begin with. Though, the same could be said for 464XLAT, and that was done in v6ops. Tore From nobody Mon Aug 4 22:26: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 B230C1B2893 for ; Mon, 4 Aug 2014 22:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVCJxDE1FC85 for ; Mon, 4 Aug 2014 22:26:52 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EDF1A011E for ; Mon, 4 Aug 2014 22:26:51 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=48913 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 1XEXGs-0006Ub-0F; Tue, 05 Aug 2014 07:26:50 +0200 Message-ID: <53E06AC9.9010908@fud.no> Date: Tue, 05 Aug 2014 07:25:29 +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: Ca By , Brian E Carpenter References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NfmT9z3mkoTlWNO7aCluRj9-n7Y Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 05:26:53 -0000 * Ca By > With 464xlat, afaik, there are globally 3 cellular providers that offer > default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ). Make that four, Telenor Norway has been doing IPv6-only/NAT64/464XLAT since early June. http://www.telenor.no/privat/kundeservice/mobilhjelp/internettpamobilen/feilsokingmmsoginternett.jsp So far only one model (Samsung S5) defaults to the new IPv6-only APN, but from what I hear they'll keep adding new models and push OTA updates to other existing ones. * Brian E Carpenter >> (In parenthesis, I've never seen sunsetting IPv4 as a real problem. >> One day somebody will notice that there are no more IPv4 packets. But >> that is many years in the future.) The thing is, if you've built your infrastructure on IPv4, removing it is going to be a royal pain in the arse. Even if all the IPv4 users have left the public internet, if your application server speaks to your database server over IPv4, and the database server speaks to the iSCSI array over IPv4, and so on and so on, then you're simply not in a position to easily shut IPv4 off. Tore From nobody Mon Aug 4 23:03: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 D236E1B2865 for ; Mon, 4 Aug 2014 23:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhJ3uV0SUE-c for ; Mon, 4 Aug 2014 23:03:15 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8980F1B2839 for ; Mon, 4 Aug 2014 23:03:15 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 88D19608E1 for ; Tue, 5 Aug 2014 08:03:12 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 44CB0608CB for ; Tue, 5 Aug 2014 08:03:12 +0200 (CEST) Received: (qmail 81906 invoked by uid 1007); 5 Aug 2014 08:03:12 +0200 Date: Tue, 5 Aug 2014 08:03:12 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20140805060312.GW51793@Space.Net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53DFEC6C.3010707@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AXqr0V2UvUpYwOHyU2W6BTMIdew Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 06:03:18 -0000 Hi, On Tue, Aug 05, 2014 at 08:26:20AM +1200, Brian E Carpenter wrote: > (In parenthesis, I've never seen sunsetting IPv4 as a real problem. > One day somebody will notice that there are no more IPv4 packets. But > that is many years in the future.) Well, at some point you have to decide to no longer provision IPv4 on new services, turn off IPv4 on existing services, stop the dual monitoring needed for IPv4+IPv6 infrastructure, etc. - so "IPv4 just stops being there" isn't going to cut it for operators :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Aug 5 00:15: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 21BBE1A032A for ; Tue, 5 Aug 2014 00:15:47 -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_74=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 jxfHdK-i_hYo for ; Tue, 5 Aug 2014 00:15:45 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBF91A017D for ; Tue, 5 Aug 2014 00:15:45 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so377537lbi.39 for ; Tue, 05 Aug 2014 00:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zC/2BQ2pJDnXimc85klUdThVNvd48Mfr8OsIDAt0HJg=; b=HedbPwGntMtH+j7WDVAx7vSLGNOW39U3HXD2JWxBqYFpRzJh6N1fkLC5kc2Fvy0UIV db4fikDayzt3tQ9WR7S/yhDmc1Bk+L1YcjIdpLBFg5D8eOGqhvPYI+oslAcEMVPq8XYH 9Lk3pv8caj3K+J0k6CnU5OBvOdXpQd6DTAM1/2CHDvstDQQ5Wxcv6KM+Qa+LeQSmWjAU 9NqAW5LAemKym0iRy2fpfBxGZP2m0TG1pEW5b+ff7HDXRkpM9ChCukEqgW1JKt5fr/R3 InxS++WYySRcylFoCRRyLOhPNjNZAl3D2nHVB/oynTvWAUlwUKZbljUcO9uxoG7KFAu5 CSrQ== X-Received: by 10.112.34.78 with SMTP id x14mr1854259lbi.38.1407222943600; Tue, 05 Aug 2014 00:15:43 -0700 (PDT) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id ue8sm469474lac.31.2014.08.05.00.15.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 00:15:42 -0700 (PDT) Message-ID: <53E0849C.9020208@gmail.com> Date: Tue, 05 Aug 2014 10:15:40 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ross Chandler , v6ops@ietf.org References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> In-Reply-To: <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5JPc6zzzsDD9SJmUjRD9rAzDM9g Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis 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: Tue, 05 Aug 2014 07:15:47 -0000 The HLR I used allowed quite a bit of configuration regarding this topic: o PDP Types IPv4, IPv6 and IPv4v6 could all have the same APN for the subscriber o IPv6 could be disabled per PLMN basis Some of these cases were briefly elaborated in Section 8.5 of RFC6459. - Jouni 7/30/2014 1:14 AM, Ross Chandler kirjoitti: > > On 29 Jul 2014, at 06:10, Mikael Abrahamsson > wrote: > >> On Tue, 29 Jul 2014, GangChen wrote: >> >>> Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support >>> IPv4v6 setting(that is the most case pre-R9), in other words, it can't >>> set ext_pdp. It may not able to support all cases. >> >> Then I guess it's a matter of implementation. The HLR I was exposed >> to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type >> IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If >> UE asked for IPv6 only PDP context that didn’t work, so we had to add >> a profile that said "IPv6" without ext_pdp_context_type. > > We have to define two allowed PDP Types for the same APN, so that legacy > IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same APN. > > e.g. > > HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA > PDPCP APNID EQOSID VPAA PDPCH PDPTY PDPID EPDPIND > 240 80 1 NO IPV4 25 NO > 76 1 NO IPV4 26 NO > 74 1 NO IPV4 31 NO > 73 1 NO IPV4 32 NO <-- testdata APN V4 > 73 1 NO IPV6 50 NO <-- testdata APN V6 > > If the Android UE APN Protocol is set to “IPv4/IPv6” with this it sets > up parallel bearers to the GGSN/PGW. > > I agree with Mikael that it might be worth having a section noting this > behaviour. An operator doing 464xlat could have UEs connecting with > dual-stack done over separate bearers when they’d prefer it to either be > single bearer with legacy IPv4 or IPv6 with 464xlat. This applies in > the home and roaming case. > > Ross > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Aug 5 00:20: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 901D01B28D7 for ; Tue, 5 Aug 2014 00:20:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwqEYkdtgrAQ for ; Tue, 5 Aug 2014 00:20:28 -0700 (PDT) Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by ietfa.amsl.com (Postfix) with SMTP id 9EA711B2877 for ; Tue, 5 Aug 2014 00:20:26 -0700 (PDT) Received: (qmail 24470 messnum 5467988 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 5 Aug 2014 07:20:23 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail01.svc.cra.dublin.eircom.net (qp 24470) with SMTP; 5 Aug 2014 07:20:23 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id avLL1o00V0mJ9Tz01vLPpi; Tue, 05 Aug 2014 08:20:23 +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: Tue, 5 Aug 2014 08:20:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13BBB964-B83A-4721-AA31-68FCC8444AA0@eircom.net> References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/88Im3bGZhK1vegMrz3mMlI0jnGw Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 05 Aug 2014 07:20:31 -0000 On 4 Aug 2014, at 17:31, Mikael Abrahamsson wrote: > My opinion is not that any part of the standard is the problem, but = rather buggy implementations. Fair enough, whether through lazy/buggy implementations or a real gap, = the resulting network reality requires significantly most commitment to = IPv6 deployment from the mobile operator. We have to make a not particularly paletable choice because of it, = getting capex approval for spending on proprietary workarounds or deploy = only on Android. >> e.g. New HLR/HSS functionality to by default restrict the sending = PDP-Ext-Type/IPv4v6 with a whitelist of known good networks. Also the = complement the default allow sending of PDP-Ext-Type/IPv4v6 with a = network blacklist. >=20 > These are operational requriements, and I fully support putting them = in some kind of document, but the question is if it's really "roaming = analysis" anymore. The language would need to be very careful not to = make any recommendations then (?), but rather suggest possible ways of = working around the problems seen. Something like my above sentence could go into it as an observation. = Analysis=92s can have observations that stop short of being = recommendations. >> Section 7, discussions, says =93dual-stack deployment is recommended = in most cases=94. >> Is that still the consensus position? Going straight to single-stack = IPv6 is looking very viable now >> when the UE supports a method of providing translated IPv4 access = over the IPv6 PDP/PDN >> connection. >=20 > I don't think there is consensus here. The draft could point out pros = and cons with each approach. Fred has generalised the scope of my question beyond 3GPP with an agenda = for what might be required to update the consensus. I think the question = is too broad for this draft. Focusing on the mobile case, where there's near ubiquitous = RFC1918/RFC6598 use to get to the provider NAT44, replacing that with = IPv6 to get the legacy NAT64 gateway seems like such a compelling case = that the one size fits all dual-stack recommendation is no longer fit = for purpose. Ross=20= From nobody Tue Aug 5 02:23: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 8C3EB1B2999 for ; Tue, 5 Aug 2014 02:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.736 X-Spam-Level: ** X-Spam-Status: No, score=2.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, 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 cUpPulhsjr2f for ; Tue, 5 Aug 2014 02:22:53 -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 5E02E1B2983 for ; Tue, 5 Aug 2014 02:22:52 -0700 (PDT) Received: from 10.236.62.156 (EHLO OPE10HT08.tp.gk.corp.tepenet) ([10.236.62.156]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id BWK75850; Tue, 05 Aug 2014 11:22:47 +0200 (CEST) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: Ca By , Brian E Carpenter Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvAqKYAgAAE0ACAABWsAIAAcMQAgACEo7A= Date: Tue, 5 Aug 2014 09:21:52 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F85768@OPE10MB05.tp.gk.corp.tepenet> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_004_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_"; type="multipart/alternative" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.8.5.81820: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, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __EXTRA_MPART_TYPE_N1, __EXTRA_MPART_TYPE_1, __MIME_VERSION, __ANY_URI, __FRAUD_BODY_WEBMAIL, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __FORWARDED_MSG, __EMBEDDED_IMG, __HAS_HTML, SINGLE_IMG_ATTACH, BODY_SIZE_10000_PLUS, __PNG_WIDTH_100, __PNG_HEIGHT_100, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, MULTIPLE_RCPTS, __FRAUD_WEBMAIL X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0209.53E0A268.000C, 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.0A0C0209.53E0A268.000C, 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: 3b4cc769aff48891f03de6b30b037e7c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r2mUXLFdyCLDeuZl6mqPt1AS48c Cc: IPv6 Ops WG , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 09:22:59 -0000 --_004_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_ Content-Type: multipart/alternative; boundary="_000_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_" --_000_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGNvbmZpcm0gdGhpcyBpcyBjb3JyZWN0LiBFdmVuIHdlIHdlbnQgZnVydGhl ciBhbmQgd2UgZG8gbm90IHVzZSBETlM2NC4gT3VyIGFyY2hpdGVjdHVyZSBpcyBDTEFUK05BVDY0 K0ROUy4gU28gd2l0aCBkbnMgYW5kIHdpdGhvdXQgZG5zIGlwdjQgdHJhZmZpYyBhbHdheXMgZ29l cyB2aWEgQ0xBVC4gSXTigJlzIHBlcmZlY3Qgc29sdXRpb24g4pi6IFVLIEVFIHdpbGwgZG8gdGhl IHNhbWUuDQoNClNlZSBtb3JlIGF0OiBodHRwOi8vd3d3LmRhdGEucHJvaWRlYS5vcmcucGwvcGxu b2cvMTJlZHljamEvZGF5Mi90cmFjazQvMDFfaXB2Nl9pbXBsZW1lbnRhdGlvbi5wZGYNCg0KRXZl biB0cmlwbGUgdHJhbnNsYXRpb24gaXMgbm90IGJhZCB0b286IENMQVQrTkFUNjRzdGF0ZWxlc3Mr TkFUNDRzdGF0ZWZ1bGwuDQoNCkJSLA0KTWN6DQpPcmFuZ2UgUG9sYW5kDQoNCltjaWQ6aW1hZ2Uw MDEucG5nQDAxQ0ZCMDlGLjcyQzc1QjMwXQ0KRmVicnVhcnkgMSUgb2YgYWN0aXZlIFBEUCBJUHY2 IGN0eCwgbm93IG92ZXIgOCUNCg0KDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhIEJ5DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDUs IDIwMTQgNToxMCBBTQ0KVG86IEJyaWFuIEUgQ2FycGVudGVyDQpDYzogSVB2NiBPcHMgV0c7IFRv cmUgQW5kZXJzb24NClN1YmplY3Q6IFJlOiBbdjZvcHNdIE9wZXJhdGlvbmFsIENvbnNlbnN1cyBv biBkZXBsb3ltZW50DQoNCg0KT24gQXVnIDQsIDIwMTQgMToyNiBQTSwgIkJyaWFuIEUgQ2FycGVu dGVyIiA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4NCj4gPiBNeSBwb2ludCBpbiBicmluZ2luZyB0aGlz IHVwIGlzIG5vdCB0aGF0IGl0IGlzIOKAnHVzZWZ1bCBpbiBhbiBJUHY2IG5ldHdvcmvigJ0gdGhh dCBtaWdodCBhbHNvIGJlIHJ1bm5pbmcgSVB2NCBpbiBwYXJhbGxlbC4gSXQgaXMgdGhhdCBpdCBz ZWVtcyB1c2VmdWwgdG8gbWUgaW4gbW92aW5nIHRvd2FyZCBhbmQgSVB2Ni0qb25seSogbmV0d29y ay4gUm9zcyBzdWdnZXN0cyB0aGF0IGhlIHNlZXMgY29uY2VwdHVhbCBtb3ZlbWVudCAtIEZpcnN0 IHRoZXkgaWdub3JlIHlvdSwgdGhlbiB0aGV5IGxhdWdoIGF0IHlvdSwgdGhlbiB0aGV5IGZpZ2h0 IHlvdSwgYW5kIHRoZW4geW91IHdpbi4gV2UgbWF5LCBSb3NzIHN1Z2dlc3RzLCBiZSBhcHByb2Fj aGluZyBzdGFnZSA0LiBJdCBtYXkgYmUgdXNlZnVsIGZvciB1cyBhcyBhIHdvcmtpbmcgZ3JvdXAg dG8gbGF5IG91dCB0aGUgZ2FtZSBwbGFuIGZvciB0aGF0IG1vdmVtZW50IC0gbm90IGp1c3QgdG8g ZG9jdW1lbnQgSVB2NiBvcGVyYXRpb25hbCBwcmFjdGljZSwgYnV0IHRvIGhlbHAgdGhlIElFVEYg ZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGR1YWwgc3RhY2sgY29uc2Vuc3VzIGhhcyBjaGFuZ2VkIG9y IGlzIGNoYW5naW5nLCBhbmQgaGVscCBvcGVyYXRvcnMgZmlndXJlIG91dCBob3cgdG8gdHVybiBJ UHY0IG9mZiB3aXRob3V0IGluZGl2aWR1YWxseSBzaG9vdGluZyB0aGVpciB0b2VzIG9mZi4gVGhp cyB3b3VsZCBiZSBwYXJ0IG9mIHRoYXQgZ2FtZSBwbGFuLg0KPg0KPiBXZWxsLCBJIHRoaW5rIHRo ZSBvcGVyYXRvcnMgdGhhdCBtb3ZlZCBlYXJseSBpbnRvIGdlbnVpbmUgZHVhbA0KPiBzdGFjayBv cGVyYXRpb24gaGF2ZSBubyByZWFzb24gdG8gcmVncmV0IGl0LiBJJ20gYSBoYXBweSBjdXN0b21l cg0KPiBvZiBvbmUgc3VjaC4gT24gdGhlIG90aGVyIGhhbmQgaXQgc2VlbXMgdGhhdCBvdGhlciBv cGVyYXRvcnMgYXJlIG9mDQo+IHRoZSBvcGluaW9uIChwcm9iYWJseSB1bnByb3ZhYmxlKSB0aGF0 IHByb3ZpZGluZyB0aGUgaWxsdXNpb24gb2YgZHVhbA0KPiBzdGFjayBzZXJ2aWNlIHRvIHRoZSBj dXN0b21lciBvdmVyIGFuIElQdjYgaW5mcmFzdHJ1Y3R1cmUgaXMgY2hlYXBlci4NCj4gSW4gYW55 IGNhc2UgdGhlIGN1c3RvbWVyIGVuZHMgdXAgd2l0aCBOQVR0ZWQgSVB2NCBzZXJ2aWNlIGluIG1v c3QNCj4gY2FzZXMsIHNvIGF0IHVzZXIgbGV2ZWwgaXQgZG9lc24ndCByZWFsbHkgbWF0dGVyLg0K Pg0KPiBJIHRoaW5rIHdlIHNob3VsZCBwcm9iYWJseSBub3QgZXhwcmVzcyBhIHByZWZlcmVuY2Ug ZWl0aGVyIHdheS4gSXQNCj4gc2VlbXMgbGlrZSBhIGRlY2lzaW9uIGZvciBlYWNoIG9wZXJhdG9y IHRvIG1ha2UgaW5kaXZpZHVhbGx5LiBXaGF0IHdlDQo+IHByb2JhYmx5IHNob3VsZCBkbyBpcyBz dG9wIGludmVudGluZyBtb3JlIHNvbHV0aW9ucy4NCj4NCg0KV2h5Pw0KDQpJIHdhcyB0b2xkIHRo ZSBzYW1lIHRoaW5nIGFib3V0IDQ2NHhsYXQsIHdlIGRpZCBub3QgbmVlZCBhbm90aGVyIHNvbHV0 aW9uLiBJZiB0aGUgaWV0ZiBoZWxkIHRoZSBsaW5lIGFnYWluc3QgZG91YmxlIHRyYW5zbGF0aW9u IGkgYmVsaWV2ZSB0aGVyZSB3b3VsZCBiZSBleGFjdGx5IDEgaXB2NiBjZWxsdWxhciBwcm92aWRl ciBpbiB0aGUgd29ybGQgKHZlcml6b24pLg0KDQpXaXRoIDQ2NHhsYXQsIGFmYWlrLCB0aGVyZSBh cmUgZ2xvYmFsbHkgMyBjZWxsdWxhciBwcm92aWRlcnMgdGhhdCBvZmZlciBkZWZhdWx0IGlwdjYg KDQ2NHhsYXQgYXQgdG1vYmlsZSB1cyBhbmQgT3JhbmdlIFBMIGFuZCBEUyBhdCBWWikuDQoNCkl0 IGRvZXMgbm90IG1hdHRlciBpZiB0aGUgY2F0IGlzIHdoaXRlIG9yIGJsYWNrLCBpdCBtYXR0ZXJz IHRoYXQgaXQgY2F0Y2hlcyBtaWNlLg0KDQpDQg0KDQo+IChJbiBwYXJlbnRoZXNpcywgSSd2ZSBu ZXZlciBzZWVuIHN1bnNldHRpbmcgSVB2NCBhcyBhIHJlYWwgcHJvYmxlbS4NCj4gT25lIGRheSBz b21lYm9keSB3aWxsIG5vdGljZSB0aGF0IHRoZXJlIGFyZSBubyBtb3JlIElQdjQgcGFja2V0cy4g QnV0DQo+IHRoYXQgaXMgbWFueSB5ZWFycyBpbiB0aGUgZnV0dXJlLikNCj4NCj4gICAgIEJyaWFu DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== --_000_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5TdHlsd2lhZG9tb2NpZS1tYWlsMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uVGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0eWxlLW5hbWU6IlRl a3N0IGR5bWthIFpuYWsiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiVGVrc3QgZHlta2EiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpQTDt9DQpzcGFuLmhwcw0KCXttc28tc3R5bGUtbmFtZTpocHM7 fQ0Kc3Bhbi5zaG9ydHRleHQNCgl7bXNvLXN0eWxlLW5hbWU6c2hvcnRfdGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlBMIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTiI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+SSBjb25maXJtIHRoaXMgaXMg Y29ycmVjdC4gRXZlbiB3ZSB3ZW50IGZ1cnRoZXIgYW5kIHdlIGRvIG5vdCB1c2UgRE5TNjQuIE91 ciBhcmNoaXRlY3R1cmUgaXMgQ0xBVCYjNDM7TkFUNjQmIzQzO0ROUy4gU28gd2l0aCBkbnMgYW5k IHdpdGhvdXQgZG5zIGlwdjQgdHJhZmZpYyBhbHdheXMgZ29lcyB2aWEgQ0xBVC4gSXTigJlzIHBl cmZlY3Qgc29sdXRpb24NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OldpbmdkaW5ncyI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+IFVLIEVFIHdpbGwgZG8gdGhlIHNh bWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOIj5TZWUgbW9yZSBhdDogPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 YSBocmVmPSJodHRwOi8vd3d3LmRhdGEucHJvaWRlYS5vcmcucGwvcGxub2cvMTJlZHljamEvZGF5 Mi90cmFjazQvMDFfaXB2Nl9pbXBsZW1lbnRhdGlvbi5wZGYiPmh0dHA6Ly93d3cuZGF0YS5wcm9p ZGVhLm9yZy5wbC9wbG5vZy8xMmVkeWNqYS9kYXkyL3RyYWNrNC8wMV9pcHY2X2ltcGxlbWVudGF0 aW9uLnBkZjwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhwcyI+PHNwYW4gbGFuZz0iRU4iPkV2ZW48L3NwYW4+ PC9zcGFuPjxzcGFuIGNsYXNzPSJzaG9ydHRleHQiPjxzcGFuIGxhbmc9IkVOIj4NCjwvc3Bhbj48 L3NwYW4+PHNwYW4gY2xhc3M9ImhwcyI+PHNwYW4gbGFuZz0iRU4iPnRyaXBsZTwvc3Bhbj48L3Nw YW4+PHNwYW4gY2xhc3M9InNob3J0dGV4dCI+PHNwYW4gbGFuZz0iRU4iPg0KPC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0iaHBzIj48c3BhbiBsYW5nPSJFTiI+dHJhbnNsYXRpb248L3NwYW4+PC9z cGFuPjxzcGFuIGNsYXNzPSJzaG9ydHRleHQiPjxzcGFuIGxhbmc9IkVOIj4NCjwvc3Bhbj48L3Nw YW4+PHNwYW4gY2xhc3M9ImhwcyI+PHNwYW4gbGFuZz0iRU4iPmlzIG5vdCBiYWQgdG9vOiBDTEFU JiM0MztOQVQ2NHN0YXRlbGVzcyYjNDM7TkFUNDRzdGF0ZWZ1bGwuPC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPk1jejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5PcmFuZ2UgUG9sYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PGltZyBib3JkZXI9IjAiIHdpZHRoPSI2OTAiIGhlaWdodD0iMTM0IiBpZD0iT2JyYXpfeDAwMjBf MiIgc3JjPSJjaWQ6aW1hZ2UwMDEucG5nQDAxQ0ZCMDlGLjcyQzc1QjMwIj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZlYnJ1YXJ5IDElIG9mIGFjdGl2 ZSBQRFAgSVB2NiBjdHgsIG5vdyBvdmVyIDglPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Q2EgQnk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDA1 LCAyMDE0IDU6MTAgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIEUgQ2FycGVudGVyPGJyPg0KPGI+ Q2M6PC9iPiBJUHY2IE9wcyBXRzsgVG9yZSBBbmRlcnNvbjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3Y2b3BzXSBPcGVyYXRpb25hbCBDb25zZW5zdXMgb24gZGVwbG95bWVudDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHA+PGJyPg0KT24gQXVnIDQsIDIwMTQgMToyNiBQTSwgJnF1b3Q7QnJpYW4gRSBDYXJwZW50ZXIm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20iPmJy aWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyAmZ3Q7IE15IHBvaW50IGluIGJyaW5naW5nIHRoaXMgdXAgaXMgbm90IHRo YXQgaXQgaXMg4oCcdXNlZnVsIGluIGFuIElQdjYgbmV0d29ya+KAnSB0aGF0IG1pZ2h0IGFsc28g YmUgcnVubmluZyBJUHY0IGluIHBhcmFsbGVsLiBJdCBpcyB0aGF0IGl0IHNlZW1zIHVzZWZ1bCB0 byBtZSBpbiBtb3ZpbmcgdG93YXJkIGFuZCBJUHY2LSpvbmx5KiBuZXR3b3JrLiBSb3NzIHN1Z2dl c3RzIHRoYXQgaGUgc2VlcyBjb25jZXB0dWFsIG1vdmVtZW50IC0gRmlyc3QgdGhleQ0KIGlnbm9y ZSB5b3UsIHRoZW4gdGhleSBsYXVnaCBhdCB5b3UsIHRoZW4gdGhleSBmaWdodCB5b3UsIGFuZCB0 aGVuIHlvdSB3aW4uIFdlIG1heSwgUm9zcyBzdWdnZXN0cywgYmUgYXBwcm9hY2hpbmcgc3RhZ2Ug NC4gSXQgbWF5IGJlIHVzZWZ1bCBmb3IgdXMgYXMgYSB3b3JraW5nIGdyb3VwIHRvIGxheSBvdXQg dGhlIGdhbWUgcGxhbiBmb3IgdGhhdCBtb3ZlbWVudCAtIG5vdCBqdXN0IHRvIGRvY3VtZW50IElQ djYgb3BlcmF0aW9uYWwgcHJhY3RpY2UsDQogYnV0IHRvIGhlbHAgdGhlIElFVEYgZGV0ZXJtaW5l IHdoZXRoZXIgdGhlIGR1YWwgc3RhY2sgY29uc2Vuc3VzIGhhcyBjaGFuZ2VkIG9yIGlzIGNoYW5n aW5nLCBhbmQgaGVscCBvcGVyYXRvcnMgZmlndXJlIG91dCBob3cgdG8gdHVybiBJUHY0IG9mZiB3 aXRob3V0IGluZGl2aWR1YWxseSBzaG9vdGluZyB0aGVpciB0b2VzIG9mZi4gVGhpcyB3b3VsZCBi ZSBwYXJ0IG9mIHRoYXQgZ2FtZSBwbGFuLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlbGwsIEkgdGhp bmsgdGhlIG9wZXJhdG9ycyB0aGF0IG1vdmVkIGVhcmx5IGludG8gZ2VudWluZSBkdWFsPGJyPg0K Jmd0OyBzdGFjayBvcGVyYXRpb24gaGF2ZSBubyByZWFzb24gdG8gcmVncmV0IGl0LiBJJ20gYSBo YXBweSBjdXN0b21lcjxicj4NCiZndDsgb2Ygb25lIHN1Y2guIE9uIHRoZSBvdGhlciBoYW5kIGl0 IHNlZW1zIHRoYXQgb3RoZXIgb3BlcmF0b3JzIGFyZSBvZjxicj4NCiZndDsgdGhlIG9waW5pb24g KHByb2JhYmx5IHVucHJvdmFibGUpIHRoYXQgcHJvdmlkaW5nIHRoZSBpbGx1c2lvbiBvZiBkdWFs PGJyPg0KJmd0OyBzdGFjayBzZXJ2aWNlIHRvIHRoZSBjdXN0b21lciBvdmVyIGFuIElQdjYgaW5m cmFzdHJ1Y3R1cmUgaXMgY2hlYXBlci48YnI+DQomZ3Q7IEluIGFueSBjYXNlIHRoZSBjdXN0b21l ciBlbmRzIHVwIHdpdGggTkFUdGVkIElQdjQgc2VydmljZSBpbiBtb3N0PGJyPg0KJmd0OyBjYXNl cywgc28gYXQgdXNlciBsZXZlbCBpdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXIuPGJyPg0KJmd0Ozxi cj4NCiZndDsgSSB0aGluayB3ZSBzaG91bGQgcHJvYmFibHkgbm90IGV4cHJlc3MgYSBwcmVmZXJl bmNlIGVpdGhlciB3YXkuIEl0PGJyPg0KJmd0OyBzZWVtcyBsaWtlIGEgZGVjaXNpb24gZm9yIGVh Y2ggb3BlcmF0b3IgdG8gbWFrZSBpbmRpdmlkdWFsbHkuIFdoYXQgd2U8YnI+DQomZ3Q7IHByb2Jh Ymx5IHNob3VsZCBkbyBpcyBzdG9wIGludmVudGluZyBtb3JlIHNvbHV0aW9ucy48YnI+DQomZ3Q7 PG86cD48L286cD48L3A+DQo8cD5XaHk/IDxvOnA+PC9vOnA+PC9wPg0KPHA+SSB3YXMgdG9sZCB0 aGUgc2FtZSB0aGluZyBhYm91dCA0NjR4bGF0LCB3ZSBkaWQgbm90IG5lZWQgYW5vdGhlciBzb2x1 dGlvbi4gSWYgdGhlIGlldGYgaGVsZCB0aGUgbGluZSBhZ2FpbnN0IGRvdWJsZSB0cmFuc2xhdGlv biBpIGJlbGlldmUgdGhlcmUgd291bGQgYmUgZXhhY3RseSAxIGlwdjYgY2VsbHVsYXIgcHJvdmlk ZXIgaW4gdGhlIHdvcmxkICh2ZXJpem9uKS48bzpwPjwvbzpwPjwvcD4NCjxwPldpdGggNDY0eGxh dCwgYWZhaWssIHRoZXJlIGFyZSBnbG9iYWxseSAzIGNlbGx1bGFyIHByb3ZpZGVycyB0aGF0IG9m ZmVyIGRlZmF1bHQgaXB2NiAoNDY0eGxhdCBhdCB0bW9iaWxlIHVzIGFuZCBPcmFuZ2UgUEwgYW5k IERTIGF0IFZaKS48bzpwPjwvbzpwPjwvcD4NCjxwPkl0IGRvZXMgbm90IG1hdHRlciBpZiB0aGUg Y2F0IGlzIHdoaXRlIG9yIGJsYWNrLCBpdCBtYXR0ZXJzIHRoYXQgaXQgY2F0Y2hlcyBtaWNlLiZu YnNwOw0KPG86cD48L286cD48L3A+DQo8cD5DQjxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyAoSW4g cGFyZW50aGVzaXMsIEkndmUgbmV2ZXIgc2VlbiBzdW5zZXR0aW5nIElQdjQgYXMgYSByZWFsIHBy b2JsZW0uPGJyPg0KJmd0OyBPbmUgZGF5IHNvbWVib2R5IHdpbGwgbm90aWNlIHRoYXQgdGhlcmUg YXJlIG5vIG1vcmUgSVB2NCBwYWNrZXRzLiBCdXQ8YnI+DQomZ3Q7IHRoYXQgaXMgbWFueSB5ZWFy cyBpbiB0aGUgZnV0dXJlLik8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEJyaWFu PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJl Zj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_-- --_004_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=23586; creation-date="Tue, 05 Aug 2014 09:21:52 GMT"; modification-date="Tue, 05 Aug 2014 09:21:52 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArIAAACGCAYAAAAhDWkSAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFuiSURBVHja 7V0HfFRF912k907ovdr7p59+9o4iKL2kUKXYEBFULHQpgmIXBZSiYgdEBUFUkCJdaigJLQQIKSTZ ZFPOf85sJtn0kOwm781/5sdlJ2/nzc68M2/mzJ07dxwXLlyAESNGjBgxYsSIESN2ktdff93hMA/C iBEjRowYMWLEiCGyRowYyVFiY2MRHx8vP1VcSVxcXIHzYFp1H//2/N7zO0/Jmi4/iYmJQWJiIlRw uVzp8dTUVPmZlJQk03nj2ahye5Yza108n1HWenk+29zqkJycLK+pkF+ZLgYXb4rn77K8LDdDUcri 2d5Kok5Z21ZCQoKsE/EpShtSbUR9egbT5xgxYoisESNGfCyRkZFSOAhzUM+PjJBQ8pP3REdHZyOo UVFROH/+vPxU+fNvpr0Y0uN0OrFp0yYEBQXhmWeewe+//47nn38eXbt2xbRp0+Tn0qVLJZn1BolV 9fCMK1H1YZlIgLKSvtzyZdnWr1+P3r17o3v37liwYIG89uSTT2LUqFGSQJU0qctPWN6PPvoI3bp1 w+HDh7PVv6DPl+2G9WV74GduExum4zP11gQlL1zYhtasWZPepi+WmPM+1o114nM5cuSIxLZXr14Y N26cbDNWx9eIESOGyBoxYgtJSUnBt99+izZt2shB/Oeff5bxSy+9FO3atcMjjzyCv//+Ww7yntpD 9TdJHAdu3nfHHXfIe+68806sXbtWXudvUFM6fvx4dOjQAe3bt0/Pn3/PnTsXWYMiOZ6BhIAkgaFT p05wOByYPHkyHnjgAVSuXBkDBw7E4sWLMWLECKxcuVKWM2se/LugREgRVxK1Vq1aYfbs2TJPPi/R Ock6XHbZZbIOQ4YMkWSF3z/66KPyuyVLlsjfnD9/vvx7w4YN8l7mzfDZZ5/JOvznP/+RxJvfTZo0 CW+88YYk91kD688Jxblz52R+U6dOldcVufPU8Krf8dTyqsBr/N4zKNKfWz68FhERIX+Xz1xpv7/8 8ks89dRTOHr0aDatuPotlZ/ScKrAcrPtfPzxx7juuutkuyGp379/f44Tp4MHDyIsLCwbAWSe6jfV d5545/QcPTWvWZ/DP//8I/EkXipfzzoxT5Uvnw/zUqsCzJPx3377Dffcc4+s0913341FixbhlVde kXi3bNlSToBYd9P/GDFiiKwRI0aKKAzz5s2Tg+yqVaskOWF8+PDhePPNN+Hn54dbb71Vat0+/fRT bN68WQ7Y27Ztw4cffohjx47JOAfoLl26yLxmzpwpSbHS0nFwp4brnXfekWmY/3PPPYd3331XEodv vvkGX3zxBVasWIH33ntPErnTp0/jq6++kgSSRODkyZOS4DCfWrVqoUmTJpgzZw7q1KmDRo0aYdas WTJ/EiPmqYjvr7/+Kr9jvcLDwzNpSpU5RE7aMZJSanurV68uy3vLLbfg1KlT8nkNGDBAXpsyZQrG jBmD0qVLY9iwYfK7K664Qn53ww03yHqwTPx79erV6SSdgUSX11lHNSFgGTmpYHn4PFjvH3/8UT7T 48ePS+LEZ8b7br75ZnzyySdS68frISEhkhzz+W3cuFE+c+bJ36H89NNPsizMe926dXj//fflsyGG u3fvltdJ5HLKh8+C6RXx5uSDef/111/yeZOY/fHHHzINJzC8l8+OBHD79u0yDYko8eNvMn9qJVn3 unXrSm0l29Zbb72VjcgqbTcnFCT8DJ5aUuL5yy+/YOHChTh79qz8jvVdvny5xJv1Y915r3qOzJ+/ w/KyzfM5sty8HhwcLMt76NAh2eZVnVi+r7/+WubPdsA0nODxnl27duGDDz6QhH7Pnj1o27YtOnbs KO/hu/Dnn3/Kcl955ZVy4mOIrBEjhsgaMWLEi0RWaQepSeKAzzgHf2qbqC0jaSTZadasGR5++GF5 DzWgpUqVkoST2tayZctKMkchkeBArQiHpwZXETsSYqXtatq0qbzGgf5///ufvG/Lli247777pOaW Gte+fftKwkbzAablNZatfPnyMn799ddLjSG/o8aUgUS8Ro0aqF+/Pm677TZJPEjKPEkQy+lZVs/n QpJaqVIludTM+pFEMwwePFj+TmhoqCQxLIN6Ltdccw2qVq2K2rVrSxJFwsO06t6sRJaEVWkDWU7W gcRN1YXPhJ8jR46U6Xr06CH/Jpm/9957JVkm4eKz4qSD91G+//57mb5169Yy/VVXXSXJL583NY68 dvXVV0sSzmdDIkvypvIhGWM+3333ncyHy+K8h/WilpH5qOdw4sQJqQln/KabbpLklHmQwJEE8jeo kWSgFvvyyy+Xz5vaftaZdaNmVy3ne+JAoshrJLIkklltcokntcT8ba4KkGQyzvKwbTLONnDjjTfK OE1SiDcnT/yb9eRkqF69epLEc+LA65xQcGLFOFcRSEBZD04kSIb5bO666y5ZnmeffVam4/1sc0zH Z8x34fPPP5e/pyY5hsgaMWKIrBEjRnxIZNUAT9LKpdGGDRvKZWwSF5INEg9qPEnYevbsKe9XJIbE itrbihUrSi2oWppW2k/mQQ0V01IrqJacObiTSFBbd+bMGUkwSRKp8eRyM8lTlSpVJGEiAWjevLn8 fWrgSChI0rjkTu0a854+fbr8PZI9mjlQy0ZtGTV0ymSA+bz00ksyf5I0EnW1xM4ykRBRq8r7t27d KjWz1CIz8Dnwd/h8aHZAIeFj/Uh6SOaGDh0qSduLL76YJ5FVJgj8bZKqa6+9VhJZElhqmqn1ZP6s I0kbNX68jxMJZYLA56TIKk0tGCcOLA+v8TnQ3ILPi4HadqZhmQMCAmScz33GjBnZ8lHkd+/evfJv aqPV76p8qC3ns1HEnBMGknmST97LPNg2WBfirMwiSC45CaA5Bp8Vv+MEiu2GGBGH1157TZJ3Yk7T FWKlTDGUtp8EnO2D9qc05ahZs6bUCLNNXHLJJfK3SfaffvppWUY+Q2px1aSHtr6KCFMYJ6FVaV54 4QV5P58pMWG5+Ft8rpxwsX40d1GTH95DksvyVqhQQeJjNLJGjBgia8SIkWIgstR6MU6NEpdcSUpI LElISIZIKDp37iw1lUpbN3r0aJQrVw779u2T5IGkj0TIc4d2XkSWZgnUrvJ3lP0mNa/Mk2SZJIda V5IpBpJXkkxFHHkvA7W8zJuEjEvXjFNrqALJg9pQxDgJCokshZpVRWQZWFdqYakhnjBhQrq2lGSS S+HMmySLz47EiIRKkVESWRJjapOpzS4MkeW9JOtKk0fhdZpy8D5uClNBaQRJpkiySaJJ0FgmEife yzqrZ/vEE0/I9CS21IYqMqpImGc+r776qsxH/a7SDGclsqoMBw4ckM+WE6Dbb79dpiMerBvbBJ8j 2wkDJwksH+tFm1TeT+2+Mh9g23j55ZclkaXWnkSSG+RogqGwUp4BeJ1tgs+MmKnJEPMcNGiQzFOZ R5B8ctKkVh5o9sH4Dz/8IHHPSmSJsdJKs02QyJOUs92qd4FmIAwsP8kzzW1YPtaX5TFE1ogRQ2SN GDHiIyJLWz5lI0uNmhrU1eYu5SKJJJC2ovye5JLkhoEEmAM2tXvUepGAkkiRaGYlstTG8X4uOSsi y3u53KyIiafWk4SNS+CMKyJLrRh/nwSIBIfkgPlwKZvpSDxZ7vvvv19qc0m0uYmKZFUtXWfdCKVI rnIFpUhaixYtJIHlUrkipCR4jFNLp+rAe0iuSFxJrtXmLaZTk4SciCyXsBWR5b2K2PF3qfFVRJ9l YBn5zEmc+Lxoq8r6MA9ee+yxx6QdKDXNNGlgoGadJJLkSz3b/v37y9+m1lnVhVrNZcuWZcuHtp/E jcvmnEzwd1XeykSBmnI+Y8b79esniSPJHIk+A8mten4001ATI9rSUqvJCQW1t8yfKwKq3XhixPtY vqzu1dQGQLWSQOFzZ6AWnm2Rz4CmDcSFz5ImB8yLaWmCQXtapaH2jCuyS9MLatZpokDbV6UJ5oYu fk/zDT4/BtqGN27cWE7AqKWmxpn3MrAdswyGyBoxYoisESNGvCQkXBy0OcBSK0aNFONcYiVh8PSH yr+5IYfEiMul/JukhMSLxId2qiQ6JEDKRMCTyJJckjQzf7rQ4m/zXhKCxx9/PN3tFEkCtatcEubm MH5HTRvJAu+hHSevkQxQy0fixXxoAsC8SZBIhqgVpRaNJJD5/Pvvv9lsMLMK8+Hu+AcffDD9HtaF BIdEhNpFkmL+Dgma2tCmys3yUEvHspHgcYmZablxytNrATV4inQzHZ+NqgvvJWFS+dD+llpS9Rx5 DzGgpo8acJJdPlcucVPrxyVt5s/fYz14r3L5xGvUsrJMJHQkfaouLH/WfGjjqTxVMC1/l5pRYq/u pcmGMi0gueW9NH0gUVbutWh+QmJO4qjaDctEsstJCdsOSbPagKfwUBMLTpCU2UFWzJgfvUawXTAv Ykb8eY32qqyHakMkvMyD2laWnRMMrg5kjXOipcwM+vTpI7XLbI/UtPJ5Mw+Wl8+DJFlNZvjJZ89N cdSqk6RTM8wycdLFtmiIrBEjhsgaMWLEy+K52Skv35nKuX9Wp/9qp7lybZTbQK0OXcjvGu/P6bey ps96r2dclUP5qi2oT1DWgfco12IU1o8ES/nIzS0vz+9yO/SBJItL11x+pxZ24sSJ8lpu9coaV+SZ RFCR/6zlU5OI/J63Zzy/fDx/1/NeBqXZ5eRBeUxQbcATQ8/JjSJ+ytxD/XZ+7TO37z0PIGAZSGRZ JppSkHhm9febW7tRdaKmW5kW5HR/Xu8CP5VGmR4bSIQbNGgg7YGVf2bT7xgxYoisESNGvERis57s lRdRy+l7z5O98iIdOd2fmwssdV3lm1P6rPfmdgrXxTqgz5pvTs+oIPfl9Ez4N7WVXIamFpyaZs+6 5ldHz9Owcnr+WQ9yyFp3z+eZtS655ZPT76q/1YY/erGg+QZJX26/mVO7yem3cnqu+ZFZz3opIssy kchyoqBcsuXV5j3rxJUK3s8DK5Tv29zKntu7QKEPXq4W0PSFRD+vgx+MGDFiiKwRI0aMWFqULS7J lSJYvjyxytdC0kZ7VPqM5bK5FUgay0DNMctEQnuxZWKdaDLB+2lqUpQ6KbMaYu2NE+eMGDFiiKwR I0aMGPEiMVd2o1bSNCpPDfkdsZzXZIP3GzMAI0aMeIXIxnJpyZxPbcSIESNGjBgxYsRuRNaIESNG jBgxYsSIEdsR2YTUVGz95husmTULcTkcJ2nEiBEjRowYMWLEiOWIbLzLhXMnT+K9++/H+JYtcWjj RiR4nJduxIgRI0aMGDFixIjliCxtYuPi47Fs3DiMqVQJIy+5BHO7dMH5M2ekZtYrP0btrq7G/LQp Zt1svCM6R7x0dSZu8DJ4WUVYLx32JOiKEeujC0amrzB4WRUvbxBZktWI06exato0TH/kEcwbMAA/ jh2L0N27pabWG0DEnDuHqNBQNyiaARF96hSiT57Up7MjXhERiAoJ0ROvsDD98Dp/Xlu8YojXiRN6 kQnVFo8dQ8yZM/bGjRiJ8SP6+HE9MRL1igkP1+PdYl8RGYmoo0f16ytYN4GTVu2QdYqKcuOlG4ll 3UTfxz6QitT4ImCWblqgTllZ/O23OCQGDYY4b81sRD4sbMT69drNLGITEhApCP/5nTsRWwj3M5YU 4iXaQMRff+mJ17//4vz27XrhJSZTEX/+qd2qB/GK2rcP57du1Qcvj7pFbNyIqEOHbP2eSYz278f5 f/7RDyNRn/ObNyMqOFiPvpCTDkH2Iv74Q79Jh8CHOBEvbdoh8Tp7FhHr1uk38eA+rJCjSNy9Ay64 j8SOiytcHTNt9qITaZ75TcfWdCpN335eETqoFrMK58GDMu61fK0goj6JJ08iQcwCdapbEv076oqX IH3a4SXe3/gDB/TE6/RpJISGalk35+HDcJ07Z++6ESNBjhJCQrTEKEGMh64zZ/Som6hDMrVfYuKh FU5pdSNOxEundpjMY8Q1xet86AlsW/knZn6yCg/6v4kz52IypaFv6YIcYpMjkeXpMd4OqWKGlBwR AR1Dinh2KWnnfWsTXC698YqO1qpOqcRLECIt8aLDfc3wUiE5MhKpaUe12rr9xcUhJSrKYGSLCiVr 21cQJ+KlVwPUF68Fi9agev1ecNTqjdJNgrBi7a5M3zsFibcWkU1IQJKuA6140Mm6ESMx8Ug6e1Zf vDQbdLXGS/RN2g1OaYGTxRRBAm2PEY+H1RWj8+e1wEiFVDHOJ505oyVWxIl46RRSBZHVEa8EVzIe 7TsNNRoIItswEI76/rjyf2Owcdvh9DSFIrI8p3rRokUICQnxQakTkKzpy5MqSKx22ghq0MPD9cRL vBgGLxvhRQ26riRJTO5TNSBJqdSaa0YgMmGUtodEjwolI/n0aS2xkisDuq0kaopXn6fnomzdXqjf 3B+ORkFwNBZStgveeH9lehpXAZ0NZDvZ64MPPsDBgwfludm0TyAj5mdR4vJTkIdYMdA6BaH1Rp5W iSeIB816xdKOT8QL+3xKui6eZZBxbnQQdfLEK1saL8TzLIMP4hIvMaGKDQtLx6s4ftfn8WLCq7jj 2uJFEVixbvFiUhWfhpstMRJjRezZs4il7bmOGIm62R2jTHFBymVfoQlGmdqhmHRc4J4VndohN+WJ /s8OZU5IcCIpKVGIK+MdyiFNdEwsrrp/HGo06o3mlw5A+dYDUbntQJRr7I9R4xfjQmycSJeAkwLL cHoMuRgiS88FH374IYKDgyUTdv9ogkcBCheXn9yRxg0BorF5I0+rxBPFc4qjv11Rt0SXq9DPp6Tr 4lkGGRdtISte2dJ4IZ5nGXwQl3iJgSlOdOSJHm28OMvgk3gx4VXccW3xogisWDdndDScabjZFiNB IOLEYGswskGcfuOpeNEEo0ztMCJCTnq1aoeCBMbaBK/ERDHxk+cSCELrSsw1zdFj4ehw11jUatYP zTr0R7lWA1GpDYlsALoOeRvnI6OlMjVMYHmG7gmtYlqQakwL7BWMaYHByyp4GdMC62NkTAtsVCG9 TQu026RsI7y+/2U7Wl/3LNr+bwz+2HQw13S79p1Ak5ueR/l6veDXQpkWBMJRtw+uvO+V9HSJBXSj VmybvVJ03uwliKzZPGQjvMxmL3vhZTZ7WR8jbvbSlchqglF6X6H7Zi/NiKydNnv1GPY+HJW7wVG9 J27uPBEfzF+NTdsPZ0v3+9/7UeOKEajYoA/qtQyAo0mQWxoGoGr7oZj+1o/4e9thaRlgvBYU18tj vBbYDy9DZO2DlyGy1sfIeC2wTTBeC2yGlw2I7FfLN6O7/yxU6zAUjkZpxLRuHzjKP4b6V47A4DHz sTf4ZHr6b1duRZmWg1CxUb/MRJbSKBAOxwMY9tLnMq2liGyK06nty0NSpFsnLicemi5VS7x06+xI ZDVdLkzmxENTn8acfKRosGwtJxu6YsQDKzQyLZBEVtO+gjjppjCzOl7JySno9sS7gnx2hKOBIKVN PUhp0zRCW6Mn6rV7Am9/ukre89WyTXDU6YsqTf3RgES2cf/MZLZSVzw/6SuZ1lpE1pgW2OvlMRpZ g5dV8DIaWetjZEwL7NNXGNMCe+FlcY1s+LkYXN/xdUFM+2Qmo55C+9davdDohpH4YOFa9Bz+ARy1 +6BKs8DsGlkrE1ljWmCzl8cQWYOXVfAyRNb6GBnTAtsEY1pgM7wsTmS37Q5FlXZPwNHAP3ciq7Sz 9f3dNrS1e4u/+6NKcx8Q2WRx08IlSxBy7Jj3wXC59CayuhEjdnaGyBq8rICXzkSWJMnptD9GOmtk iZFGR9SmpqToS2QFTkm6mbikploCr4joeGz/9xi27z2eLrPn/YaGN45yE9TGQRctlQWR9VOmBZ7f VeyKkZOWyt+NoR/dAhNZ0RElhIZi3tSpOLRtG8DBI832U34WIU7ikETfbocOuUlE1jRpS/Pe+K1i jwuh/YpL1M/zmq3qkuX501SCdcoVL1+XwZdxhdepU9nxKq4yeDku8aIfY0+8bFqXHPESdUvHS5d6 iTgJeuKRI3CdPJk+ubI1RqIe2mJ04oS9MVJx9hWCFCUEB7v/1q2vEHUjVjq1QyooJF5ezFO6M4y9 gNSY3NtAapRI43Li73XbseizX9C171TUaNgbNZv2RfWm/qjRtB+qN+mLSg37oHaLANQRhLRWi8AC x2uLz4atAtCyjb+8RqmTlqZC9a54Y8oipBw9jCjx/pGfFpzIigYwf/p0HNqxA6CKPm3JXH4WIc7O QA60R4+6Z+5eyNMycZJ0duKCHHles3O9JF6iQ2AHLrVhuuHFzk43vERnZ1u80gbYPPHiRNGXeHmW oZji7AsTQ0LkJD+9XyzB8hQlzvaXCSMb1yUbRqGhWmCU/j6dOyf7ipJu/z5rh5z02qkdqj47t/4w IsKNlxd/FxdikBApSLIi/LmkOX74ODrc+BQc5R9BWb9eqNbMH9WFVBVEthrJbHNKIGq2IEENuKh4 DUFc6wvS2ry1v4x7pikviOyUKYuRcjwUUaKPLDiR5WAIt2nBUV+YFtCGz2z2ss9qBk1BjGmBffAy pgW2DNJG1pgWWBsjY1pgn3YYF2dMCwoQ9h05jRY3jcJLM77LNc3+o+Foe+eLcNQPKJTZQMmYFpjN XoV/eYzXAnvhZTZ72Qsvs9nL+hgZrwX26SuM1wJ74eWDzV7TPlwJR+lH8XDQW3C5knNMM4Np6vSW hxTkuYmrCOKTzV6GyBby5TFeC+yHlyGy9sHLEFnrY2S8FtgmGK8FNsPLy0SWhxc0uWw4HNV64JYu kxEVE49d+46jx6A56DHsPXk6F6Xpf57L3xPB/zciKw9E0NnBvjkQwV54mQMR7IOXORDB8sEciGCj vsIciPD/Fq/UVMD/mY/hKNcFDr9+aHXrCzgUGo5pH6yEo0xnt2usKmlSr2/mww28LY2DUFUQWVsd iGBMC2z28hiNrMHLKngZjaz1MTKmBfbpK4xpgb3w8qJGNibWiYcCZsnDCXgKV6W2Q7B55xH0GPq+ m7g2DvKpBtaYFlj55TGmBfbDyxBZ++BliKz1MTKmBbYJxrTAZngVkciu2bAPPfq9ifX/BONsxAVc /cCrGadwNQ7ELY9NRs3LR8DRKKBYSazPiGyyeGCLFi1CSEiI99EQRDZZ05cnlW5aNCNGEMQoWVPT glS6rDJ42Qcv0Tel6EqSxOQ+VQOSlCqIbIquGllipJFpgRjokaypaQHfpRTdTFyKgNeBI6dxU8fx cDgexJCxC3Dk2FnUvfopaVbg9hAQCEeNnh4HGgQWnzQKRJVmAfBrIX67UZbfrvA4Rk92ey3Ij8Rm I7KUDz74AAcPHhTjYiLi4+PhdDrlZ1Hi8lOQh1gBhlMQWm/kaZV4gssl60VhvLDPp6Tr4lkGGRdt ISte2dJ4IZ5nGXwQl3gJwhcbFpaOV3H8rs/jxYRXccclXmICHHvqlF54UQRWrFu8mFTFp+FmS4zE WGEwslFckHL2f7pglKkdiknHhZMn9WqHdD/lgRdS3V4GUpKT0q8lJbncRD4lScYTExMEn4vFjQ+/ itJ+fVCpZX+0v+MFjJ60GFXbD0alVgNQue1AVGrjlpKIV2g9EH4dBqDFpf1RvnXmNGXq9caIlxfg QkwkwsV4fVFENlY08A8//BDBwcFwiYaQIF5cbwkH2jhRIDY2b+Zb0pIonlOc6OgoiV5+ZiUqoi1o i9fZs7JuBi+b4CUGpzieNKcTXhSBFduiMzra1rgRl3iDkX1EECNipRVOqh2eP484niKqUzsUhJZ4 KQL73crNeHLcZzgRdg5JLnebDD5yCkPGfIpN24MFj4uXJHfHv0fR5MZnUa5JACoKcli6WRAcgtRW ECSWJLKSkIqtB5ZYvHyrgajbbgCadeiPcq0ypylTpxeeEnWMi43BWfH+Wca0INWYFtgrGNMCg5dV 8KJpgc7L1sa0wPoYGdMCe7RDDTd7SbxE3x5+Lgb/bDuC/3aeJF1nNb9pFP7cfFAmmf/1emn3WqfD MLS59QXs3Hcc6zYeQPkWA9PMCAKtJ74yLfD5Zi9dN6MYrwX2wkvXzV66buAwm72sj5HxWmCfvsJ4 LbBZpdwnsY0YtxCOio+7fbtyY1atXvhvl0l4Z/5vuLnzRDjqCcJatw8cNXvi3j4z0OfJDzNsYZtY U4zXAiu1M+O1wH54mYmHffAyRNb6GBmvBbYJWh9nraHXAqSmIOLIMdzbe4Z7Y5YnMSVxrdxVfGbx +Vq7t9vFVlPrklj7Hoig6SzQHIhgQ7zMgQj2wcsciGD5YA5EsFFfYQ5EsF04un0vmtw0yq1htTAx /f9xIIIxLbBPZ2c0svbDy5gW2C4Y0wKDUbH3Fca0wFYh7kI83p29FKUaB0i7Um2IrDEtsNjLY0wL 7IeXmXjYBy9DZK2PkTEtsE0wByLYCCshM99fger1urttYzUisb47EEHctHDJEoQcO+Z9QFwuQ2Tt 1tnpjJduRFZnuzediSxJEn1D2h0jHW0TNcMova9ITdW3r4iPR5ImGtkkwWLHTPsWpf36okELdYCB XlJZEVmaFnh+V7ErRk5yey2IoR/dAhNZMaNOCAnBvClTcGjrVvo8SLcllJ9FiHPpPYm+3Q4dcpMI L+RpmbgQ1s116lSma3aul8SLPiGJF80mdMNL1M3gZaG4IKn54nXypG/x8ixDMcVJ0BOPHIHrxAl3 v1gCZfBKXAjt6TNhZNe66IqRR5unNjYhOLjE27/P2qHAygrtEBeo3EoCXE55MmHWNHTbCSdtr1Nx 4fQZ/LJsPT7+aDn+WvMPEBsDV2QUbrh9FGr79cAV7fuhTstA1G0RgFotAlFHfNZtae94bfHZsFUA Wrbxl3HPNBWqP45pUxYh5cghRB0+LPlpwYms6Ijmz5iBQzt2ADzqjf426SOVn0WJ0wCbBwYcPSrj 2dLQT6S3fqu440LkyyPE85qt6pL1+dPMRMzYc8XL12XwZZx4ibboEuQoG17FVQZvx3PCy651yQkv Ubd0vHSpF+Oij00MDZVEXeJmd4zEhF5bjFg3O2Pk0VfQnIXkXP6tW19x7pxUUpR0O0RCPA7tOYwu PSZj2sylQKJTcKrM7ScpKhq/rPgb3QJn4tZ7x6Jy475wlO+Eum3644Eur+MRcW+1Zv6S3HVo2w81 BNGrKeLVmweKeIDt46yPnyCtzVv7yziv10xLU75aV0yeshgpJ44hSrx/BSeyfLBwmxYc9YVpAW34 dF2q1nGzF01BjI2sffAypgW2DNJGVgfTAp03e1EzGx+vT1+R5pdUy75CTDysYFoQdi4GA0fNE8T0 MVTtMAw/rN6BpJTUTGlen/0jqnIZvXpPOGr1hqNhIBxN+8NRPwCOmr3SXW1d0jRIai51NS3w86pp gfFaUPiXx3gtsBdexmuBvfAym72sj5HxWmCfvsJ4LShUOBcZix9+3Y7k5JS824uYKPTmYQSVuro3 LtXrh0uaDcDfWw+lp4m5EI//dZ0CR9Vu+W6IKtPUvQSv20Yv47XAai+P8VpgP7zMxMM+eBkia32M jNcC2wRzIELhwqLvN6LOlU9i9/4Teabbte846l/zDBx+fd2kjC6zGvhj5kc/p6f5Z+dR1LhseIE8 EZRRGllDZM2BCD7t6MyBCPbDyxyIYB+8zIEIlg/mQAQb9RXmQISLDqfCo9Al6C15YtaYyUuxY88x uJKS07+ntnbrziOY+eHPqH/dM5kJamP3CVz39ZmJrbtD8OZHv6CBTFMwclq2aSCatNLP9ZY5EMFq L48xLbAXXsa0wF54GY2s9TEypgX26SuMacHF4Z+Sgrt7ToOjWg9BuALhqNNHHv26Zv0++f3S5Vtw W6cJ7mNh6/UT0jdn4tZQELb6/dync/n1LTDhM6YFF+tHNjkZCxcu9A2RFQOtrjP21LQdi1oFlwvJ mpqCpKbt1jV42QQv7hbXbOKhQoogf6kabCRKpZcbXTESkygdMEoPYpxP1lRJQZxSvDDp3bj9MB4P nI3HBr2DuwSJLcVNWA3TNlxRkyrI7KiJX+LPTQdRqpn4rko3twkBJbfNTfyuYUDeaXKQ0k2otfTX c7NXM7dLsWzfVXwcoye7N3vlR2KzEdl40Qjmzp2LQ4cOSVLrEoOjtyRREL34kye9mqdVxCk6BSdd OmlUp0RBHuJPnNATL0H4DF42wktMgJ10cadh3eLDwpAgCKDd65EgCLmT/n51xUiQI236CjHOxx8/ riVWxIl45ZWGK89ITcGegydw5Fi44DpJ8pr6jtxn3PRvBJnqAkfNHoK09kKZ5v1RruUAlBfCz3Li 7xqXDUW9q59E6WZBGdc903gpXqlVf7RqH+iz/Ess3mIA6rTpj6btgkR8YKY0pcVzf+a1RUhwxiNC 9P8FJrKxYiCkCvfdd9/FgQMHkJCQIK+R3PKzqPFY0dHRH5g387RKPEa8ONGnThU6n7i4uBKvi2cZ GI8THUJUSEi2696O51UGX8WJV4wHXsX1u76MxwkyVBx4lUQ8RhCkGDEJ1q1ejEcLQhErJla2x0hM NGLEREpbjM6e1aevEON81NGj2mBESUhwutvhmTMSr7zSIzUJu/YeRbU2A3Hdgy/j2PFwOJ1OmQby fNNUPNBnGio0D0SVtoNQrf0gVGk3KHNcSKXWJGNBuacpcHxwnmlqCGl/5YAi5G/deMPLBqLV5aJu bQdnul62fh8Me3EeoiLPIUyM17EX40eWM5FFixYhRAyIXg/GtMBegUvVOuNlTAvsg1faIQ86Brls rYEfWWNaYKNA0wLN+opU5aK1AKYFv/65B1ff+ZL03Vq57RNYt+lg+neffb0enXpMQ8U2QzJMCWgX W4JC04L6LfxLvBxel0aBqNQsEHWa09wiy3OuUATTAuO1oJD9gvFaYD+8jNcC++BlvBZYPhivBTbq KzTzWvDBot8x7KXPkZKSKie9nl4Ljp86jxOnI9P/3vZvCG7s+HqGTatfPzz32hLp1zUh0YX7+syA w/Gwm8RaZEOU8VpgJfdbxmuBvTo747XAfngZrwW2C8ZrgcGo2PsKzbwW3N93Jupe8zTCzsaIhujK dLLXsJc/x+W3vYDZn/wqN2dJTSu9Dni6xqreA2OmLBWkNwJN/zPK7VXAQoRPd68FfuZABIt04roe iKAzXmbiYR+8DJG1PkbmQATbBF0ORJi/9C906v6Gm5z69cX9/Wbh9Kkzoh26J1Q8gasPT9gq3wWO yl3hqNY9Z9+tDQNQ/dJh+G/nSW7vBI2tRfbMgQjmQITi6eiMaYH98DKmBfbBy5gWWD4Y0wIb9RUa mBZciEvA3T2nw+F4xG0GwAMIBEld/uMGICpSpomMjsPdvabBUatX/qSK99fs5bbPtBjZM6YFxrSg eDpxY1pgL7yMaYG98DIaWetjZEwL7NNXaGBaEHryHBpc92yGGUDaxqzJ05cCcRdkmpAT53D53S/L U7XsTPiMacHFEtnUVHy+eDGOhoZ6/+WhjzZNOzo50GrmtUB2dppqWOSga/CyD148rUdTrwUk6Cka eC1IiY/XFyMx6dUBo/S+IiWl2M3G3pr/G75YvjnH75yuZCSmHfd66kw0ej/1EToHvYVHB72Dzr1m YO6Xf2VKfywsEvf3exOO+v4ZZgDc9V6nH7r3n4WECDfPOHj0DGpe+ZQ7nadNrM3ilwipr8ieDcuf V1x6LWiRRSMrD0Toiucmub0WxOTjeiszkRWJE8+exYI5c3B4zx4gIUF2ThxE5GcR45zVJgqC7M08 rRJPogPmU6e0qhe1K4khIXriRcftuuElCJG2ePEwhBMntKsXP13HjkntmO0x4gEjumJ0/LgWGKX3 FWLCkXj0aJHySS1geiQlIjkuHlff8QKuv3sMNm3ai6gzYsLtFN+5EhEZHoFHek/FHZ3Hi3Rx+OWX LYKQ9oSjymNw1OgGR6mO6NH/TcRGRMLt4xVY8uXvcNTugcqN+0mNHk+H4meVJgFocdlA3HrLkxj9 +kKRbh2q0s9rU/+MNJ7pbRKvKYheu7b9bFv+XOPikwS9dRt/GfdMU7ZqV7w+eQlSz56RPvovFMiP LBOJRuQMDsan48cjeLOYOYnGTg0Pl5flZxHj7OScBw54NU+rxNkpJBw5olW9XCdP6ouXIHwGLwvF z53LGy8xAU44fLj4ylCM8QTR57J+JVkGb8QTBSFnXexa/jwxOnhQC4xU3BUWBuf+/YXOBxdiBKd0 Co4QmWsa6ctVfB8RchzjX/8MDZr7o3aTPihTrQtGPDkHztPhtIfCT9/9geZtglC1Xg9s/Ws75sz6 CjUb9ES9Fv5o0CoA1Rv2xv0Pv4yQ3cE4/G8w3nxjCTp2GodqjXrLJWmm4WYhFW/esi9aN+uBmuL7 Go37iuv+2dJkjdfP5bpV4k1a++Pq9v0sWbYixYW0FCT2qnb9ZNwTi0o1HsebUxYiZf8eRIpxjfy0 4AciiNnOwiVLECI6Ja8vZ9Bhu66mBXTYfuGCVnXiUrXBy0Z40cm5xqYF2h04kha4bM2NlbZvf9TA aWxaoANG6Vilphapr1i3+SA695yO3z0OEsgpOBOTMWHOcjiq9YCjftrhAnX7SldZW/ccw/yvN+By Hkzg596odcX9r6LJzaPdngUapy0xi3hFHlqwORgBz30KR5nOMg9Hk/4ZaTyES9W1WqQ52Kef2BzS 2E1KNQly25FqUJesUlHgVVuZFnh+V7ErRirTgnxIrPFa4MWOzngtsBFe3JxnvBbYBy/jtcDywXgt sFFfUUSvBUGjBKF0PIiAkXPTryW6krF5xxEEh7jHjPc+W4NGV4xAuZYD3YQy0271QNS58kmUaT4g s0eB2r3hqCdIatOgbOlribxKNxuQt2ss8V215u7l6my74G0sxmuB8VpQLCHZeC2wF17Ga4G98DJe CywfjNcCG/UVRfBa8Pk3G+B3+XCpFfW7cgTeWfCbILFJWLpiizzytcmNI/HKzO/Q8pbRbndWuZ2Q RW8DDS6CnDF9o/x37lfNzS+pzb0WNDJeC8yBCD7vxM2BCPbDy0w87IOX7kSWm2LsjpE5EME2IbcD ERISk5AoJLfA414bXv+s21SABwdQe1qnD27vNhXNb37eTUzr9XMf/0ri2bT4iRGJbF3tiKw5EMGY FhRHR2dMC+yFlzEtsBdexrTA8sGYFhRPOHf+AkJPFvE5p6YAzgyb86iYeCz+dgNaCTJ6X98ZSEpO yfG2VX/tQaXWgzO7s6LZQI2eaXarJb9UbUwLjGmBMS0oZDCmBTbDy5gW2AsvY1pg+WBMC4onzP5k FR4f8q48frWwISbqAhZ9ugKr/9or/57x4S9wVO0GR+VuaHj9SOwLPpXtnuCj4egcMEseBWu1I1yN aYExLcjstSA5GQsXLkRISIjXX0AOtLrO2FPFs9NuVzW9TOiMl247rImXpqYgqfQyodnEQ4UUQf5S NTAtSKVnCV0xEpMoq2D07OtL0Oa2MYiIzKwhPn02Wn43a+4viItPxM69xzD4hfnYm0ZKaTbA63HO REya/QNKle2IFreMxq59x3FXz2nSRIDmABVaDcLKtbvS71HhuQlfwlH+Mcvvgq+S7mBfn539pZtQ y+yvpdcC+o6tmxNeFR/H6MlurwX5kdhsRDZevKxz587FoUOHpHbWJQZHb0miIHpxJ054NU+riPPs WcTTIbhGdUoU7UFnvJy64SXIXtzx43riJQi6k4dYaFi3+FOnkCAIoO0xEpNebTEKC0OCILMlWQaO x4mJLvQY9g7KNAvCou/WI96ZIE/p2nvwOC69aywc9XqjbIsBaPnfUah/9ZNw1O6FYS/Oxw+/bsV1 D76Kljc+I7+r1X4wWrcLEGn7o/41T6FSm0EoJ+4r17w/yjXyx7jp3+Cd+atwfcdXsXT5JmzbfRRX 3fcyyjUJQLmWA1BeSLk0KWq8vJfykXFRh7pt+6NpuyARH+jVcpZkvHKrAWjVIVCLumTFq47Aq1kO eJWu2RPPvLoQCc44RIi+pcBENlYMhFThvvfeezhw4AASEhLkNZJbfhY1Hnv+PKJDQ72ap1XiMaKj ixEDUmHziYuLK/G6eJaB8TjRcUeHhGS77u14XmXwVTwrXsX1u76MxwkyVBx4lUQ8RhCkmJMntauX 7HPF5CNWEHW71+VCeDhixMRXW4zE5NfXv5WclEjdtvzk3+p6nDRrSEFyShL+0+lVlG1MzekA/LR6 m7z+weerUbnNAFRoGSSvl20uSE+LIEFQSQ6C5N+lmwXKzzLis2rr/mh/5QBUaTtQXAtCZfFZpd0g 8fcgVBWf5Vv2z0ifdk+l1gMypfFWvKqX82x06UC0vJx1G+zVcvo2PjjPNDWEtL9igE3qcnHxhgKv VjngVbZ+Hwx/cR6iIs8hTIzXsQU62cvDtGDRokU+MS0Q00mkaLxUnaqhaYG2eHGpWje8kpKQoqtp AZetNXW2L5etnU49MDKmBUUKP6/bLc0DzpzL3jfNmvsrHuw6FeVaDnJvtqrbFyPGLUS804WAZ+fC UbuP2z1V48DMws1YDdXfbp+sZbhU3cI/e1qVplFghvBeutBqlHG/ZUWUsXLTQNRunnYggpXLehFS Ok+8bCwCr0oCrzo54VWhCKYFxmtB4YLxWmAzvIzXAnvhZbwWWD4YrwUFC//sOop/D5zI8bt+T38s N1zVv/YZTH5nOTZuOyzlq+WbUeOyYWJwfyzjcAHxWa7VIOkOS5LbxoEF3mBTTuNd8MZrgfFaYLwW FHagNV4L7IWX8VpgL7yM1wLLB+O1IO/w74GTGDF2gdRu1rxsBPYdyvAMsOrPPZg04zv4XfO02/8q /bNmlZwOFuC13L7LhxjpugveeC0wXgvMgQiF7cTNgQj2w8tMPOyDl85Els72zYEIxR64I9+Z4Cow Rkhw5ppPfiHmghMPB8yGo1wX96EBDQJwxR1jMe+rP3HgcBha/Hc0HJd0cn+nDhFo7LG8fxHa1oIR WX0d7JsDEcyBCMa0oLCDkTEtsBdexrTAXngZ0wLLBzuZFpw+F41rHnwNbf73gjwIIPxc3koITuid kVHYvPMoNm49lL7kP3/pX7j8npcxfvYP7mtbgrP5YHW5kvFA35nSg0Am/6u1eqF08wGodcWIDHOB YhJjWmBMC4xpQWE7Oo1NC1KMaYG98DKmBfbCy5gWWB8jm5gW/LHpALoPnONekq/dG46avXBz54mY 8eHPmPHBSrz50S84cixrv+fCvAW/ujWmvCenpX9Khcfw386TMt255+BJ97GugrhmG8gbBLhNCRoH FjsxMqYFxrRAX9OC1FR8vngxjoaGen+gpS88TW2o5ECr2S54eR63plowOegavOyDlyB6upnuqECC nqKB1wKaR5T05DBZjF9OV3KO312IT8SQsZ+hVruhcFTtnqEd5Sd3/IuBk07Yudmq3X9HY8wb3+Dk mWi89/ladH5sPBpcPjRj976nNPYwA6jWE9c9PB6xzgyThWW/7czwNKCcvTcJKtF4afHp1lpaozze jNPBfu0WHho+Dep1icZ4VUo/wCILXhW74rlJbq8FMfm43spMZEXixLNnseDtt3H433+BhATZOXEQ kZ9FjFPzkBgS4tU8rRJ3hYXBdeqUVvWidkVrvE6e1A+vo0ftWX5+5oUXHe2fOFF8ZSjGeOKxY1KT XpJl8EacdXAdP14sv5XqEaftKv8+dvg4Aoe/g449JuPv9buxa3swdu9wC+Oz5nyP0n69UaZuL6kF ouaOp0DlFC9VpyfKNeyLltc9Kf4OQl2/rqjXtE+u6VW8ssj/mjtfwJmT4UiIipG/O/a1z1Glfm+R JiDf361cTHESvfZt+xX77xZHnLakrdv4a1WvWhrj1UDg1SYHvMpW7Yrxk5cg9Ww4osRYfaFAfmSZ SHQKzkOH8OmECQjevBngcrkgn8mC3MrPIsY5ECUcOJBzGjEIe/O3ijtOApF45Ihty5/T808SjSdX vHxdBh/HSdBzxKsYy+DteDa8bFyXbHiFhiLx8GHt6sV4QnAwXKJ+dq+LSxDyRDF++Pq3EB0JuOKB C9FuSU3Elj+24fLrh6N87W6o3qg3ajTqhaoNe6OaR5zX/Vr6y2VnLmVyAGW8nkfc83rd5v6o2bg3 ajX1xxXt+qFtW3Fvi8xpssbrivRX3PgkTh44gkM79qOOyKN6g165ps8ar1tM8aat/XF1+37F/ru5 xet7K08hrdq48WK8oPfWz1KG4ow3KECaJh54lVQ5fRIX0lLgdaXAq37LzFhUqvE4Zk5ZiJT9exF5 8KDkpwU/EAHAwiVLECI6Ja8vffIseF1NC+hgXzw/nQKXqrXFi9oc3fBKTtZ2Q5TES7cDLNICl+O5 sdL27Y9a0mIw/9i5/yQGvjAfew+fxi9/7sUjA95Gh7tehsPPP82pelD25X8pQYU8D76/1IhVbBaY f9q6fdHghpHYJcr4z7/HUIYmBX7+ljvfnkvVfi0DLFcubwiXqmuppWpN6lRKY7wqepqCNM5sWjBS mRbkQ2KN1wIvDkbGa4GN8DJeC+yFl/FaYPnga68Fp85EYcPmg+j2xLtwVOuBmpcNR6W2Q0S8u3sD ls92VveXWiLuhs/kdSAn8euHmpePwPp/grFs9Q7pleBifbwarwXGa4HxWmC8FpRMJ268FtgLL+O1 wF54Ga8F1sfIR14LklNSMP+rv3D9fa/AUaMnHPXTdvlzt3/94hncufzPATfftKI8FVoPxs9rd+GT JX+4y2lBImu8FhivBXp7LTAHIhSuEzcHItgPLzPxsA9e5kAE62N0kQcipKSkIjk5Jcfv6Hs1Ni5B ytc/bXG7vareI+0c9uIfbOsWlMgK0lpKlPGrZZsxcc4yN+kuZh+xBSOyQdI2U1ciq+OBCLriZQ5E sNJgZEwL7IWXMS2wF17GtMDyoaCmBfsPhWHDpgPoOugdBDw7N8c0PGCgfsuBqH/dM27zgZLUal6M aQFJa+1e+OLHTXhu4hdw1Opd7D5ijWmBMS0wpgW+1sjqvFSto0bWmBbYCy9jWmC7oItpgUAJSMi5 HiR2095ehnEzvkP9a59xa1dr9ZLL8KMmfolp7/+EaXOW4dgpNxEe9MJ8OMp0lpunist8IK/BNl0j 2zj/tI66ffDogLflyWHykASLEqOGGhOjumpjlEamBbrila6RzYpXxSIQ2UQxGC5YsABHjhxBamoq UlJSvCbJTidc1D54MU9LiHhOSYIUuejY3MvPrCQlWUw8tMaLS7q64UV/pDriJSaJLhI+jfBSwnol 0+uJj39HdOgZlNMb+SkinpyM73/Zhs5dJ+DlV+Yh/Gw03vvsN3TqOxOd+r+F+/rMQOnm/eWpV3Jj Fs0Emgbhkmb93drK6uJa5a5wlO6EH1dtl3kHPfcJSgmyyzQlLk37o16rQFRrESTj+abnBq86vaVZ wSXNLVD+HKR88yA0bB1oybIVFavqLYPgJ+pWqqk+9SrXTF+8qgm86ueAV6kq3fDchC9k/xIlxusC E9lY0Znyhjlz5mD//v1wCuKprqvEhY7zUxC9qFOnpD8wr+RpkXiceE5RJ04g6vhxGdeiXuIzVrQF 6YhYR7xEvaKOHTN4GbxKNi6wig4LwwVBZpWfxPzu5WecR9qc4okJOZ0UloSNWw8g9PhpxEsNsJvY uhKdSHDmZaOblGOekZHRWPTtH3g0aCYqthuEGk17o+Vl/dH05pGo0WGwIHKCzDXoA0ejvqjcZgCq iWu8Xl1ItfaZ49XbD0KlFoH4ZsVGme/AUR+jdMO+uaYvzngV8dn08oHwu3QQqvrot6oVY734WzU7 DEKLKwdm+t2Silf3Yp6V2hGrQWgr6sZ4SdbLm/Ea4v1oaRG8vBmvLDBqIvBqlwNePJBk6JhPcD4i HKcEb4wt0IEIxrSgaItqxmuBvfAypgX2wktj0wJEi3bo8q4f2cjoOLwzfzXeeHsZ3njvJykvvvEN anUYipHjv5BpFn+/EW/MWY4TYecRF58g0v+WKb0U8fdfW4LdxbwQnykNta1cRnfU6SOX/6sJIlq7 uT8c9fpdvE0rNbMin/c/W4tEVzIe9H8Tjpo9LbP8Wa+gpgU2srlspLFpQT0NTQt0xSvda0Fj47XA GsTIeC2wF15m4mEfvEhkSwAvrsZfiHXiQlyC+EyQ8fxCoosazHjEO1355J0q8407HY7Y81Hu/ONy l29/3oqHAmbhoX5vuj/zkOs7vi6IYC/3cr4YEKRU6SZtNmtcNhx3dJ/qHiwqPI7L73kZNz06Udqs ZkpPKf8Y6l39tMzzxkfGZ07D/NVGprRNNnUKSyCYjyDFU99dIUn47d2m+tY3rK9sZG1EZLXcBa+x jayueOVqI2u8FhR/MF4LbIaXrl4LdMWrBLwW7NhzDH2Gvw+/y4bB75qn3XLFCAwZMx/rtwTnKMt/ 24lbH58MvzaDJUFc9N3fmdNs3I+9wadk/rQlbXLzaFx945Noe+PTGb+Ri5RvNchtY1oQ8SSZWYWb p+iPVWlNSRip/cwpfdMg94al/PIUg1CNFgFpA1L/Qg1oJLJjp34tNcSSiFPTa4nB9iK8FthEjNcC 47XAeC0oZND5QIRkY1pgP2JkTAvsg1cRTQvWrN+HqTO/w9T3fspZ3l2BqW8vw4nTGb9x7YOvurWP JHKewp30XFLPTTKlzfJd2c64t/cMmf+p8CiUajYAVer1QNkGfbL/TlZpYO2BrFpR/HemHe867KXP ceDIaXS46yX387JI3Qp8IIKtTAvMgQj2Mi0wByIY0wIfB2NaYEO8zMSjWEJiIpfanWlL8xmyaccR 9Bj2Hh7qM8O9JN5rOgJHzkXw0dPyeM+HukzC1yu2uPHKh8hOfOtHREa7NywNHD0PY6YszfT9kLEL 4HDcl3nZ3FMqPg7HJZ2wbtOB9Htu6jQBjuo9cyZd0jF/LpJ1ydxTqnZDR1FXhrAzUajQ9gnUbtJX duZ2H5DSTQsKm4cg632e+hDb/w1Fs5tHuU/uskjd6mpHZM2BCPYisuZABGNaUAzBmBbYK8jNebpt HkpOgutUWIGSHjl2Fuv/3u9e7t50EFt2HpUnLeUXIiJjsX7jgYyl8s0HEXPBmZbnmYw804SE9BZB SDMtz6dJ1Q5D3UvaVdOWw/lZu7c8q57+RR2OBzDx7WXuquVjWkAtZ9hZ90SSeV/X8fVM39ONiySs uWoEA6VGcMPWQ+n33Ey70Rpe3nAk6vlw4GyZvySybZ5AvaZ97W9/WVTTgjQi21E8G7abOlc9WfL+ Y41pgTEtMKYFNjUtSE7G5wsXIiQ0xCcDLSL1sktMJ0biQSPugmaVSkaKpqcpISlBtMcEWxZ93tK/ MHX2j3JJfIpaFn9nBU6dPAu44rB6w/5My+jpaeYsTyd7XMKlBlIu31bpjlpXPAlnPpuTGJau+AeO cl3c99G2UpDPjxb9joTEJNzbZwYc5btkLKPXyWGp3VN4fGfjHAglNXEkMaIjm/7hz+6mmI9GtvOA OQg/537/Wv9vDO7oMS0zkZ34ZcGI7LbD6ffc5DMi+5abyAosyrdxa2Qra0BkMzZ7FZ7I0r74t/X7 xESGp3lZh8hSw1dFIyJLDV9D7Td76UNkS2uMV8Zmr+xEdpQisvmQ2GxE1hUXh88//RQH9u3H6dPn ERYWgdNCwtLEM57oFEQgNQUR56KREOeUxAeCCPPvU6eypw8/dhpnDh7JM08V5/0R56JkfkoS4xPE 9XP53lvQPD3LGSa/i6ancPdvOd2/5Xk9NSkJqeI7KR5xmT7iPE4Fh6b9RrR8Li6RR2HKaZm4wCvy SGi2Z+KN/Pmczp3NwOJ8RM5t5qLiaXkqTIgRcTgfESO+O5ee/oQgfONeW4A77nwed4iBM0MmFTp+ +/3j8PLUpfL3+Bv39JiK2ztPKFKeMt5lEm7vNB579x1Lx6HJdU/D4bhTyENp8qCQ+7Fu3U4gPga9 h38g/r7V43uV5j78sWEv6D900HOfuK/V6CHJZ61Lh8LJHfnquaWkSEziY+PdbT/tmX6zfDMcpR4W 93V3O7Kv+Bju6T4FP6zcgrJ0cF/lcXeeUrq7P2sq6emWWj1RSpAUDqZc4iyTJlnjl1Tuitkf/Sz7 FWmDLiZV6e+f5zsoPnsMfgfh4ZEy7WV3jJXPj3HVBka+tgilq3TN9bfKNAlEaUGk1m/an/6cb+sy EaVFefMr58XES4tn8rD/TFkmvkuV2w5B/aZ9UbNFoChDkFd/qzjjlJotAqStW5nC5lO/Ly6/cyzm f7EOZRsHoKzAxAp1LN3Evaxrd4w845WaBaJpa38t6pK1HdZo4dbIltGoXhU1xqt6C7dGtkwO/f+L k74EEpyIpp/tAhHZNOfc8Xv3YtGE8Vi1dBmeeuodDBs2G0+PeAsjRrwthXFeGzp0Ng5u2S01QLOn L8GuP7cJ2hyJ1IhzmPXGIgwcNDM9PT+HDn8bLz/7NmaNfUfGs+aZNT5I3D9zykKknjuLZNr9RUZg 3+bdCAyalu+9+eZJLeP5CMx+YzEGDnSXc8igGZgl6oHYaPlb+7f8iyDxW57XeY49TSOkeMSZPmzX PowcOlPkl5ZePJcj2/ZgmHhOOT1Dy8WHZ74+TPzN+vzwvmhIF9zP5ODWPeKZTPfK7xKLNyZ+JvGl lv6dmV9iwIAZRcpzMPOcsEC2lxQhxAjxF/D+219j8MDp6emHD38L/ftNQo/OL+O+B1/EvUL4+cBD Ywsdv+OO5zDymXfFSxeLwwL3ex96EffcP6ZIeTJ+zwNjcec9o7Hlt81uHES7nfzaPDzy6Dh07zkR vXpNQLceE/BYt/HY+usG4FQoZk77Ap3Tvs+U5vHXsO33f2gzgplTF6en6fzYaxj59By4wsMznltc DN6bvRSbVm0SvxuV3s73infwkU7j0KvnhPT8+/aZhAGi3fM3evWamOl3c4p36z4eDdoOQNlqnVGh ZheUrfEYyglR8bJpcYfjHnz6/neyX3EdP47EkBD3O8cypr2DxJrmL0MHz0R48FEgOhL//d8zuPam p+R9si7OC7JtOUrdlyl/z3jp6uL3KjyMn79Zm97eO3Z8EY5LHsgxfWHjpco8gNsFnmyXh8X7VK5O NzSv+yjq1xPfVc/8HKwWr1qvGxq37CcHnYYt/dG4lb+I+8s4j89sIQbadm36ybi63riAcRKPhs37 od2VQ/Do4+Ph18J9vaG4zk0uTVr7Lt4wnzTU7l3Xvh8ua9dPao58Ux5/GW/gcd1Xcda3ZRt/3Hhp 3/S6N8hWhuKMe68MrA/bYfu2/WS8oPc2LrG65x9XdfqPwEs+q1bWLGdh8Wou/u7ggZfCokrNx/H2 1M+RvHM7IvfsST8w5uJsZEN8YFqQmIiUCF03D0UjNUavzV5IciFZ081eSIh3i1Z4JdnGBn3ut5sx ZsIXGDP169zllUX4Y9NB9/uVj2nB599skL5WGWiO8NHidZm+X7Fmp8wv19+aslSU50uEnswwpXnv szUY8/qSvMt4sfLaYixYul7mHxPrxCszv8Ooke9j9Cufefd3fCAPDXwPjnr+bntmmlxkkVJ1e6BC PWrie+X4fb5S4TH0HPU59h0/jya3j0szU+nrNjOhGUpBJTfvDjQfYV6NAgtlWnBRdswsQ0PrLgWX 1dy0oJ5mpgU6m4JkHIhgE/dbJLLJmtpc0kZW2snqFFz6EtlU0dZTdPMyIfAyByLYMSTZopSxiSn4 +Y+9+Om3nfhp7a7MsmYXfl+7HevXbpXxbN/nJ7xn9Q4cD3e/kzv2n8QPK7fill6zUbXVIFRtP7TA UrrFILfP2+o9Mkgy44IUV2gzRJDMgMzf5SfVe6Jc3e4o1yDNHRh965Iw8zvaiXt6quD1Wr1QttVg ka5/zmksQmTNgQj2IrI6H4hQ1xyIYI1gvBbYDC9zIIK98CqBAxGKK3DykRIbqwNKQGKcV3OMdboQ fiYa4ecKLt+t3Ys7er+JWx+dgFsfm+yWR15Hz2fn4Z99YRj5xg/i7/EZ3+UrU9CzzxS0vOFZOCq6 Tzsr3eoJ+V2r216Eo1oPt79hIaWbDcSdfWbh142H8P5XG3Fr50locesYdxq6eMvN/VteQiJMLTLJ N//mRkmlYS6k5LgLPr/7bLTp0M94Lfh/7rXAHIhQuC7cHIhgL7zMgQj2wquIByJYOSQJgp4SF2f7 epCM6zY5TA/xF/Dr77sxdvJSjB3/BT5fvl1ePnQyCi+/+SPGTvwSYydkXPcMB45HutNM+lKeXHax ctUjkwV5DcCjT3wg/65/8xj3ccOFMd9QUrc36jXzMNuo0zvv9NykSQ8kBTHzUKYdNK3g3zmZWJAY M12jAJ8Qo3oaHlGr5YEImUwLbKKRNQci2CuYAxFsiJfOpgWaElmSv5R4+9trSyKrKUYpsl4lYwIS Gh6DlX/sgzPJ7ed5Z/BprFy9AyvX7iq0BI1ZiObtBqBqm8Go2m4o/McszjP9st924ra+b7vNPDoM zVPKKNMOkkr6im7SP4upRj5mHkrjXEgxByLYS8yBCFYajIxpgb3wMqYF9sLLmBZYPsjJhq4YiQm9 HuYf7uBKdCF0536En42Wkpz/WSiIdSYVyMzjh9/34n+93sT0+evk37MXrsetXSYLmZRu5tHt6U+x Zd8pPD9zWTYzj1rXPJtx2l5BzS/8+rr9DlNTXb0rytXOap7RK81E4mJNMjJrDzPFi9HcwpgWFILI Lly40HcaWV01RrpqZHXGy5gW2AcvnTWyOpkWGIzsgpZ0VWfFsHZrCMZO+VrI0gKZXowWaf1uHA1H iyEY+NIijB2/EM+P/ihTmuu7vJHhTYPa4oIK7ZOVyQTjPORFxfl9PWWeUUBRHjMaBWaYaTTM3wyC pgUNNSWyVXIzBalYBCKbKAbD+fPn48iRI0hNTUVKSorXJNnpRCK1D17M0xIinlOSIEUu0YmnePmZ laRojxeXdHXCS0wUEwWR1RIvMUl0kUxohJcS1itJkEDbYyQGG4ORTfoKl8unfYUgD+KfO87PVPl3 atr11HRuob7zvF6YsHXvCfy28WDGhdTETN8fOxOD5at3YMXq7Vjx2w4sF7IiTfKKv/7uz6h+5VOo etkITHj/Vwx+ZQmqXvE0xr21Qqa5ve9bqNJyEKq0fyJPqZr2Ke2CeUiM+ORhKNWk6UWQ9HShDotx NPJHqSaBbrJcq2e6VPHrnvG3Z5qG/rikWX8ppdM+bRNv2h/VWwahfutAGfdMU6pqN3m0eHJyEqLE eF1gIhsrXlTeMGfOHOzfvx9OQWTUdZW40HF+iryjT52Sjm29kqdF4nGCQESdOIGo48dlXIt6ic9Y 4nXypJ54iXpFHTtm8DJ4lWxcYBUdFoYLYlKlHH7bEiMxVrBvjwoN1ROj06dxgacL2RijTH2FmBjK voJxDTBCColrMpzsK8T7FBUSkqkdpvBIcmqhkZomBYtTsRdyPBxHQsOQ6EqU+B85dhoJiQkyzZlz kTgacgohx8JEmlM4KtLlFA89LuInwjF25ne4q/skPD/9O+wNPo7w8HN487O16NR/Fjr2m46H/Geg 5pXD4WgWhNu6TsYjgTPQMWAGHhWfA4e+iYdFXKUp1TwIt4o0ftc/LQgt7Y6pIU6TvOL1e6NS6/6C XA9GjQ6DBZkWklO8/SBUbTco7zRFjFduNxhNLh+EdlcORMV2mdOUa9gXQ8d8gvMR4Tgl+hZPzEt+ s5euS9XGa4G98DKmBfbCy5gWWB8jjb0W6GZakGqjw1Muuh0KnOxsq/3Zj1sx+cNViHFm2VwYE5Up zdSPVyMqPglfr/4XL076Ci++8U2B5Ilxi1Cu/Qj3Jju/NLMJPw9Rf9fq7db4el7zgZeJgngt4ATC KdpsXHy88Vrg05fHeC2wH15m4mEfvDQ+EMF4LbAJRroRWV37ChJZ3SZUKclIPuc9vDbsCMGAFxej WodhqNbuCfenkrZDUPPqZzBJkOmnJn+bKU2BDxPJ6xAQaV6RkSbHAxGYxvEQnnxlkSzvsX//xeYv vpC2sgkpKYjN4bhaSWTjCH5ysrzpyy+/RLivdj9rtPMzU3C55Mll2gXRQLQMoiPXEi/dTpdTgX2T 06ln3XQhSLSN1BUjTjQKab9p2aBrX0GcNJgYFgde8QmpQlLSPtPEmQKnK3uaWGcqXn1/LR7sPQsP +s/BgwG5yzUPT4Gj4UA46ghCWjcgQ2r3Q5UrnpVpru00VaYpW78fajXhxjdqaAeIdP6ofPmzuFd8 /9m3m2UZjm7ciJfr18eiAQNwcP16RIuJSlZTA0lkaYOwfPly/PDDDxgzZgzmzZuHFStWyGteEeYl 8l729dfuuLfytYL89BOWf/utWxjXoU7E6Mcf9cSL9fnuO4OXwcsafcc332D599/bGzeWnXVgXQxG 1sdq2TIsW7pUz75Ct3boiZcX8/155U9YveqXHGWVkJU/rciWZs1vv2LtmlX5yrufLMEN9w/H1bcG 4Orb+2fIfwPQbch4meaD+V/ihgdG4Kr/9ME1N/dFvct7COJ7H5pc3h09npiAX1b9il9/+Rk/Chw/ nzkTL9WqhVEVKmDWLbcgZMcOQbZd2YnsmTNnsFGw3k2bNmHy5Mn4WgyIjP/111/ekQ0b8IcAZM0n n+Av8Ttey9cKIurz+xdf4PfFi/GXN59ZSQrxWrkSa+bOxV9//60fXl99hd8XLdIHLzFL/ePnn7Hm 44/1xEv0R2sXLtQHLyWiPmvnzcM6MfjaGjeB0TpBHtZ+9pmeGC1YgHViMqXF2MW+YtUqrPnoIxnX ra8gTsRLp779z9WrsebDDy1RnvXr85ctm/7G/j3bcWDfThzY6yHi7907/5FpNjPN/t3Y++dv2LPs G2zcthUrf1mDf7ZuwZ5dW7EhrW1u3LYNywVvfNnPD4sHDsS+tWsRefZsNvMCSWSppqV9LANtZA8e dLuy4DVvCI0W6O4jbvNmGfdWvpl+IznZJ/kWpG7OAwcQv3evT+rGeikptnoRL9FY4kRn4Eu88quX L+os8RLtO37PHq/WLWtdihWv1FQkRkQgTnTk3sbLE6eSeMckXocPI273bi37jritW5Fw/HiJ9B1u i4AU72B05Ajidu706TtVElhJjHbsQEJoqE8xKs6+whUdjdgNG5DkBezzwqa460Z8iBPx0qavoPu3 mBjECmKXxN/20e/nhpXLlWFnwLjX8RJ9X6zoAzMslJKz9VGnxXi9QUxOYkS7pUFgbA6bvjJt9kpI SMBvv/0mN3sp91teE1GIGLqZ8WaeQmgAzLKyQ+ZnQZznel3o5ywy0uv5sj4Ek25AKPm5oLADXtJd j5hN8aVQL0ZubY0vlk/q7GW8pBG6eHfYBlle/s26xYsXrrjaI3/H23ipd4s4sP0RqwQPtzbF+X7F EC8ftAW2RdarRPoNPmPWS7xr3s43Ns3vqeo7ckrDw2/CwsLkM7AaRp79unqn+Dd9jRZrP8iy8L3y AUYU9hM+6+dyEx/0FSw/sVF9HtsU/y72MdmH45ZS+BV7P+EDvHJ619gWs2LFvuOnn37C33//nWs/ UmS88hmLYy/WawElmhn7quH54GXlw90qGH3v3r2lOQT/5svEzoH1UPHYLBvNvEoyWC8v142EYffu 3Rg5ciQef/xxzJgxAzQBYbnVLEnVy+1c2r0ZwasTEB8RB36+88476Nq1q6wfD+BgfVVd3Db7qXjl lVfkNYWlV+vlxbqxfN9//z1GjBghfTHz7zfeeAN//PFH+ixX4aU2VqqBi/X1CpHwAV4s56+//ooH H3wQjz32GIYOHSrfMVeafZJqh6yDwtYu75fqO/bs2YNx48bJuniWn+8R26R6r/jpNZyKoe84duwY OnXqhC5duiAgIABn0w438azLHXfcgdDQUHmtyBMUH7xTP//8M5588klERETIMq9fvx79+vXDiRMn 0kmtWjlUxElhZ+X+Qr0rfOZvv/02nn32WdlvqL5d1YNxRRC9Xi8v1oflYjsaMGCAHLNYXu67CQoK kooxYqn6CkV2VR/I+jAenwdJsUJfwTpSwffiiy9K7FS/rcrPvsTzQAf1nZXHYs93bdWqVZg5c2b6 oRaKuDOw3589e7aMW7X/y0ZkY7M4Sba6MEycOBE33XSTJD4MfIlIbvlyML5t2zbZEFevXi0Nnf/8 80+pifDay+OjerEBDR48WA62n332GQ4cOCBfFv69aNEibNmyRdaL9s2s27fffptOdq1aL74krAs7 PZb7tddew3PPPZeu1aRdDDVF3HDYvn17vPfee/j333+9v0LgZazeffddNGzYUG6YZODEirbmDOzc WSe2Qw5YrLfqHDdv3izbqE9IkhfqxQ6MA9Lhw4dlvE+fPggODpbf8eAUtkPWhx05J8ErV66U+JJI WRkzCgkQNQ0PPPCAfK/OnTsn6/PFF19ITFgHtkdiygGZbdQOfSNJwz///IN77rkH58+fl30d3y2a jLF+SrtCovvVV1/hu+++s1x/yMB3pnTp0rK87DcmTJiAChUqSNLEwZeaIqbh+8W2x36d/fuhQ4cs 3/aIBwk5J4h33nknfv/9d9kG2dcxTlz27dsn25yqF987K9aLbYnKCGLDPoL14HjkcDikFyQGjlU0 W+TknpMq9nvEjPeyX+S7ZsU+MOukl+8UseP7pcZalp9j84YNG7Bs2TL88ssvsm5Wrk/Wd419dmBg oOwTiQ3Lzgkk+/hRo0bhgw8+8A2R9ZJkI7J2EjYuvtwvv/yybET8PH78ONatWye1mAx8oTiLZ6dH 7cTo0aPRrl07rF27Vr5wVh5k2QkMGTIETz/9NH788UfZme/cuRPDhw+X2r/+/fvLAfb222/HE088 ge7duxNQOdha9SViIDn/5ptvZJyu3h599FH50rCz7tatm6wfpWXLlhg0aJDE0JVll6LV6qQ0K5zV slMbNmyY1ChxUGX78/f3l58ken379pUdIdtu586dZfoSWbIvYL1eeumldE0D2xw76pCQEKktYztk B8j36eOPP5b4PfXUU3IQtjJm6h1jp00ywb6AbZAaF06ypkyZgvfffx/XXnstxo4di4ceeki2WaWt sDqR5aB75ZVXSuy4OrBjxw7ZPhVefKceeeQRiWevXr2kt5rIyEjL9Btqvwa1xpzMsn2xf+fffKcY eJ19Iyf87N+vuuoqWb9du3ZZvu1x7Fq6dCk++ugj2bez32Bgfe666y5Zp4EDB2LNmjWyXuwPiaEV 68W6cJJ06623SmUSifesWbNw3333yYkTA/uM559/Xq4OcPLB8Yoadt7PflGtploZL/ZpHKvYB3Ts 2FHiwcD3h5vk2VfwfWNfwTraoa9Q79qSJUtkf87J/P333y/7Rr5nVMiQM7GdGiLrQwDmz5+PK664 QhJXdtx8cTg4kdQxUGXOl4bEgsu/DFwq5XUrE1mSUQ4snBGxo+OLw86CL0jTpk1lfdipc4meAzFn xNS+3H333Th58qRlNRIMHGyocWVQZI4zW3bcxFMFaoxUiPaRjZo3NZfUGLE+06ZNk2YT7Kg//fRT 2UEwcJIxadIkSYjYOVAbTZJR7PbPF0lkX3311fTlMpJwamCpxWvcuLFshxx433rrLfTo0UNqx9Sy qJUxy4nIckWDpJV1vOGGGySOrB8Dj+6mGYyVO3NPIkscbr75ZkkG2X+w3yBeJEjUKpFoEC8OxnwO vMb+xSoTKoa5c+dKgk2S8PDDD8u+gRNC9nVccWO7JMFr3ry5fP84iVL7CkrK5rkgoswKWF6+O5xQ sL2xD2Abe/PNN2X9OYlnf8F0nuZyViR51CQTm08++URixXfnhRdekOMxxzH+zYkUyR5Neah4Yn/I tsnvlBmgXYgsMePYzMBVKvb9XLlS2k1yDjv0FVmJLCfz5EdqbCamhsj6UNgRUPvK2RxJETs3NiCS Ic7eSY6oIaJ2pWfPnrJTZONix3799denL+VYtX58WVhWEgl+cvmTnQWXOjnwUnNEu1nOZDkITZ06 FePHj5faTnYcVu0UOMhQU0lMuFzBznr69OnpZIF4cdClVoUdOL+zg2kBn78iOiSqFStWlJoJdtic 1dL0gASJkymaF9xyyy1S07KX3i7EAGXVerH9cYZOMwlqWjkJ4aBDks7JI4kf2yGXDhnnMtTixYvl u2n15V0+dy4L8n1i4OSD2hUOsCQW1K6wPmqiQhJoh8GJ7xj7BTUgMRAv1pPEUPUbt912m9SgcTJF Tdnp06ct028wcJLONkfSSs0xJ+jU8tHsg2Vm+anJpAKDk0L2F2pzmJXxYRnZD7CtcWWGZjskESTq xIcTDI5d7C84ppE8FfuGsIskeVwpZD/B956Ejn9zEqgUSySwNAEkfrzOsZcTFD4D9pNWHovV5JDE jsoVlpV1oIaZBO+6666T5FxNeslH+D7ZicjSlIWTQr7/XLnmZIr9H/sQrhJwbDZE1gfCQZLklSQv Mu1oRBIEvjjsGLhMTWLB5SeCxMGXHSMHJpIIapWsSiBU/agh4YycnTkPqFAzeS4LssNjXdQSIZdC SW65pGhlAsHOmB0f8eEMnfhwFshr1ChzOZdkiSYT7ODYwXNZyspLhSw7J0bEiOXk8gwJILEgqaCm j3UiQVf157LiggULZMdhVTMQtZFSLUmTNNCkgHVkG+OEkW2O7xmXQGkzRs0E09rBtIDvPzXLJA4c nFgfvlec9FKTzlUbLlnzObAt0v7Nysufnn0HcWL7Upso+UmTK4UXN/FRC0PNLDUu27dvt1S/wefM SSAJn3IRxvIRF7YzmuNwwsEJBvsMtj/Wx+qTJ1U39mnsu9kG2fY4cec1YsPJPYkR2x5Ju+onrFof lo0ElgSO7YxYETO+W5zgcmWGE3ni9eGHH0otLAM/qVxi+7Ry/VRfQbw4GWT9qIBgX8H2x0kHv6Mt PbFlnanMsENfoTZYk7gqRQz7QTU2853iuMaJsJXrY1siq5YiPHcIql3HnjtaPXcRcobBhsiZIcmG lV8e5RIj4+S91Ewzes96URMRk3aEHRublZfVcquDJ35qJ7I6NtnqS4Usm+q8Peuhlmk926LaqauC 1d+xxCxH+XrunFb4KIziPY6GLDFXeBehteSKAJd2SZaUGyTPwL8Vpp742qlv9CxvVrw8g9UmHcqF Hd8dz0126h3iu5UVq6z1tTI+ym9n1veMygkSQOUNJCccrdzeFDniNWKnzKayBpodcFWOEyirv1d8 V6iEoCkfiR3bXtZ+UU1IsrZbq5NYlpu25zQH4WpvTv0g8cnJNZchsiUknEVxmdrKS++FEc7a7dCB GzFiFeFkg1pLLhfq1BcYsa+QWHDzK1eo7OQ5qDDvHu1LqVW3w85+lpFeFVR5dcKGdWEfyL7QDqsZ hshecC/pKEf1OtXLijvejRixurDjtupGOyP/f9ukXdw2FXXMstO7R86ga19BLJQJkiGyRowYMWLE iBEjRowUN5Hlf0aMGDFixIgRI0aM2E3+D4Rd5d5I2j4WAAAAAElFTkSuQmCC --_004_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_-- From nobody Tue Aug 5 03:28: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 C906A1B2959 for ; Tue, 5 Aug 2014 03:28:30 -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 VQceVVBpgCWW for ; Tue, 5 Aug 2014 03:28:29 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1DD1B292B for ; Tue, 5 Aug 2014 03:28:29 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id a108so720730qge.24 for ; Tue, 05 Aug 2014 03:28: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:content-transfer-encoding; bh=NwuBPNaxY3QndRCwrjNSzY3UfqkWyRb6qJWnmiaNfnk=; b=hN1SuxfIYAHIGYWtcLm2yeZi3MsA610tZ/cwDqCWtRHu6aDWljd4LJuxz9iZGOOcpE jUrd8cW9HPqkO6k6vZODX+ctrtXohjrcysJibHoI7SQkihR2sx/xfoJ5QidZeWhgx9aI ZIke/ylkTvyA21yE96JbZ2Q4UnGVyqzyfh7vRXnRoBBZS5H10wd3rmM5OH0inZZvnaAh pnidTl6jq8A7uo8hZAghuCAiMYAImRjMY+LXG0Zqf7T5C/zc1sPBLA15MN7fwnaC/SD7 t70qO+MuA4AKgSMztTRJQZqmP16DAGM2AhxNMaXwIPOTfGHvVD2PJDaamfkIXMwEL4b/ hkEA== MIME-Version: 1.0 X-Received: by 10.224.119.193 with SMTP id a1mr4221010qar.18.1407234508240; Tue, 05 Aug 2014 03:28:28 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Tue, 5 Aug 2014 03:28:28 -0700 (PDT) In-Reply-To: References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> Date: Tue, 5 Aug 2014 18:28:28 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5Ihc1oEPO0ZZ4ANH5-hDGKpU8tg Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 05 Aug 2014 10:28:31 -0000 2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson : >> Section 7, discussions, says =E2=80=9Cdual-stack deployment is recommen= ded in >> most cases=E2=80=9D. >> Is that still the consensus position? Going straight to single-stack IP= v6 >> is looking very viable now >> when the UE supports a method of providing translated IPv4 access over t= he >> IPv6 PDP/PDN >> connection. > > I don't think there is consensus here. The draft could point out pros and > cons with each approach. I'm not a fan of dual-stack deployment. However, I have to point out if you take look at TS23.060 or TS23.401, you may find the sentence "A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". GSMA quotes the similar language from 3GPP for roaming guidance. Therefore, that is at least a consensus in other SDOs. The draft intends to state the issues and potential workarounds in various scenarios. Argument of selection of dual-stack or IPv6-only may not be the goal of the draft. BRs Gang > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 5 03:53: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 636281B2984 for ; Tue, 5 Aug 2014 03:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGh3lC2uTsAf for ; Tue, 5 Aug 2014 03:53:55 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010: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 BA57A1B2951 for ; Tue, 5 Aug 2014 03:53:54 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so559580lab.21 for ; Tue, 05 Aug 2014 03:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2eGAmoUbTBQCYZW/O9x7mEsyuNKKhAmh5mWAhXJP0AY=; b=Pf6g/Pbg30/kP+99EhzCweTnSU+kKvTO5aQS0MUs7G9bZbJxXgnoRYYF/H+qNl72W/ ZliJqofH6MR2DrOU9fCv8e5H9v57LJMJtfCv0FmfjdhDX/Tr/u22TBUvYH2t4ySTuGFq 661kfR4wVXCZszsMWPUp0+OVQWsauyXg/wCf3VKF3My4WI7o3oBAFsfpV8z1aF2ltWCv frKPuHVg277cHTEb//hoSuIyzpD58p/dMCGMw36aDjP5uV/bR+PtxiSk4Xy1l0rMTrWj Z8f3JKTL7g+rVgoJVogHRUjivFAUvzGb0V9yJbJ+Mu59kWs+NXxhy5UBvL7T7cflpq4p wG6A== X-Received: by 10.112.30.39 with SMTP id p7mr2945766lbh.35.1407236033083; Tue, 05 Aug 2014 03:53:53 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id qv5sm2166043lbb.19.2014.08.05.03.53.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 03:53:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: Date: Tue, 5 Aug 2014 13:53:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> To: GangChen X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NstQ8G0e1tsb92D7WmZvvNQctrc Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 05 Aug 2014 10:53:58 -0000 On Aug 5, 2014, at 1:28 PM, GangChen wrote: > 2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson : >=20 >>> Section 7, discussions, says =93dual-stack deployment is = recommended in >>> most cases=94. >>> Is that still the consensus position? Going straight to = single-stack IPv6 >>> is looking very viable now >>> when the UE supports a method of providing translated IPv4 access = over the >>> IPv6 PDP/PDN >>> connection. >>=20 >> I don't think there is consensus here. The draft could point out pros = and >> cons with each approach. >=20 > I'm not a fan of dual-stack deployment. However, I have to point out > if you take look at TS23.060 or TS23.401, you may find the sentence "A > UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". > GSMA quotes the similar language from 3GPP for roaming guidance. > Therefore, that is at least a consensus in other SDOs. >=20 > The draft intends to state the issues and potential workarounds in > various scenarios. Argument of selection of dual-stack or IPv6-only > may not be the goal of the draft. We had this discussion a long ago.. and back then we agreed not to = promote any specific solution (like XLAT etc) but just give facts how = different approaches work. - Jouni >=20 > BRs >=20 > Gang >=20 >=20 >=20 >=20 >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 5 04:32: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 240391B29C3 for ; Tue, 5 Aug 2014 04:32:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a56b5p7UYk8g for ; Tue, 5 Aug 2014 04:32:50 -0700 (PDT) Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id 53D0F1B29C1 for ; Tue, 5 Aug 2014 04:32:49 -0700 (PDT) Received: (qmail 92890 messnum 323570 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 5 Aug 2014 11:32:48 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail19.svc.cra.dublin.eircom.net (qp 92890) with SMTP; 5 Aug 2014 11:32:48 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id azYl1o00i0mJ9Tz01zYohX; Tue, 05 Aug 2014 12:32:48 +0100 From: Ross Chandler Content-Type: multipart/alternative; boundary="Apple-Mail=_7D0763D4-2311-4F49-968F-15DBD0D3CE12" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 5 Aug 2014 12:32:41 +0100 References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> To: v6ops@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sq4DWg0E29B23EyvR2lDtHiDut4 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 05 Aug 2014 11:32:55 -0000 --Apple-Mail=_7D0763D4-2311-4F49-968F-15DBD0D3CE12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 5 Aug 2014, at 11:53, Jouni wrote: >=20 > On Aug 5, 2014, at 1:28 PM, GangChen wrote: >=20 >> 2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson : >>=20 >>>> Section 7, discussions, says =93dual-stack deployment is = recommended in >>>> most cases=94. >>>> Is that still the consensus position? Going straight to = single-stack IPv6 >>>> is looking very viable now >>>> when the UE supports a method of providing translated IPv4 access = over the >>>> IPv6 PDP/PDN >>>> connection. >>>=20 >>> I don't think there is consensus here. The draft could point out = pros and >>> cons with each approach. >>=20 >> I'm not a fan of dual-stack deployment. However, I have to point out >> if you take look at TS23.060 or TS23.401, you may find the sentence = "A >> UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". >> GSMA quotes the similar language from 3GPP for roaming guidance. >> Therefore, that is at least a consensus in other SDOs. >>=20 >> The draft intends to state the issues and potential workarounds in >> various scenarios. Argument of selection of dual-stack or IPv6-only >> may not be the goal of the draft. >=20 > We had this discussion a long ago.. and back then we agreed not to = promote any specific solution (like XLAT etc) but just give facts how = different approaches work. >=20 > - Jouni The TS23.975 recommendations do allow for a second strategy. I can=92t = find TS23.975 explicitly saying dual-stack is preferred or recommended = over single stack. Although at the time they were writing it they were probably implicitly = assuming that. TS23.975 mentions DS-Lite, NAT64 and BIH but was too = early for 464XLAT, or MAP-T/E. "The second strategy, consisting of providing the UE with IPv6-only = connectivity, can be considered as a first stage or an ultimate target = scenario for operators.=94 So there=92s an argument to remove =93dual-stack deployment is = recommended in most cases=94 from this draft, particularly if it has = already been discussed and agreed not to promote any solution. BR=20 Ross= --Apple-Mail=_7D0763D4-2311-4F49-968F-15DBD0D3CE12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 5 Aug 2014, at 11:53, Jouni <jouni.nospam@gmail.com> = wrote:


On Aug 5, 2014, at 1:28 PM, GangChen = wrote:

2014-08-05 0:31 GMT+08:00, = Mikael Abrahamsson <swmike@swm.pp.se>:

Section 7, discussions, =  says =93dual-stack deployment is recommended in
most = cases=94.
Is that still the consensus position?  Going straight = to single-stack IPv6
is looking very viable now
when the UE = supports a method of providing translated IPv4 access over the
IPv6 = PDP/PDN
connection.

I don't think there is = consensus here. The draft could point out pros and
cons with each = approach.

I'm not a fan of dual-stack deployment. = However, I have to point out
if you take look at TS23.060 or = TS23.401, you may find the sentence "A
UE which is IPv6 and IPv4 = capable shall request for PDN type IPv4v6".
GSMA quotes the similar = language from 3GPP for roaming guidance.
Therefore, that is at least = a consensus in other SDOs.

The draft intends to state the issues = and potential workarounds in
various scenarios. Argument of selection = of dual-stack or IPv6-only
may not be the goal of the = draft.

We had this discussion a long ago.. and back = then we agreed not to promote any specific solution (like XLAT etc) but = just give facts how different approaches work.

- = Jouni


The TS23.975 recommendations do allow for a = second strategy. I can=92t find TS23.975 explicitly saying dual-stack is = preferred or recommended over single stack.
Although at the time they were writing it = they were probably implicitly assuming that. TS23.975 mentions DS-Lite, = NAT64 and BIH but was too early for 464XLAT, or = MAP-T/E.

"The second strategy, = consisting of providing the UE with IPv6-only connectivity, can be = considered as a first stage or an ultimate target scenario for = operators.=94

So there=92s an argument to remove =93dual-stack = deployment is recommended in most cases=94 from this draft, particularly = if it has already been discussed and agreed not to promote any = solution.

BR 
Ross
= --Apple-Mail=_7D0763D4-2311-4F49-968F-15DBD0D3CE12-- From nobody Tue Aug 5 04: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 CBC151B29FC for ; Tue, 5 Aug 2014 04:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkIN7lo01lVL for ; Tue, 5 Aug 2014 04:52:58 -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 879751B29E6 for ; Tue, 5 Aug 2014 04:52:58 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=57782 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 1XEdIW-0006Ai-IA; Tue, 05 Aug 2014 13:52:56 +0200 Message-ID: <53E0C548.9050706@fud.no> Date: Tue, 05 Aug 2014 13:51:36 +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: "Fred Baker (fred)" References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> In-Reply-To: <53DFD634.4020304@fud.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JzJBuOqhWz2gy_MmgaKCBLeNXbQ Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 11:53:03 -0000 * Tore Anderson > Eerily good timing... I just started working on this again today, as it > happens. What I'm looking at now is two drafts, the one that's already > there for a single-translation network-only implementation, plus another > one describing an extension very similar to 464XLAT that would allow > NAT-incompatible and/or IPv4-only applications to be used in an > otherwise IPv6-only data centre. Here you go: http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc-2xlat.html XML sources and .txt formats at https://github.com/toreanderson/ietf/. They're work in progress obviously, I haven't uploaded them to the I-D repository yet. It would be nice if you and Lee could have a chat with the sunset4 chairs and agree on which WG is the most appropriate first. (I have no particular preference, but I want it done Right.) Comments, criticisms, suggestions, pull requests would be very welcome! Tore From nobody Tue Aug 5 05:56: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 108121ABB17 for ; Tue, 5 Aug 2014 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jClyRUJ_T65p for ; Tue, 5 Aug 2014 05:56:32 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) (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 375AC1A8BAF for ; Tue, 5 Aug 2014 05:56:32 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.9/8.14.9) with ESMTP id s75CuNbG027940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Aug 2014 08:56:24 -0400 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.9/8.14.6/Submit) with ESMTP id s75CuM0d027935; Tue, 5 Aug 2014 08:56:22 -0400 Date: Tue, 5 Aug 2014 08:56:22 -0400 (EDT) From: "William F. Maton Sotomayor" To: Tore Anderson In-Reply-To: <53E06AC9.9010908@fud.no> Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> User-Agent: Alpine 2.03 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jr2M3U4xfhw33YLvleVMOgscbwg Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 12:56:34 -0000 On Tue, 5 Aug 2014, Tore Anderson wrote: > * Brian E Carpenter > >>> (In parenthesis, I've never seen sunsetting IPv4 as a real problem. >>> One day somebody will notice that there are no more IPv4 packets. But >>> that is many years in the future.) > > The thing is, if you've built your infrastructure on IPv4, removing it > is going to be a royal pain in the arse. Even if all the IPv4 users have > left the public internet, if your application server speaks to your > database server over IPv4, and the database server speaks to the iSCSI > array over IPv4, and so on and so on, then you're simply not in a > position to easily shut IPv4 off. Worse still is all the gear to workaround NAT, so it isn't just the usual suspects of desktops vs servers vs appilcations, but also the point-to-point setups (video conferecing comes to mind) I have encountered that require going around NATs. (There is something to be said about a net gain in maintenace overhead in elminating some of that, but there's also the effort to remove it and test, etc.) wfms From nobody Tue Aug 5 06:29: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 E07D61B27B7; Tue, 5 Aug 2014 06:29: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 QJIjjctVC6DI; Tue, 5 Aug 2014 06:29:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3181A1B27C4; Tue, 5 Aug 2014 06:29:32 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805132932.9415.45052.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 06:29:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/awYvXFJP9LVVfTDTrnNCcMGS5Lw Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Protocol Action: 'IPv4 Service Continuity Prefix' to Proposed Standard (draft-ietf-v6ops-clatip-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:29:40 -0000 The IESG has approved the following document: - 'IPv4 Service Continuity Prefix' (draft-ietf-v6ops-clatip-04.txt) as Proposed Standard This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ Technical Summary DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. Working Group Summary There was support in the working group for the draft, and little if any dissent. Document Quality This is not a protocol; it is advice to implementers of 464xlat that the prefix set aside for use with DS-Lite may also be used by them. Per Lorenzo Colitti, it is implemented in the Android OS, and works. Personnel Document Shepherd: Fred Baker Responsible Area Director: Joel Jaeggli From nobody Tue Aug 5 08:00: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 AF5BE1B2864 for ; Tue, 5 Aug 2014 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, 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 78QVFzQD6VCd for ; Tue, 5 Aug 2014 08:00:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A576F1B27F6 for ; Tue, 5 Aug 2014 08:00:12 -0700 (PDT) Received: from [10.0.0.11] (ip72-199-16-177.sd.sd.cox.net [72.199.16.177]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s75Ev8DY004832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Aug 2014 07:57:09 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s75Ev8DY004832 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407250630; bh=vVgo202Bmbsx+V46IMpPJKD5AUU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pRIBAdmoqtJt8fsINkyo5My2vbLBrOXeYCRUwB5PzvhZkSkcDsjyMKARS2wpVjxe6 XdAMkBnRVzaX+WvCi6swPvYi24xrkL6oXLIrLNuDM0orwh0b3tprZQ3IONt9DvFLE8 Bv53Inn81ubk9MiQcxqhAlh+XPjs+ZBZIJz5nVAc= 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: <53E06AC9.9010908@fud.no> Date: Tue, 5 Aug 2014 07:57:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 05 Aug 2014 07:57:10 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SUBBK2iaYFN8o6lfb_IuS78C9Jg Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:00:18 -0000 > The thing is, if you've built your infrastructure on IPv4, removing it > is going to be a royal pain in the arse. Even if all the IPv4 users = have > left the public internet, if your application server speaks to your > database server over IPv4, and the database server speaks to the iSCSI > array over IPv4, and so on and so on, then you're simply not in a > position to easily shut IPv4 off. Yes and no=85 Upgrading your application to be protocol agnostic about its connection to the database server shouldn=92t be very difficult these days. Once that=92s done, getting your database server to speak dual stack = also shouldn=92t be very hard (you=92ve been talking to your database vendor = about this for at least a couple of years now, right?). Surely your iSCSI clients and servers are also on their way to being = protocol agnostic since you=92ve been having those discussions with the = appropriate vendors as well, right? Seems to me that your database server should speak to the iSCSI array via configured hostname(s) and that if the client and server are = dual-stack capable, then adding IPv6 addresses to interfaces and AAAA records to DNS should be about all that is required for the communication to move relatively seamlessly from IPv4 to IPv6. Likewise with your client <-> database communication. Once that=92s done, it shouldn=92t be too hard to remove the A records, = wait for IPv4 to stop carrying traffic (or pick a maintenance window), and drop = the IPv4 addresses from the interfaces (with appropriate regard for = quiescence and/or restart of the various services/clients). All of this should be achievable with 5 or fewer maintenance windows (2 = or fewer if your software is up to snuff). Owen From nobody Tue Aug 5 08:08: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 743FB1B2896 for ; Tue, 5 Aug 2014 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylnrWeI2y5A1 for ; Tue, 5 Aug 2014 08:08:18 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A3E1B2890 for ; Tue, 5 Aug 2014 08:08:17 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so1179848wgg.24 for ; Tue, 05 Aug 2014 08:08: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=F9gBWimGsgBsoe3GyWKCP4ilcWYcUGcoNKOO4o31gpY=; b=vuEhrpkuWs+d4xs5n9jGJgYDuNHgY2gU8o+Y+64Z1JnKvjwPkVmZPZxPmCsjigZTDl KOdzTeNUG5h9VUuxqQJAVzZbaABTKFT+/OtGxYAcjJKSOkRye2SVfBPwtjnWNDrQtcRw l7mxafRQuGmhRQsxceHKg2S30JglPS9vBHMzQOlTNe1L79T3V4z5NBe3cLitZaZqhy5E BY1JAM1KP8yTloqS6f+KaCrPHtifg2Ze360F5k3q3CRkXf6TizvsZMJOCCiE3cjCcKII Ieba2KKVL5ebtTzqfi8Hjlq835mP4F8Mjp7EGaRifM8o8sStAqoJayZvrtMIS6X/cvMP chHA== MIME-Version: 1.0 X-Received: by 10.181.13.44 with SMTP id ev12mr42043841wid.57.1407251295036; Tue, 05 Aug 2014 08:08:15 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Tue, 5 Aug 2014 08:08:14 -0700 (PDT) In-Reply-To: <53E06AC9.9010908@fud.no> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> Date: Tue, 5 Aug 2014 08:08:14 -0700 Message-ID: From: Ca By To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jD_2vlMYgtccJ2SgUiV06uW9Xng Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:08:24 -0000 On Mon, Aug 4, 2014 at 10:25 PM, Tore Anderson wrote: > * Ca By > >> With 464xlat, afaik, there are globally 3 cellular providers that offer >> default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ). > > Make that four, Telenor Norway has been doing IPv6-only/NAT64/464XLAT > since early June. > > http://www.telenor.no/privat/kundeservice/mobilhjelp/internettpamobilen/feilsokingmmsoginternett.jsp > > So far only one model (Samsung S5) defaults to the new IPv6-only APN, > but from what I hear they'll keep adding new models and push OTA updates > to other existing ones. > This is excellent. Well done Telenor. CB > * Brian E Carpenter > >>> (In parenthesis, I've never seen sunsetting IPv4 as a real problem. >>> One day somebody will notice that there are no more IPv4 packets. But >>> that is many years in the future.) > > The thing is, if you've built your infrastructure on IPv4, removing it > is going to be a royal pain in the arse. Even if all the IPv4 users have > left the public internet, if your application server speaks to your > database server over IPv4, and the database server speaks to the iSCSI > array over IPv4, and so on and so on, then you're simply not in a > position to easily shut IPv4 off. > > Tore > From nobody Tue Aug 5 08: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 0EE621B289E for ; Tue, 5 Aug 2014 08:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, 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 yX-IVERcxjF0 for ; Tue, 5 Aug 2014 08:17:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id ED0C41B289A for ; Tue, 5 Aug 2014 08:17:11 -0700 (PDT) Received: from [10.0.0.11] (ip72-199-16-177.sd.sd.cox.net [72.199.16.177]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s75FBCN6005565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Aug 2014 08:11:13 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s75FBCN6005565 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407251474; bh=YKVL6GvvhEHEX/Na3TBNs4l5ujU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nzNJCfCdzvJdW/hioBA7EkM4h2FkUnij+rcyifxqHXktxAJQyChsQJFAcMIFH9TFv GbuTSpOdo7HPRW1uIpXxSYKZVBSWrFA8SaR+5Rfe2ReWldaY/BDXS3VwDy99qKx7Ho +nI9fs1OdIkzZ2HLuKIYoRoVl4ICp6JR1JqDjQVo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: Date: Tue, 5 Aug 2014 08:11:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42E9089E-CA04-418F-8B23-D89BB1452D86@delong.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> To: "William F. Maton Sotomayor" X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 05 Aug 2014 08:11:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/y7koKkeGw2TEMXiZJmXu4vd28qs Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:17:13 -0000 On Aug 5, 2014, at 5:56 AM, William F. Maton Sotomayor = wrote: > On Tue, 5 Aug 2014, Tore Anderson wrote: >=20 >> * Brian E Carpenter >>=20 >>>> (In parenthesis, I've never seen sunsetting IPv4 as a real problem. >>>> One day somebody will notice that there are no more IPv4 packets. = But >>>> that is many years in the future.) >>=20 >> The thing is, if you've built your infrastructure on IPv4, removing = it >> is going to be a royal pain in the arse. Even if all the IPv4 users = have >> left the public internet, if your application server speaks to your >> database server over IPv4, and the database server speaks to the = iSCSI >> array over IPv4, and so on and so on, then you're simply not in a >> position to easily shut IPv4 off. >=20 > Worse still is all the gear to workaround NAT, so it isn't just the = usual suspects of desktops vs servers vs appilcations, but also the = point-to-point setups (video conferecing comes to mind) I have = encountered that require going around NATs. Once the video conferencing setup is running over IPv6, will it care if = you remove the IPv4 NAT workaround infrastructure? Perhaps I am confused. >=20 > (There is something to be said about a net gain in maintenace overhead = in elminating some of that, but there's also the effort to remove it and = test, etc.) As a general rule, once nothing is depending on something, removing it = is usually fairly quick and painless, often accompanied with much = celebration and the consumption of adult beverages with bubbles in the = case of perpetually painful legacy infrastructure like NAT gateways and = NAT workarounds. The hard part is getting all that other stuff that depends on such = infrastructure to the point that it depended on such infrastructure = (past tense), but no longer does. Owen From nobody Tue Aug 5 08:30: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 63BFE1B2977 for ; Tue, 5 Aug 2014 08:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSX4wQW351-G for ; Tue, 5 Aug 2014 08:30:15 -0700 (PDT) Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id C781D1B298B for ; Tue, 5 Aug 2014 08:30:14 -0700 (PDT) Received: (qmail 36866 messnum 323447 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 5 Aug 2014 15:30:13 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail19.svc.cra.dublin.eircom.net (qp 36866) with SMTP; 5 Aug 2014 15:30:13 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id b3WA1o00D0mJ9Tz013WDoA; Tue, 05 Aug 2014 16:30:13 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_8EFBF376-257C-41A5-A577-54B7A5D6E278" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Tue, 5 Aug 2014 16:30:06 +0100 Message-Id: <94146541-768B-4853-A011-7558655C361C@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> To: Ca By X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pfIJIYoNuFs_BsKyPgkyQjuNyHQ Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:30:17 -0000 --Apple-Mail=_8EFBF376-257C-41A5-A577-54B7A5D6E278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 5 Aug 2014, at 16:08, Ca By wrote: > On Mon, Aug 4, 2014 at 10:25 PM, Tore Anderson wrote: >>>=20 >>=20 >> Make that four, Telenor Norway has been doing IPv6-only/NAT64/464XLAT >> since early June. >>=20 >> = http://www.telenor.no/privat/kundeservice/mobilhjelp/internettpamobilen/fe= ilsokingmmsoginternett.jsp >>=20 >>=20 >=20 > This is excellent. Well done Telenor. >=20 The APN roaming protocol setting for =93telenor.mobil=94 listed at that = URL says it is IPv6. Is that really their setting? AFAIK the Android UE or more accurately = the RIL it calls doesn=92t fallback to IPv4 when IPv6 is explicitly = requested. Ross --Apple-Mail=_8EFBF376-257C-41A5-A577-54B7A5D6E278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 5 Aug 2014, at 16:08, Ca By <cb.list6@gmail.com> = wrote:

On Mon, Aug 4, 2014 at 10:25 PM, Tore Anderson <tore@fud.no> wrote:


Make that = four, Telenor Norway has been doing IPv6-only/NAT64/464XLAT
since = early June.

http://www.telenor.no/privat/kundeserv= ice/mobilhjelp/internettpamobilen/feilsokingmmsoginternett.jsp

=

This is excellent.  Well done = Telenor.


The APN roaming protocol = setting for =93telenor.mobil=94 listed at that URL says it is = IPv6.

Is that really their setting? AFAIK the = Android UE or more accurately the RIL it calls doesn=92t fallback to = IPv4 when IPv6 is explicitly = requested.


Ross
= --Apple-Mail=_8EFBF376-257C-41A5-A577-54B7A5D6E278-- From nobody Tue Aug 5 08:40: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 813061B2A24 for ; Tue, 5 Aug 2014 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huaFr4OH9mOj for ; Tue, 5 Aug 2014 08:40:53 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0529A1B2A22 for ; Tue, 5 Aug 2014 08:40:52 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8E8F41B85B2 for ; Tue, 5 Aug 2014 08:40:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7D604190043; Tue, 5 Aug 2014 08:40:52 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 5 Aug 2014 08:40:52 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> Date: Tue, 5 Aug 2014 11:40:15 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IPmbimZbgTRYAcDcIg6ja2vLOs0 Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:40:55 -0000 On Aug 5, 2014, at 10:57 AM, Owen DeLong wrote: > Upgrading your application to be protocol agnostic about its = connection > to the database server shouldn=92t be very difficult these days. Furthermore, you don't need to upgrade these parts of the application. = The only part you really need to upgrade is the part that sticks out of = the data center. The rest you can leave running IPv4 until the = equipment dies: that's really your deadline. From nobody Tue Aug 5 08:53: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 5B2A31B2A45 for ; Tue, 5 Aug 2014 08:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 1BlUiDKGWWyt for ; Tue, 5 Aug 2014 08:53:19 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id BC9991B2A42 for ; Tue, 5 Aug 2014 08:53:18 -0700 (PDT) Received: from [85.158.139.3:29431] by server-3.bemta-5.messagelabs.com id EC/77-13873-DEDF0E35; Tue, 05 Aug 2014 15:53:17 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-6.tower-90.messagelabs.com!1407253997!37501976!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3501 invoked from network); 5 Aug 2014 15:53:17 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-6.tower-90.messagelabs.com with SMTP; 5 Aug 2014 15:53:17 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Tue, 05 Aug 2014 16:54:35 +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; Tue, 5 Aug 2014 16:53:05 +0100 From: "Heatley, Nick" To: Ross Chandler , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt Thread-Index: AQHPr4EllxYk3iQ+rUWF2+fqMoejC5vAj84AgAADY4CAAS0GAIAABxcAgAAK24CAAFfzgA== Date: Tue, 5 Aug 2014 15:53:04 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303B6F82CUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IXvdNMdYqKbTEZqSCuRc9wuT5Qg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 05 Aug 2014 15:53:22 -0000 --_000_6536E263028723489CCD5B6821D4B21303B6F82CUK30S005EXS06EE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >So there's an argument to remove "dual-stack deployment is recommended i= n most cases" from this draft, particularly if it has already been discus= sed and agreed not to promote any solution. Agree. Also the standards statement: "A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". does not mean that the UE is placed into a dual stack mode of operation. = It is signalling to the network that it can support all modes. (We desire the UE to request IPv4v6 in the home network and we can let th= e core network push the UE to IPv6-only mode of operation. When on legacy small-cells, where the access-points do not support the ne= w PDN types, the device can gracefully fallback to IPv4, if it requests I= Pv4v6.) Nick From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ross Chandler Sent: 05 August 2014 12:33 To: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-0= 2.txt On 5 Aug 2014, at 11:53, Jouni > wrote: On Aug 5, 2014, at 1:28 PM, GangChen wrote: 2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson >: Section 7, discussions, says "dual-stack deployment is recommended in most cases". Is that still the consensus position? Going straight to single-stack IPv= 6 is looking very viable now when the UE supports a method of providing translated IPv4 access over th= e IPv6 PDP/PDN connection. I don't think there is consensus here. The draft could point out pros and= cons with each approach. I'm not a fan of dual-stack deployment. However, I have to point out if you take look at TS23.060 or TS23.401, you may find the sentence "A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". GSMA quotes the similar language from 3GPP for roaming guidance. Therefore, that is at least a consensus in other SDOs. The draft intends to state the issues and potential workarounds in various scenarios. Argument of selection of dual-stack or IPv6-only may not be the goal of the draft. We had this discussion a long ago.. and back then we agreed not to promot= e any specific solution (like XLAT etc) but just give facts how different= =20approaches work. - Jouni The TS23.975 recommendations do allow for a second strategy. I can't find= =20TS23.975 explicitly saying dual-stack is preferred or recommended over= =20single stack. Although at the time they were writing it they were probably implicitly a= ssuming that. TS23.975 mentions DS-Lite, NAT64 and BIH but was too early = for 464XLAT, or MAP-T/E. "The second strategy, consisting of providing the UE with IPv6-only conne= ctivity, can be considered as a first stage or an ultimate target scenari= o for operators." So there's an argument to remove "dual-stack deployment is recommended in= =20most cases" from this draft, particularly if it has already been discu= ssed and agreed not to promote any solution. BR Ross 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 --_000_6536E263028723489CCD5B6821D4B21303B6F82CUK30S005EXS06EE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

>So there̵= 7;s an argument to remove “dual-stack deployment is rec= ommended in most cases” from this draft, particularly if it has alr= eady been discussed and agreed not to promote any solution.

 

Agree.

 

Also the standards st= atement:

"A UE which is IPv6 and IPv4 capable shall re= quest for PDN type IPv4v6".<= /span>

does not mean that th= e UE is placed into a dual stack mode of operation. It is signalling to t= he network that it can support all modes.

(We desire the UE to = request IPv4v6 in the home network and we can let the core network push t= he UE to IPv6-only mode of operation.

When on legacy small-= cells, where the access-points do not support the new PDN types, the devi= ce can gracefully fallback to IPv4, if it requests IPv4v6.)

Nick

 

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ross Chandler
Sent: 05 August 2014 12:33
To: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-ana= lysis-02.txt

 

 

On 5 Aug 2014, at 11:53, Jouni <jouni.nospam@gmail.com> wrote:




On Aug 5, 2014, at 1:28 PM, GangChen wrote:


2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson = <swmike@swm.pp.se>:


Section 7, discussions,  says “dual-sta= ck deployment is recommended in
most cases”.
Is that still the consensus position?  Going straight to single-stac= k IPv6
is looking very viable now
when the UE supports a method of providing translated IPv4 access over th= e
IPv6 PDP/PDN
connection.


I don't think there is consensus here. The draft could point out pros and=
cons with each approach.


I'm not a fan of dual-stack deployment. However, I have to point out
if you take look at TS23.060 or TS23.401, you may find the sentence "= ;A
UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6"= .
GSMA quotes the similar language from 3GPP for roaming guidance.
Therefore, that is at least a consensus in other SDOs.

The draft intends to state the issues and potential workarounds in
various scenarios. Argument of selection of dual-stack or IPv6-only
may not be the goal of the draft.


We had this discussion a long ago.. and back then we agreed not to promot= e any specific solution (like XLAT etc) but just give facts how different= =20approaches work.

- Jouni

 

 

The TS23.975 reco= mmendations do allow for a second strategy. I can’t find TS23.975 e= xplicitly saying dual-stack is preferred or recommended over single stack= .

Although at the t= ime they were writing it they were probably implicitly assuming that. TS2= 3.975 mentions DS-Lite, NAT64 and BIH but was too early for 464XLAT, or M= AP-T/E.

 

"The second = strategy, consisting of providing the UE with IPv6-only connectivity, can= =20be considered as a first stage or an ultimate target scenario for oper= ators.”

 

So there’s = an argument to remove “dual-stack deployment is recomme= nded in most cases” from this draft, particularly if it has already= =20been discussed and agreed not to promote any solution.

 

BR 

Ross<= /o:p>

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

EE Limited
Registered in England and Wales
Company Registered Nu= mber:=20 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfi= eld,=20 Hertfordshire, AL10 9BW

--_000_6536E263028723489CCD5B6821D4B21303B6F82CUK30S005EXS06EE_-- From nobody Tue Aug 5 08:57: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 A1D961B2A38 for ; Tue, 5 Aug 2014 08:57:18 -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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 DlbRaRfqbgBW for ; Tue, 5 Aug 2014 08:57:15 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id 61A121B2A46 for ; Tue, 5 Aug 2014 08:57:14 -0700 (PDT) Received: from [85.158.136.35:43696] by server-3.bemta-5.messagelabs.com id 1A/AE-13873-9DEF0E35; Tue, 05 Aug 2014 15:57:13 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-7.tower-125.messagelabs.com!1407254232!38548088!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10013 invoked from network); 5 Aug 2014 15:57:12 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-7.tower-125.messagelabs.com with SMTP; 5 Aug 2014 15:57:12 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Tue, 05 Aug 2014 17:05:16 +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, 5 Aug 2014 16:57:00 +0100 From: "Heatley, Nick" To: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= , Ca By , Brian E Carpenter Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvAuWkAgAAE0QCAABWsAIAAcMQAgABn6gCAAB/6IA== Date: Tue, 5 Aug 2014 15:57:00 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303B6F85F@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <2D29C51862222E49B991EF64EEB0B5B745F85768@OPE10MB05.tp.gk.corp.tepenet> In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745F85768@OPE10MB05.tp.gk.corp.tepenet> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/related; boundary="_004_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qhG1P2wUtxnSLb__-4jux3MFo3A Cc: IPv6 Ops WG , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:57:19 -0000 --_004_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_ Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_" --_000_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLCBFRSBzaW1pbGFyLCBidXQgbm90IGlkZW50aWNhbC4gV2UgYXJlIGhvdCBvbiA0NjR4 bGF0IChSRkM2ODc3KSwgaXQgaXMgcGVyZmVjdCBmb3IgbmV0d29ya3MgdGhhdCBhbHJlYWR5IGV4 dGVuc2l2ZWx5IHVzZSBOQVQ0NCwgYW5kIGdldHMgY3VzdG9tZXJzIG9mZiBJUHY0IChib3RoIHB1 YmxpYyBhbmQgcHJpdmF0ZSwgYXMgbmVpdGhlciBpcyBzdWZmaWNpZW50KS4NClJlZ2FyZHMsDQpO aWNrDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEN6ZXJ3b25rYSBNaWNoYWwgMSAtIEh1cnQNClNlbnQ6IDA1IEF1Z3VzdCAyMDE0IDEw OjIyDQpUbzogQ2EgQnk7IEJyaWFuIEUgQ2FycGVudGVyDQpDYzogSVB2NiBPcHMgV0c7IFRvcmUg QW5kZXJzb247IEtvc3N1dCBUb21hc3ogLSBIdXJ0DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBPcGVy YXRpb25hbCBDb25zZW5zdXMgb24gZGVwbG95bWVudA0KDQpIaSBhbGwsDQoNCkkgY29uZmlybSB0 aGlzIGlzIGNvcnJlY3QuIEV2ZW4gd2Ugd2VudCBmdXJ0aGVyIGFuZCB3ZSBkbyBub3QgdXNlIERO UzY0LiBPdXIgYXJjaGl0ZWN0dXJlIGlzIENMQVQrTkFUNjQrRE5TLiBTbyB3aXRoIGRucyBhbmQg d2l0aG91dCBkbnMgaXB2NCB0cmFmZmljIGFsd2F5cyBnb2VzIHZpYSBDTEFULiBJdOKAmXMgcGVy ZmVjdCBzb2x1dGlvbiDimLogVUsgRUUgd2lsbCBkbyB0aGUgc2FtZS4NCg0KU2VlIG1vcmUgYXQ6 IGh0dHA6Ly93d3cuZGF0YS5wcm9pZGVhLm9yZy5wbC9wbG5vZy8xMmVkeWNqYS9kYXkyL3RyYWNr NC8wMV9pcHY2X2ltcGxlbWVudGF0aW9uLnBkZg0KDQpFdmVuIHRyaXBsZSB0cmFuc2xhdGlvbiBp cyBub3QgYmFkIHRvbzogQ0xBVCtOQVQ2NHN0YXRlbGVzcytOQVQ0NHN0YXRlZnVsbC4NCg0KQlIs DQpNY3oNCk9yYW5nZSBQb2xhbmQNCg0KW2NpZDppbWFnZTAwMy5wbmdAMDFDRkIwQTAuNjIyMjNB NjBdDQpGZWJydWFyeSAxJSBvZiBhY3RpdmUgUERQIElQdjYgY3R4LCBub3cgb3ZlciA4JQ0KDQoN Cg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQ2EgQnkNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNSwgMjAxNCA1OjEwIEFNDQpUbzogQnJp YW4gRSBDYXJwZW50ZXINCkNjOiBJUHY2IE9wcyBXRzsgVG9yZSBBbmRlcnNvbg0KU3ViamVjdDog UmU6IFt2Nm9wc10gT3BlcmF0aW9uYWwgQ29uc2Vuc3VzIG9uIGRlcGxveW1lbnQNCg0KDQpPbiBB dWcgNCwgMjAxNCAxOjI2IFBNLCAiQnJpYW4gRSBDYXJwZW50ZXIiIDxicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4+IHdyb3RlOg0K Pg0KPg0KPiA+IE15IHBvaW50IGluIGJyaW5naW5nIHRoaXMgdXAgaXMgbm90IHRoYXQgaXQgaXMg 4oCcdXNlZnVsIGluIGFuIElQdjYgbmV0d29ya+KAnSB0aGF0IG1pZ2h0IGFsc28gYmUgcnVubmlu ZyBJUHY0IGluIHBhcmFsbGVsLiBJdCBpcyB0aGF0IGl0IHNlZW1zIHVzZWZ1bCB0byBtZSBpbiBt b3ZpbmcgdG93YXJkIGFuZCBJUHY2LSpvbmx5KiBuZXR3b3JrLiBSb3NzIHN1Z2dlc3RzIHRoYXQg aGUgc2VlcyBjb25jZXB0dWFsIG1vdmVtZW50IC0gRmlyc3QgdGhleSBpZ25vcmUgeW91LCB0aGVu IHRoZXkgbGF1Z2ggYXQgeW91LCB0aGVuIHRoZXkgZmlnaHQgeW91LCBhbmQgdGhlbiB5b3Ugd2lu LiBXZSBtYXksIFJvc3Mgc3VnZ2VzdHMsIGJlIGFwcHJvYWNoaW5nIHN0YWdlIDQuIEl0IG1heSBi ZSB1c2VmdWwgZm9yIHVzIGFzIGEgd29ya2luZyBncm91cCB0byBsYXkgb3V0IHRoZSBnYW1lIHBs YW4gZm9yIHRoYXQgbW92ZW1lbnQgLSBub3QganVzdCB0byBkb2N1bWVudCBJUHY2IG9wZXJhdGlv bmFsIHByYWN0aWNlLCBidXQgdG8gaGVscCB0aGUgSUVURiBkZXRlcm1pbmUgd2hldGhlciB0aGUg ZHVhbCBzdGFjayBjb25zZW5zdXMgaGFzIGNoYW5nZWQgb3IgaXMgY2hhbmdpbmcsIGFuZCBoZWxw IG9wZXJhdG9ycyBmaWd1cmUgb3V0IGhvdyB0byB0dXJuIElQdjQgb2ZmIHdpdGhvdXQgaW5kaXZp ZHVhbGx5IHNob290aW5nIHRoZWlyIHRvZXMgb2ZmLiBUaGlzIHdvdWxkIGJlIHBhcnQgb2YgdGhh dCBnYW1lIHBsYW4uDQo+DQo+IFdlbGwsIEkgdGhpbmsgdGhlIG9wZXJhdG9ycyB0aGF0IG1vdmVk IGVhcmx5IGludG8gZ2VudWluZSBkdWFsDQo+IHN0YWNrIG9wZXJhdGlvbiBoYXZlIG5vIHJlYXNv biB0byByZWdyZXQgaXQuIEknbSBhIGhhcHB5IGN1c3RvbWVyDQo+IG9mIG9uZSBzdWNoLiBPbiB0 aGUgb3RoZXIgaGFuZCBpdCBzZWVtcyB0aGF0IG90aGVyIG9wZXJhdG9ycyBhcmUgb2YNCj4gdGhl IG9waW5pb24gKHByb2JhYmx5IHVucHJvdmFibGUpIHRoYXQgcHJvdmlkaW5nIHRoZSBpbGx1c2lv biBvZiBkdWFsDQo+IHN0YWNrIHNlcnZpY2UgdG8gdGhlIGN1c3RvbWVyIG92ZXIgYW4gSVB2NiBp bmZyYXN0cnVjdHVyZSBpcyBjaGVhcGVyLg0KPiBJbiBhbnkgY2FzZSB0aGUgY3VzdG9tZXIgZW5k cyB1cCB3aXRoIE5BVHRlZCBJUHY0IHNlcnZpY2UgaW4gbW9zdA0KPiBjYXNlcywgc28gYXQgdXNl ciBsZXZlbCBpdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXIuDQo+DQo+IEkgdGhpbmsgd2Ugc2hvdWxk IHByb2JhYmx5IG5vdCBleHByZXNzIGEgcHJlZmVyZW5jZSBlaXRoZXIgd2F5LiBJdA0KPiBzZWVt cyBsaWtlIGEgZGVjaXNpb24gZm9yIGVhY2ggb3BlcmF0b3IgdG8gbWFrZSBpbmRpdmlkdWFsbHku IFdoYXQgd2UNCj4gcHJvYmFibHkgc2hvdWxkIGRvIGlzIHN0b3AgaW52ZW50aW5nIG1vcmUgc29s dXRpb25zLg0KPg0KDQpXaHk/DQoNCkkgd2FzIHRvbGQgdGhlIHNhbWUgdGhpbmcgYWJvdXQgNDY0 eGxhdCwgd2UgZGlkIG5vdCBuZWVkIGFub3RoZXIgc29sdXRpb24uIElmIHRoZSBpZXRmIGhlbGQg dGhlIGxpbmUgYWdhaW5zdCBkb3VibGUgdHJhbnNsYXRpb24gaSBiZWxpZXZlIHRoZXJlIHdvdWxk IGJlIGV4YWN0bHkgMSBpcHY2IGNlbGx1bGFyIHByb3ZpZGVyIGluIHRoZSB3b3JsZCAodmVyaXpv bikuDQoNCldpdGggNDY0eGxhdCwgYWZhaWssIHRoZXJlIGFyZSBnbG9iYWxseSAzIGNlbGx1bGFy IHByb3ZpZGVycyB0aGF0IG9mZmVyIGRlZmF1bHQgaXB2NiAoNDY0eGxhdCBhdCB0bW9iaWxlIHVz IGFuZCBPcmFuZ2UgUEwgYW5kIERTIGF0IFZaKS4NCg0KSXQgZG9lcyBub3QgbWF0dGVyIGlmIHRo ZSBjYXQgaXMgd2hpdGUgb3IgYmxhY2ssIGl0IG1hdHRlcnMgdGhhdCBpdCBjYXRjaGVzIG1pY2Uu DQoNCkNCDQoNCj4gKEluIHBhcmVudGhlc2lzLCBJJ3ZlIG5ldmVyIHNlZW4gc3Vuc2V0dGluZyBJ UHY0IGFzIGEgcmVhbCBwcm9ibGVtLg0KPiBPbmUgZGF5IHNvbWVib2R5IHdpbGwgbm90aWNlIHRo YXQgdGhlcmUgYXJlIG5vIG1vcmUgSVB2NCBwYWNrZXRzLiBCdXQNCj4gdGhhdCBpcyBtYW55IHll YXJzIGluIHRoZSBmdXR1cmUuKQ0KPg0KPiAgICAgQnJpYW4NCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRo aXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhl IGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBm cm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9z ZS4gIA0KIA0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMg aW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8g ZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkg dmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQg dmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0KDQpFRSBMaW1pdGVkDQpSZWdp c3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAw MjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVp dG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcNCg== --_000_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uVGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0 eWxlLW5hbWU6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiVGVrc3QgZHlta2EiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpQTDt9DQpwLlRla3N0ZHlta2EsIGxpLlRl a3N0ZHlta2EsIGRpdi5UZWtzdGR5bWthDQoJe21zby1zdHlsZS1uYW1lOiJUZWtzdCBkeW1rYSI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSBa bmFrIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uaHBzDQoJe21zby1z dHlsZS1uYW1lOmhwczt9DQpzcGFuLnNob3J0dGV4dA0KCXttc28tc3R5bGUtbmFtZTpzaG9ydF90 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjEzOTU2NjczMzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODUwODUxOTAyIDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0 ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1Nzcg MTM0ODA3NTc5O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjIxMjk0NzAwNzY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xOTI5MDk4MzM0IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAx MzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDo1NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgltYXJnaW4tbGVmdDo5MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI2LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTYyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCW1hcmdpbi1sZWZ0OjE5OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjM0LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcwLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCW1hcmdpbi1sZWZ0OjMwNi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLCBFRSBzaW1pbGFyLCBidXQgbm90IGlk ZW50aWNhbC4gV2UgYXJlIGhvdCBvbiA0NjR4bGF0IChSRkM2ODc3KSwgaXQgaXMgcGVyZmVjdCBm b3IgbmV0d29ya3MgdGhhdCBhbHJlYWR5IGV4dGVuc2l2ZWx5IHVzZSBOQVQ0NCwgYW5kIGdldHMg Y3VzdG9tZXJzIG9mZg0KIElQdjQgKGJvdGggcHVibGljIGFuZCBwcml2YXRlLCBhcyBuZWl0aGVy IGlzIHN1ZmZpY2llbnQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkN6ZXJ3b25rYSBNaWNoYWwgMSAtIEh1cnQ8YnI+DQo8 Yj5TZW50OjwvYj4gMDUgQXVndXN0IDIwMTQgMTA6MjI8YnI+DQo8Yj5Ubzo8L2I+IENhIEJ5OyBC cmlhbiBFIENhcnBlbnRlcjxicj4NCjxiPkNjOjwvYj4gSVB2NiBPcHMgV0c7IFRvcmUgQW5kZXJz b247IEtvc3N1dCBUb21hc3ogLSBIdXJ0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNd IE9wZXJhdGlvbmFsIENvbnNlbnN1cyBvbiBkZXBsb3ltZW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iPkhpIGFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4iPkkgY29uZmlybSB0aGlzIGlzIGNvcnJlY3QuIEV2ZW4gd2Ugd2VudCBmdXJ0aGVyIGFu ZCB3ZSBkbyBub3QgdXNlIEROUzY0LiBPdXIgYXJjaGl0ZWN0dXJlIGlzIENMQVQmIzQzO05BVDY0 JiM0MztETlMuIFNvIHdpdGggZG5zIGFuZCB3aXRob3V0IGRucyBpcHY0IHRyYWZmaWMgYWx3YXlz IGdvZXMgdmlhIENMQVQuIEl04oCZcyBwZXJmZWN0IHNvbHV0aW9uDQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gbGFuZz0i RU4iPiBVSyBFRSB3aWxsIGRvIHRoZSBzYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+U2VlIG1vcmUgYXQ6IDwv c3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmRhdGEucHJvaWRlYS5vcmcucGwvcGxub2cvMTJlZHlj amEvZGF5Mi90cmFjazQvMDFfaXB2Nl9pbXBsZW1lbnRhdGlvbi5wZGYiPjxzcGFuIGxhbmc9IkVO LVVTIj5odHRwOi8vd3d3LmRhdGEucHJvaWRlYS5vcmcucGwvcGxub2cvMTJlZHljamEvZGF5Mi90 cmFjazQvMDFfaXB2Nl9pbXBsZW1lbnRhdGlvbi5wZGY8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBj bGFzcz0iaHBzIj48c3BhbiBsYW5nPSJFTiI+RXZlbjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9 InNob3J0dGV4dCI+PHNwYW4gbGFuZz0iRU4iPg0KPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0i aHBzIj48c3BhbiBsYW5nPSJFTiI+dHJpcGxlPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ic2hv cnR0ZXh0Ij48c3BhbiBsYW5nPSJFTiI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJocHMi PjxzcGFuIGxhbmc9IkVOIj50cmFuc2xhdGlvbjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9InNo b3J0dGV4dCI+PHNwYW4gbGFuZz0iRU4iPg0KPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iaHBz Ij48c3BhbiBsYW5nPSJFTiI+aXMgbm90IGJhZCB0b286IENMQVQmIzQzO05BVDY0c3RhdGVsZXNz JiM0MztOQVQ0NHN0YXRlZnVsbC48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CUiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWN6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9yYW5nZSBQb2xhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48aW1nIGJvcmRlcj0iMCIgd2lk dGg9IjY5MCIgaGVpZ2h0PSIxMzQiIGlkPSJPYnJhel94MDAyMF8yIiBzcmM9ImNpZDppbWFnZTAw My5wbmdAMDFDRkIwQTAuNjIyMjNBNjAiIGFsdD0iY2lkOmltYWdlMDAzLnBuZ0AwMUNGQjBBMC42 MjIyM0E2MCI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5GZWJydWFyeSAxJSBvZiBhY3RpdmUgUERQIElQdjYgY3R4LCBub3cgb3ZlciA4JTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IlBMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IlBMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2 b3BzIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFu IGxhbmc9IlBMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlBMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5DYSBCeTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1 c3QgMDUsIDIwMTQgNToxMCBBTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gRSBDYXJwZW50ZXI8YnI+ DQo8Yj5DYzo8L2I+IElQdjYgT3BzIFdHOyBUb3JlIEFuZGVyc29uPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdjZvcHNdIE9wZXJhdGlvbmFsIENvbnNlbnN1cyBvbiBkZXBsb3ltZW50PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUEwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IlBMIj48YnI+DQpPbiBB dWcgNCwgMjAxNCAxOjI2IFBNLCAmcXVvdDtCcmlhbiBFIENhcnBlbnRlciZxdW90OyAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20iPjxzcGFuIGxh bmc9IlBMIj5icmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IlBMIj4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE15IHBv aW50IGluIGJyaW5naW5nIHRoaXMgdXAgaXMgbm90IHRoYXQgaXQgaXMg4oCcdXNlZnVsIGluIGFu IElQdjYgbmV0d29ya+KAnSB0aGF0IG1pZ2h0IGFsc28gYmUgcnVubmluZyBJUHY0IGluIHBhcmFs bGVsLiBJdCBpcyB0aGF0IGl0IHNlZW1zIHVzZWZ1bCB0byBtZSBpbiBtb3ZpbmcgdG93YXJkIGFu ZCBJUHY2LSpvbmx5KiBuZXR3b3JrLiBSb3NzIHN1Z2dlc3RzIHRoYXQgaGUgc2VlcyBjb25jZXB0 dWFsIG1vdmVtZW50IC0gRmlyc3QgdGhleQ0KIGlnbm9yZSB5b3UsIHRoZW4gdGhleSBsYXVnaCBh dCB5b3UsIHRoZW4gdGhleSBmaWdodCB5b3UsIGFuZCB0aGVuIHlvdSB3aW4uIFdlIG1heSwgUm9z cyBzdWdnZXN0cywgYmUgYXBwcm9hY2hpbmcgc3RhZ2UgNC4gSXQgbWF5IGJlIHVzZWZ1bCBmb3Ig dXMgYXMgYSB3b3JraW5nIGdyb3VwIHRvIGxheSBvdXQgdGhlIGdhbWUgcGxhbiBmb3IgdGhhdCBt b3ZlbWVudCAtIG5vdCBqdXN0IHRvIGRvY3VtZW50IElQdjYgb3BlcmF0aW9uYWwgcHJhY3RpY2Us DQogYnV0IHRvIGhlbHAgdGhlIElFVEYgZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGR1YWwgc3RhY2sg Y29uc2Vuc3VzIGhhcyBjaGFuZ2VkIG9yIGlzIGNoYW5naW5nLCBhbmQgaGVscCBvcGVyYXRvcnMg ZmlndXJlIG91dCBob3cgdG8gdHVybiBJUHY0IG9mZiB3aXRob3V0IGluZGl2aWR1YWxseSBzaG9v dGluZyB0aGVpciB0b2VzIG9mZi4gVGhpcyB3b3VsZCBiZSBwYXJ0IG9mIHRoYXQgZ2FtZSBwbGFu Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFdlbGwsIEkgdGhpbmsgdGhlIG9wZXJhdG9ycyB0aGF0IG1v dmVkIGVhcmx5IGludG8gZ2VudWluZSBkdWFsPGJyPg0KJmd0OyBzdGFjayBvcGVyYXRpb24gaGF2 ZSBubyByZWFzb24gdG8gcmVncmV0IGl0LiBJJ20gYSBoYXBweSBjdXN0b21lcjxicj4NCiZndDsg b2Ygb25lIHN1Y2guIE9uIHRoZSBvdGhlciBoYW5kIGl0IHNlZW1zIHRoYXQgb3RoZXIgb3BlcmF0 b3JzIGFyZSBvZjxicj4NCiZndDsgdGhlIG9waW5pb24gKHByb2JhYmx5IHVucHJvdmFibGUpIHRo YXQgcHJvdmlkaW5nIHRoZSBpbGx1c2lvbiBvZiBkdWFsPGJyPg0KJmd0OyBzdGFjayBzZXJ2aWNl IHRvIHRoZSBjdXN0b21lciBvdmVyIGFuIElQdjYgaW5mcmFzdHJ1Y3R1cmUgaXMgY2hlYXBlci48 YnI+DQomZ3Q7IEluIGFueSBjYXNlIHRoZSBjdXN0b21lciBlbmRzIHVwIHdpdGggTkFUdGVkIElQ djQgc2VydmljZSBpbiBtb3N0PGJyPg0KJmd0OyBjYXNlcywgc28gYXQgdXNlciBsZXZlbCBpdCBk b2Vzbid0IHJlYWxseSBtYXR0ZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0aGluayB3ZSBzaG91 bGQgcHJvYmFibHkgbm90IGV4cHJlc3MgYSBwcmVmZXJlbmNlIGVpdGhlciB3YXkuIEl0PGJyPg0K Jmd0OyBzZWVtcyBsaWtlIGEgZGVjaXNpb24gZm9yIGVhY2ggb3BlcmF0b3IgdG8gbWFrZSBpbmRp dmlkdWFsbHkuIFdoYXQgd2U8YnI+DQomZ3Q7IHByb2JhYmx5IHNob3VsZCBkbyBpcyBzdG9wIGlu dmVudGluZyBtb3JlIHNvbHV0aW9ucy48YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iUEwiPldoeT8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iUEwiPkkgd2FzIHRvbGQgdGhlIHNhbWUgdGhpbmcgYWJvdXQgNDY0eGxhdCwgd2UgZGlk IG5vdCBuZWVkIGFub3RoZXIgc29sdXRpb24uIElmIHRoZSBpZXRmIGhlbGQgdGhlIGxpbmUgYWdh aW5zdCBkb3VibGUgdHJhbnNsYXRpb24gaSBiZWxpZXZlIHRoZXJlIHdvdWxkIGJlIGV4YWN0bHkg MSBpcHY2IGNlbGx1bGFyIHByb3ZpZGVyIGluIHRoZSB3b3JsZCAodmVyaXpvbikuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iUEwiPldpdGggNDY0eGxhdCwgYWZhaWssIHRo ZXJlIGFyZSBnbG9iYWxseSAzIGNlbGx1bGFyIHByb3ZpZGVycyB0aGF0IG9mZmVyIGRlZmF1bHQg aXB2NiAoNDY0eGxhdCBhdCB0bW9iaWxlIHVzIGFuZCBPcmFuZ2UgUEwgYW5kIERTIGF0IFZaKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJQTCI+SXQgZG9lcyBub3QgbWF0 dGVyIGlmIHRoZSBjYXQgaXMgd2hpdGUgb3IgYmxhY2ssIGl0IG1hdHRlcnMgdGhhdCBpdCBjYXRj aGVzIG1pY2UuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJQ TCI+Q0I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJQTCI+Jmd0OyAoSW4g cGFyZW50aGVzaXMsIEkndmUgbmV2ZXIgc2VlbiBzdW5zZXR0aW5nIElQdjQgYXMgYSByZWFsIHBy b2JsZW0uPGJyPg0KJmd0OyBPbmUgZGF5IHNvbWVib2R5IHdpbGwgbm90aWNlIHRoYXQgdGhlcmUg YXJlIG5vIG1vcmUgSVB2NCBwYWNrZXRzLiBCdXQ8YnI+DQomZ3Q7IHRoYXQgaXMgbWFueSB5ZWFy cyBpbiB0aGUgZnV0dXJlLik8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEJyaWFu PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPC9zcGFu PjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iUEwiPnY2b3BzQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJQTCI+PGJyPg0KJmd0OyA8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+PHNwYW4gbGFu Zz0iUEwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IlBMIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCg0KPFA+ Tk9USUNFIEFORCBESVNDTEFJTUVSPEJSPlRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFj aG1lbnRzKSBpcyBpbnRlbmRlZCANCmZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiZuYnNw OyBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCANCm5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBk byBub3QgDQpkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiZuYnNwOyA8QlI+Jm5ic3A7 PEJSPldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyANCmFuZCBvdXRnb2luZyBlbWFpbHMgaW4g bGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gDQpl bnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2 aXJ1cywgYnV0IGl0IHJlbWFpbnMgDQp5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0 IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91LiA8L1A+DQo8UD5FRSBMaW1pdGVk PEJSPlJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXM8QlI+Q29tcGFueSBSZWdpc3RlcmVk IE51bWJlcjogDQowMjM4MjE2MTxCUj5SZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50 IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCANCkhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJX PC9QPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_-- --_004_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=23586; creation-date="Tue, 05 Aug 2014 15:57:00 GMT"; modification-date="Tue, 05 Aug 2014 15:57:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArIAAACGCAYAAAAhDWkSAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFuiSURBVHja 7V0HfFRF912k907ovdr7p59+9o4iKL2kUKXYEBFULHQpgmIXBZSiYgdEBUFUkCJdaigJLQQIKSTZ ZFPOf85sJtn0kOwm781/5sdlJ2/nzc68M2/mzJ07dxwXLlyAESNGjBgxYsSIESN2ktdff93hMA/C iBEjRowYMWLEiCGyRowYyVFiY2MRHx8vP1VcSVxcXIHzYFp1H//2/N7zO0/Jmi4/iYmJQWJiIlRw uVzp8dTUVPmZlJQk03nj2ahye5Yza108n1HWenk+29zqkJycLK+pkF+ZLgYXb4rn77K8LDdDUcri 2d5Kok5Z21ZCQoKsE/EpShtSbUR9egbT5xgxYoisESNGfCyRkZFSOAhzUM+PjJBQ8pP3REdHZyOo UVFROH/+vPxU+fNvpr0Y0uN0OrFp0yYEBQXhmWeewe+//47nn38eXbt2xbRp0+Tn0qVLJZn1BolV 9fCMK1H1YZlIgLKSvtzyZdnWr1+P3r17o3v37liwYIG89uSTT2LUqFGSQJU0qctPWN6PPvoI3bp1 w+HDh7PVv6DPl+2G9WV74GduExum4zP11gQlL1zYhtasWZPepi+WmPM+1o114nM5cuSIxLZXr14Y N26cbDNWx9eIESOGyBoxYgtJSUnBt99+izZt2shB/Oeff5bxSy+9FO3atcMjjzyCv//+Ww7yntpD 9TdJHAdu3nfHHXfIe+68806sXbtWXudvUFM6fvx4dOjQAe3bt0/Pn3/PnTsXWYMiOZ6BhIAkgaFT p05wOByYPHkyHnjgAVSuXBkDBw7E4sWLMWLECKxcuVKWM2se/LugREgRVxK1Vq1aYfbs2TJPPi/R Ock6XHbZZbIOQ4YMkWSF3z/66KPyuyVLlsjfnD9/vvx7w4YN8l7mzfDZZ5/JOvznP/+RxJvfTZo0 CW+88YYk91kD688Jxblz52R+U6dOldcVufPU8Krf8dTyqsBr/N4zKNKfWz68FhERIX+Xz1xpv7/8 8ks89dRTOHr0aDatuPotlZ/ScKrAcrPtfPzxx7juuutkuyGp379/f44Tp4MHDyIsLCwbAWSe6jfV d5545/QcPTWvWZ/DP//8I/EkXipfzzoxT5Uvnw/zUqsCzJPx3377Dffcc4+s0913341FixbhlVde kXi3bNlSToBYd9P/GDFiiKwRI0aKKAzz5s2Tg+yqVaskOWF8+PDhePPNN+Hn54dbb71Vat0+/fRT bN68WQ7Y27Ztw4cffohjx47JOAfoLl26yLxmzpwpSbHS0nFwp4brnXfekWmY/3PPPYd3331XEodv vvkGX3zxBVasWIH33ntPErnTp0/jq6++kgSSRODkyZOS4DCfWrVqoUmTJpgzZw7q1KmDRo0aYdas WTJ/EiPmqYjvr7/+Kr9jvcLDwzNpSpU5RE7aMZJSanurV68uy3vLLbfg1KlT8nkNGDBAXpsyZQrG jBmD0qVLY9iwYfK7K664Qn53ww03yHqwTPx79erV6SSdgUSX11lHNSFgGTmpYHn4PFjvH3/8UT7T 48ePS+LEZ8b7br75ZnzyySdS68frISEhkhzz+W3cuFE+c+bJ36H89NNPsizMe926dXj//fflsyGG u3fvltdJ5HLKh8+C6RXx5uSDef/111/yeZOY/fHHHzINJzC8l8+OBHD79u0yDYko8eNvMn9qJVn3 unXrSm0l29Zbb72VjcgqbTcnFCT8DJ5aUuL5yy+/YOHChTh79qz8jvVdvny5xJv1Y915r3qOzJ+/ w/KyzfM5sty8HhwcLMt76NAh2eZVnVi+r7/+WubPdsA0nODxnl27duGDDz6QhH7Pnj1o27YtOnbs KO/hu/Dnn3/Kcl955ZVy4mOIrBEjhsgaMWLEi0RWaQepSeKAzzgHf2qbqC0jaSTZadasGR5++GF5 DzWgpUqVkoST2tayZctKMkchkeBArQiHpwZXETsSYqXtatq0qbzGgf5///ufvG/Lli247777pOaW Gte+fftKwkbzAablNZatfPnyMn799ddLjSG/o8aUgUS8Ro0aqF+/Pm677TZJPEjKPEkQy+lZVs/n QpJaqVIludTM+pFEMwwePFj+TmhoqCQxLIN6Ltdccw2qVq2K2rVrSxJFwsO06t6sRJaEVWkDWU7W gcRN1YXPhJ8jR46U6Xr06CH/Jpm/9957JVkm4eKz4qSD91G+//57mb5169Yy/VVXXSXJL583NY68 dvXVV0sSzmdDIkvypvIhGWM+3333ncyHy+K8h/WilpH5qOdw4sQJqQln/KabbpLklHmQwJEE8jeo kWSgFvvyyy+Xz5vaftaZdaNmVy3ne+JAoshrJLIkklltcokntcT8ba4KkGQyzvKwbTLONnDjjTfK OE1SiDcnT/yb9eRkqF69epLEc+LA65xQcGLFOFcRSEBZD04kSIb5bO666y5ZnmeffVam4/1sc0zH Z8x34fPPP5e/pyY5hsgaMWKIrBEjRnxIZNUAT9LKpdGGDRvKZWwSF5INEg9qPEnYevbsKe9XJIbE itrbihUrSi2oWppW2k/mQQ0V01IrqJacObiTSFBbd+bMGUkwSRKp8eRyM8lTlSpVJGEiAWjevLn8 fWrgSChI0rjkTu0a854+fbr8PZI9mjlQy0ZtGTV0ymSA+bz00ksyf5I0EnW1xM4ykRBRq8r7t27d KjWz1CIz8Dnwd/h8aHZAIeFj/Uh6SOaGDh0qSduLL76YJ5FVJgj8bZKqa6+9VhJZElhqmqn1ZP6s I0kbNX68jxMJZYLA56TIKk0tGCcOLA+v8TnQ3ILPi4HadqZhmQMCAmScz33GjBnZ8lHkd+/evfJv aqPV76p8qC3ns1HEnBMGknmST97LPNg2WBfirMwiSC45CaA5Bp8Vv+MEiu2GGBGH1157TZJ3Yk7T FWKlTDGUtp8EnO2D9qc05ahZs6bUCLNNXHLJJfK3SfaffvppWUY+Q2px1aSHtr6KCFMYJ6FVaV54 4QV5P58pMWG5+Ft8rpxwsX40d1GTH95DksvyVqhQQeJjNLJGjBgia8SIkWIgstR6MU6NEpdcSUpI LElISIZIKDp37iw1lUpbN3r0aJQrVw779u2T5IGkj0TIc4d2XkSWZgnUrvJ3lP0mNa/Mk2SZJIda V5IpBpJXkkxFHHkvA7W8zJuEjEvXjFNrqALJg9pQxDgJCokshZpVRWQZWFdqYakhnjBhQrq2lGSS S+HMmySLz47EiIRKkVESWRJjapOpzS4MkeW9JOtKk0fhdZpy8D5uClNBaQRJpkiySaJJ0FgmEife yzqrZ/vEE0/I9CS21IYqMqpImGc+r776qsxH/a7SDGclsqoMBw4ckM+WE6Dbb79dpiMerBvbBJ8j 2wkDJwksH+tFm1TeT+2+Mh9g23j55ZclkaXWnkSSG+RogqGwUp4BeJ1tgs+MmKnJEPMcNGiQzFOZ R5B8ctKkVh5o9sH4Dz/8IHHPSmSJsdJKs02QyJOUs92qd4FmIAwsP8kzzW1YPtaX5TFE1ogRQ2SN GDHiIyJLWz5lI0uNmhrU1eYu5SKJJJC2ovye5JLkhoEEmAM2tXvUepGAkkiRaGYlstTG8X4uOSsi y3u53KyIiafWk4SNS+CMKyJLrRh/nwSIBIfkgPlwKZvpSDxZ7vvvv19qc0m0uYmKZFUtXWfdCKVI rnIFpUhaixYtJIHlUrkipCR4jFNLp+rAe0iuSFxJrtXmLaZTk4SciCyXsBWR5b2K2PF3qfFVRJ9l YBn5zEmc+Lxoq8r6MA9ee+yxx6QdKDXNNGlgoGadJJLkSz3b/v37y9+m1lnVhVrNZcuWZcuHtp/E jcvmnEzwd1XeykSBmnI+Y8b79esniSPJHIk+A8mten4001ATI9rSUqvJCQW1t8yfKwKq3XhixPtY vqzu1dQGQLWSQOFzZ6AWnm2Rz4CmDcSFz5ImB8yLaWmCQXtapaH2jCuyS9MLatZpokDbV6UJ5oYu fk/zDT4/BtqGN27cWE7AqKWmxpn3MrAdswyGyBoxYoisESNGvCQkXBy0OcBSK0aNFONcYiVh8PSH yr+5IYfEiMul/JukhMSLxId2qiQ6JEDKRMCTyJJckjQzf7rQ4m/zXhKCxx9/PN3tFEkCtatcEubm MH5HTRvJAu+hHSevkQxQy0fixXxoAsC8SZBIhqgVpRaNJJD5/Pvvv9lsMLMK8+Hu+AcffDD9HtaF BIdEhNpFkmL+Dgma2tCmys3yUEvHspHgcYmZablxytNrATV4inQzHZ+NqgvvJWFS+dD+llpS9Rx5 DzGgpo8acJJdPlcucVPrxyVt5s/fYz14r3L5xGvUsrJMJHQkfaouLH/WfGjjqTxVMC1/l5pRYq/u pcmGMi0gueW9NH0gUVbutWh+QmJO4qjaDctEsstJCdsOSbPagKfwUBMLTpCU2UFWzJgfvUawXTAv Ykb8eY32qqyHakMkvMyD2laWnRMMrg5kjXOipcwM+vTpI7XLbI/UtPJ5Mw+Wl8+DJFlNZvjJZ89N cdSqk6RTM8wycdLFtmiIrBEjhsgaMWLEy+K52Skv35nKuX9Wp/9qp7lybZTbQK0OXcjvGu/P6bey ps96r2dclUP5qi2oT1DWgfco12IU1o8ES/nIzS0vz+9yO/SBJItL11x+pxZ24sSJ8lpu9coaV+SZ RFCR/6zlU5OI/J63Zzy/fDx/1/NeBqXZ5eRBeUxQbcATQ8/JjSJ+ytxD/XZ+7TO37z0PIGAZSGRZ JppSkHhm9febW7tRdaKmW5kW5HR/Xu8CP5VGmR4bSIQbNGgg7YGVf2bT7xgxYoisESNGvERis57s lRdRy+l7z5O98iIdOd2fmwssdV3lm1P6rPfmdgrXxTqgz5pvTs+oIPfl9Ez4N7WVXIamFpyaZs+6 5ldHz9Owcnr+WQ9yyFp3z+eZtS655ZPT76q/1YY/erGg+QZJX26/mVO7yem3cnqu+ZFZz3opIssy kchyoqBcsuXV5j3rxJUK3s8DK5Tv29zKntu7QKEPXq4W0PSFRD+vgx+MGDFiiKwRI0aMWFqULS7J lSJYvjyxytdC0kZ7VPqM5bK5FUgay0DNMctEQnuxZWKdaDLB+2lqUpQ6KbMaYu2NE+eMGDFiiKwR I0aMGPEiMVd2o1bSNCpPDfkdsZzXZIP3GzMAI0aMeIXIxnJpyZxPbcSIESNGjBgxYsRuRNaIESNG jBgxYsSIEdsR2YTUVGz95husmTULcTkcJ2nEiBEjRowYMWLEiOWIbLzLhXMnT+K9++/H+JYtcWjj RiR4nJduxIgRI0aMGDFixIjliCxtYuPi47Fs3DiMqVQJIy+5BHO7dMH5M2ekZtYrP0btrq7G/LQp Zt1svCM6R7x0dSZu8DJ4WUVYLx32JOiKEeujC0amrzB4WRUvbxBZktWI06exato0TH/kEcwbMAA/ jh2L0N27pabWG0DEnDuHqNBQNyiaARF96hSiT57Up7MjXhERiAoJ0ROvsDD98Dp/Xlu8YojXiRN6 kQnVFo8dQ8yZM/bGjRiJ8SP6+HE9MRL1igkP1+PdYl8RGYmoo0f16ytYN4GTVu2QdYqKcuOlG4ll 3UTfxz6QitT4ImCWblqgTllZ/O23OCQGDYY4b81sRD4sbMT69drNLGITEhApCP/5nTsRWwj3M5YU 4iXaQMRff+mJ17//4vz27XrhJSZTEX/+qd2qB/GK2rcP57du1Qcvj7pFbNyIqEOHbP2eSYz278f5 f/7RDyNRn/ObNyMqOFiPvpCTDkH2Iv74Q79Jh8CHOBEvbdoh8Tp7FhHr1uk38eA+rJCjSNy9Ay64 j8SOiytcHTNt9qITaZ75TcfWdCpN335eETqoFrMK58GDMu61fK0goj6JJ08iQcwCdapbEv076oqX IH3a4SXe3/gDB/TE6/RpJISGalk35+HDcJ07Z++6ESNBjhJCQrTEKEGMh64zZ/Som6hDMrVfYuKh FU5pdSNOxEundpjMY8Q1xet86AlsW/knZn6yCg/6v4kz52IypaFv6YIcYpMjkeXpMd4OqWKGlBwR AR1Dinh2KWnnfWsTXC698YqO1qpOqcRLECIt8aLDfc3wUiE5MhKpaUe12rr9xcUhJSrKYGSLCiVr 21cQJ+KlVwPUF68Fi9agev1ecNTqjdJNgrBi7a5M3zsFibcWkU1IQJKuA6140Mm6ESMx8Ug6e1Zf vDQbdLXGS/RN2g1OaYGTxRRBAm2PEY+H1RWj8+e1wEiFVDHOJ505oyVWxIl46RRSBZHVEa8EVzIe 7TsNNRoIItswEI76/rjyf2Owcdvh9DSFIrI8p3rRokUICQnxQakTkKzpy5MqSKx22ghq0MPD9cRL vBgGLxvhRQ26riRJTO5TNSBJqdSaa0YgMmGUtodEjwolI/n0aS2xkisDuq0kaopXn6fnomzdXqjf 3B+ORkFwNBZStgveeH9lehpXAZ0NZDvZ64MPPsDBgwfludm0TyAj5mdR4vJTkIdYMdA6BaH1Rp5W iSeIB816xdKOT8QL+3xKui6eZZBxbnQQdfLEK1saL8TzLIMP4hIvMaGKDQtLx6s4ftfn8WLCq7jj 2uJFEVixbvFiUhWfhpstMRJjRezZs4il7bmOGIm62R2jTHFBymVfoQlGmdqhmHRc4J4VndohN+WJ /s8OZU5IcCIpKVGIK+MdyiFNdEwsrrp/HGo06o3mlw5A+dYDUbntQJRr7I9R4xfjQmycSJeAkwLL cHoMuRgiS88FH374IYKDgyUTdv9ogkcBCheXn9yRxg0BorF5I0+rxBPFc4qjv11Rt0SXq9DPp6Tr 4lkGGRdtISte2dJ4IZ5nGXwQl3iJgSlOdOSJHm28OMvgk3gx4VXccW3xogisWDdndDScabjZFiNB IOLEYGswskGcfuOpeNEEo0ztMCJCTnq1aoeCBMbaBK/ERDHxk+cSCELrSsw1zdFj4ehw11jUatYP zTr0R7lWA1GpDYlsALoOeRvnI6OlMjVMYHmG7gmtYlqQakwL7BWMaYHByyp4GdMC62NkTAtsVCG9 TQu026RsI7y+/2U7Wl/3LNr+bwz+2HQw13S79p1Ak5ueR/l6veDXQpkWBMJRtw+uvO+V9HSJBXSj VmybvVJ03uwliKzZPGQjvMxmL3vhZTZ7WR8jbvbSlchqglF6X6H7Zi/NiKydNnv1GPY+HJW7wVG9 J27uPBEfzF+NTdsPZ0v3+9/7UeOKEajYoA/qtQyAo0mQWxoGoGr7oZj+1o/4e9thaRlgvBYU18tj vBbYDy9DZO2DlyGy1sfIeC2wTTBeC2yGlw2I7FfLN6O7/yxU6zAUjkZpxLRuHzjKP4b6V47A4DHz sTf4ZHr6b1duRZmWg1CxUb/MRJbSKBAOxwMY9tLnMq2liGyK06nty0NSpFsnLicemi5VS7x06+xI ZDVdLkzmxENTn8acfKRosGwtJxu6YsQDKzQyLZBEVtO+gjjppjCzOl7JySno9sS7gnx2hKOBIKVN PUhp0zRCW6Mn6rV7Am9/ukre89WyTXDU6YsqTf3RgES2cf/MZLZSVzw/6SuZ1lpE1pgW2OvlMRpZ g5dV8DIaWetjZEwL7NNXGNMCe+FlcY1s+LkYXN/xdUFM+2Qmo55C+9davdDohpH4YOFa9Bz+ARy1 +6BKs8DsGlkrE1ljWmCzl8cQWYOXVfAyRNb6GBnTAtsEY1pgM7wsTmS37Q5FlXZPwNHAP3ciq7Sz 9f3dNrS1e4u/+6NKcx8Q2WRx08IlSxBy7Jj3wXC59CayuhEjdnaGyBq8rICXzkSWJMnptD9GOmtk iZFGR9SmpqToS2QFTkm6mbikploCr4joeGz/9xi27z2eLrPn/YaGN45yE9TGQRctlQWR9VOmBZ7f VeyKkZOWyt+NoR/dAhNZ0RElhIZi3tSpOLRtG8DBI832U34WIU7ikETfbocOuUlE1jRpS/Pe+K1i jwuh/YpL1M/zmq3qkuX501SCdcoVL1+XwZdxhdepU9nxKq4yeDku8aIfY0+8bFqXHPESdUvHS5d6 iTgJeuKRI3CdPJk+ubI1RqIe2mJ04oS9MVJx9hWCFCUEB7v/1q2vEHUjVjq1QyooJF5ezFO6M4y9 gNSY3NtAapRI43Li73XbseizX9C171TUaNgbNZv2RfWm/qjRtB+qN+mLSg37oHaLANQRhLRWi8AC x2uLz4atAtCyjb+8RqmTlqZC9a54Y8oipBw9jCjx/pGfFpzIigYwf/p0HNqxA6CKPm3JXH4WIc7O QA60R4+6Z+5eyNMycZJ0duKCHHles3O9JF6iQ2AHLrVhuuHFzk43vERnZ1u80gbYPPHiRNGXeHmW oZji7AsTQ0LkJD+9XyzB8hQlzvaXCSMb1yUbRqGhWmCU/j6dOyf7ipJu/z5rh5z02qkdqj47t/4w IsKNlxd/FxdikBApSLIi/LmkOX74ODrc+BQc5R9BWb9eqNbMH9WFVBVEthrJbHNKIGq2IEENuKh4 DUFc6wvS2ry1v4x7pikviOyUKYuRcjwUUaKPLDiR5WAIt2nBUV+YFtCGz2z2ss9qBk1BjGmBffAy pgW2DNJG1pgWWBsjY1pgn3YYF2dMCwoQ9h05jRY3jcJLM77LNc3+o+Foe+eLcNQPKJTZQMmYFpjN XoV/eYzXAnvhZTZ72Qsvs9nL+hgZrwX26SuM1wJ74eWDzV7TPlwJR+lH8XDQW3C5knNMM4Np6vSW hxTkuYmrCOKTzV6GyBby5TFeC+yHlyGy9sHLEFnrY2S8FtgmGK8FNsPLy0SWhxc0uWw4HNV64JYu kxEVE49d+46jx6A56DHsPXk6F6Xpf57L3xPB/zciKw9E0NnBvjkQwV54mQMR7IOXORDB8sEciGCj vsIciPD/Fq/UVMD/mY/hKNcFDr9+aHXrCzgUGo5pH6yEo0xnt2usKmlSr2/mww28LY2DUFUQWVsd iGBMC2z28hiNrMHLKngZjaz1MTKmBfbpK4xpgb3w8qJGNibWiYcCZsnDCXgKV6W2Q7B55xH0GPq+ m7g2DvKpBtaYFlj55TGmBfbDyxBZ++BliKz1MTKmBbYJxrTAZngVkciu2bAPPfq9ifX/BONsxAVc /cCrGadwNQ7ELY9NRs3LR8DRKKBYSazPiGyyeGCLFi1CSEiI99EQRDZZ05cnlW5aNCNGEMQoWVPT glS6rDJ42Qcv0Tel6EqSxOQ+VQOSlCqIbIquGllipJFpgRjokaypaQHfpRTdTFyKgNeBI6dxU8fx cDgexJCxC3Dk2FnUvfopaVbg9hAQCEeNnh4HGgQWnzQKRJVmAfBrIX67UZbfrvA4Rk92ey3Ij8Rm I7KUDz74AAcPHhTjYiLi4+PhdDrlZ1Hi8lOQh1gBhlMQWm/kaZV4gssl60VhvLDPp6Tr4lkGGRdt ISte2dJ4IZ5nGXwQl3gJwhcbFpaOV3H8rs/jxYRXccclXmICHHvqlF54UQRWrFu8mFTFp+FmS4zE WGEwslFckHL2f7pglKkdiknHhZMn9WqHdD/lgRdS3V4GUpKT0q8lJbncRD4lScYTExMEn4vFjQ+/ itJ+fVCpZX+0v+MFjJ60GFXbD0alVgNQue1AVGrjlpKIV2g9EH4dBqDFpf1RvnXmNGXq9caIlxfg QkwkwsV4fVFENlY08A8//BDBwcFwiYaQIF5cbwkH2jhRIDY2b+Zb0pIonlOc6OgoiV5+ZiUqoi1o i9fZs7JuBi+b4CUGpzieNKcTXhSBFduiMzra1rgRl3iDkX1EECNipRVOqh2eP484niKqUzsUhJZ4 KQL73crNeHLcZzgRdg5JLnebDD5yCkPGfIpN24MFj4uXJHfHv0fR5MZnUa5JACoKcli6WRAcgtRW ECSWJLKSkIqtB5ZYvHyrgajbbgCadeiPcq0ypylTpxeeEnWMi43BWfH+Wca0INWYFtgrGNMCg5dV 8KJpgc7L1sa0wPoYGdMCe7RDDTd7SbxE3x5+Lgb/bDuC/3aeJF1nNb9pFP7cfFAmmf/1emn3WqfD MLS59QXs3Hcc6zYeQPkWA9PMCAKtJ74yLfD5Zi9dN6MYrwX2wkvXzV66buAwm72sj5HxWmCfvsJ4 LbBZpdwnsY0YtxCOio+7fbtyY1atXvhvl0l4Z/5vuLnzRDjqCcJatw8cNXvi3j4z0OfJDzNsYZtY U4zXAiu1M+O1wH54mYmHffAyRNb6GBmvBbYJWh9nraHXAqSmIOLIMdzbe4Z7Y5YnMSVxrdxVfGbx +Vq7t9vFVlPrklj7Hoig6SzQHIhgQ7zMgQj2wcsciGD5YA5EsFFfYQ5EsF04un0vmtw0yq1htTAx /f9xIIIxLbBPZ2c0svbDy5gW2C4Y0wKDUbH3Fca0wFYh7kI83p29FKUaB0i7Um2IrDEtsNjLY0wL 7IeXmXjYBy9DZK2PkTEtsE0wByLYCCshM99fger1urttYzUisb47EEHctHDJEoQcO+Z9QFwuQ2Tt 1tnpjJduRFZnuzediSxJEn1D2h0jHW0TNcMova9ITdW3r4iPR5ImGtkkwWLHTPsWpf36okELdYCB XlJZEVmaFnh+V7ErRk5yey2IoR/dAhNZMaNOCAnBvClTcGjrVvo8SLcllJ9FiHPpPYm+3Q4dcpMI L+RpmbgQ1s116lSma3aul8SLPiGJF80mdMNL1M3gZaG4IKn54nXypG/x8ixDMcVJ0BOPHIHrxAl3 v1gCZfBKXAjt6TNhZNe66IqRR5unNjYhOLjE27/P2qHAygrtEBeo3EoCXE55MmHWNHTbCSdtr1Nx 4fQZ/LJsPT7+aDn+WvMPEBsDV2QUbrh9FGr79cAV7fuhTstA1G0RgFotAlFHfNZtae94bfHZsFUA Wrbxl3HPNBWqP45pUxYh5cghRB0+LPlpwYms6Ijmz5iBQzt2ADzqjf426SOVn0WJ0wCbBwYcPSrj 2dLQT6S3fqu440LkyyPE85qt6pL1+dPMRMzYc8XL12XwZZx4ibboEuQoG17FVQZvx3PCy651yQkv Ubd0vHSpF+Oij00MDZVEXeJmd4zEhF5bjFg3O2Pk0VfQnIXkXP6tW19x7pxUUpR0O0RCPA7tOYwu PSZj2sylQKJTcKrM7ScpKhq/rPgb3QJn4tZ7x6Jy475wlO+Eum3644Eur+MRcW+1Zv6S3HVo2w81 BNGrKeLVmweKeIDt46yPnyCtzVv7yziv10xLU75aV0yeshgpJ44hSrx/BSeyfLBwmxYc9YVpAW34 dF2q1nGzF01BjI2sffAypgW2DNJGVgfTAp03e1EzGx+vT1+R5pdUy75CTDysYFoQdi4GA0fNE8T0 MVTtMAw/rN6BpJTUTGlen/0jqnIZvXpPOGr1hqNhIBxN+8NRPwCOmr3SXW1d0jRIai51NS3w86pp gfFaUPiXx3gtsBdexmuBvfAym72sj5HxWmCfvsJ4LShUOBcZix9+3Y7k5JS824uYKPTmYQSVuro3 LtXrh0uaDcDfWw+lp4m5EI//dZ0CR9Vu+W6IKtPUvQSv20Yv47XAai+P8VpgP7zMxMM+eBkia32M jNcC2wRzIELhwqLvN6LOlU9i9/4Teabbte846l/zDBx+fd2kjC6zGvhj5kc/p6f5Z+dR1LhseIE8 EZRRGllDZM2BCD7t6MyBCPbDyxyIYB+8zIEIlg/mQAQb9RXmQISLDqfCo9Al6C15YtaYyUuxY88x uJKS07+ntnbrziOY+eHPqH/dM5kJamP3CVz39ZmJrbtD8OZHv6CBTFMwclq2aSCatNLP9ZY5EMFq L48xLbAXXsa0wF54GY2s9TEypgX26SuMacHF4Z+Sgrt7ToOjWg9BuALhqNNHHv26Zv0++f3S5Vtw W6cJ7mNh6/UT0jdn4tZQELb6/dync/n1LTDhM6YFF+tHNjkZCxcu9A2RFQOtrjP21LQdi1oFlwvJ mpqCpKbt1jV42QQv7hbXbOKhQoogf6kabCRKpZcbXTESkygdMEoPYpxP1lRJQZxSvDDp3bj9MB4P nI3HBr2DuwSJLcVNWA3TNlxRkyrI7KiJX+LPTQdRqpn4rko3twkBJbfNTfyuYUDeaXKQ0k2otfTX c7NXM7dLsWzfVXwcoye7N3vlR2KzEdl40Qjmzp2LQ4cOSVLrEoOjtyRREL34kye9mqdVxCk6BSdd OmlUp0RBHuJPnNATL0H4DF42wktMgJ10cadh3eLDwpAgCKDd65EgCLmT/n51xUiQI236CjHOxx8/ riVWxIl45ZWGK89ITcGegydw5Fi44DpJ8pr6jtxn3PRvBJnqAkfNHoK09kKZ5v1RruUAlBfCz3Li 7xqXDUW9q59E6WZBGdc903gpXqlVf7RqH+iz/Ess3mIA6rTpj6btgkR8YKY0pcVzf+a1RUhwxiNC 9P8FJrKxYiCkCvfdd9/FgQMHkJCQIK+R3PKzqPFY0dHRH5g387RKPEa8ONGnThU6n7i4uBKvi2cZ GI8THUJUSEi2696O51UGX8WJV4wHXsX1u76MxwkyVBx4lUQ8RhCkGDEJ1q1ejEcLQhErJla2x0hM NGLEREpbjM6e1aevEON81NGj2mBESUhwutvhmTMSr7zSIzUJu/YeRbU2A3Hdgy/j2PFwOJ1OmQby fNNUPNBnGio0D0SVtoNQrf0gVGk3KHNcSKXWJGNBuacpcHxwnmlqCGl/5YAi5G/deMPLBqLV5aJu bQdnul62fh8Me3EeoiLPIUyM17EX40eWM5FFixYhRAyIXg/GtMBegUvVOuNlTAvsg1faIQ86Brls rYEfWWNaYKNA0wLN+opU5aK1AKYFv/65B1ff+ZL03Vq57RNYt+lg+neffb0enXpMQ8U2QzJMCWgX W4JC04L6LfxLvBxel0aBqNQsEHWa09wiy3OuUATTAuO1oJD9gvFaYD+8jNcC++BlvBZYPhivBTbq KzTzWvDBot8x7KXPkZKSKie9nl4Ljp86jxOnI9P/3vZvCG7s+HqGTatfPzz32hLp1zUh0YX7+syA w/Gwm8RaZEOU8VpgJfdbxmuBvTo747XAfngZrwW2C8ZrgcGo2PsKzbwW3N93Jupe8zTCzsaIhujK dLLXsJc/x+W3vYDZn/wqN2dJTSu9Dni6xqreA2OmLBWkNwJN/zPK7VXAQoRPd68FfuZABIt04roe iKAzXmbiYR+8DJG1PkbmQATbBF0ORJi/9C906v6Gm5z69cX9/Wbh9Kkzoh26J1Q8gasPT9gq3wWO yl3hqNY9Z9+tDQNQ/dJh+G/nSW7vBI2tRfbMgQjmQITi6eiMaYH98DKmBfbBy5gWWD4Y0wIb9RUa mBZciEvA3T2nw+F4xG0GwAMIBEld/uMGICpSpomMjsPdvabBUatX/qSK99fs5bbPtBjZM6YFxrSg eDpxY1pgL7yMaYG98DIaWetjZEwL7NNXaGBaEHryHBpc92yGGUDaxqzJ05cCcRdkmpAT53D53S/L U7XsTPiMacHFEtnUVHy+eDGOhoZ6/+WhjzZNOzo50GrmtUB2dppqWOSga/CyD148rUdTrwUk6Cka eC1IiY/XFyMx6dUBo/S+IiWl2M3G3pr/G75YvjnH75yuZCSmHfd66kw0ej/1EToHvYVHB72Dzr1m YO6Xf2VKfywsEvf3exOO+v4ZZgDc9V6nH7r3n4WECDfPOHj0DGpe+ZQ7nadNrM3ilwipr8ieDcuf V1x6LWiRRSMrD0Toiucmub0WxOTjeiszkRWJE8+exYI5c3B4zx4gIUF2ThxE5GcR45zVJgqC7M08 rRJPogPmU6e0qhe1K4khIXriRcftuuElCJG2ePEwhBMntKsXP13HjkntmO0x4gEjumJ0/LgWGKX3 FWLCkXj0aJHySS1geiQlIjkuHlff8QKuv3sMNm3ai6gzYsLtFN+5EhEZHoFHek/FHZ3Hi3Rx+OWX LYKQ9oSjymNw1OgGR6mO6NH/TcRGRMLt4xVY8uXvcNTugcqN+0mNHk+H4meVJgFocdlA3HrLkxj9 +kKRbh2q0s9rU/+MNJ7pbRKvKYheu7b9bFv+XOPikwS9dRt/GfdMU7ZqV7w+eQlSz56RPvovFMiP LBOJRuQMDsan48cjeLOYOYnGTg0Pl5flZxHj7OScBw54NU+rxNkpJBw5olW9XCdP6ouXIHwGLwvF z53LGy8xAU44fLj4ylCM8QTR57J+JVkGb8QTBSFnXexa/jwxOnhQC4xU3BUWBuf+/YXOBxdiBKd0 Co4QmWsa6ctVfB8RchzjX/8MDZr7o3aTPihTrQtGPDkHztPhtIfCT9/9geZtglC1Xg9s/Ws75sz6 CjUb9ES9Fv5o0CoA1Rv2xv0Pv4yQ3cE4/G8w3nxjCTp2GodqjXrLJWmm4WYhFW/esi9aN+uBmuL7 Go37iuv+2dJkjdfP5bpV4k1a++Pq9v0sWbYixYW0FCT2qnb9ZNwTi0o1HsebUxYiZf8eRIpxjfy0 4AciiNnOwiVLECI6Ja8vZ9Bhu66mBXTYfuGCVnXiUrXBy0Z40cm5xqYF2h04kha4bM2NlbZvf9TA aWxaoANG6Vilphapr1i3+SA695yO3z0OEsgpOBOTMWHOcjiq9YCjftrhAnX7SldZW/ccw/yvN+By Hkzg596odcX9r6LJzaPdngUapy0xi3hFHlqwORgBz30KR5nOMg9Hk/4ZaTyES9W1WqQ52Kef2BzS 2E1KNQly25FqUJesUlHgVVuZFnh+V7ErRirTgnxIrPFa4MWOzngtsBFe3JxnvBbYBy/jtcDywXgt sFFfUUSvBUGjBKF0PIiAkXPTryW6krF5xxEEh7jHjPc+W4NGV4xAuZYD3YQy0271QNS58kmUaT4g s0eB2r3hqCdIatOgbOlribxKNxuQt2ss8V215u7l6my74G0sxmuB8VpQLCHZeC2wF17Ga4G98DJe CywfjNcCG/UVRfBa8Pk3G+B3+XCpFfW7cgTeWfCbILFJWLpiizzytcmNI/HKzO/Q8pbRbndWuZ2Q RW8DDS6CnDF9o/x37lfNzS+pzb0WNDJeC8yBCD7vxM2BCPbDy0w87IOX7kSWm2LsjpE5EME2IbcD ERISk5AoJLfA414bXv+s21SABwdQe1qnD27vNhXNb37eTUzr9XMf/0ri2bT4iRGJbF3tiKw5EMGY FhRHR2dMC+yFlzEtsBdexrTA8sGYFhRPOHf+AkJPFvE5p6YAzgyb86iYeCz+dgNaCTJ6X98ZSEpO yfG2VX/tQaXWgzO7s6LZQI2eaXarJb9UbUwLjGmBMS0oZDCmBTbDy5gW2AsvY1pg+WBMC4onzP5k FR4f8q48frWwISbqAhZ9ugKr/9or/57x4S9wVO0GR+VuaHj9SOwLPpXtnuCj4egcMEseBWu1I1yN aYExLcjstSA5GQsXLkRISIjXX0AOtLrO2FPFs9NuVzW9TOiMl247rImXpqYgqfQyodnEQ4UUQf5S NTAtSKVnCV0xEpMoq2D07OtL0Oa2MYiIzKwhPn02Wn43a+4viItPxM69xzD4hfnYm0ZKaTbA63HO REya/QNKle2IFreMxq59x3FXz2nSRIDmABVaDcLKtbvS71HhuQlfwlH+Mcvvgq+S7mBfn539pZtQ y+yvpdcC+o6tmxNeFR/H6MlurwX5kdhsRDZevKxz587FoUOHpHbWJQZHb0miIHpxJ054NU+riPPs WcTTIbhGdUoU7UFnvJy64SXIXtzx43riJQi6k4dYaFi3+FOnkCAIoO0xEpNebTEKC0OCILMlWQaO x4mJLvQY9g7KNAvCou/WI96ZIE/p2nvwOC69aywc9XqjbIsBaPnfUah/9ZNw1O6FYS/Oxw+/bsV1 D76Kljc+I7+r1X4wWrcLEGn7o/41T6FSm0EoJ+4r17w/yjXyx7jp3+Cd+atwfcdXsXT5JmzbfRRX 3fcyyjUJQLmWA1BeSLk0KWq8vJfykXFRh7pt+6NpuyARH+jVcpZkvHKrAWjVIVCLumTFq47Aq1kO eJWu2RPPvLoQCc44RIi+pcBENlYMhFThvvfeezhw4AASEhLkNZJbfhY1Hnv+PKJDQ72ap1XiMaKj ixEDUmHziYuLK/G6eJaB8TjRcUeHhGS77u14XmXwVTwrXsX1u76MxwkyVBx4lUQ8RhCkmJMntauX 7HPF5CNWEHW71+VCeDhixMRXW4zE5NfXv5WclEjdtvzk3+p6nDRrSEFyShL+0+lVlG1MzekA/LR6 m7z+weerUbnNAFRoGSSvl20uSE+LIEFQSQ6C5N+lmwXKzzLis2rr/mh/5QBUaTtQXAtCZfFZpd0g 8fcgVBWf5Vv2z0ifdk+l1gMypfFWvKqX82x06UC0vJx1G+zVcvo2PjjPNDWEtL9igE3qcnHxhgKv VjngVbZ+Hwx/cR6iIs8hTIzXsQU62cvDtGDRokU+MS0Q00mkaLxUnaqhaYG2eHGpWje8kpKQoqtp AZetNXW2L5etnU49MDKmBUUKP6/bLc0DzpzL3jfNmvsrHuw6FeVaDnJvtqrbFyPGLUS804WAZ+fC UbuP2z1V48DMws1YDdXfbp+sZbhU3cI/e1qVplFghvBeutBqlHG/ZUWUsXLTQNRunnYggpXLehFS Ok+8bCwCr0oCrzo54VWhCKYFxmtB4YLxWmAzvIzXAnvhZbwWWD4YrwUFC//sOop/D5zI8bt+T38s N1zVv/YZTH5nOTZuOyzlq+WbUeOyYWJwfyzjcAHxWa7VIOkOS5LbxoEF3mBTTuNd8MZrgfFaYLwW FHagNV4L7IWX8VpgL7yM1wLLB+O1IO/w74GTGDF2gdRu1rxsBPYdyvAMsOrPPZg04zv4XfO02/8q /bNmlZwOFuC13L7LhxjpugveeC0wXgvMgQiF7cTNgQj2w8tMPOyDl85Els72zYEIxR64I9+Z4Cow Rkhw5ppPfiHmghMPB8yGo1wX96EBDQJwxR1jMe+rP3HgcBha/Hc0HJd0cn+nDhFo7LG8fxHa1oIR WX0d7JsDEcyBCMa0oLCDkTEtsBdexrTAXngZ0wLLBzuZFpw+F41rHnwNbf73gjwIIPxc3koITuid kVHYvPMoNm49lL7kP3/pX7j8npcxfvYP7mtbgrP5YHW5kvFA35nSg0Am/6u1eqF08wGodcWIDHOB YhJjWmBMC4xpQWE7Oo1NC1KMaYG98DKmBfbCy5gWWB8jm5gW/LHpALoPnONekq/dG46avXBz54mY 8eHPmPHBSrz50S84cixrv+fCvAW/ujWmvCenpX9Khcfw386TMt255+BJ97GugrhmG8gbBLhNCRoH FjsxMqYFxrRAX9OC1FR8vngxjoaGen+gpS88TW2o5ECr2S54eR63plowOegavOyDlyB6upnuqECC nqKB1wKaR5T05DBZjF9OV3KO312IT8SQsZ+hVruhcFTtnqEd5Sd3/IuBk07Yudmq3X9HY8wb3+Dk mWi89/ladH5sPBpcPjRj976nNPYwA6jWE9c9PB6xzgyThWW/7czwNKCcvTcJKtF4afHp1lpaozze jNPBfu0WHho+Dep1icZ4VUo/wCILXhW74rlJbq8FMfm43spMZEXixLNnseDtt3H433+BhATZOXEQ kZ9FjFPzkBgS4tU8rRJ3hYXBdeqUVvWidkVrvE6e1A+vo0ftWX5+5oUXHe2fOFF8ZSjGeOKxY1KT XpJl8EacdXAdP14sv5XqEaftKv8+dvg4Aoe/g449JuPv9buxa3swdu9wC+Oz5nyP0n69UaZuL6kF ouaOp0DlFC9VpyfKNeyLltc9Kf4OQl2/rqjXtE+u6VW8ssj/mjtfwJmT4UiIipG/O/a1z1Glfm+R JiDf361cTHESvfZt+xX77xZHnLakrdv4a1WvWhrj1UDg1SYHvMpW7Yrxk5cg9Ww4osRYfaFAfmSZ SHQKzkOH8OmECQjevBngcrkgn8mC3MrPIsY5ECUcOJBzGjEIe/O3ijtOApF45Ihty5/T808SjSdX vHxdBh/HSdBzxKsYy+DteDa8bFyXbHiFhiLx8GHt6sV4QnAwXKJ+dq+LSxDyRDF++Pq3EB0JuOKB C9FuSU3Elj+24fLrh6N87W6o3qg3ajTqhaoNe6OaR5zX/Vr6y2VnLmVyAGW8nkfc83rd5v6o2bg3 ajX1xxXt+qFtW3Fvi8xpssbrivRX3PgkTh44gkM79qOOyKN6g165ps8ar1tM8aat/XF1+37F/ru5 xet7K08hrdq48WK8oPfWz1KG4ow3KECaJh54lVQ5fRIX0lLgdaXAq37LzFhUqvE4Zk5ZiJT9exF5 8KDkpwU/EAHAwiVLECI6Ja8vffIseF1NC+hgXzw/nQKXqrXFi9oc3fBKTtZ2Q5TES7cDLNICl+O5 sdL27Y9a0mIw/9i5/yQGvjAfew+fxi9/7sUjA95Gh7tehsPPP82pelD25X8pQYU8D76/1IhVbBaY f9q6fdHghpHYJcr4z7/HUIYmBX7+ljvfnkvVfi0DLFcubwiXqmuppWpN6lRKY7wqepqCNM5sWjBS mRbkQ2KN1wIvDkbGa4GN8DJeC+yFl/FaYPnga68Fp85EYcPmg+j2xLtwVOuBmpcNR6W2Q0S8u3sD ls92VveXWiLuhs/kdSAn8euHmpePwPp/grFs9Q7pleBifbwarwXGa4HxWmC8FpRMJ268FtgLL+O1 wF54Ga8F1sfIR14LklNSMP+rv3D9fa/AUaMnHPXTdvlzt3/94hncufzPATfftKI8FVoPxs9rd+GT JX+4y2lBImu8FhivBXp7LTAHIhSuEzcHItgPLzPxsA9e5kAE62N0kQcipKSkIjk5Jcfv6Hs1Ni5B ytc/bXG7vareI+0c9uIfbOsWlMgK0lpKlPGrZZsxcc4yN+kuZh+xBSOyQdI2U1ciq+OBCLriZQ5E sNJgZEwL7IWXMS2wF17GtMDyoaCmBfsPhWHDpgPoOugdBDw7N8c0PGCgfsuBqH/dM27zgZLUal6M aQFJa+1e+OLHTXhu4hdw1Opd7D5ijWmBMS0wpgW+1sjqvFSto0bWmBbYCy9jWmC7oItpgUAJSMi5 HiR2095ehnEzvkP9a59xa1dr9ZLL8KMmfolp7/+EaXOW4dgpNxEe9MJ8OMp0lpunist8IK/BNl0j 2zj/tI66ffDogLflyWHykASLEqOGGhOjumpjlEamBbrila6RzYpXxSIQ2UQxGC5YsABHjhxBamoq UlJSvCbJTidc1D54MU9LiHhOSYIUuejY3MvPrCQlWUw8tMaLS7q64UV/pDriJSaJLhI+jfBSwnol 0+uJj39HdOgZlNMb+SkinpyM73/Zhs5dJ+DlV+Yh/Gw03vvsN3TqOxOd+r+F+/rMQOnm/eWpV3Jj Fs0Emgbhkmb93drK6uJa5a5wlO6EH1dtl3kHPfcJSgmyyzQlLk37o16rQFRrESTj+abnBq86vaVZ wSXNLVD+HKR88yA0bB1oybIVFavqLYPgJ+pWqqk+9SrXTF+8qgm86ueAV6kq3fDchC9k/xIlxusC E9lY0Znyhjlz5mD//v1wCuKprqvEhY7zUxC9qFOnpD8wr+RpkXiceE5RJ04g6vhxGdeiXuIzVrQF 6YhYR7xEvaKOHTN4GbxKNi6wig4LwwVBZpWfxPzu5WecR9qc4okJOZ0UloSNWw8g9PhpxEsNsJvY uhKdSHDmZaOblGOekZHRWPTtH3g0aCYqthuEGk17o+Vl/dH05pGo0WGwIHKCzDXoA0ejvqjcZgCq iWu8Xl1ItfaZ49XbD0KlFoH4ZsVGme/AUR+jdMO+uaYvzngV8dn08oHwu3QQqvrot6oVY734WzU7 DEKLKwdm+t2Silf3Yp6V2hGrQWgr6sZ4SdbLm/Ea4v1oaRG8vBmvLDBqIvBqlwNePJBk6JhPcD4i HKcEb4wt0IEIxrSgaItqxmuBvfAypgX2wktj0wJEi3bo8q4f2cjoOLwzfzXeeHsZ3njvJykvvvEN anUYipHjv5BpFn+/EW/MWY4TYecRF58g0v+WKb0U8fdfW4LdxbwQnykNta1cRnfU6SOX/6sJIlq7 uT8c9fpdvE0rNbMin/c/W4tEVzIe9H8Tjpo9LbP8Wa+gpgU2srlspLFpQT0NTQt0xSvda0Fj47XA GsTIeC2wF15m4mEfvEhkSwAvrsZfiHXiQlyC+EyQ8fxCoosazHjEO1355J0q8407HY7Y81Hu/ONy l29/3oqHAmbhoX5vuj/zkOs7vi6IYC/3cr4YEKRU6SZtNmtcNhx3dJ/qHiwqPI7L73kZNz06Udqs ZkpPKf8Y6l39tMzzxkfGZ07D/NVGprRNNnUKSyCYjyDFU99dIUn47d2m+tY3rK9sZG1EZLXcBa+x jayueOVqI2u8FhR/MF4LbIaXrl4LdMWrBLwW7NhzDH2Gvw+/y4bB75qn3XLFCAwZMx/rtwTnKMt/ 24lbH58MvzaDJUFc9N3fmdNs3I+9wadk/rQlbXLzaFx945Noe+PTGb+Ri5RvNchtY1oQ8SSZWYWb p+iPVWlNSRip/cwpfdMg94al/PIUg1CNFgFpA1L/Qg1oJLJjp34tNcSSiFPTa4nB9iK8FthEjNcC 47XAeC0oZND5QIRkY1pgP2JkTAvsg1cRTQvWrN+HqTO/w9T3fspZ3l2BqW8vw4nTGb9x7YOvurWP JHKewp30XFLPTTKlzfJd2c64t/cMmf+p8CiUajYAVer1QNkGfbL/TlZpYO2BrFpR/HemHe867KXP ceDIaXS46yX387JI3Qp8IIKtTAvMgQj2Mi0wByIY0wIfB2NaYEO8zMSjWEJiIpfanWlL8xmyaccR 9Bj2Hh7qM8O9JN5rOgJHzkXw0dPyeM+HukzC1yu2uPHKh8hOfOtHREa7NywNHD0PY6YszfT9kLEL 4HDcl3nZ3FMqPg7HJZ2wbtOB9Htu6jQBjuo9cyZd0jF/LpJ1ydxTqnZDR1FXhrAzUajQ9gnUbtJX duZ2H5DSTQsKm4cg632e+hDb/w1Fs5tHuU/uskjd6mpHZM2BCPYisuZABGNaUAzBmBbYK8jNebpt HkpOgutUWIGSHjl2Fuv/3u9e7t50EFt2HpUnLeUXIiJjsX7jgYyl8s0HEXPBmZbnmYw804SE9BZB SDMtz6dJ1Q5D3UvaVdOWw/lZu7c8q57+RR2OBzDx7WXuquVjWkAtZ9hZ90SSeV/X8fVM39ONiySs uWoEA6VGcMPWQ+n33Ey70Rpe3nAk6vlw4GyZvySybZ5AvaZ97W9/WVTTgjQi21E8G7abOlc9WfL+ Y41pgTEtMKYFNjUtSE7G5wsXIiQ0xCcDLSL1sktMJ0biQSPugmaVSkaKpqcpISlBtMcEWxZ93tK/ MHX2j3JJfIpaFn9nBU6dPAu44rB6w/5My+jpaeYsTyd7XMKlBlIu31bpjlpXPAlnPpuTGJau+AeO cl3c99G2UpDPjxb9joTEJNzbZwYc5btkLKPXyWGp3VN4fGfjHAglNXEkMaIjm/7hz+6mmI9GtvOA OQg/537/Wv9vDO7oMS0zkZ34ZcGI7LbD6ffc5DMi+5abyAosyrdxa2Qra0BkMzZ7FZ7I0r74t/X7 xESGp3lZh8hSw1dFIyJLDV9D7Td76UNkS2uMV8Zmr+xEdpQisvmQ2GxE1hUXh88//RQH9u3H6dPn ERYWgdNCwtLEM57oFEQgNQUR56KREOeUxAeCCPPvU6eypw8/dhpnDh7JM08V5/0R56JkfkoS4xPE 9XP53lvQPD3LGSa/i6ancPdvOd2/5Xk9NSkJqeI7KR5xmT7iPE4Fh6b9RrR8Li6RR2HKaZm4wCvy SGi2Z+KN/Pmczp3NwOJ8RM5t5qLiaXkqTIgRcTgfESO+O5ee/oQgfONeW4A77nwed4iBM0MmFTp+ +/3j8PLUpfL3+Bv39JiK2ztPKFKeMt5lEm7vNB579x1Lx6HJdU/D4bhTyENp8qCQ+7Fu3U4gPga9 h38g/r7V43uV5j78sWEv6D900HOfuK/V6CHJZ61Lh8LJHfnquaWkSEziY+PdbT/tmX6zfDMcpR4W 93V3O7Kv+Bju6T4FP6zcgrJ0cF/lcXeeUrq7P2sq6emWWj1RSpAUDqZc4iyTJlnjl1Tuitkf/Sz7 FWmDLiZV6e+f5zsoPnsMfgfh4ZEy7WV3jJXPj3HVBka+tgilq3TN9bfKNAlEaUGk1m/an/6cb+sy EaVFefMr58XES4tn8rD/TFkmvkuV2w5B/aZ9UbNFoChDkFd/qzjjlJotAqStW5nC5lO/Ly6/cyzm f7EOZRsHoKzAxAp1LN3Evaxrd4w845WaBaJpa38t6pK1HdZo4dbIltGoXhU1xqt6C7dGtkwO/f+L k74EEpyIpp/tAhHZNOfc8Xv3YtGE8Vi1dBmeeuodDBs2G0+PeAsjRrwthXFeGzp0Ng5u2S01QLOn L8GuP7cJ2hyJ1IhzmPXGIgwcNDM9PT+HDn8bLz/7NmaNfUfGs+aZNT5I3D9zykKknjuLZNr9RUZg 3+bdCAyalu+9+eZJLeP5CMx+YzEGDnSXc8igGZgl6oHYaPlb+7f8iyDxW57XeY49TSOkeMSZPmzX PowcOlPkl5ZePJcj2/ZgmHhOOT1Dy8WHZ74+TPzN+vzwvmhIF9zP5ODWPeKZTPfK7xKLNyZ+JvGl lv6dmV9iwIAZRcpzMPOcsEC2lxQhxAjxF/D+219j8MDp6emHD38L/ftNQo/OL+O+B1/EvUL4+cBD Ywsdv+OO5zDymXfFSxeLwwL3ex96EffcP6ZIeTJ+zwNjcec9o7Hlt81uHES7nfzaPDzy6Dh07zkR vXpNQLceE/BYt/HY+usG4FQoZk77Ap3Tvs+U5vHXsO33f2gzgplTF6en6fzYaxj59By4wsMznltc DN6bvRSbVm0SvxuV3s73infwkU7j0KvnhPT8+/aZhAGi3fM3evWamOl3c4p36z4eDdoOQNlqnVGh ZheUrfEYyglR8bJpcYfjHnz6/neyX3EdP47EkBD3O8cypr2DxJrmL0MHz0R48FEgOhL//d8zuPam p+R9si7OC7JtOUrdlyl/z3jp6uL3KjyMn79Zm97eO3Z8EY5LHsgxfWHjpco8gNsFnmyXh8X7VK5O NzSv+yjq1xPfVc/8HKwWr1qvGxq37CcHnYYt/dG4lb+I+8s4j89sIQbadm36ybi63riAcRKPhs37 od2VQ/Do4+Ph18J9vaG4zk0uTVr7Lt4wnzTU7l3Xvh8ua9dPao58Ux5/GW/gcd1Xcda3ZRt/3Hhp 3/S6N8hWhuKMe68MrA/bYfu2/WS8oPc2LrG65x9XdfqPwEs+q1bWLGdh8Wou/u7ggZfCokrNx/H2 1M+RvHM7IvfsST8w5uJsZEN8YFqQmIiUCF03D0UjNUavzV5IciFZ081eSIh3i1Z4JdnGBn3ut5sx ZsIXGDP169zllUX4Y9NB9/uVj2nB599skL5WGWiO8NHidZm+X7Fmp8wv19+aslSU50uEnswwpXnv szUY8/qSvMt4sfLaYixYul7mHxPrxCszv8Ooke9j9Cufefd3fCAPDXwPjnr+bntmmlxkkVJ1e6BC PWrie+X4fb5S4TH0HPU59h0/jya3j0szU+nrNjOhGUpBJTfvDjQfYV6NAgtlWnBRdswsQ0PrLgWX 1dy0oJ5mpgU6m4JkHIhgE/dbJLLJmtpc0kZW2snqFFz6EtlU0dZTdPMyIfAyByLYMSTZopSxiSn4 +Y+9+Om3nfhp7a7MsmYXfl+7HevXbpXxbN/nJ7xn9Q4cD3e/kzv2n8QPK7fill6zUbXVIFRtP7TA UrrFILfP2+o9Mkgy44IUV2gzRJDMgMzf5SfVe6Jc3e4o1yDNHRh965Iw8zvaiXt6quD1Wr1QttVg ka5/zmksQmTNgQj2IrI6H4hQ1xyIYI1gvBbYDC9zIIK98CqBAxGKK3DykRIbqwNKQGKcV3OMdboQ fiYa4ecKLt+t3Ys7er+JWx+dgFsfm+yWR15Hz2fn4Z99YRj5xg/i7/EZ3+UrU9CzzxS0vOFZOCq6 Tzsr3eoJ+V2r216Eo1oPt79hIaWbDcSdfWbh142H8P5XG3Fr50locesYdxq6eMvN/VteQiJMLTLJ N//mRkmlYS6k5LgLPr/7bLTp0M94Lfh/7rXAHIhQuC7cHIhgL7zMgQj2wquIByJYOSQJgp4SF2f7 epCM6zY5TA/xF/Dr77sxdvJSjB3/BT5fvl1ePnQyCi+/+SPGTvwSYydkXPcMB45HutNM+lKeXHax ctUjkwV5DcCjT3wg/65/8xj3ccOFMd9QUrc36jXzMNuo0zvv9NykSQ8kBTHzUKYdNK3g3zmZWJAY M12jAJ8Qo3oaHlGr5YEImUwLbKKRNQci2CuYAxFsiJfOpgWaElmSv5R4+9trSyKrKUYpsl4lYwIS Gh6DlX/sgzPJ7ed5Z/BprFy9AyvX7iq0BI1ZiObtBqBqm8Go2m4o/McszjP9st924ra+b7vNPDoM zVPKKNMOkkr6im7SP4upRj5mHkrjXEgxByLYS8yBCFYajIxpgb3wMqYF9sLLmBZYPsjJhq4YiQm9 HuYf7uBKdCF0536En42Wkpz/WSiIdSYVyMzjh9/34n+93sT0+evk37MXrsetXSYLmZRu5tHt6U+x Zd8pPD9zWTYzj1rXPJtx2l5BzS/8+rr9DlNTXb0rytXOap7RK81E4mJNMjJrDzPFi9HcwpgWFILI Lly40HcaWV01RrpqZHXGy5gW2AcvnTWyOpkWGIzsgpZ0VWfFsHZrCMZO+VrI0gKZXowWaf1uHA1H iyEY+NIijB2/EM+P/ihTmuu7vJHhTYPa4oIK7ZOVyQTjPORFxfl9PWWeUUBRHjMaBWaYaTTM3wyC pgUNNSWyVXIzBalYBCKbKAbD+fPn48iRI0hNTUVKSorXJNnpRCK1D17M0xIinlOSIEUu0YmnePmZ laRojxeXdHXCS0wUEwWR1RIvMUl0kUxohJcS1itJkEDbYyQGG4ORTfoKl8unfYUgD+KfO87PVPl3 atr11HRuob7zvF6YsHXvCfy28WDGhdTETN8fOxOD5at3YMXq7Vjx2w4sF7IiTfKKv/7uz6h+5VOo etkITHj/Vwx+ZQmqXvE0xr21Qqa5ve9bqNJyEKq0fyJPqZr2Ke2CeUiM+ORhKNWk6UWQ9HShDotx NPJHqSaBbrJcq2e6VPHrnvG3Z5qG/rikWX8ppdM+bRNv2h/VWwahfutAGfdMU6pqN3m0eHJyEqLE eF1gIhsrXlTeMGfOHOzfvx9OQWTUdZW40HF+iryjT52Sjm29kqdF4nGCQESdOIGo48dlXIt6ic9Y 4nXypJ54iXpFHTtm8DJ4lWxcYBUdFoYLYlKlHH7bEiMxVrBvjwoN1ROj06dxgacL2RijTH2FmBjK voJxDTBCColrMpzsK8T7FBUSkqkdpvBIcmqhkZomBYtTsRdyPBxHQsOQ6EqU+B85dhoJiQkyzZlz kTgacgohx8JEmlM4KtLlFA89LuInwjF25ne4q/skPD/9O+wNPo7w8HN487O16NR/Fjr2m46H/Geg 5pXD4WgWhNu6TsYjgTPQMWAGHhWfA4e+iYdFXKUp1TwIt4o0ftc/LQgt7Y6pIU6TvOL1e6NS6/6C XA9GjQ6DBZkWklO8/SBUbTco7zRFjFduNxhNLh+EdlcORMV2mdOUa9gXQ8d8gvMR4Tgl+hZPzEt+ s5euS9XGa4G98DKmBfbCy5gWWB8jjb0W6GZakGqjw1Muuh0KnOxsq/3Zj1sx+cNViHFm2VwYE5Up zdSPVyMqPglfr/4XL076Ci++8U2B5Ilxi1Cu/Qj3Jju/NLMJPw9Rf9fq7db4el7zgZeJgngt4ATC KdpsXHy88Vrg05fHeC2wH15m4mEfvDQ+EMF4LbAJRroRWV37ChJZ3SZUKclIPuc9vDbsCMGAFxej WodhqNbuCfenkrZDUPPqZzBJkOmnJn+bKU2BDxPJ6xAQaV6RkSbHAxGYxvEQnnxlkSzvsX//xeYv vpC2sgkpKYjN4bhaSWTjCH5ysrzpyy+/RLivdj9rtPMzU3C55Mll2gXRQLQMoiPXEi/dTpdTgX2T 06ln3XQhSLSN1BUjTjQKab9p2aBrX0GcNJgYFgde8QmpQlLSPtPEmQKnK3uaWGcqXn1/LR7sPQsP +s/BgwG5yzUPT4Gj4UA46ghCWjcgQ2r3Q5UrnpVpru00VaYpW78fajXhxjdqaAeIdP6ofPmzuFd8 /9m3m2UZjm7ciJfr18eiAQNwcP16RIuJSlZTA0lkaYOwfPly/PDDDxgzZgzmzZuHFStWyGteEeYl 8l729dfuuLfytYL89BOWf/utWxjXoU7E6Mcf9cSL9fnuO4OXwcsafcc332D599/bGzeWnXVgXQxG 1sdq2TIsW7pUz75Ct3boiZcX8/155U9YveqXHGWVkJU/rciWZs1vv2LtmlX5yrufLMEN9w/H1bcG 4Orb+2fIfwPQbch4meaD+V/ihgdG4Kr/9ME1N/dFvct7COJ7H5pc3h09npiAX1b9il9/+Rk/Chw/ nzkTL9WqhVEVKmDWLbcgZMcOQbZd2YnsmTNnsFGw3k2bNmHy5Mn4WgyIjP/111/ekQ0b8IcAZM0n n+Av8Ttey9cKIurz+xdf4PfFi/GXN59ZSQrxWrkSa+bOxV9//60fXl99hd8XLdIHLzFL/ePnn7Hm 44/1xEv0R2sXLtQHLyWiPmvnzcM6MfjaGjeB0TpBHtZ+9pmeGC1YgHViMqXF2MW+YtUqrPnoIxnX ra8gTsRLp779z9WrsebDDy1RnvXr85ctm/7G/j3bcWDfThzY6yHi7907/5FpNjPN/t3Y++dv2LPs G2zcthUrf1mDf7ZuwZ5dW7EhrW1u3LYNywVvfNnPD4sHDsS+tWsRefZsNvMCSWSppqV9LANtZA8e dLuy4DVvCI0W6O4jbvNmGfdWvpl+IznZJ/kWpG7OAwcQv3evT+rGeikptnoRL9FY4kRn4Eu88quX L+os8RLtO37PHq/WLWtdihWv1FQkRkQgTnTk3sbLE6eSeMckXocPI273bi37jritW5Fw/HiJ9B1u i4AU72B05Ajidu706TtVElhJjHbsQEJoqE8xKs6+whUdjdgNG5DkBezzwqa460Z8iBPx0qavoPu3 mBjECmKXxN/20e/nhpXLlWFnwLjX8RJ9X6zoAzMslJKz9VGnxXi9QUxOYkS7pUFgbA6bvjJt9kpI SMBvv/0mN3sp91teE1GIGLqZ8WaeQmgAzLKyQ+ZnQZznel3o5ywy0uv5sj4Ek25AKPm5oLADXtJd j5hN8aVQL0ZubY0vlk/q7GW8pBG6eHfYBlle/s26xYsXrrjaI3/H23ipd4s4sP0RqwQPtzbF+X7F EC8ftAW2RdarRPoNPmPWS7xr3s43Ns3vqeo7ckrDw2/CwsLkM7AaRp79unqn+Dd9jRZrP8iy8L3y AUYU9hM+6+dyEx/0FSw/sVF9HtsU/y72MdmH45ZS+BV7P+EDvHJ619gWs2LFvuOnn37C33//nWs/ UmS88hmLYy/WawElmhn7quH54GXlw90qGH3v3r2lOQT/5svEzoH1UPHYLBvNvEoyWC8v142EYffu 3Rg5ciQef/xxzJgxAzQBYbnVLEnVy+1c2r0ZwasTEB8RB36+88476Nq1q6wfD+BgfVVd3Db7qXjl lVfkNYWlV+vlxbqxfN9//z1GjBghfTHz7zfeeAN//PFH+ixX4aU2VqqBi/X1CpHwAV4s56+//ooH H3wQjz32GIYOHSrfMVeafZJqh6yDwtYu75fqO/bs2YNx48bJuniWn+8R26R6r/jpNZyKoe84duwY OnXqhC5duiAgIABn0w438azLHXfcgdDQUHmtyBMUH7xTP//8M5588klERETIMq9fvx79+vXDiRMn 0kmtWjlUxElhZ+X+Qr0rfOZvv/02nn32WdlvqL5d1YNxRRC9Xi8v1oflYjsaMGCAHLNYXu67CQoK kooxYqn6CkV2VR/I+jAenwdJsUJfwTpSwffiiy9K7FS/rcrPvsTzQAf1nZXHYs93bdWqVZg5c2b6 oRaKuDOw3589e7aMW7X/y0ZkY7M4Sba6MEycOBE33XSTJD4MfIlIbvlyML5t2zbZEFevXi0Nnf/8 80+pifDay+OjerEBDR48WA62n332GQ4cOCBfFv69aNEibNmyRdaL9s2s27fffptOdq1aL74krAs7 PZb7tddew3PPPZeu1aRdDDVF3HDYvn17vPfee/j333+9v0LgZazeffddNGzYUG6YZODEirbmDOzc WSe2Qw5YrLfqHDdv3izbqE9IkhfqxQ6MA9Lhw4dlvE+fPggODpbf8eAUtkPWhx05J8ErV66U+JJI WRkzCgkQNQ0PPPCAfK/OnTsn6/PFF19ITFgHtkdiygGZbdQOfSNJwz///IN77rkH58+fl30d3y2a jLF+SrtCovvVV1/hu+++s1x/yMB3pnTp0rK87DcmTJiAChUqSNLEwZeaIqbh+8W2x36d/fuhQ4cs 3/aIBwk5J4h33nknfv/9d9kG2dcxTlz27dsn25yqF987K9aLbYnKCGLDPoL14HjkcDikFyQGjlU0 W+TknpMq9nvEjPeyX+S7ZsU+MOukl+8UseP7pcZalp9j84YNG7Bs2TL88ssvsm5Wrk/Wd419dmBg oOwTiQ3Lzgkk+/hRo0bhgw8+8A2R9ZJkI7J2EjYuvtwvv/yybET8PH78ONatWye1mAx8oTiLZ6dH 7cTo0aPRrl07rF27Vr5wVh5k2QkMGTIETz/9NH788UfZme/cuRPDhw+X2r/+/fvLAfb222/HE088 ge7duxNQOdha9SViIDn/5ptvZJyu3h599FH50rCz7tatm6wfpWXLlhg0aJDE0JVll6LV6qQ0K5zV slMbNmyY1ChxUGX78/f3l58ken379pUdIdtu586dZfoSWbIvYL1eeumldE0D2xw76pCQEKktYztk B8j36eOPP5b4PfXUU3IQtjJm6h1jp00ywb6AbZAaF06ypkyZgvfffx/XXnstxo4di4ceeki2WaWt sDqR5aB75ZVXSuy4OrBjxw7ZPhVefKceeeQRiWevXr2kt5rIyEjL9Btqvwa1xpzMsn2xf+fffKcY eJ19Iyf87N+vuuoqWb9du3ZZvu1x7Fq6dCk++ugj2bez32Bgfe666y5Zp4EDB2LNmjWyXuwPiaEV 68W6cJJ06623SmUSifesWbNw3333yYkTA/uM559/Xq4OcPLB8Yoadt7PflGtploZL/ZpHKvYB3Ts 2FHiwcD3h5vk2VfwfWNfwTraoa9Q79qSJUtkf87J/P333y/7Rr5nVMiQM7GdGiLrQwDmz5+PK664 QhJXdtx8cTg4kdQxUGXOl4bEgsu/DFwq5XUrE1mSUQ4snBGxo+OLw86CL0jTpk1lfdipc4meAzFn xNS+3H333Th58qRlNRIMHGyocWVQZI4zW3bcxFMFaoxUiPaRjZo3NZfUGLE+06ZNk2YT7Kg//fRT 2UEwcJIxadIkSYjYOVAbTZJR7PbPF0lkX3311fTlMpJwamCpxWvcuLFshxx433rrLfTo0UNqx9Sy qJUxy4nIckWDpJV1vOGGGySOrB8Dj+6mGYyVO3NPIkscbr75ZkkG2X+w3yBeJEjUKpFoEC8OxnwO vMb+xSoTKoa5c+dKgk2S8PDDD8u+gRNC9nVccWO7JMFr3ry5fP84iVL7CkrK5rkgoswKWF6+O5xQ sL2xD2Abe/PNN2X9OYlnf8F0nuZyViR51CQTm08++URixXfnhRdekOMxxzH+zYkUyR5Neah4Yn/I tsnvlBmgXYgsMePYzMBVKvb9XLlS2k1yDjv0FVmJLCfz5EdqbCamhsj6UNgRUPvK2RxJETs3NiCS Ic7eSY6oIaJ2pWfPnrJTZONix3799denL+VYtX58WVhWEgl+cvmTnQWXOjnwUnNEu1nOZDkITZ06 FePHj5faTnYcVu0UOMhQU0lMuFzBznr69OnpZIF4cdClVoUdOL+zg2kBn78iOiSqFStWlJoJdtic 1dL0gASJkymaF9xyyy1S07KX3i7EAGXVerH9cYZOMwlqWjkJ4aBDks7JI4kf2yGXDhnnMtTixYvl u2n15V0+dy4L8n1i4OSD2hUOsCQW1K6wPmqiQhJoh8GJ7xj7BTUgMRAv1pPEUPUbt912m9SgcTJF Tdnp06ct028wcJLONkfSSs0xJ+jU8tHsg2Vm+anJpAKDk0L2F2pzmJXxYRnZD7CtcWWGZjskESTq xIcTDI5d7C84ppE8FfuGsIskeVwpZD/B956Ejn9zEqgUSySwNAEkfrzOsZcTFD4D9pNWHovV5JDE jsoVlpV1oIaZBO+6666T5FxNeslH+D7ZicjSlIWTQr7/XLnmZIr9H/sQrhJwbDZE1gfCQZLklSQv Mu1oRBIEvjjsGLhMTWLB5SeCxMGXHSMHJpIIapWsSiBU/agh4YycnTkPqFAzeS4LssNjXdQSIZdC SW65pGhlAsHOmB0f8eEMnfhwFshr1ChzOZdkiSYT7ODYwXNZyspLhSw7J0bEiOXk8gwJILEgqaCm j3UiQVf157LiggULZMdhVTMQtZFSLUmTNNCkgHVkG+OEkW2O7xmXQGkzRs0E09rBtIDvPzXLJA4c nFgfvlec9FKTzlUbLlnzObAt0v7Nysufnn0HcWL7Upso+UmTK4UXN/FRC0PNLDUu27dvt1S/wefM SSAJn3IRxvIRF7YzmuNwwsEJBvsMtj/Wx+qTJ1U39mnsu9kG2fY4cec1YsPJPYkR2x5Ju+onrFof lo0ElgSO7YxYETO+W5zgcmWGE3ni9eGHH0otLAM/qVxi+7Ry/VRfQbw4GWT9qIBgX8H2x0kHv6Mt PbFlnanMsENfoTZYk7gqRQz7QTU2853iuMaJsJXrY1siq5YiPHcIql3HnjtaPXcRcobBhsiZIcmG lV8e5RIj4+S91Ewzes96URMRk3aEHRublZfVcquDJ35qJ7I6NtnqS4Usm+q8Peuhlmk926LaqauC 1d+xxCxH+XrunFb4KIziPY6GLDFXeBehteSKAJd2SZaUGyTPwL8Vpp742qlv9CxvVrw8g9UmHcqF Hd8dz0126h3iu5UVq6z1tTI+ym9n1veMygkSQOUNJCccrdzeFDniNWKnzKayBpodcFWOEyirv1d8 V6iEoCkfiR3bXtZ+UU1IsrZbq5NYlpu25zQH4WpvTv0g8cnJNZchsiUknEVxmdrKS++FEc7a7dCB GzFiFeFkg1pLLhfq1BcYsa+QWHDzK1eo7OQ5qDDvHu1LqVW3w85+lpFeFVR5dcKGdWEfyL7QDqsZ hshecC/pKEf1OtXLijvejRixurDjtupGOyP/f9ukXdw2FXXMstO7R86ga19BLJQJkiGyRowYMWLE iBEjRowUN5Hlf0aMGDFixIgRI0aM2E3+D4Rd5d5I2j4WAAAAAElFTkSuQmCC --_004_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_-- From nobody Tue Aug 5 09:00: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 03FA21B2A2A for ; Tue, 5 Aug 2014 09:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLGWeAyrtUwm for ; Tue, 5 Aug 2014 09:00:40 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c: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 01AE31B2A3D for ; Tue, 5 Aug 2014 09:00:31 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so1224035wes.11 for ; Tue, 05 Aug 2014 09:00: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:content-transfer-encoding; bh=k4KzOjAho5OhgHfM3cWWPQvLbFn0KKFjxn96ec4QSkw=; b=l0SymzPvREI6yY9n1vWuV41YkAOtN+gh2NkQTPIT5ayWVCEb5MhWGBpD+K+ubCoiKj 2Z7vJ19yXa7Iuc/5hQY77oyn6XEwdixPpHk9wacKHH2NUDyhsQbfwlpTjPnfD9CeUd9/ j0cKDttg+tVQmMwIvbJ8ktjTtY6R7UkcX6IvncN3G2mPmtFdyPddtX0rReCpe4ZviJkY tmRgrFsGrvIbwZHWio/9Eyt/dYKF4C79o5qM5KnjSck6mlPnMQJ5tRlEiRlOViofeaVj 1KcQjuJns0LeWav3gofWWhqLaCyukk72+6djOIYXzWz062FDg9Aw8nx3mGCtqQjs9c9R nNHw== MIME-Version: 1.0 X-Received: by 10.180.81.234 with SMTP id d10mr7868551wiy.79.1407254427378; Tue, 05 Aug 2014 09:00:27 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Tue, 5 Aug 2014 09:00:27 -0700 (PDT) In-Reply-To: <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> Date: Tue, 5 Aug 2014 09:00:27 -0700 Message-ID: From: Ca By To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2xa_HYBO6uSPmgSZ-88NP-IKITs Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 16:00:46 -0000 On Tue, Aug 5, 2014 at 8:40 AM, Ted Lemon wrote: > On Aug 5, 2014, at 10:57 AM, Owen DeLong wrote: >> Upgrading your application to be protocol agnostic about its connection >> to the database server shouldn=E2=80=99t be very difficult these days. > > Furthermore, you don't need to upgrade these parts of the application. T= he only part you really need to upgrade is the part that sticks out of the = data center. The rest you can leave running IPv4 until the equipment dies= : that's really your deadline. >. One of the fundamental flaws with the dual-stack transition dream is that people care and will upgrade. Today in 2014, a young developer somewhere in the world using the best tools is hard coding an IPv4 literal into a application. Somewhere else in the world, the biggest and smartest companies are investing billions of dollars into futuristic cloud platforms that dont even have token IPv6 supports (Azure and Google Cloud) In summary, the premise of the daul stack transition for the Internet is faulty. It already failed. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 5 09:25: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 E83921B2A6E for ; Tue, 5 Aug 2014 09:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.736 X-Spam-Level: ** X-Spam-Status: No, score=2.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, 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 J79YGDanWd-9 for ; Tue, 5 Aug 2014 09:25:24 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A022E1B2A49 for ; Tue, 5 Aug 2014 09:25:22 -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 CGZ15593; Tue, 05 Aug 2014 18:25:15 +0200 (CEST) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: "Heatley, Nick" , Ca By , "Brian E Carpenter" Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvAqKYAgAAE0ACAABWsAIAAcMQAgACEo7CAAFGuAIAAKEDQ Date: Tue, 5 Aug 2014 16:24:39 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F859D9@OPE10MB05.tp.gk.corp.tepenet> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <2D29C51862222E49B991EF64EEB0B5B745F85768@OPE10MB05.tp.gk.corp.tepenet> <6536E263028723489CCD5B6821D4B21303B6F85F@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303B6F85F@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_004_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_"; type="multipart/alternative" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.8.5.150019: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, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __EXTRA_MPART_TYPE_N1, __EXTRA_MPART_TYPE_1, __MIME_VERSION, __ANY_URI, __FRAUD_BODY_WEBMAIL, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __FORWARDED_MSG, __HAS_HTML, SINGLE_IMG_ATTACH, BODY_SIZE_10000_PLUS, __PNG_WIDTH_100, __PNG_HEIGHT_100, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, MULTIPLE_RCPTS, __FRAUD_WEBMAIL X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0208.53E1056D.0171, 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.0A0C0208.53E1056D.0171, 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: 3b4cc769aff48891f03de6b30b037e7c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8EeRx076BiA8b80K-Pkjp0Oy39k Cc: IPv6 Ops WG , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 16:25:28 -0000 --_004_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_ Content-Type: multipart/alternative; boundary="_000_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_" --_000_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljaywNCg0KSWYgeW914oCZcmUgc2F5aW5nIGNvbXBsYWluYXQgd2l0aCBSRkM2ODc3LCB5 b3Ugd2lsbCBpbXBsZW1lbnQgREhDUHY2IFBEIGFuZCB1c2UgZGVkaWNhdGVkIGlwdjYgcHJlZml4 IGZvciBDTEFUPw0KDQpCUiwNCk1jeg0KRnJvbTogSGVhdGxleSwgTmljayBbbWFpbHRvOm5pY2su aGVhdGxleUBlZS5jby51a10NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNSwgMjAxNCA1OjU3IFBN DQpUbzogQ3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ7IENhIEJ5OyBCcmlhbiBFIENhcnBlbnRl cg0KQ2M6IElQdjYgT3BzIFdHOyBUb3JlIEFuZGVyc29uOyBLb3NzdXQgVG9tYXN6IC0gSHVydA0K U3ViamVjdDogUkU6IFt2Nm9wc10gT3BlcmF0aW9uYWwgQ29uc2Vuc3VzIG9uIGRlcGxveW1lbnQN Cg0KSGkgYWxsLCBFRSBzaW1pbGFyLCBidXQgbm90IGlkZW50aWNhbC4gV2UgYXJlIGhvdCBvbiA0 NjR4bGF0IChSRkM2ODc3KSwgaXQgaXMgcGVyZmVjdCBmb3IgbmV0d29ya3MgdGhhdCBhbHJlYWR5 IGV4dGVuc2l2ZWx5IHVzZSBOQVQ0NCwgYW5kIGdldHMgY3VzdG9tZXJzIG9mZiBJUHY0IChib3Ro IHB1YmxpYyBhbmQgcHJpdmF0ZSwgYXMgbmVpdGhlciBpcyBzdWZmaWNpZW50KS4NClJlZ2FyZHMs DQpOaWNrDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEN6ZXJ3b25rYSBNaWNoYWwgMSAtIEh1cnQNClNlbnQ6IDA1IEF1Z3VzdCAyMDE0 IDEwOjIyDQpUbzogQ2EgQnk7IEJyaWFuIEUgQ2FycGVudGVyDQpDYzogSVB2NiBPcHMgV0c7IFRv cmUgQW5kZXJzb247IEtvc3N1dCBUb21hc3ogLSBIdXJ0DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBP cGVyYXRpb25hbCBDb25zZW5zdXMgb24gZGVwbG95bWVudA0KDQpIaSBhbGwsDQoNCkkgY29uZmly bSB0aGlzIGlzIGNvcnJlY3QuIEV2ZW4gd2Ugd2VudCBmdXJ0aGVyIGFuZCB3ZSBkbyBub3QgdXNl IEROUzY0LiBPdXIgYXJjaGl0ZWN0dXJlIGlzIENMQVQrTkFUNjQrRE5TLiBTbyB3aXRoIGRucyBh bmQgd2l0aG91dCBkbnMgaXB2NCB0cmFmZmljIGFsd2F5cyBnb2VzIHZpYSBDTEFULiBJdOKAmXMg cGVyZmVjdCBzb2x1dGlvbiDimLogVUsgRUUgd2lsbCBkbyB0aGUgc2FtZS4NCg0KU2VlIG1vcmUg YXQ6IGh0dHA6Ly93d3cuZGF0YS5wcm9pZGVhLm9yZy5wbC9wbG5vZy8xMmVkeWNqYS9kYXkyL3Ry YWNrNC8wMV9pcHY2X2ltcGxlbWVudGF0aW9uLnBkZg0KDQpFdmVuIHRyaXBsZSB0cmFuc2xhdGlv biBpcyBub3QgYmFkIHRvbzogQ0xBVCtOQVQ2NHN0YXRlbGVzcytOQVQ0NHN0YXRlZnVsbC4NCg0K QlIsDQpNY3oNCk9yYW5nZSBQb2xhbmQNCg0KW2NpZDppbWFnZTAwMy5wbmdAMDFDRkIwQTAuNjIy MjNBNjBdDQpGZWJydWFyeSAxJSBvZiBhY3RpdmUgUERQIElQdjYgY3R4LCBub3cgb3ZlciA4JQ0K DQoNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQ2EgQnkNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNSwgMjAxNCA1OjEwIEFNDQpUbzog QnJpYW4gRSBDYXJwZW50ZXINCkNjOiBJUHY2IE9wcyBXRzsgVG9yZSBBbmRlcnNvbg0KU3ViamVj dDogUmU6IFt2Nm9wc10gT3BlcmF0aW9uYWwgQ29uc2Vuc3VzIG9uIGRlcGxveW1lbnQNCg0KDQpP biBBdWcgNCwgMjAxNCAxOjI2IFBNLCAiQnJpYW4gRSBDYXJwZW50ZXIiIDxicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4+IHdyb3Rl Og0KPg0KPg0KPiA+IE15IHBvaW50IGluIGJyaW5naW5nIHRoaXMgdXAgaXMgbm90IHRoYXQgaXQg aXMg4oCcdXNlZnVsIGluIGFuIElQdjYgbmV0d29ya+KAnSB0aGF0IG1pZ2h0IGFsc28gYmUgcnVu bmluZyBJUHY0IGluIHBhcmFsbGVsLiBJdCBpcyB0aGF0IGl0IHNlZW1zIHVzZWZ1bCB0byBtZSBp biBtb3ZpbmcgdG93YXJkIGFuZCBJUHY2LSpvbmx5KiBuZXR3b3JrLiBSb3NzIHN1Z2dlc3RzIHRo YXQgaGUgc2VlcyBjb25jZXB0dWFsIG1vdmVtZW50IC0gRmlyc3QgdGhleSBpZ25vcmUgeW91LCB0 aGVuIHRoZXkgbGF1Z2ggYXQgeW91LCB0aGVuIHRoZXkgZmlnaHQgeW91LCBhbmQgdGhlbiB5b3Ug d2luLiBXZSBtYXksIFJvc3Mgc3VnZ2VzdHMsIGJlIGFwcHJvYWNoaW5nIHN0YWdlIDQuIEl0IG1h eSBiZSB1c2VmdWwgZm9yIHVzIGFzIGEgd29ya2luZyBncm91cCB0byBsYXkgb3V0IHRoZSBnYW1l IHBsYW4gZm9yIHRoYXQgbW92ZW1lbnQgLSBub3QganVzdCB0byBkb2N1bWVudCBJUHY2IG9wZXJh dGlvbmFsIHByYWN0aWNlLCBidXQgdG8gaGVscCB0aGUgSUVURiBkZXRlcm1pbmUgd2hldGhlciB0 aGUgZHVhbCBzdGFjayBjb25zZW5zdXMgaGFzIGNoYW5nZWQgb3IgaXMgY2hhbmdpbmcsIGFuZCBo ZWxwIG9wZXJhdG9ycyBmaWd1cmUgb3V0IGhvdyB0byB0dXJuIElQdjQgb2ZmIHdpdGhvdXQgaW5k aXZpZHVhbGx5IHNob290aW5nIHRoZWlyIHRvZXMgb2ZmLiBUaGlzIHdvdWxkIGJlIHBhcnQgb2Yg dGhhdCBnYW1lIHBsYW4uDQo+DQo+IFdlbGwsIEkgdGhpbmsgdGhlIG9wZXJhdG9ycyB0aGF0IG1v dmVkIGVhcmx5IGludG8gZ2VudWluZSBkdWFsDQo+IHN0YWNrIG9wZXJhdGlvbiBoYXZlIG5vIHJl YXNvbiB0byByZWdyZXQgaXQuIEknbSBhIGhhcHB5IGN1c3RvbWVyDQo+IG9mIG9uZSBzdWNoLiBP biB0aGUgb3RoZXIgaGFuZCBpdCBzZWVtcyB0aGF0IG90aGVyIG9wZXJhdG9ycyBhcmUgb2YNCj4g dGhlIG9waW5pb24gKHByb2JhYmx5IHVucHJvdmFibGUpIHRoYXQgcHJvdmlkaW5nIHRoZSBpbGx1 c2lvbiBvZiBkdWFsDQo+IHN0YWNrIHNlcnZpY2UgdG8gdGhlIGN1c3RvbWVyIG92ZXIgYW4gSVB2 NiBpbmZyYXN0cnVjdHVyZSBpcyBjaGVhcGVyLg0KPiBJbiBhbnkgY2FzZSB0aGUgY3VzdG9tZXIg ZW5kcyB1cCB3aXRoIE5BVHRlZCBJUHY0IHNlcnZpY2UgaW4gbW9zdA0KPiBjYXNlcywgc28gYXQg dXNlciBsZXZlbCBpdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXIuDQo+DQo+IEkgdGhpbmsgd2Ugc2hv dWxkIHByb2JhYmx5IG5vdCBleHByZXNzIGEgcHJlZmVyZW5jZSBlaXRoZXIgd2F5LiBJdA0KPiBz ZWVtcyBsaWtlIGEgZGVjaXNpb24gZm9yIGVhY2ggb3BlcmF0b3IgdG8gbWFrZSBpbmRpdmlkdWFs bHkuIFdoYXQgd2UNCj4gcHJvYmFibHkgc2hvdWxkIGRvIGlzIHN0b3AgaW52ZW50aW5nIG1vcmUg c29sdXRpb25zLg0KPg0KDQpXaHk/DQoNCkkgd2FzIHRvbGQgdGhlIHNhbWUgdGhpbmcgYWJvdXQg NDY0eGxhdCwgd2UgZGlkIG5vdCBuZWVkIGFub3RoZXIgc29sdXRpb24uIElmIHRoZSBpZXRmIGhl bGQgdGhlIGxpbmUgYWdhaW5zdCBkb3VibGUgdHJhbnNsYXRpb24gaSBiZWxpZXZlIHRoZXJlIHdv dWxkIGJlIGV4YWN0bHkgMSBpcHY2IGNlbGx1bGFyIHByb3ZpZGVyIGluIHRoZSB3b3JsZCAodmVy aXpvbikuDQoNCldpdGggNDY0eGxhdCwgYWZhaWssIHRoZXJlIGFyZSBnbG9iYWxseSAzIGNlbGx1 bGFyIHByb3ZpZGVycyB0aGF0IG9mZmVyIGRlZmF1bHQgaXB2NiAoNDY0eGxhdCBhdCB0bW9iaWxl IHVzIGFuZCBPcmFuZ2UgUEwgYW5kIERTIGF0IFZaKS4NCg0KSXQgZG9lcyBub3QgbWF0dGVyIGlm IHRoZSBjYXQgaXMgd2hpdGUgb3IgYmxhY2ssIGl0IG1hdHRlcnMgdGhhdCBpdCBjYXRjaGVzIG1p Y2UuDQoNCkNCDQoNCj4gKEluIHBhcmVudGhlc2lzLCBJJ3ZlIG5ldmVyIHNlZW4gc3Vuc2V0dGlu ZyBJUHY0IGFzIGEgcmVhbCBwcm9ibGVtLg0KPiBPbmUgZGF5IHNvbWVib2R5IHdpbGwgbm90aWNl IHRoYXQgdGhlcmUgYXJlIG5vIG1vcmUgSVB2NCBwYWNrZXRzLiBCdXQNCj4gdGhhdCBpcyBtYW55 IHllYXJzIGluIHRoZSBmdXR1cmUuKQ0KPg0KPiAgICAgQnJpYW4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0 DQo+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K --_000_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29B Y2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0 b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uVGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0eWxlLW5hbWU6IlRla3N0IGR5bWthIFpu YWsiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGVrc3QgZHlt a2EiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpQTDt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJhbGxvb25U ZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlN0 eWx3aWFkb21vY2llLW1haWwyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5ocHMN Cgl7bXNvLXN0eWxlLW5hbWU6aHBzO30NCnNwYW4uc2hvcnR0ZXh0DQoJe21zby1zdHlsZS1uYW1l OnNob3J0X3RleHQ7fQ0Kc3Bhbi5TdHlsd2lhZG9tb2NpZS1tYWlsMjYNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uU3R5bHdpYWRvbW9jaWUtbWFpbDI3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IlBMIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkhpIE5pY2ssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHlvdeKAmXJl IHNheWluZyBjb21wbGFpbmF0IHdpdGggUkZDNjg3NywgeW91IHdpbGwgaW1wbGVtZW50IERIQ1B2 NiBQRCBhbmQgdXNlIGRlZGljYXRlZCBpcHY2IHByZWZpeCBmb3IgQ0xBVD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NY3o8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSGVhdGxleSwgTmlj ayBbbWFpbHRvOm5pY2suaGVhdGxleUBlZS5jby51a10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBBdWd1c3QgMDUsIDIwMTQgNTo1NyBQTTxicj4NCjxiPlRvOjwvYj4gQ3plcndvbmthIE1p Y2hhxYIgMSAtIEh1cnQ7IENhIEJ5OyBCcmlhbiBFIENhcnBlbnRlcjxicj4NCjxiPkNjOjwvYj4g SVB2NiBPcHMgV0c7IFRvcmUgQW5kZXJzb247IEtvc3N1dCBUb21hc3ogLSBIdXJ0PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbdjZvcHNdIE9wZXJhdGlvbmFsIENvbnNlbnN1cyBvbiBkZXBsb3lt ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBhbGws IEVFIHNpbWlsYXIsIGJ1dCBub3QgaWRlbnRpY2FsLiBXZSBhcmUgaG90IG9uIDQ2NHhsYXQgKFJG QzY4NzcpLCBpdCBpcyBwZXJmZWN0IGZvciBuZXR3b3JrcyB0aGF0IGFscmVhZHkgZXh0ZW5zaXZl bHkgdXNlIE5BVDQ0LCBhbmQgZ2V0cw0KIGN1c3RvbWVycyBvZmYgSVB2NCAoYm90aCBwdWJsaWMg YW5kIHByaXZhdGUsIGFzIG5laXRoZXIgaXMgc3VmZmljaWVudCkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TmljazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFs8YSBocmVmPSJtYWlsdG86djZvcHMt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5DemVyd29ua2EgTWljaGFsIDEgLSBIdXJ0PGJyPg0KPGI+U2VudDo8 L2I+IDA1IEF1Z3VzdCAyMDE0IDEwOjIyPGJyPg0KPGI+VG86PC9iPiBDYSBCeTsgQnJpYW4gRSBD YXJwZW50ZXI8YnI+DQo8Yj5DYzo8L2I+IElQdjYgT3BzIFdHOyBUb3JlIEFuZGVyc29uOyBLb3Nz dXQgVG9tYXN6IC0gSHVydDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBPcGVyYXRp b25hbCBDb25zZW5zdXMgb24gZGVwbG95bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4iPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iPkkgY29uZmlybSB0aGlzIGlzIGNvcnJlY3QuIEV2ZW4g d2Ugd2VudCBmdXJ0aGVyIGFuZCB3ZSBkbyBub3QgdXNlIEROUzY0LiBPdXIgYXJjaGl0ZWN0dXJl IGlzIENMQVQmIzQzO05BVDY0JiM0MztETlMuIFNvIHdpdGggZG5zIGFuZCB3aXRob3V0IGRucyBp cHY0IHRyYWZmaWMgYWx3YXlzIGdvZXMgdmlhIENMQVQuIEl04oCZcyBwZXJmZWN0IHNvbHV0aW9u DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPko8 L3NwYW4+PHNwYW4gbGFuZz0iRU4iPiBVSyBFRSB3aWxsIGRvIHRoZSBzYW1lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF TiI+U2VlIG1vcmUgYXQ6IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cDov L3d3dy5kYXRhLnByb2lkZWEub3JnLnBsL3Bsbm9nLzEyZWR5Y2phL2RheTIvdHJhY2s0LzAxX2lw djZfaW1wbGVtZW50YXRpb24ucGRmIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cDovL3d3dy5kYXRh LnByb2lkZWEub3JnLnBsL3Bsbm9nLzEyZWR5Y2phL2RheTIvdHJhY2s0LzAxX2lwdjZfaW1wbGVt ZW50YXRpb24ucGRmPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJocHMiPjxz cGFuIGxhbmc9IkVOIj5FdmVuPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ic2hvcnR0ZXh0Ij48 c3BhbiBsYW5nPSJFTiI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJocHMiPjxzcGFuIGxh bmc9IkVOIj50cmlwbGU8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJzaG9ydHRleHQiPjxzcGFu IGxhbmc9IkVOIj4NCjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImhwcyI+PHNwYW4gbGFuZz0i RU4iPnRyYW5zbGF0aW9uPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ic2hvcnR0ZXh0Ij48c3Bh biBsYW5nPSJFTiI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJocHMiPjxzcGFuIGxhbmc9 IkVOIj5pcyBub3QgYmFkIHRvbzogQ0xBVCYjNDM7TkFUNjRzdGF0ZWxlc3MmIzQzO05BVDQ0c3Rh dGVmdWxsLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NY3o8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T3JhbmdlIFBvbGFu ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48aW1nIGJvcmRlcj0iMCIgd2lk dGg9IjY5MCIgaGVpZ2h0PSIxMzQiIGlkPSJPYnJhel94MDAyMF8yIiBzcmM9ImNpZDppbWFnZTAw MS5wbmdAMDFDRkIwREEuODNCMTJFRTAiIGFsdD0iY2lkOmltYWdlMDAzLnBuZ0AwMUNGQjBBMC42 MjIyM0E2MCI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5GZWJydWFyeSAxJSBvZiBhY3RpdmUgUERQIElQdjYgY3R4LCBub3cgb3ZlciA4JTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4g bGFuZz0iUEwiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkNhIEJ5PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAw NSwgMjAxNCA1OjEwIEFNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBFIENhcnBlbnRlcjxicj4NCjxi PkNjOjwvYj4gSVB2NiBPcHMgV0c7IFRvcmUgQW5kZXJzb248YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt2Nm9wc10gT3BlcmF0aW9uYWwgQ29uc2Vuc3VzIG9uIGRlcGxveW1lbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwPjxicj4NCk9uIEF1ZyA0LCAyMDE0IDE6MjYgUE0sICZxdW90O0JyaWFuIEUgQ2FycGVudGVy JnF1b3Q7ICZsdDs8c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbSI+PHNwYW4gbGFuZz0iUEwiPmJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbTwvc3Bhbj48L2E+PC9zcGFuPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7ICZndDsgTXkgcG9pbnQgaW4gYnJpbmdpbmcgdGhpcyB1cCBpcyBub3QgdGhhdCBpdCBp cyDigJx1c2VmdWwgaW4gYW4gSVB2NiBuZXR3b3Jr4oCdIHRoYXQgbWlnaHQgYWxzbyBiZSBydW5u aW5nIElQdjQgaW4gcGFyYWxsZWwuIEl0IGlzIHRoYXQgaXQgc2VlbXMgdXNlZnVsIHRvIG1lIGlu IG1vdmluZyB0b3dhcmQgYW5kIElQdjYtKm9ubHkqIG5ldHdvcmsuIFJvc3Mgc3VnZ2VzdHMgdGhh dCBoZSBzZWVzIGNvbmNlcHR1YWwgbW92ZW1lbnQgLSBGaXJzdCB0aGV5DQogaWdub3JlIHlvdSwg dGhlbiB0aGV5IGxhdWdoIGF0IHlvdSwgdGhlbiB0aGV5IGZpZ2h0IHlvdSwgYW5kIHRoZW4geW91 IHdpbi4gV2UgbWF5LCBSb3NzIHN1Z2dlc3RzLCBiZSBhcHByb2FjaGluZyBzdGFnZSA0LiBJdCBt YXkgYmUgdXNlZnVsIGZvciB1cyBhcyBhIHdvcmtpbmcgZ3JvdXAgdG8gbGF5IG91dCB0aGUgZ2Ft ZSBwbGFuIGZvciB0aGF0IG1vdmVtZW50IC0gbm90IGp1c3QgdG8gZG9jdW1lbnQgSVB2NiBvcGVy YXRpb25hbCBwcmFjdGljZSwNCiBidXQgdG8gaGVscCB0aGUgSUVURiBkZXRlcm1pbmUgd2hldGhl ciB0aGUgZHVhbCBzdGFjayBjb25zZW5zdXMgaGFzIGNoYW5nZWQgb3IgaXMgY2hhbmdpbmcsIGFu ZCBoZWxwIG9wZXJhdG9ycyBmaWd1cmUgb3V0IGhvdyB0byB0dXJuIElQdjQgb2ZmIHdpdGhvdXQg aW5kaXZpZHVhbGx5IHNob290aW5nIHRoZWlyIHRvZXMgb2ZmLiBUaGlzIHdvdWxkIGJlIHBhcnQg b2YgdGhhdCBnYW1lIHBsYW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgV2VsbCwgSSB0aGluayB0aGUg b3BlcmF0b3JzIHRoYXQgbW92ZWQgZWFybHkgaW50byBnZW51aW5lIGR1YWw8YnI+DQomZ3Q7IHN0 YWNrIG9wZXJhdGlvbiBoYXZlIG5vIHJlYXNvbiB0byByZWdyZXQgaXQuIEknbSBhIGhhcHB5IGN1 c3RvbWVyPGJyPg0KJmd0OyBvZiBvbmUgc3VjaC4gT24gdGhlIG90aGVyIGhhbmQgaXQgc2VlbXMg dGhhdCBvdGhlciBvcGVyYXRvcnMgYXJlIG9mPGJyPg0KJmd0OyB0aGUgb3BpbmlvbiAocHJvYmFi bHkgdW5wcm92YWJsZSkgdGhhdCBwcm92aWRpbmcgdGhlIGlsbHVzaW9uIG9mIGR1YWw8YnI+DQom Z3Q7IHN0YWNrIHNlcnZpY2UgdG8gdGhlIGN1c3RvbWVyIG92ZXIgYW4gSVB2NiBpbmZyYXN0cnVj dHVyZSBpcyBjaGVhcGVyLjxicj4NCiZndDsgSW4gYW55IGNhc2UgdGhlIGN1c3RvbWVyIGVuZHMg dXAgd2l0aCBOQVR0ZWQgSVB2NCBzZXJ2aWNlIGluIG1vc3Q8YnI+DQomZ3Q7IGNhc2VzLCBzbyBh dCB1c2VyIGxldmVsIGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlci48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJIHRoaW5rIHdlIHNob3VsZCBwcm9iYWJseSBub3QgZXhwcmVzcyBhIHByZWZlcmVuY2UgZWl0 aGVyIHdheS4gSXQ8YnI+DQomZ3Q7IHNlZW1zIGxpa2UgYSBkZWNpc2lvbiBmb3IgZWFjaCBvcGVy YXRvciB0byBtYWtlIGluZGl2aWR1YWxseS4gV2hhdCB3ZTxicj4NCiZndDsgcHJvYmFibHkgc2hv dWxkIGRvIGlzIHN0b3AgaW52ZW50aW5nIG1vcmUgc29sdXRpb25zLjxicj4NCiZndDs8bzpwPjwv bzpwPjwvcD4NCjxwPldoeT8gPG86cD48L286cD48L3A+DQo8cD5JIHdhcyB0b2xkIHRoZSBzYW1l IHRoaW5nIGFib3V0IDQ2NHhsYXQsIHdlIGRpZCBub3QgbmVlZCBhbm90aGVyIHNvbHV0aW9uLiBJ ZiB0aGUgaWV0ZiBoZWxkIHRoZSBsaW5lIGFnYWluc3QgZG91YmxlIHRyYW5zbGF0aW9uIGkgYmVs aWV2ZSB0aGVyZSB3b3VsZCBiZSBleGFjdGx5IDEgaXB2NiBjZWxsdWxhciBwcm92aWRlciBpbiB0 aGUgd29ybGQgKHZlcml6b24pLjxvOnA+PC9vOnA+PC9wPg0KPHA+V2l0aCA0NjR4bGF0LCBhZmFp aywgdGhlcmUgYXJlIGdsb2JhbGx5IDMgY2VsbHVsYXIgcHJvdmlkZXJzIHRoYXQgb2ZmZXIgZGVm YXVsdCBpcHY2ICg0NjR4bGF0IGF0IHRtb2JpbGUgdXMgYW5kIE9yYW5nZSBQTCBhbmQgRFMgYXQg VlopLjxvOnA+PC9vOnA+PC9wPg0KPHA+SXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoZSBjYXQgaXMg d2hpdGUgb3IgYmxhY2ssIGl0IG1hdHRlcnMgdGhhdCBpdCBjYXRjaGVzIG1pY2UuJm5ic3A7DQo8 bzpwPjwvbzpwPjwvcD4NCjxwPkNCPG86cD48L286cD48L3A+DQo8cD4mZ3Q7IChJbiBwYXJlbnRo ZXNpcywgSSd2ZSBuZXZlciBzZWVuIHN1bnNldHRpbmcgSVB2NCBhcyBhIHJlYWwgcHJvYmxlbS48 YnI+DQomZ3Q7IE9uZSBkYXkgc29tZWJvZHkgd2lsbCBub3RpY2UgdGhhdCB0aGVyZSBhcmUgbm8g bW9yZSBJUHY0IHBhY2tldHMuIEJ1dDxicj4NCiZndDsgdGhhdCBpcyBtYW55IHllYXJzIGluIHRo ZSBmdXR1cmUuKTxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgQnJpYW48YnI+DQom Z3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8c3BhbiBsYW5nPSJF Ti1HQiI+PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj48c3BhbiBsYW5nPSJQTCI+djZv cHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48YnI+DQomZ3Q7IDxzcGFuIGxhbmc9IkVOLUdC Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj48 c3BhbiBsYW5nPSJQTCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w czwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_-- --_004_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=23586; creation-date="Tue, 05 Aug 2014 16:24:39 GMT"; modification-date="Tue, 05 Aug 2014 16:24:39 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArIAAACGCAYAAAAhDWkSAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFuiSURBVHja 7V0HfFRF912k907ovdr7p59+9o4iKL2kUKXYEBFULHQpgmIXBZSiYgdEBUFUkCJdaigJLQQIKSTZ ZFPOf85sJtn0kOwm781/5sdlJ2/nzc68M2/mzJ07dxwXLlyAESNGjBgxYsSIESN2ktdff93hMA/C iBEjRowYMWLEiCGyRowYyVFiY2MRHx8vP1VcSVxcXIHzYFp1H//2/N7zO0/Jmi4/iYmJQWJiIlRw uVzp8dTUVPmZlJQk03nj2ahye5Yza108n1HWenk+29zqkJycLK+pkF+ZLgYXb4rn77K8LDdDUcri 2d5Kok5Z21ZCQoKsE/EpShtSbUR9egbT5xgxYoisESNGfCyRkZFSOAhzUM+PjJBQ8pP3REdHZyOo UVFROH/+vPxU+fNvpr0Y0uN0OrFp0yYEBQXhmWeewe+//47nn38eXbt2xbRp0+Tn0qVLJZn1BolV 9fCMK1H1YZlIgLKSvtzyZdnWr1+P3r17o3v37liwYIG89uSTT2LUqFGSQJU0qctPWN6PPvoI3bp1 w+HDh7PVv6DPl+2G9WV74GduExum4zP11gQlL1zYhtasWZPepi+WmPM+1o114nM5cuSIxLZXr14Y N26cbDNWx9eIESOGyBoxYgtJSUnBt99+izZt2shB/Oeff5bxSy+9FO3atcMjjzyCv//+Ww7yntpD 9TdJHAdu3nfHHXfIe+68806sXbtWXudvUFM6fvx4dOjQAe3bt0/Pn3/PnTsXWYMiOZ6BhIAkgaFT p05wOByYPHkyHnjgAVSuXBkDBw7E4sWLMWLECKxcuVKWM2se/LugREgRVxK1Vq1aYfbs2TJPPi/R Ock6XHbZZbIOQ4YMkWSF3z/66KPyuyVLlsjfnD9/vvx7w4YN8l7mzfDZZ5/JOvznP/+RxJvfTZo0 CW+88YYk91kD688Jxblz52R+U6dOldcVufPU8Krf8dTyqsBr/N4zKNKfWz68FhERIX+Xz1xpv7/8 8ks89dRTOHr0aDatuPotlZ/ScKrAcrPtfPzxx7juuutkuyGp379/f44Tp4MHDyIsLCwbAWSe6jfV d5545/QcPTWvWZ/DP//8I/EkXipfzzoxT5Uvnw/zUqsCzJPx3377Dffcc4+s0913341FixbhlVde kXi3bNlSToBYd9P/GDFiiKwRI0aKKAzz5s2Tg+yqVaskOWF8+PDhePPNN+Hn54dbb71Vat0+/fRT bN68WQ7Y27Ztw4cffohjx47JOAfoLl26yLxmzpwpSbHS0nFwp4brnXfekWmY/3PPPYd3331XEodv vvkGX3zxBVasWIH33ntPErnTp0/jq6++kgSSRODkyZOS4DCfWrVqoUmTJpgzZw7q1KmDRo0aYdas WTJ/EiPmqYjvr7/+Kr9jvcLDwzNpSpU5RE7aMZJSanurV68uy3vLLbfg1KlT8nkNGDBAXpsyZQrG jBmD0qVLY9iwYfK7K664Qn53ww03yHqwTPx79erV6SSdgUSX11lHNSFgGTmpYHn4PFjvH3/8UT7T 48ePS+LEZ8b7br75ZnzyySdS68frISEhkhzz+W3cuFE+c+bJ36H89NNPsizMe926dXj//fflsyGG u3fvltdJ5HLKh8+C6RXx5uSDef/111/yeZOY/fHHHzINJzC8l8+OBHD79u0yDYko8eNvMn9qJVn3 unXrSm0l29Zbb72VjcgqbTcnFCT8DJ5aUuL5yy+/YOHChTh79qz8jvVdvny5xJv1Y915r3qOzJ+/ w/KyzfM5sty8HhwcLMt76NAh2eZVnVi+r7/+WubPdsA0nODxnl27duGDDz6QhH7Pnj1o27YtOnbs KO/hu/Dnn3/Kcl955ZVy4mOIrBEjhsgaMWLEi0RWaQepSeKAzzgHf2qbqC0jaSTZadasGR5++GF5 DzWgpUqVkoST2tayZctKMkchkeBArQiHpwZXETsSYqXtatq0qbzGgf5///ufvG/Lli247777pOaW Gte+fftKwkbzAablNZatfPnyMn799ddLjSG/o8aUgUS8Ro0aqF+/Pm677TZJPEjKPEkQy+lZVs/n QpJaqVIludTM+pFEMwwePFj+TmhoqCQxLIN6Ltdccw2qVq2K2rVrSxJFwsO06t6sRJaEVWkDWU7W gcRN1YXPhJ8jR46U6Xr06CH/Jpm/9957JVkm4eKz4qSD91G+//57mb5169Yy/VVXXSXJL583NY68 dvXVV0sSzmdDIkvypvIhGWM+3333ncyHy+K8h/WilpH5qOdw4sQJqQln/KabbpLklHmQwJEE8jeo kWSgFvvyyy+Xz5vaftaZdaNmVy3ne+JAoshrJLIkklltcokntcT8ba4KkGQyzvKwbTLONnDjjTfK OE1SiDcnT/yb9eRkqF69epLEc+LA65xQcGLFOFcRSEBZD04kSIb5bO666y5ZnmeffVam4/1sc0zH Z8x34fPPP5e/pyY5hsgaMWKIrBEjRnxIZNUAT9LKpdGGDRvKZWwSF5INEg9qPEnYevbsKe9XJIbE itrbihUrSi2oWppW2k/mQQ0V01IrqJacObiTSFBbd+bMGUkwSRKp8eRyM8lTlSpVJGEiAWjevLn8 fWrgSChI0rjkTu0a854+fbr8PZI9mjlQy0ZtGTV0ymSA+bz00ksyf5I0EnW1xM4ykRBRq8r7t27d KjWz1CIz8Dnwd/h8aHZAIeFj/Uh6SOaGDh0qSduLL76YJ5FVJgj8bZKqa6+9VhJZElhqmqn1ZP6s I0kbNX68jxMJZYLA56TIKk0tGCcOLA+v8TnQ3ILPi4HadqZhmQMCAmScz33GjBnZ8lHkd+/evfJv aqPV76p8qC3ns1HEnBMGknmST97LPNg2WBfirMwiSC45CaA5Bp8Vv+MEiu2GGBGH1157TZJ3Yk7T FWKlTDGUtp8EnO2D9qc05ahZs6bUCLNNXHLJJfK3SfaffvppWUY+Q2px1aSHtr6KCFMYJ6FVaV54 4QV5P58pMWG5+Ft8rpxwsX40d1GTH95DksvyVqhQQeJjNLJGjBgia8SIkWIgstR6MU6NEpdcSUpI LElISIZIKDp37iw1lUpbN3r0aJQrVw779u2T5IGkj0TIc4d2XkSWZgnUrvJ3lP0mNa/Mk2SZJIda V5IpBpJXkkxFHHkvA7W8zJuEjEvXjFNrqALJg9pQxDgJCokshZpVRWQZWFdqYakhnjBhQrq2lGSS S+HMmySLz47EiIRKkVESWRJjapOpzS4MkeW9JOtKk0fhdZpy8D5uClNBaQRJpkiySaJJ0FgmEife yzqrZ/vEE0/I9CS21IYqMqpImGc+r776qsxH/a7SDGclsqoMBw4ckM+WE6Dbb79dpiMerBvbBJ8j 2wkDJwksH+tFm1TeT+2+Mh9g23j55ZclkaXWnkSSG+RogqGwUp4BeJ1tgs+MmKnJEPMcNGiQzFOZ R5B8ctKkVh5o9sH4Dz/8IHHPSmSJsdJKs02QyJOUs92qd4FmIAwsP8kzzW1YPtaX5TFE1ogRQ2SN GDHiIyJLWz5lI0uNmhrU1eYu5SKJJJC2ovye5JLkhoEEmAM2tXvUepGAkkiRaGYlstTG8X4uOSsi y3u53KyIiafWk4SNS+CMKyJLrRh/nwSIBIfkgPlwKZvpSDxZ7vvvv19qc0m0uYmKZFUtXWfdCKVI rnIFpUhaixYtJIHlUrkipCR4jFNLp+rAe0iuSFxJrtXmLaZTk4SciCyXsBWR5b2K2PF3qfFVRJ9l YBn5zEmc+Lxoq8r6MA9ee+yxx6QdKDXNNGlgoGadJJLkSz3b/v37y9+m1lnVhVrNZcuWZcuHtp/E jcvmnEzwd1XeykSBmnI+Y8b79esniSPJHIk+A8mten4001ATI9rSUqvJCQW1t8yfKwKq3XhixPtY vqzu1dQGQLWSQOFzZ6AWnm2Rz4CmDcSFz5ImB8yLaWmCQXtapaH2jCuyS9MLatZpokDbV6UJ5oYu fk/zDT4/BtqGN27cWE7AqKWmxpn3MrAdswyGyBoxYoisESNGvCQkXBy0OcBSK0aNFONcYiVh8PSH yr+5IYfEiMul/JukhMSLxId2qiQ6JEDKRMCTyJJckjQzf7rQ4m/zXhKCxx9/PN3tFEkCtatcEubm MH5HTRvJAu+hHSevkQxQy0fixXxoAsC8SZBIhqgVpRaNJJD5/Pvvv9lsMLMK8+Hu+AcffDD9HtaF BIdEhNpFkmL+Dgma2tCmys3yUEvHspHgcYmZablxytNrATV4inQzHZ+NqgvvJWFS+dD+llpS9Rx5 DzGgpo8acJJdPlcucVPrxyVt5s/fYz14r3L5xGvUsrJMJHQkfaouLH/WfGjjqTxVMC1/l5pRYq/u pcmGMi0gueW9NH0gUVbutWh+QmJO4qjaDctEsstJCdsOSbPagKfwUBMLTpCU2UFWzJgfvUawXTAv Ykb8eY32qqyHakMkvMyD2laWnRMMrg5kjXOipcwM+vTpI7XLbI/UtPJ5Mw+Wl8+DJFlNZvjJZ89N cdSqk6RTM8wycdLFtmiIrBEjhsgaMWLEy+K52Skv35nKuX9Wp/9qp7lybZTbQK0OXcjvGu/P6bey ps96r2dclUP5qi2oT1DWgfco12IU1o8ES/nIzS0vz+9yO/SBJItL11x+pxZ24sSJ8lpu9coaV+SZ RFCR/6zlU5OI/J63Zzy/fDx/1/NeBqXZ5eRBeUxQbcATQ8/JjSJ+ytxD/XZ+7TO37z0PIGAZSGRZ JppSkHhm9febW7tRdaKmW5kW5HR/Xu8CP5VGmR4bSIQbNGgg7YGVf2bT7xgxYoisESNGvERis57s lRdRy+l7z5O98iIdOd2fmwssdV3lm1P6rPfmdgrXxTqgz5pvTs+oIPfl9Ez4N7WVXIamFpyaZs+6 5ldHz9Owcnr+WQ9yyFp3z+eZtS655ZPT76q/1YY/erGg+QZJX26/mVO7yem3cnqu+ZFZz3opIssy kchyoqBcsuXV5j3rxJUK3s8DK5Tv29zKntu7QKEPXq4W0PSFRD+vgx+MGDFiiKwRI0aMWFqULS7J lSJYvjyxytdC0kZ7VPqM5bK5FUgay0DNMctEQnuxZWKdaDLB+2lqUpQ6KbMaYu2NE+eMGDFiiKwR I0aMGPEiMVd2o1bSNCpPDfkdsZzXZIP3GzMAI0aMeIXIxnJpyZxPbcSIESNGjBgxYsRuRNaIESNG jBgxYsSIEdsR2YTUVGz95husmTULcTkcJ2nEiBEjRowYMWLEiOWIbLzLhXMnT+K9++/H+JYtcWjj RiR4nJduxIgRI0aMGDFixIjliCxtYuPi47Fs3DiMqVQJIy+5BHO7dMH5M2ekZtYrP0btrq7G/LQp Zt1svCM6R7x0dSZu8DJ4WUVYLx32JOiKEeujC0amrzB4WRUvbxBZktWI06exato0TH/kEcwbMAA/ jh2L0N27pabWG0DEnDuHqNBQNyiaARF96hSiT57Up7MjXhERiAoJ0ROvsDD98Dp/Xlu8YojXiRN6 kQnVFo8dQ8yZM/bGjRiJ8SP6+HE9MRL1igkP1+PdYl8RGYmoo0f16ytYN4GTVu2QdYqKcuOlG4ll 3UTfxz6QitT4ImCWblqgTllZ/O23OCQGDYY4b81sRD4sbMT69drNLGITEhApCP/5nTsRWwj3M5YU 4iXaQMRff+mJ17//4vz27XrhJSZTEX/+qd2qB/GK2rcP57du1Qcvj7pFbNyIqEOHbP2eSYz278f5 f/7RDyNRn/ObNyMqOFiPvpCTDkH2Iv74Q79Jh8CHOBEvbdoh8Tp7FhHr1uk38eA+rJCjSNy9Ay64 j8SOiytcHTNt9qITaZ75TcfWdCpN335eETqoFrMK58GDMu61fK0goj6JJ08iQcwCdapbEv076oqX IH3a4SXe3/gDB/TE6/RpJISGalk35+HDcJ07Z++6ESNBjhJCQrTEKEGMh64zZ/Som6hDMrVfYuKh FU5pdSNOxEundpjMY8Q1xet86AlsW/knZn6yCg/6v4kz52IypaFv6YIcYpMjkeXpMd4OqWKGlBwR AR1Dinh2KWnnfWsTXC698YqO1qpOqcRLECIt8aLDfc3wUiE5MhKpaUe12rr9xcUhJSrKYGSLCiVr 21cQJ+KlVwPUF68Fi9agev1ecNTqjdJNgrBi7a5M3zsFibcWkU1IQJKuA6140Mm6ESMx8Ug6e1Zf vDQbdLXGS/RN2g1OaYGTxRRBAm2PEY+H1RWj8+e1wEiFVDHOJ505oyVWxIl46RRSBZHVEa8EVzIe 7TsNNRoIItswEI76/rjyf2Owcdvh9DSFIrI8p3rRokUICQnxQakTkKzpy5MqSKx22ghq0MPD9cRL vBgGLxvhRQ26riRJTO5TNSBJqdSaa0YgMmGUtodEjwolI/n0aS2xkisDuq0kaopXn6fnomzdXqjf 3B+ORkFwNBZStgveeH9lehpXAZ0NZDvZ64MPPsDBgwfludm0TyAj5mdR4vJTkIdYMdA6BaH1Rp5W iSeIB816xdKOT8QL+3xKui6eZZBxbnQQdfLEK1saL8TzLIMP4hIvMaGKDQtLx6s4ftfn8WLCq7jj 2uJFEVixbvFiUhWfhpstMRJjRezZs4il7bmOGIm62R2jTHFBymVfoQlGmdqhmHRc4J4VndohN+WJ /s8OZU5IcCIpKVGIK+MdyiFNdEwsrrp/HGo06o3mlw5A+dYDUbntQJRr7I9R4xfjQmycSJeAkwLL cHoMuRgiS88FH374IYKDgyUTdv9ogkcBCheXn9yRxg0BorF5I0+rxBPFc4qjv11Rt0SXq9DPp6Tr 4lkGGRdtISte2dJ4IZ5nGXwQl3iJgSlOdOSJHm28OMvgk3gx4VXccW3xogisWDdndDScabjZFiNB IOLEYGswskGcfuOpeNEEo0ztMCJCTnq1aoeCBMbaBK/ERDHxk+cSCELrSsw1zdFj4ehw11jUatYP zTr0R7lWA1GpDYlsALoOeRvnI6OlMjVMYHmG7gmtYlqQakwL7BWMaYHByyp4GdMC62NkTAtsVCG9 TQu026RsI7y+/2U7Wl/3LNr+bwz+2HQw13S79p1Ak5ueR/l6veDXQpkWBMJRtw+uvO+V9HSJBXSj VmybvVJ03uwliKzZPGQjvMxmL3vhZTZ7WR8jbvbSlchqglF6X6H7Zi/NiKydNnv1GPY+HJW7wVG9 J27uPBEfzF+NTdsPZ0v3+9/7UeOKEajYoA/qtQyAo0mQWxoGoGr7oZj+1o/4e9thaRlgvBYU18tj vBbYDy9DZO2DlyGy1sfIeC2wTTBeC2yGlw2I7FfLN6O7/yxU6zAUjkZpxLRuHzjKP4b6V47A4DHz sTf4ZHr6b1duRZmWg1CxUb/MRJbSKBAOxwMY9tLnMq2liGyK06nty0NSpFsnLicemi5VS7x06+xI ZDVdLkzmxENTn8acfKRosGwtJxu6YsQDKzQyLZBEVtO+gjjppjCzOl7JySno9sS7gnx2hKOBIKVN PUhp0zRCW6Mn6rV7Am9/ukre89WyTXDU6YsqTf3RgES2cf/MZLZSVzw/6SuZ1lpE1pgW2OvlMRpZ g5dV8DIaWetjZEwL7NNXGNMCe+FlcY1s+LkYXN/xdUFM+2Qmo55C+9davdDohpH4YOFa9Bz+ARy1 +6BKs8DsGlkrE1ljWmCzl8cQWYOXVfAyRNb6GBnTAtsEY1pgM7wsTmS37Q5FlXZPwNHAP3ciq7Sz 9f3dNrS1e4u/+6NKcx8Q2WRx08IlSxBy7Jj3wXC59CayuhEjdnaGyBq8rICXzkSWJMnptD9GOmtk iZFGR9SmpqToS2QFTkm6mbikploCr4joeGz/9xi27z2eLrPn/YaGN45yE9TGQRctlQWR9VOmBZ7f VeyKkZOWyt+NoR/dAhNZ0RElhIZi3tSpOLRtG8DBI832U34WIU7ikETfbocOuUlE1jRpS/Pe+K1i jwuh/YpL1M/zmq3qkuX501SCdcoVL1+XwZdxhdepU9nxKq4yeDku8aIfY0+8bFqXHPESdUvHS5d6 iTgJeuKRI3CdPJk+ubI1RqIe2mJ04oS9MVJx9hWCFCUEB7v/1q2vEHUjVjq1QyooJF5ezFO6M4y9 gNSY3NtAapRI43Li73XbseizX9C171TUaNgbNZv2RfWm/qjRtB+qN+mLSg37oHaLANQRhLRWi8AC x2uLz4atAtCyjb+8RqmTlqZC9a54Y8oipBw9jCjx/pGfFpzIigYwf/p0HNqxA6CKPm3JXH4WIc7O QA60R4+6Z+5eyNMycZJ0duKCHHles3O9JF6iQ2AHLrVhuuHFzk43vERnZ1u80gbYPPHiRNGXeHmW oZji7AsTQ0LkJD+9XyzB8hQlzvaXCSMb1yUbRqGhWmCU/j6dOyf7ipJu/z5rh5z02qkdqj47t/4w IsKNlxd/FxdikBApSLIi/LmkOX74ODrc+BQc5R9BWb9eqNbMH9WFVBVEthrJbHNKIGq2IEENuKh4 DUFc6wvS2ry1v4x7pikviOyUKYuRcjwUUaKPLDiR5WAIt2nBUV+YFtCGz2z2ss9qBk1BjGmBffAy pgW2DNJG1pgWWBsjY1pgn3YYF2dMCwoQ9h05jRY3jcJLM77LNc3+o+Foe+eLcNQPKJTZQMmYFpjN XoV/eYzXAnvhZTZ72Qsvs9nL+hgZrwX26SuM1wJ74eWDzV7TPlwJR+lH8XDQW3C5knNMM4Np6vSW hxTkuYmrCOKTzV6GyBby5TFeC+yHlyGy9sHLEFnrY2S8FtgmGK8FNsPLy0SWhxc0uWw4HNV64JYu kxEVE49d+46jx6A56DHsPXk6F6Xpf57L3xPB/zciKw9E0NnBvjkQwV54mQMR7IOXORDB8sEciGCj vsIciPD/Fq/UVMD/mY/hKNcFDr9+aHXrCzgUGo5pH6yEo0xnt2usKmlSr2/mww28LY2DUFUQWVsd iGBMC2z28hiNrMHLKngZjaz1MTKmBfbpK4xpgb3w8qJGNibWiYcCZsnDCXgKV6W2Q7B55xH0GPq+ m7g2DvKpBtaYFlj55TGmBfbDyxBZ++BliKz1MTKmBbYJxrTAZngVkciu2bAPPfq9ifX/BONsxAVc /cCrGadwNQ7ELY9NRs3LR8DRKKBYSazPiGyyeGCLFi1CSEiI99EQRDZZ05cnlW5aNCNGEMQoWVPT glS6rDJ42Qcv0Tel6EqSxOQ+VQOSlCqIbIquGllipJFpgRjokaypaQHfpRTdTFyKgNeBI6dxU8fx cDgexJCxC3Dk2FnUvfopaVbg9hAQCEeNnh4HGgQWnzQKRJVmAfBrIX67UZbfrvA4Rk92ey3Ij8Rm I7KUDz74AAcPHhTjYiLi4+PhdDrlZ1Hi8lOQh1gBhlMQWm/kaZV4gssl60VhvLDPp6Tr4lkGGRdt ISte2dJ4IZ5nGXwQl3gJwhcbFpaOV3H8rs/jxYRXccclXmICHHvqlF54UQRWrFu8mFTFp+FmS4zE WGEwslFckHL2f7pglKkdiknHhZMn9WqHdD/lgRdS3V4GUpKT0q8lJbncRD4lScYTExMEn4vFjQ+/ itJ+fVCpZX+0v+MFjJ60GFXbD0alVgNQue1AVGrjlpKIV2g9EH4dBqDFpf1RvnXmNGXq9caIlxfg QkwkwsV4fVFENlY08A8//BDBwcFwiYaQIF5cbwkH2jhRIDY2b+Zb0pIonlOc6OgoiV5+ZiUqoi1o i9fZs7JuBi+b4CUGpzieNKcTXhSBFduiMzra1rgRl3iDkX1EECNipRVOqh2eP484niKqUzsUhJZ4 KQL73crNeHLcZzgRdg5JLnebDD5yCkPGfIpN24MFj4uXJHfHv0fR5MZnUa5JACoKcli6WRAcgtRW ECSWJLKSkIqtB5ZYvHyrgajbbgCadeiPcq0ypylTpxeeEnWMi43BWfH+Wca0INWYFtgrGNMCg5dV 8KJpgc7L1sa0wPoYGdMCe7RDDTd7SbxE3x5+Lgb/bDuC/3aeJF1nNb9pFP7cfFAmmf/1emn3WqfD MLS59QXs3Hcc6zYeQPkWA9PMCAKtJ74yLfD5Zi9dN6MYrwX2wkvXzV66buAwm72sj5HxWmCfvsJ4 LbBZpdwnsY0YtxCOio+7fbtyY1atXvhvl0l4Z/5vuLnzRDjqCcJatw8cNXvi3j4z0OfJDzNsYZtY U4zXAiu1M+O1wH54mYmHffAyRNb6GBmvBbYJWh9nraHXAqSmIOLIMdzbe4Z7Y5YnMSVxrdxVfGbx +Vq7t9vFVlPrklj7Hoig6SzQHIhgQ7zMgQj2wcsciGD5YA5EsFFfYQ5EsF04un0vmtw0yq1htTAx /f9xIIIxLbBPZ2c0svbDy5gW2C4Y0wKDUbH3Fca0wFYh7kI83p29FKUaB0i7Um2IrDEtsNjLY0wL 7IeXmXjYBy9DZK2PkTEtsE0wByLYCCshM99fger1urttYzUisb47EEHctHDJEoQcO+Z9QFwuQ2Tt 1tnpjJduRFZnuzediSxJEn1D2h0jHW0TNcMova9ITdW3r4iPR5ImGtkkwWLHTPsWpf36okELdYCB XlJZEVmaFnh+V7ErRk5yey2IoR/dAhNZMaNOCAnBvClTcGjrVvo8SLcllJ9FiHPpPYm+3Q4dcpMI L+RpmbgQ1s116lSma3aul8SLPiGJF80mdMNL1M3gZaG4IKn54nXypG/x8ixDMcVJ0BOPHIHrxAl3 v1gCZfBKXAjt6TNhZNe66IqRR5unNjYhOLjE27/P2qHAygrtEBeo3EoCXE55MmHWNHTbCSdtr1Nx 4fQZ/LJsPT7+aDn+WvMPEBsDV2QUbrh9FGr79cAV7fuhTstA1G0RgFotAlFHfNZtae94bfHZsFUA Wrbxl3HPNBWqP45pUxYh5cghRB0+LPlpwYms6Ijmz5iBQzt2ADzqjf426SOVn0WJ0wCbBwYcPSrj 2dLQT6S3fqu440LkyyPE85qt6pL1+dPMRMzYc8XL12XwZZx4ibboEuQoG17FVQZvx3PCy651yQkv Ubd0vHSpF+Oij00MDZVEXeJmd4zEhF5bjFg3O2Pk0VfQnIXkXP6tW19x7pxUUpR0O0RCPA7tOYwu PSZj2sylQKJTcKrM7ScpKhq/rPgb3QJn4tZ7x6Jy475wlO+Eum3644Eur+MRcW+1Zv6S3HVo2w81 BNGrKeLVmweKeIDt46yPnyCtzVv7yziv10xLU75aV0yeshgpJ44hSrx/BSeyfLBwmxYc9YVpAW34 dF2q1nGzF01BjI2sffAypgW2DNJGVgfTAp03e1EzGx+vT1+R5pdUy75CTDysYFoQdi4GA0fNE8T0 MVTtMAw/rN6BpJTUTGlen/0jqnIZvXpPOGr1hqNhIBxN+8NRPwCOmr3SXW1d0jRIai51NS3w86pp gfFaUPiXx3gtsBdexmuBvfAym72sj5HxWmCfvsJ4LShUOBcZix9+3Y7k5JS824uYKPTmYQSVuro3 LtXrh0uaDcDfWw+lp4m5EI//dZ0CR9Vu+W6IKtPUvQSv20Yv47XAai+P8VpgP7zMxMM+eBkia32M jNcC2wRzIELhwqLvN6LOlU9i9/4Teabbte846l/zDBx+fd2kjC6zGvhj5kc/p6f5Z+dR1LhseIE8 EZRRGllDZM2BCD7t6MyBCPbDyxyIYB+8zIEIlg/mQAQb9RXmQISLDqfCo9Al6C15YtaYyUuxY88x uJKS07+ntnbrziOY+eHPqH/dM5kJamP3CVz39ZmJrbtD8OZHv6CBTFMwclq2aSCatNLP9ZY5EMFq L48xLbAXXsa0wF54GY2s9TEypgX26SuMacHF4Z+Sgrt7ToOjWg9BuALhqNNHHv26Zv0++f3S5Vtw W6cJ7mNh6/UT0jdn4tZQELb6/dync/n1LTDhM6YFF+tHNjkZCxcu9A2RFQOtrjP21LQdi1oFlwvJ mpqCpKbt1jV42QQv7hbXbOKhQoogf6kabCRKpZcbXTESkygdMEoPYpxP1lRJQZxSvDDp3bj9MB4P nI3HBr2DuwSJLcVNWA3TNlxRkyrI7KiJX+LPTQdRqpn4rko3twkBJbfNTfyuYUDeaXKQ0k2otfTX c7NXM7dLsWzfVXwcoye7N3vlR2KzEdl40Qjmzp2LQ4cOSVLrEoOjtyRREL34kye9mqdVxCk6BSdd OmlUp0RBHuJPnNATL0H4DF42wktMgJ10cadh3eLDwpAgCKDd65EgCLmT/n51xUiQI236CjHOxx8/ riVWxIl45ZWGK89ITcGegydw5Fi44DpJ8pr6jtxn3PRvBJnqAkfNHoK09kKZ5v1RruUAlBfCz3Li 7xqXDUW9q59E6WZBGdc903gpXqlVf7RqH+iz/Ess3mIA6rTpj6btgkR8YKY0pcVzf+a1RUhwxiNC 9P8FJrKxYiCkCvfdd9/FgQMHkJCQIK+R3PKzqPFY0dHRH5g387RKPEa8ONGnThU6n7i4uBKvi2cZ GI8THUJUSEi2696O51UGX8WJV4wHXsX1u76MxwkyVBx4lUQ8RhCkGDEJ1q1ejEcLQhErJla2x0hM NGLEREpbjM6e1aevEON81NGj2mBESUhwutvhmTMSr7zSIzUJu/YeRbU2A3Hdgy/j2PFwOJ1OmQby fNNUPNBnGio0D0SVtoNQrf0gVGk3KHNcSKXWJGNBuacpcHxwnmlqCGl/5YAi5G/deMPLBqLV5aJu bQdnul62fh8Me3EeoiLPIUyM17EX40eWM5FFixYhRAyIXg/GtMBegUvVOuNlTAvsg1faIQ86Brls rYEfWWNaYKNA0wLN+opU5aK1AKYFv/65B1ff+ZL03Vq57RNYt+lg+neffb0enXpMQ8U2QzJMCWgX W4JC04L6LfxLvBxel0aBqNQsEHWa09wiy3OuUATTAuO1oJD9gvFaYD+8jNcC++BlvBZYPhivBTbq KzTzWvDBot8x7KXPkZKSKie9nl4Ljp86jxOnI9P/3vZvCG7s+HqGTatfPzz32hLp1zUh0YX7+syA w/Gwm8RaZEOU8VpgJfdbxmuBvTo747XAfngZrwW2C8ZrgcGo2PsKzbwW3N93Jupe8zTCzsaIhujK dLLXsJc/x+W3vYDZn/wqN2dJTSu9Dni6xqreA2OmLBWkNwJN/zPK7VXAQoRPd68FfuZABIt04roe iKAzXmbiYR+8DJG1PkbmQATbBF0ORJi/9C906v6Gm5z69cX9/Wbh9Kkzoh26J1Q8gasPT9gq3wWO yl3hqNY9Z9+tDQNQ/dJh+G/nSW7vBI2tRfbMgQjmQITi6eiMaYH98DKmBfbBy5gWWD4Y0wIb9RUa mBZciEvA3T2nw+F4xG0GwAMIBEld/uMGICpSpomMjsPdvabBUatX/qSK99fs5bbPtBjZM6YFxrSg eDpxY1pgL7yMaYG98DIaWetjZEwL7NNXaGBaEHryHBpc92yGGUDaxqzJ05cCcRdkmpAT53D53S/L U7XsTPiMacHFEtnUVHy+eDGOhoZ6/+WhjzZNOzo50GrmtUB2dppqWOSga/CyD148rUdTrwUk6Cka eC1IiY/XFyMx6dUBo/S+IiWl2M3G3pr/G75YvjnH75yuZCSmHfd66kw0ej/1EToHvYVHB72Dzr1m YO6Xf2VKfywsEvf3exOO+v4ZZgDc9V6nH7r3n4WECDfPOHj0DGpe+ZQ7nadNrM3ilwipr8ieDcuf V1x6LWiRRSMrD0Toiucmub0WxOTjeiszkRWJE8+exYI5c3B4zx4gIUF2ThxE5GcR45zVJgqC7M08 rRJPogPmU6e0qhe1K4khIXriRcftuuElCJG2ePEwhBMntKsXP13HjkntmO0x4gEjumJ0/LgWGKX3 FWLCkXj0aJHySS1geiQlIjkuHlff8QKuv3sMNm3ai6gzYsLtFN+5EhEZHoFHek/FHZ3Hi3Rx+OWX LYKQ9oSjymNw1OgGR6mO6NH/TcRGRMLt4xVY8uXvcNTugcqN+0mNHk+H4meVJgFocdlA3HrLkxj9 +kKRbh2q0s9rU/+MNJ7pbRKvKYheu7b9bFv+XOPikwS9dRt/GfdMU7ZqV7w+eQlSz56RPvovFMiP LBOJRuQMDsan48cjeLOYOYnGTg0Pl5flZxHj7OScBw54NU+rxNkpJBw5olW9XCdP6ouXIHwGLwvF z53LGy8xAU44fLj4ylCM8QTR57J+JVkGb8QTBSFnXexa/jwxOnhQC4xU3BUWBuf+/YXOBxdiBKd0 Co4QmWsa6ctVfB8RchzjX/8MDZr7o3aTPihTrQtGPDkHztPhtIfCT9/9geZtglC1Xg9s/Ws75sz6 CjUb9ES9Fv5o0CoA1Rv2xv0Pv4yQ3cE4/G8w3nxjCTp2GodqjXrLJWmm4WYhFW/esi9aN+uBmuL7 Go37iuv+2dJkjdfP5bpV4k1a++Pq9v0sWbYixYW0FCT2qnb9ZNwTi0o1HsebUxYiZf8eRIpxjfy0 4AciiNnOwiVLECI6Ja8vZ9Bhu66mBXTYfuGCVnXiUrXBy0Z40cm5xqYF2h04kha4bM2NlbZvf9TA aWxaoANG6Vilphapr1i3+SA695yO3z0OEsgpOBOTMWHOcjiq9YCjftrhAnX7SldZW/ccw/yvN+By Hkzg596odcX9r6LJzaPdngUapy0xi3hFHlqwORgBz30KR5nOMg9Hk/4ZaTyES9W1WqQ52Kef2BzS 2E1KNQly25FqUJesUlHgVVuZFnh+V7ErRirTgnxIrPFa4MWOzngtsBFe3JxnvBbYBy/jtcDywXgt sFFfUUSvBUGjBKF0PIiAkXPTryW6krF5xxEEh7jHjPc+W4NGV4xAuZYD3YQy0271QNS58kmUaT4g s0eB2r3hqCdIatOgbOlribxKNxuQt2ss8V215u7l6my74G0sxmuB8VpQLCHZeC2wF17Ga4G98DJe CywfjNcCG/UVRfBa8Pk3G+B3+XCpFfW7cgTeWfCbILFJWLpiizzytcmNI/HKzO/Q8pbRbndWuZ2Q RW8DDS6CnDF9o/x37lfNzS+pzb0WNDJeC8yBCD7vxM2BCPbDy0w87IOX7kSWm2LsjpE5EME2IbcD ERISk5AoJLfA414bXv+s21SABwdQe1qnD27vNhXNb37eTUzr9XMf/0ri2bT4iRGJbF3tiKw5EMGY FhRHR2dMC+yFlzEtsBdexrTA8sGYFhRPOHf+AkJPFvE5p6YAzgyb86iYeCz+dgNaCTJ6X98ZSEpO yfG2VX/tQaXWgzO7s6LZQI2eaXarJb9UbUwLjGmBMS0oZDCmBTbDy5gW2AsvY1pg+WBMC4onzP5k FR4f8q48frWwISbqAhZ9ugKr/9or/57x4S9wVO0GR+VuaHj9SOwLPpXtnuCj4egcMEseBWu1I1yN aYExLcjstSA5GQsXLkRISIjXX0AOtLrO2FPFs9NuVzW9TOiMl247rImXpqYgqfQyodnEQ4UUQf5S NTAtSKVnCV0xEpMoq2D07OtL0Oa2MYiIzKwhPn02Wn43a+4viItPxM69xzD4hfnYm0ZKaTbA63HO REya/QNKle2IFreMxq59x3FXz2nSRIDmABVaDcLKtbvS71HhuQlfwlH+Mcvvgq+S7mBfn539pZtQ y+yvpdcC+o6tmxNeFR/H6MlurwX5kdhsRDZevKxz587FoUOHpHbWJQZHb0miIHpxJ054NU+riPPs WcTTIbhGdUoU7UFnvJy64SXIXtzx43riJQi6k4dYaFi3+FOnkCAIoO0xEpNebTEKC0OCILMlWQaO x4mJLvQY9g7KNAvCou/WI96ZIE/p2nvwOC69aywc9XqjbIsBaPnfUah/9ZNw1O6FYS/Oxw+/bsV1 D76Kljc+I7+r1X4wWrcLEGn7o/41T6FSm0EoJ+4r17w/yjXyx7jp3+Cd+atwfcdXsXT5JmzbfRRX 3fcyyjUJQLmWA1BeSLk0KWq8vJfykXFRh7pt+6NpuyARH+jVcpZkvHKrAWjVIVCLumTFq47Aq1kO eJWu2RPPvLoQCc44RIi+pcBENlYMhFThvvfeezhw4AASEhLkNZJbfhY1Hnv+PKJDQ72ap1XiMaKj ixEDUmHziYuLK/G6eJaB8TjRcUeHhGS77u14XmXwVTwrXsX1u76MxwkyVBx4lUQ8RhCkmJMntauX 7HPF5CNWEHW71+VCeDhixMRXW4zE5NfXv5WclEjdtvzk3+p6nDRrSEFyShL+0+lVlG1MzekA/LR6 m7z+weerUbnNAFRoGSSvl20uSE+LIEFQSQ6C5N+lmwXKzzLis2rr/mh/5QBUaTtQXAtCZfFZpd0g 8fcgVBWf5Vv2z0ifdk+l1gMypfFWvKqX82x06UC0vJx1G+zVcvo2PjjPNDWEtL9igE3qcnHxhgKv VjngVbZ+Hwx/cR6iIs8hTIzXsQU62cvDtGDRokU+MS0Q00mkaLxUnaqhaYG2eHGpWje8kpKQoqtp AZetNXW2L5etnU49MDKmBUUKP6/bLc0DzpzL3jfNmvsrHuw6FeVaDnJvtqrbFyPGLUS804WAZ+fC UbuP2z1V48DMws1YDdXfbp+sZbhU3cI/e1qVplFghvBeutBqlHG/ZUWUsXLTQNRunnYggpXLehFS Ok+8bCwCr0oCrzo54VWhCKYFxmtB4YLxWmAzvIzXAnvhZbwWWD4YrwUFC//sOop/D5zI8bt+T38s N1zVv/YZTH5nOTZuOyzlq+WbUeOyYWJwfyzjcAHxWa7VIOkOS5LbxoEF3mBTTuNd8MZrgfFaYLwW FHagNV4L7IWX8VpgL7yM1wLLB+O1IO/w74GTGDF2gdRu1rxsBPYdyvAMsOrPPZg04zv4XfO02/8q /bNmlZwOFuC13L7LhxjpugveeC0wXgvMgQiF7cTNgQj2w8tMPOyDl85Els72zYEIxR64I9+Z4Cow Rkhw5ppPfiHmghMPB8yGo1wX96EBDQJwxR1jMe+rP3HgcBha/Hc0HJd0cn+nDhFo7LG8fxHa1oIR WX0d7JsDEcyBCMa0oLCDkTEtsBdexrTAXngZ0wLLBzuZFpw+F41rHnwNbf73gjwIIPxc3koITuid kVHYvPMoNm49lL7kP3/pX7j8npcxfvYP7mtbgrP5YHW5kvFA35nSg0Am/6u1eqF08wGodcWIDHOB YhJjWmBMC4xpQWE7Oo1NC1KMaYG98DKmBfbCy5gWWB8jm5gW/LHpALoPnONekq/dG46avXBz54mY 8eHPmPHBSrz50S84cixrv+fCvAW/ujWmvCenpX9Khcfw386TMt255+BJ97GugrhmG8gbBLhNCRoH FjsxMqYFxrRAX9OC1FR8vngxjoaGen+gpS88TW2o5ECr2S54eR63plowOegavOyDlyB6upnuqECC nqKB1wKaR5T05DBZjF9OV3KO312IT8SQsZ+hVruhcFTtnqEd5Sd3/IuBk07Yudmq3X9HY8wb3+Dk mWi89/ladH5sPBpcPjRj976nNPYwA6jWE9c9PB6xzgyThWW/7czwNKCcvTcJKtF4afHp1lpaozze jNPBfu0WHho+Dep1icZ4VUo/wCILXhW74rlJbq8FMfm43spMZEXixLNnseDtt3H433+BhATZOXEQ kZ9FjFPzkBgS4tU8rRJ3hYXBdeqUVvWidkVrvE6e1A+vo0ftWX5+5oUXHe2fOFF8ZSjGeOKxY1KT XpJl8EacdXAdP14sv5XqEaftKv8+dvg4Aoe/g449JuPv9buxa3swdu9wC+Oz5nyP0n69UaZuL6kF ouaOp0DlFC9VpyfKNeyLltc9Kf4OQl2/rqjXtE+u6VW8ssj/mjtfwJmT4UiIipG/O/a1z1Glfm+R JiDf361cTHESvfZt+xX77xZHnLakrdv4a1WvWhrj1UDg1SYHvMpW7Yrxk5cg9Ww4osRYfaFAfmSZ SHQKzkOH8OmECQjevBngcrkgn8mC3MrPIsY5ECUcOJBzGjEIe/O3ijtOApF45Ihty5/T808SjSdX vHxdBh/HSdBzxKsYy+DteDa8bFyXbHiFhiLx8GHt6sV4QnAwXKJ+dq+LSxDyRDF++Pq3EB0JuOKB C9FuSU3Elj+24fLrh6N87W6o3qg3ajTqhaoNe6OaR5zX/Vr6y2VnLmVyAGW8nkfc83rd5v6o2bg3 ajX1xxXt+qFtW3Fvi8xpssbrivRX3PgkTh44gkM79qOOyKN6g165ps8ar1tM8aat/XF1+37F/ru5 xet7K08hrdq48WK8oPfWz1KG4ow3KECaJh54lVQ5fRIX0lLgdaXAq37LzFhUqvE4Zk5ZiJT9exF5 8KDkpwU/EAHAwiVLECI6Ja8vffIseF1NC+hgXzw/nQKXqrXFi9oc3fBKTtZ2Q5TES7cDLNICl+O5 sdL27Y9a0mIw/9i5/yQGvjAfew+fxi9/7sUjA95Gh7tehsPPP82pelD25X8pQYU8D76/1IhVbBaY f9q6fdHghpHYJcr4z7/HUIYmBX7+ljvfnkvVfi0DLFcubwiXqmuppWpN6lRKY7wqepqCNM5sWjBS mRbkQ2KN1wIvDkbGa4GN8DJeC+yFl/FaYPnga68Fp85EYcPmg+j2xLtwVOuBmpcNR6W2Q0S8u3sD ls92VveXWiLuhs/kdSAn8euHmpePwPp/grFs9Q7pleBifbwarwXGa4HxWmC8FpRMJ268FtgLL+O1 wF54Ga8F1sfIR14LklNSMP+rv3D9fa/AUaMnHPXTdvlzt3/94hncufzPATfftKI8FVoPxs9rd+GT JX+4y2lBImu8FhivBXp7LTAHIhSuEzcHItgPLzPxsA9e5kAE62N0kQcipKSkIjk5Jcfv6Hs1Ni5B ytc/bXG7vareI+0c9uIfbOsWlMgK0lpKlPGrZZsxcc4yN+kuZh+xBSOyQdI2U1ciq+OBCLriZQ5E sNJgZEwL7IWXMS2wF17GtMDyoaCmBfsPhWHDpgPoOugdBDw7N8c0PGCgfsuBqH/dM27zgZLUal6M aQFJa+1e+OLHTXhu4hdw1Opd7D5ijWmBMS0wpgW+1sjqvFSto0bWmBbYCy9jWmC7oItpgUAJSMi5 HiR2095ehnEzvkP9a59xa1dr9ZLL8KMmfolp7/+EaXOW4dgpNxEe9MJ8OMp0lpunist8IK/BNl0j 2zj/tI66ffDogLflyWHykASLEqOGGhOjumpjlEamBbrila6RzYpXxSIQ2UQxGC5YsABHjhxBamoq UlJSvCbJTidc1D54MU9LiHhOSYIUuejY3MvPrCQlWUw8tMaLS7q64UV/pDriJSaJLhI+jfBSwnol 0+uJj39HdOgZlNMb+SkinpyM73/Zhs5dJ+DlV+Yh/Gw03vvsN3TqOxOd+r+F+/rMQOnm/eWpV3Jj Fs0Emgbhkmb93drK6uJa5a5wlO6EH1dtl3kHPfcJSgmyyzQlLk37o16rQFRrESTj+abnBq86vaVZ wSXNLVD+HKR88yA0bB1oybIVFavqLYPgJ+pWqqk+9SrXTF+8qgm86ueAV6kq3fDchC9k/xIlxusC E9lY0Znyhjlz5mD//v1wCuKprqvEhY7zUxC9qFOnpD8wr+RpkXiceE5RJ04g6vhxGdeiXuIzVrQF 6YhYR7xEvaKOHTN4GbxKNi6wig4LwwVBZpWfxPzu5WecR9qc4okJOZ0UloSNWw8g9PhpxEsNsJvY uhKdSHDmZaOblGOekZHRWPTtH3g0aCYqthuEGk17o+Vl/dH05pGo0WGwIHKCzDXoA0ejvqjcZgCq iWu8Xl1ItfaZ49XbD0KlFoH4ZsVGme/AUR+jdMO+uaYvzngV8dn08oHwu3QQqvrot6oVY734WzU7 DEKLKwdm+t2Silf3Yp6V2hGrQWgr6sZ4SdbLm/Ea4v1oaRG8vBmvLDBqIvBqlwNePJBk6JhPcD4i HKcEb4wt0IEIxrSgaItqxmuBvfAypgX2wktj0wJEi3bo8q4f2cjoOLwzfzXeeHsZ3njvJykvvvEN anUYipHjv5BpFn+/EW/MWY4TYecRF58g0v+WKb0U8fdfW4LdxbwQnykNta1cRnfU6SOX/6sJIlq7 uT8c9fpdvE0rNbMin/c/W4tEVzIe9H8Tjpo9LbP8Wa+gpgU2srlspLFpQT0NTQt0xSvda0Fj47XA GsTIeC2wF15m4mEfvEhkSwAvrsZfiHXiQlyC+EyQ8fxCoosazHjEO1355J0q8407HY7Y81Hu/ONy l29/3oqHAmbhoX5vuj/zkOs7vi6IYC/3cr4YEKRU6SZtNmtcNhx3dJ/qHiwqPI7L73kZNz06Udqs ZkpPKf8Y6l39tMzzxkfGZ07D/NVGprRNNnUKSyCYjyDFU99dIUn47d2m+tY3rK9sZG1EZLXcBa+x jayueOVqI2u8FhR/MF4LbIaXrl4LdMWrBLwW7NhzDH2Gvw+/y4bB75qn3XLFCAwZMx/rtwTnKMt/ 24lbH58MvzaDJUFc9N3fmdNs3I+9wadk/rQlbXLzaFx945Noe+PTGb+Ri5RvNchtY1oQ8SSZWYWb p+iPVWlNSRip/cwpfdMg94al/PIUg1CNFgFpA1L/Qg1oJLJjp34tNcSSiFPTa4nB9iK8FthEjNcC 47XAeC0oZND5QIRkY1pgP2JkTAvsg1cRTQvWrN+HqTO/w9T3fspZ3l2BqW8vw4nTGb9x7YOvurWP JHKewp30XFLPTTKlzfJd2c64t/cMmf+p8CiUajYAVer1QNkGfbL/TlZpYO2BrFpR/HemHe867KXP ceDIaXS46yX387JI3Qp8IIKtTAvMgQj2Mi0wByIY0wIfB2NaYEO8zMSjWEJiIpfanWlL8xmyaccR 9Bj2Hh7qM8O9JN5rOgJHzkXw0dPyeM+HukzC1yu2uPHKh8hOfOtHREa7NywNHD0PY6YszfT9kLEL 4HDcl3nZ3FMqPg7HJZ2wbtOB9Htu6jQBjuo9cyZd0jF/LpJ1ydxTqnZDR1FXhrAzUajQ9gnUbtJX duZ2H5DSTQsKm4cg632e+hDb/w1Fs5tHuU/uskjd6mpHZM2BCPYisuZABGNaUAzBmBbYK8jNebpt HkpOgutUWIGSHjl2Fuv/3u9e7t50EFt2HpUnLeUXIiJjsX7jgYyl8s0HEXPBmZbnmYw804SE9BZB SDMtz6dJ1Q5D3UvaVdOWw/lZu7c8q57+RR2OBzDx7WXuquVjWkAtZ9hZ90SSeV/X8fVM39ONiySs uWoEA6VGcMPWQ+n33Ey70Rpe3nAk6vlw4GyZvySybZ5AvaZ97W9/WVTTgjQi21E8G7abOlc9WfL+ Y41pgTEtMKYFNjUtSE7G5wsXIiQ0xCcDLSL1sktMJ0biQSPugmaVSkaKpqcpISlBtMcEWxZ93tK/ MHX2j3JJfIpaFn9nBU6dPAu44rB6w/5My+jpaeYsTyd7XMKlBlIu31bpjlpXPAlnPpuTGJau+AeO cl3c99G2UpDPjxb9joTEJNzbZwYc5btkLKPXyWGp3VN4fGfjHAglNXEkMaIjm/7hz+6mmI9GtvOA OQg/537/Wv9vDO7oMS0zkZ34ZcGI7LbD6ffc5DMi+5abyAosyrdxa2Qra0BkMzZ7FZ7I0r74t/X7 xESGp3lZh8hSw1dFIyJLDV9D7Td76UNkS2uMV8Zmr+xEdpQisvmQ2GxE1hUXh88//RQH9u3H6dPn ERYWgdNCwtLEM57oFEQgNQUR56KREOeUxAeCCPPvU6eypw8/dhpnDh7JM08V5/0R56JkfkoS4xPE 9XP53lvQPD3LGSa/i6ancPdvOd2/5Xk9NSkJqeI7KR5xmT7iPE4Fh6b9RrR8Li6RR2HKaZm4wCvy SGi2Z+KN/Pmczp3NwOJ8RM5t5qLiaXkqTIgRcTgfESO+O5ee/oQgfONeW4A77nwed4iBM0MmFTp+ +/3j8PLUpfL3+Bv39JiK2ztPKFKeMt5lEm7vNB579x1Lx6HJdU/D4bhTyENp8qCQ+7Fu3U4gPga9 h38g/r7V43uV5j78sWEv6D900HOfuK/V6CHJZ61Lh8LJHfnquaWkSEziY+PdbT/tmX6zfDMcpR4W 93V3O7Kv+Bju6T4FP6zcgrJ0cF/lcXeeUrq7P2sq6emWWj1RSpAUDqZc4iyTJlnjl1Tuitkf/Sz7 FWmDLiZV6e+f5zsoPnsMfgfh4ZEy7WV3jJXPj3HVBka+tgilq3TN9bfKNAlEaUGk1m/an/6cb+sy EaVFefMr58XES4tn8rD/TFkmvkuV2w5B/aZ9UbNFoChDkFd/qzjjlJotAqStW5nC5lO/Ly6/cyzm f7EOZRsHoKzAxAp1LN3Evaxrd4w845WaBaJpa38t6pK1HdZo4dbIltGoXhU1xqt6C7dGtkwO/f+L k74EEpyIpp/tAhHZNOfc8Xv3YtGE8Vi1dBmeeuodDBs2G0+PeAsjRrwthXFeGzp0Ng5u2S01QLOn L8GuP7cJ2hyJ1IhzmPXGIgwcNDM9PT+HDn8bLz/7NmaNfUfGs+aZNT5I3D9zykKknjuLZNr9RUZg 3+bdCAyalu+9+eZJLeP5CMx+YzEGDnSXc8igGZgl6oHYaPlb+7f8iyDxW57XeY49TSOkeMSZPmzX PowcOlPkl5ZePJcj2/ZgmHhOOT1Dy8WHZ74+TPzN+vzwvmhIF9zP5ODWPeKZTPfK7xKLNyZ+JvGl lv6dmV9iwIAZRcpzMPOcsEC2lxQhxAjxF/D+219j8MDp6emHD38L/ftNQo/OL+O+B1/EvUL4+cBD Ywsdv+OO5zDymXfFSxeLwwL3ex96EffcP6ZIeTJ+zwNjcec9o7Hlt81uHES7nfzaPDzy6Dh07zkR vXpNQLceE/BYt/HY+usG4FQoZk77Ap3Tvs+U5vHXsO33f2gzgplTF6en6fzYaxj59By4wsMznltc DN6bvRSbVm0SvxuV3s73infwkU7j0KvnhPT8+/aZhAGi3fM3evWamOl3c4p36z4eDdoOQNlqnVGh ZheUrfEYyglR8bJpcYfjHnz6/neyX3EdP47EkBD3O8cypr2DxJrmL0MHz0R48FEgOhL//d8zuPam p+R9si7OC7JtOUrdlyl/z3jp6uL3KjyMn79Zm97eO3Z8EY5LHsgxfWHjpco8gNsFnmyXh8X7VK5O NzSv+yjq1xPfVc/8HKwWr1qvGxq37CcHnYYt/dG4lb+I+8s4j89sIQbadm36ybi63riAcRKPhs37 od2VQ/Do4+Ph18J9vaG4zk0uTVr7Lt4wnzTU7l3Xvh8ua9dPao58Ux5/GW/gcd1Xcda3ZRt/3Hhp 3/S6N8hWhuKMe68MrA/bYfu2/WS8oPc2LrG65x9XdfqPwEs+q1bWLGdh8Wou/u7ggZfCokrNx/H2 1M+RvHM7IvfsST8w5uJsZEN8YFqQmIiUCF03D0UjNUavzV5IciFZ081eSIh3i1Z4JdnGBn3ut5sx ZsIXGDP169zllUX4Y9NB9/uVj2nB599skL5WGWiO8NHidZm+X7Fmp8wv19+aslSU50uEnswwpXnv szUY8/qSvMt4sfLaYixYul7mHxPrxCszv8Ooke9j9Cufefd3fCAPDXwPjnr+bntmmlxkkVJ1e6BC PWrie+X4fb5S4TH0HPU59h0/jya3j0szU+nrNjOhGUpBJTfvDjQfYV6NAgtlWnBRdswsQ0PrLgWX 1dy0oJ5mpgU6m4JkHIhgE/dbJLLJmtpc0kZW2snqFFz6EtlU0dZTdPMyIfAyByLYMSTZopSxiSn4 +Y+9+Om3nfhp7a7MsmYXfl+7HevXbpXxbN/nJ7xn9Q4cD3e/kzv2n8QPK7fill6zUbXVIFRtP7TA UrrFILfP2+o9Mkgy44IUV2gzRJDMgMzf5SfVe6Jc3e4o1yDNHRh965Iw8zvaiXt6quD1Wr1QttVg ka5/zmksQmTNgQj2IrI6H4hQ1xyIYI1gvBbYDC9zIIK98CqBAxGKK3DykRIbqwNKQGKcV3OMdboQ fiYa4ecKLt+t3Ys7er+JWx+dgFsfm+yWR15Hz2fn4Z99YRj5xg/i7/EZ3+UrU9CzzxS0vOFZOCq6 Tzsr3eoJ+V2r216Eo1oPt79hIaWbDcSdfWbh142H8P5XG3Fr50locesYdxq6eMvN/VteQiJMLTLJ N//mRkmlYS6k5LgLPr/7bLTp0M94Lfh/7rXAHIhQuC7cHIhgL7zMgQj2wquIByJYOSQJgp4SF2f7 epCM6zY5TA/xF/Dr77sxdvJSjB3/BT5fvl1ePnQyCi+/+SPGTvwSYydkXPcMB45HutNM+lKeXHax ctUjkwV5DcCjT3wg/65/8xj3ccOFMd9QUrc36jXzMNuo0zvv9NykSQ8kBTHzUKYdNK3g3zmZWJAY M12jAJ8Qo3oaHlGr5YEImUwLbKKRNQci2CuYAxFsiJfOpgWaElmSv5R4+9trSyKrKUYpsl4lYwIS Gh6DlX/sgzPJ7ed5Z/BprFy9AyvX7iq0BI1ZiObtBqBqm8Go2m4o/McszjP9st924ra+b7vNPDoM zVPKKNMOkkr6im7SP4upRj5mHkrjXEgxByLYS8yBCFYajIxpgb3wMqYF9sLLmBZYPsjJhq4YiQm9 HuYf7uBKdCF0536En42Wkpz/WSiIdSYVyMzjh9/34n+93sT0+evk37MXrsetXSYLmZRu5tHt6U+x Zd8pPD9zWTYzj1rXPJtx2l5BzS/8+rr9DlNTXb0rytXOap7RK81E4mJNMjJrDzPFi9HcwpgWFILI Lly40HcaWV01RrpqZHXGy5gW2AcvnTWyOpkWGIzsgpZ0VWfFsHZrCMZO+VrI0gKZXowWaf1uHA1H iyEY+NIijB2/EM+P/ihTmuu7vJHhTYPa4oIK7ZOVyQTjPORFxfl9PWWeUUBRHjMaBWaYaTTM3wyC pgUNNSWyVXIzBalYBCKbKAbD+fPn48iRI0hNTUVKSorXJNnpRCK1D17M0xIinlOSIEUu0YmnePmZ laRojxeXdHXCS0wUEwWR1RIvMUl0kUxohJcS1itJkEDbYyQGG4ORTfoKl8unfYUgD+KfO87PVPl3 atr11HRuob7zvF6YsHXvCfy28WDGhdTETN8fOxOD5at3YMXq7Vjx2w4sF7IiTfKKv/7uz6h+5VOo etkITHj/Vwx+ZQmqXvE0xr21Qqa5ve9bqNJyEKq0fyJPqZr2Ke2CeUiM+ORhKNWk6UWQ9HShDotx NPJHqSaBbrJcq2e6VPHrnvG3Z5qG/rikWX8ppdM+bRNv2h/VWwahfutAGfdMU6pqN3m0eHJyEqLE eF1gIhsrXlTeMGfOHOzfvx9OQWTUdZW40HF+iryjT52Sjm29kqdF4nGCQESdOIGo48dlXIt6ic9Y 4nXypJ54iXpFHTtm8DJ4lWxcYBUdFoYLYlKlHH7bEiMxVrBvjwoN1ROj06dxgacL2RijTH2FmBjK voJxDTBCColrMpzsK8T7FBUSkqkdpvBIcmqhkZomBYtTsRdyPBxHQsOQ6EqU+B85dhoJiQkyzZlz kTgacgohx8JEmlM4KtLlFA89LuInwjF25ne4q/skPD/9O+wNPo7w8HN487O16NR/Fjr2m46H/Geg 5pXD4WgWhNu6TsYjgTPQMWAGHhWfA4e+iYdFXKUp1TwIt4o0ftc/LQgt7Y6pIU6TvOL1e6NS6/6C XA9GjQ6DBZkWklO8/SBUbTco7zRFjFduNxhNLh+EdlcORMV2mdOUa9gXQ8d8gvMR4Tgl+hZPzEt+ s5euS9XGa4G98DKmBfbCy5gWWB8jjb0W6GZakGqjw1Muuh0KnOxsq/3Zj1sx+cNViHFm2VwYE5Up zdSPVyMqPglfr/4XL076Ci++8U2B5Ilxi1Cu/Qj3Jju/NLMJPw9Rf9fq7db4el7zgZeJgngt4ATC KdpsXHy88Vrg05fHeC2wH15m4mEfvDQ+EMF4LbAJRroRWV37ChJZ3SZUKclIPuc9vDbsCMGAFxej WodhqNbuCfenkrZDUPPqZzBJkOmnJn+bKU2BDxPJ6xAQaV6RkSbHAxGYxvEQnnxlkSzvsX//xeYv vpC2sgkpKYjN4bhaSWTjCH5ysrzpyy+/RLivdj9rtPMzU3C55Mll2gXRQLQMoiPXEi/dTpdTgX2T 06ln3XQhSLSN1BUjTjQKab9p2aBrX0GcNJgYFgde8QmpQlLSPtPEmQKnK3uaWGcqXn1/LR7sPQsP +s/BgwG5yzUPT4Gj4UA46ghCWjcgQ2r3Q5UrnpVpru00VaYpW78fajXhxjdqaAeIdP6ofPmzuFd8 /9m3m2UZjm7ciJfr18eiAQNwcP16RIuJSlZTA0lkaYOwfPly/PDDDxgzZgzmzZuHFStWyGteEeYl 8l729dfuuLfytYL89BOWf/utWxjXoU7E6Mcf9cSL9fnuO4OXwcsafcc332D599/bGzeWnXVgXQxG 1sdq2TIsW7pUz75Ct3boiZcX8/155U9YveqXHGWVkJU/rciWZs1vv2LtmlX5yrufLMEN9w/H1bcG 4Orb+2fIfwPQbch4meaD+V/ihgdG4Kr/9ME1N/dFvct7COJ7H5pc3h09npiAX1b9il9/+Rk/Chw/ nzkTL9WqhVEVKmDWLbcgZMcOQbZd2YnsmTNnsFGw3k2bNmHy5Mn4WgyIjP/111/ekQ0b8IcAZM0n n+Av8Ttey9cKIurz+xdf4PfFi/GXN59ZSQrxWrkSa+bOxV9//60fXl99hd8XLdIHLzFL/ePnn7Hm 44/1xEv0R2sXLtQHLyWiPmvnzcM6MfjaGjeB0TpBHtZ+9pmeGC1YgHViMqXF2MW+YtUqrPnoIxnX ra8gTsRLp779z9WrsebDDy1RnvXr85ctm/7G/j3bcWDfThzY6yHi7907/5FpNjPN/t3Y++dv2LPs G2zcthUrf1mDf7ZuwZ5dW7EhrW1u3LYNywVvfNnPD4sHDsS+tWsRefZsNvMCSWSppqV9LANtZA8e dLuy4DVvCI0W6O4jbvNmGfdWvpl+IznZJ/kWpG7OAwcQv3evT+rGeikptnoRL9FY4kRn4Eu88quX L+os8RLtO37PHq/WLWtdihWv1FQkRkQgTnTk3sbLE6eSeMckXocPI273bi37jritW5Fw/HiJ9B1u i4AU72B05Ajidu706TtVElhJjHbsQEJoqE8xKs6+whUdjdgNG5DkBezzwqa460Z8iBPx0qavoPu3 mBjECmKXxN/20e/nhpXLlWFnwLjX8RJ9X6zoAzMslJKz9VGnxXi9QUxOYkS7pUFgbA6bvjJt9kpI SMBvv/0mN3sp91teE1GIGLqZ8WaeQmgAzLKyQ+ZnQZznel3o5ywy0uv5sj4Ek25AKPm5oLADXtJd j5hN8aVQL0ZubY0vlk/q7GW8pBG6eHfYBlle/s26xYsXrrjaI3/H23ipd4s4sP0RqwQPtzbF+X7F EC8ftAW2RdarRPoNPmPWS7xr3s43Ns3vqeo7ckrDw2/CwsLkM7AaRp79unqn+Dd9jRZrP8iy8L3y AUYU9hM+6+dyEx/0FSw/sVF9HtsU/y72MdmH45ZS+BV7P+EDvHJ619gWs2LFvuOnn37C33//nWs/ UmS88hmLYy/WawElmhn7quH54GXlw90qGH3v3r2lOQT/5svEzoH1UPHYLBvNvEoyWC8v142EYffu 3Rg5ciQef/xxzJgxAzQBYbnVLEnVy+1c2r0ZwasTEB8RB36+88476Nq1q6wfD+BgfVVd3Db7qXjl lVfkNYWlV+vlxbqxfN9//z1GjBghfTHz7zfeeAN//PFH+ixX4aU2VqqBi/X1CpHwAV4s56+//ooH H3wQjz32GIYOHSrfMVeafZJqh6yDwtYu75fqO/bs2YNx48bJuniWn+8R26R6r/jpNZyKoe84duwY OnXqhC5duiAgIABn0w438azLHXfcgdDQUHmtyBMUH7xTP//8M5588klERETIMq9fvx79+vXDiRMn 0kmtWjlUxElhZ+X+Qr0rfOZvv/02nn32WdlvqL5d1YNxRRC9Xi8v1oflYjsaMGCAHLNYXu67CQoK kooxYqn6CkV2VR/I+jAenwdJsUJfwTpSwffiiy9K7FS/rcrPvsTzQAf1nZXHYs93bdWqVZg5c2b6 oRaKuDOw3589e7aMW7X/y0ZkY7M4Sba6MEycOBE33XSTJD4MfIlIbvlyML5t2zbZEFevXi0Nnf/8 80+pifDay+OjerEBDR48WA62n332GQ4cOCBfFv69aNEibNmyRdaL9s2s27fffptOdq1aL74krAs7 PZb7tddew3PPPZeu1aRdDDVF3HDYvn17vPfee/j333+9v0LgZazeffddNGzYUG6YZODEirbmDOzc WSe2Qw5YrLfqHDdv3izbqE9IkhfqxQ6MA9Lhw4dlvE+fPggODpbf8eAUtkPWhx05J8ErV66U+JJI WRkzCgkQNQ0PPPCAfK/OnTsn6/PFF19ITFgHtkdiygGZbdQOfSNJwz///IN77rkH58+fl30d3y2a jLF+SrtCovvVV1/hu+++s1x/yMB3pnTp0rK87DcmTJiAChUqSNLEwZeaIqbh+8W2x36d/fuhQ4cs 3/aIBwk5J4h33nknfv/9d9kG2dcxTlz27dsn25yqF987K9aLbYnKCGLDPoL14HjkcDikFyQGjlU0 W+TknpMq9nvEjPeyX+S7ZsU+MOukl+8UseP7pcZalp9j84YNG7Bs2TL88ssvsm5Wrk/Wd419dmBg oOwTiQ3Lzgkk+/hRo0bhgw8+8A2R9ZJkI7J2EjYuvtwvv/yybET8PH78ONatWye1mAx8oTiLZ6dH 7cTo0aPRrl07rF27Vr5wVh5k2QkMGTIETz/9NH788UfZme/cuRPDhw+X2r/+/fvLAfb222/HE088 ge7duxNQOdha9SViIDn/5ptvZJyu3h599FH50rCz7tatm6wfpWXLlhg0aJDE0JVll6LV6qQ0K5zV slMbNmyY1ChxUGX78/f3l58ken379pUdIdtu586dZfoSWbIvYL1eeumldE0D2xw76pCQEKktYztk B8j36eOPP5b4PfXUU3IQtjJm6h1jp00ywb6AbZAaF06ypkyZgvfffx/XXnstxo4di4ceeki2WaWt sDqR5aB75ZVXSuy4OrBjxw7ZPhVefKceeeQRiWevXr2kt5rIyEjL9Btqvwa1xpzMsn2xf+fffKcY eJ19Iyf87N+vuuoqWb9du3ZZvu1x7Fq6dCk++ugj2bez32Bgfe666y5Zp4EDB2LNmjWyXuwPiaEV 68W6cJJ06623SmUSifesWbNw3333yYkTA/uM559/Xq4OcPLB8Yoadt7PflGtploZL/ZpHKvYB3Ts 2FHiwcD3h5vk2VfwfWNfwTraoa9Q79qSJUtkf87J/P333y/7Rr5nVMiQM7GdGiLrQwDmz5+PK664 QhJXdtx8cTg4kdQxUGXOl4bEgsu/DFwq5XUrE1mSUQ4snBGxo+OLw86CL0jTpk1lfdipc4meAzFn xNS+3H333Th58qRlNRIMHGyocWVQZI4zW3bcxFMFaoxUiPaRjZo3NZfUGLE+06ZNk2YT7Kg//fRT 2UEwcJIxadIkSYjYOVAbTZJR7PbPF0lkX3311fTlMpJwamCpxWvcuLFshxx433rrLfTo0UNqx9Sy qJUxy4nIckWDpJV1vOGGGySOrB8Dj+6mGYyVO3NPIkscbr75ZkkG2X+w3yBeJEjUKpFoEC8OxnwO vMb+xSoTKoa5c+dKgk2S8PDDD8u+gRNC9nVccWO7JMFr3ry5fP84iVL7CkrK5rkgoswKWF6+O5xQ sL2xD2Abe/PNN2X9OYlnf8F0nuZyViR51CQTm08++URixXfnhRdekOMxxzH+zYkUyR5Neah4Yn/I tsnvlBmgXYgsMePYzMBVKvb9XLlS2k1yDjv0FVmJLCfz5EdqbCamhsj6UNgRUPvK2RxJETs3NiCS Ic7eSY6oIaJ2pWfPnrJTZONix3799denL+VYtX58WVhWEgl+cvmTnQWXOjnwUnNEu1nOZDkITZ06 FePHj5faTnYcVu0UOMhQU0lMuFzBznr69OnpZIF4cdClVoUdOL+zg2kBn78iOiSqFStWlJoJdtic 1dL0gASJkymaF9xyyy1S07KX3i7EAGXVerH9cYZOMwlqWjkJ4aBDks7JI4kf2yGXDhnnMtTixYvl u2n15V0+dy4L8n1i4OSD2hUOsCQW1K6wPmqiQhJoh8GJ7xj7BTUgMRAv1pPEUPUbt912m9SgcTJF Tdnp06ct028wcJLONkfSSs0xJ+jU8tHsg2Vm+anJpAKDk0L2F2pzmJXxYRnZD7CtcWWGZjskESTq xIcTDI5d7C84ppE8FfuGsIskeVwpZD/B956Ejn9zEqgUSySwNAEkfrzOsZcTFD4D9pNWHovV5JDE jsoVlpV1oIaZBO+6666T5FxNeslH+D7ZicjSlIWTQr7/XLnmZIr9H/sQrhJwbDZE1gfCQZLklSQv Mu1oRBIEvjjsGLhMTWLB5SeCxMGXHSMHJpIIapWsSiBU/agh4YycnTkPqFAzeS4LssNjXdQSIZdC SW65pGhlAsHOmB0f8eEMnfhwFshr1ChzOZdkiSYT7ODYwXNZyspLhSw7J0bEiOXk8gwJILEgqaCm j3UiQVf157LiggULZMdhVTMQtZFSLUmTNNCkgHVkG+OEkW2O7xmXQGkzRs0E09rBtIDvPzXLJA4c nFgfvlec9FKTzlUbLlnzObAt0v7Nysufnn0HcWL7Upso+UmTK4UXN/FRC0PNLDUu27dvt1S/wefM SSAJn3IRxvIRF7YzmuNwwsEJBvsMtj/Wx+qTJ1U39mnsu9kG2fY4cec1YsPJPYkR2x5Ju+onrFof lo0ElgSO7YxYETO+W5zgcmWGE3ni9eGHH0otLAM/qVxi+7Ry/VRfQbw4GWT9qIBgX8H2x0kHv6Mt PbFlnanMsENfoTZYk7gqRQz7QTU2853iuMaJsJXrY1siq5YiPHcIql3HnjtaPXcRcobBhsiZIcmG lV8e5RIj4+S91Ewzes96URMRk3aEHRublZfVcquDJ35qJ7I6NtnqS4Usm+q8Peuhlmk926LaqauC 1d+xxCxH+XrunFb4KIziPY6GLDFXeBehteSKAJd2SZaUGyTPwL8Vpp742qlv9CxvVrw8g9UmHcqF Hd8dz0126h3iu5UVq6z1tTI+ym9n1veMygkSQOUNJCccrdzeFDniNWKnzKayBpodcFWOEyirv1d8 V6iEoCkfiR3bXtZ+UU1IsrZbq5NYlpu25zQH4WpvTv0g8cnJNZchsiUknEVxmdrKS++FEc7a7dCB GzFiFeFkg1pLLhfq1BcYsa+QWHDzK1eo7OQ5qDDvHu1LqVW3w85+lpFeFVR5dcKGdWEfyL7QDqsZ hshecC/pKEf1OtXLijvejRixurDjtupGOyP/f9ukXdw2FXXMstO7R86ga19BLJQJkiGyRowYMWLE iBEjRowUN5Hlf0aMGDFixIgRI0aM2E3+D4Rd5d5I2j4WAAAAAElFTkSuQmCC --_004_2D29C51862222E49B991EF64EEB0B5B745F859D9OPE10MB05tpgkco_-- From nobody Tue Aug 5 09:30: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 3C8EB1B2A82 for ; Tue, 5 Aug 2014 09:30: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 fo5HFLyHOR7D for ; Tue, 5 Aug 2014 09:30:21 -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 80A681A036B for ; Tue, 5 Aug 2014 09:30:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XEhcW-0000BoC; Tue, 5 Aug 2014 18:29:52 +0200 Message-Id: To: Ca By From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> In-reply-to: Your message of "Tue, 5 Aug 2014 09:00:27 -0700 ." Date: Tue, 05 Aug 2014 18:29:49 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7CLKpck9USjbsCUw18pAdqHPk18 Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 16:30:24 -0000 > Somewhere else in the world, the biggest and smartest companies > are investing billions of dollars into futuristic cloud platforms > that dont even have token IPv6 supports (Azure and Google Cloud) > > In summary, the premise of the daul stack transition for the Internet > is faulty. It already failed. People have been creating websites that only worked on IE6 long after it became clear that doing so was a bad idea. The question is if IPv4 is going to be bad enough that the pain of supporting IPv6 will be worth it. If so, the transition will happen and probably will even happen quickly. The current IPv6 is mature enough that you can run it in production. Whether people will run it in production depends on whether there is a net gain in doing so. That gain has to come from off-loading traffic from scarce IPv4 addresses. From nobody Tue Aug 5 09:53: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 03F4C1A03BB for ; Tue, 5 Aug 2014 09:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jarrqF-U72ne for ; Tue, 5 Aug 2014 09:53:46 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CB11A03AD for ; Tue, 5 Aug 2014 09:53:46 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1DF3EF803B for ; Tue, 5 Aug 2014 09:53:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id F16CA190043; Tue, 5 Aug 2014 09:53:45 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 5 Aug 2014 09:53:45 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 5 Aug 2014 12:53:08 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> To: Ca By X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dWsV-f0lfeNc3KlQvz5xmcdfp8k Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 16:53:48 -0000 On Aug 5, 2014, at 12:00 PM, Ca By wrote: > In summary, the premise of the daul stack transition for the Internet > is faulty. It already failed. With all due respect, I don't see how what you have said here benefits = the discussion. First of all, there's a great deal of evidence that = what you've said isn't actually true, and secondly, even to the extent = that it is true, it's not really actionable. Of course there will be = people who will do things the wrong way, and either limp along forever = or eventually get bulldozed off the cliff. So what? =20 There are still mainframes in back offices running SNA, but that doesn't = mean that IPv4 is irrelevant: quite the opposite--they are probably = running SNA in IP tunnels, their 370 is probably an emulation running on = an Intel box, and chances are that people are sshing in using a 3270 = emulator. So we don't care that they are still running SNA, and we = don't care when they get rid of it, because it is not an "internet" = protocol. That is the future of IPv4 as well. The question is, are there people who want to do a transition to IPv6 = (or will want to), whether for altruistic or pragmatic reasons, and if = so, is there additional help we can offer them, or is what we've done = thus far sufficient? From nobody Tue Aug 5 10:36: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 B37941A005D for ; Tue, 5 Aug 2014 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, 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 ZN57BSiWlDW6 for ; Tue, 5 Aug 2014 10:36:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AA4561A004E for ; Tue, 5 Aug 2014 10:36:09 -0700 (PDT) Received: from [172.26.26.231] ([65.113.17.1]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s75HUqKm016313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Aug 2014 10:30:53 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s75HUqKm016313 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407259854; bh=4AT6u65hV6R9F0Dpf5DP/cnXmWI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NR08vMWeeBo3OlFfH2WySEsKC+Ie8BQW5tDGvIK5J8AmYWvF6mx6/0PISrQBjJKIB cmAimCoiCzwyu1Ojc61vX63vWpa+X0olgMyovRL+z8D+9rxKS997GDGlZgi0b7B+ZC VzFu5Jnavi0H9rGnjsbadDM7qTp/S8rNBwe0b0og= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Tue, 5 Aug 2014 10:30:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> To: Ted Lemon X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 05 Aug 2014 10:30:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5rlaXsy3Jqi9hTH3NslYVttVN4M Cc: Tore Anderson , IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 17:36:11 -0000 While this is rare, I come rely agree with Ted here.=20 Well said, Ted.=20 Owen > On Aug 5, 2014, at 9:53, Ted Lemon wrote: >=20 >> On Aug 5, 2014, at 12:00 PM, Ca By wrote: >> In summary, the premise of the daul stack transition for the Internet >> is faulty. It already failed. >=20 > With all due respect, I don't see how what you have said here benefits the= discussion. First of all, there's a great deal of evidence that what you'= ve said isn't actually true, and secondly, even to the extent that it is tru= e, it's not really actionable. Of course there will be people who will do t= hings the wrong way, and either limp along forever or eventually get bulldoz= ed off the cliff. So what? =20 >=20 > There are still mainframes in back offices running SNA, but that doesn't m= ean that IPv4 is irrelevant: quite the opposite--they are probably running S= NA in IP tunnels, their 370 is probably an emulation running on an Intel box= , and chances are that people are sshing in using a 3270 emulator. So we d= on't care that they are still running SNA, and we don't care when they get r= id of it, because it is not an "internet" protocol. That is the future of I= Pv4 as well. >=20 > The question is, are there people who want to do a transition to IPv6 (or w= ill want to), whether for altruistic or pragmatic reasons, and if so, is the= re additional help we can offer them, or is what we've done thus far suffici= ent? From nobody Tue Aug 5 10:42: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 CCD3E1A0035 for ; Tue, 5 Aug 2014 10:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHbfWAMf_0uT for ; Tue, 5 Aug 2014 10:42:48 -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 E9B681B2A90 for ; Tue, 5 Aug 2014 10:42:47 -0700 (PDT) Received: from cm-84.209.85.233.getinternet.no ([84.209.85.233]:59698 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XEil3-00052w-Dp; Tue, 05 Aug 2014 19:42:45 +0200 Message-ID: <53E11795.7060305@fud.no> Date: Tue, 05 Aug 2014 19:42:45 +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: Ross Chandler , Ca By References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> In-Reply-To: <94146541-768B-4853-A011-7558655C361C@eircom.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ePH6Z2mPcz8U2OBFgokAbWr4Izo Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 17:42:49 -0000 * Ross Chandler > The APN roaming protocol setting for “telenor.mobil” listed at that > URL says it is IPv6. > > Is that really their setting? AFAIK the Android UE or more > accurately the RIL it calls doesn’t fallback to IPv4 when IPv6 is > explicitly requested. Yes, that's their setting. No need for fallback when IPv6 works, right? To be honest I've never quite understood what all the fuss is about regarding IPv6 and 3GPP roaming. My personal experience, having been a customer of Tele 2 Norway (formerly Network Norway) using their IPv6 pilot for about two years, then moving to Telenor about six months ago, is that IPv6 roaming Just Works. I've not visited every country in the world, but I have been around a bit, and I've made a point out of trying to establish an IPv6 data bearer to every single PLMN I can register with. So far I've had 100% success, including on Cameron's network... Thus enabling IPv6 roaming doesn't seem like a scary proposition to me. I'm guessing perhaps Telenor came to the same conclusion. Tore From nobody Tue Aug 5 11:23: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 068FC1B2AC5 for ; Tue, 5 Aug 2014 11:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg9RPMYwvqzQ for ; Tue, 5 Aug 2014 11:23:05 -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 D55331B2AC7 for ; Tue, 5 Aug 2014 11:23:04 -0700 (PDT) Received: (qmail 98325 messnum 6601063 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 5 Aug 2014 18:23:02 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail11.svc.cra.dublin.eircom.net (qp 98325) with SMTP; 5 Aug 2014 18:23:02 -0000 Received: from [192.168.43.190] ([86.43.53.4]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id b6Ny1o00e05SpG6016P2Wj; Tue, 05 Aug 2014 19:23:02 +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: <53E11795.7060305@fud.no> Date: Tue, 5 Aug 2014 19:22:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/S66Om4ySB2JTC_aTcQdYzB3gWj8 Cc: IPv6 Ops WG Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 05 Aug 2014 18:23:09 -0000 Subject line change as this has turned more appropriate to the = roaming-analysis draft. On 5 Aug 2014, at 18:42, Tore Anderson wrote: >> The APN roaming protocol setting for =93telenor.mobil=94 listed at = that >> URL says it is IPv6. >>=20 >> Is that really their setting? AFAIK the Android UE or more >> accurately the RIL it calls doesn=92t fallback to IPv4 when IPv6 is >> explicitly requested. >=20 > Yes, that's their setting. No need for fallback when IPv6 works, = right? >=20 > To be honest I've never quite understood what all the fuss is about > regarding IPv6 and 3GPP roaming. My personal experience, having been a > customer of Tele 2 Norway (formerly Network Norway) using their IPv6 > pilot for about two years, then moving to Telenor about six months = ago, > is that IPv6 roaming Just Works. >=20 > I've not visited every country in the world, but I have been around a > bit, and I've made a point out of trying to establish an IPv6 data > bearer to every single PLMN I can register with. So far I've had 100% > success, including on Cameron's network... Thus enabling IPv6 roaming > doesn't seem like a scary proposition to me. I'm guessing perhaps > Telenor came to the same conclusion. According to the manual my SGSN-MMEs have an =93AllowIPv6ForAllVisitors=94= parameter that has to be set true to allow IPv6 PDP/PDN connections be = set-up be visitors. Out of the box the SGSN-MME had userplane IPv6 enabled for home users. = It needed the DAF flag to be set (to allow dual-stack in a single = bearer). Proposal for addition to the draft - it should mention =93IPv6 Roaming = friendly operator=94 settings (user plane IPv6 allowed, DAF=3D1 if = possible) on how to make your network friendly for visitors.=20 Ross= From nobody Tue Aug 5 11: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 A63FD1A0657 for ; Tue, 5 Aug 2014 11:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b48PXceauyO4 for ; Tue, 5 Aug 2014 11:33:16 -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 9DF151A03CA for ; Tue, 5 Aug 2014 11:33:16 -0700 (PDT) Received: from cm-84.209.85.233.getinternet.no ([84.209.85.233]:60403 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XEjXu-00064s-9q; Tue, 05 Aug 2014 20:33:14 +0200 Message-ID: <53E1236A.605@fud.no> Date: Tue, 05 Aug 2014 20:33:14 +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: Ted Lemon , Ca By References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sZG7rca3PwsQQXx1cu3CJYPDWxU Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 18:33:18 -0000 * Ted Lemon > On Aug 5, 2014, at 12:00 PM, Ca By wrote: >> In summary, the premise of the daul stack transition for the >> Internet is faulty. It already failed. > > With all due respect, I don't see how what you have said here > benefits the discussion. First of all, there's a great deal of > evidence that what you've said isn't actually true, and secondly, > even to the extent that it is true, it's not really actionable. Of > course there will be people who will do things the wrong way, and > either limp along forever or eventually get bulldozed off the cliff. > So what? The dual stack transition has indeed already failed. If you're located in Europe, Asia, or Latin America, chances are that you simply cannot obtain the IPv4 addresses you need to run dual stack. North America should be in the same situation shortly. Any *current* recommendation to use dual stack to needs to come with a caveat that it is only really applicable to African operators, to operators who happens to be sitting on a large reserve of IPv4 addresses, or to operators who have no growth. Geoff saw this coming of course, slides 27 through 29 of http://www.potaroo.net/presentations/2007-10-23-ipv4-depletion.pdf sums up how dual stack has failed much better than I ever could. > There are still mainframes in back offices running SNA, but that > doesn't mean that IPv4 is irrelevant: quite the opposite--they are > probably running SNA in IP tunnels, their 370 is probably an > emulation running on an Intel box, and chances are that people are > sshing in using a 3270 emulator. So we don't care that they are > still running SNA, and we don't care when they get rid of it, because > it is not an "internet" protocol. That is the future of IPv4 as > well. I agree that once we're there, problem solved, nobody will care. However we're very far from that that being reality. As Cameron rightly pointed out, somewhere in the world right now, someone is writing a line of code, creating a database schema, making an ACL, purchasing a piece of hardware or service, or whatever, that creates yet another dependency on IPv4, making it ever more difficult to demote IPv4 to a «not an "internet protocol» ŕ la SNA. As Owen points out, I could weed out such dependencies in maintenance windows. But even if that is true, with dual stack, IPv4-dependent infrastructure will continue to be created at a much greater rate than I can retroactively fix it to become IPv4-independent. And there is just no way that I could possibly audit every line of code written, every piece of software installed, or every service or piece of hardware procured, and that way make sure that no new IPv4 dependencies are introduced. The way I see it, the only realistic solution to stopping the infrastructure from acquiring more and more dependencies on IPv4 is to remove it entirely. Cold turkey. > The question is, are there people who want to do a transition to IPv6 > (or will want to), whether for altruistic or pragmatic reasons, and > if so, is there additional help we can offer them, or is what we've > done thus far sufficient? I'm transitioning to IPv4 for pragmatic reasons, and dual stack doesn't cut it for me, for reasons that include: - I don't have enough IPv4 addresses to do dual stack for much longer. - Dual stack greatly increases complexity, which in turn increases the OpEx and reduces service reliability. - As mentioned above, the presence of IPv4 will inevitably cause an ever increasing dependency on IPv4, because of technological inertia in the humans that design, develop, and deploy the application stacks. As for additional help needed, well, I'm trying to put my money where my mouth is and coming up with a solution to these problems - you could help by reviewing my drafts. :-) The solution works, there is already running open-source code, so rough consensus is all that's missing... Tore From nobody Tue Aug 5 12:22: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 415631A01FA for ; Tue, 5 Aug 2014 12:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoowXL0N706m for ; Tue, 5 Aug 2014 12:22:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id DC44D1A0167 for ; Tue, 5 Aug 2014 12:22:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XEkJJ-0000BuC; Tue, 5 Aug 2014 21:22:13 +0200 Message-Id: To: Tore Anderson From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> In-reply-to: Your message of "Tue, 05 Aug 2014 20:33:14 +0200 ." <53E1236A.605@fud.no> Date: Tue, 05 Aug 2014 21:22:10 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RPxvFYIkz0vaCvPmZj4rzVKx-t0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 19:22:20 -0000 In your letter dated Tue, 05 Aug 2014 20:33:14 +0200 you wrote: >The dual stack transition has indeed already failed. If you're located >in Europe, Asia, or Latin America, chances are that you simply cannot >obtain the IPv4 addresses you need to run dual stack. North America >should be in the same situation shortly. If dual stack implies no NAT anywhere what is then the correct term for NAT44 or NAT444 along with native IPv6? Just curious. I would call that dual stack. But you don't appearently. >As for additional help needed, well, I'm trying to put my money where my >mouth is and coming up with a solution to these problems - you could >help by reviewing my drafts. :-) The solution works, there is already >running open-source code, so rough consensus is all that's missing... My gut feeling is that translating IPv4 packets to IPv6 or vise versa is bad idea. Some thing will come up to make your life miserable. In some sense it is very similar to tunneling. I think it is safe to say that in your model you have enough public IPv4 address to run your services. What your proposal eliminates is the need for internal IPv4 addresses. The question is then, why not simply run on RFC-1918 addresses internally? Afterall, usually the goal is to provide IPv4 services. Maybe our setup is unique, but we have quite a few servers in remote data centers that need to access internal servers. What we do is have ACLs in the firewalls to only allow the addresses we know about and keep the rest of the Internet out. In your model, any IPv4 address in a remote data center would either have to translated to an IPv6 address (which of course nobody recognizes) or we need an IPv4 firewall infront of the SIIT Gateway. Leaving the dual ACL problem in place. If I look at our system, if we would just drop IPv4 support for all internal communication then we would probably see a similar reduction in complexity. Leaving only the communication between the load balancer and the actual web front-ends as something that could be moved to IPv6. From nobody Tue Aug 5 12:54: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 70F991A01D2 for ; Tue, 5 Aug 2014 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEQPxE1b4c98 for ; Tue, 5 Aug 2014 12:54:06 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBE31A01C3 for ; Tue, 5 Aug 2014 12:54:05 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A71FE608E0 for ; Tue, 5 Aug 2014 21:54:02 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6FB80608D5 for ; Tue, 5 Aug 2014 21:54:02 +0200 (CEST) Received: (qmail 7264 invoked by uid 1007); 5 Aug 2014 21:54:02 +0200 Date: Tue, 5 Aug 2014 21:54:02 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20140805195402.GO51793@Space.Net> References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XjgrULmdJeAr9l-r3zpS9r7I6Kw Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 19:54:09 -0000 Hi, On Tue, Aug 05, 2014 at 09:22:10PM +0200, Philip Homburg wrote: > The question is then, why not simply run on RFC-1918 addresses internally? Why have dual everything inside, when single IPv6 is sufficient to achieve service delivery? Dual everything is *dual* *work*, translating to real money out in the real world. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Aug 5 13:10: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 5B1901A02D5 for ; Tue, 5 Aug 2014 13:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlI1EB0bUDvX for ; Tue, 5 Aug 2014 13:10: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 1EAC41A029F for ; Tue, 5 Aug 2014 13:10:40 -0700 (PDT) Received: from cm-84.209.85.233.getinternet.no ([84.209.85.233]:33083 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XEl48-0008Vm-8p; Tue, 05 Aug 2014 22:10:36 +0200 Message-ID: <53E13A3B.4050303@fud.no> Date: Tue, 05 Aug 2014 22:10:35 +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: Philip Homburg References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7lt5T06cILYIBRxVC8R-x-biKVQ Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 20:10:44 -0000 * Philip Homburg > If dual stack implies no NAT anywhere what is then the correct term for > NAT44 or NAT444 along with native IPv6? > > Just curious. I would call that dual stack. But you don't appearently. The current IPv6 dual stack transition mechanism is defined in RFC 4213, and it makes no reference to NAT whatsoever. This thread started out by Fred asking if we needed to update the consensus that dual stack is the IETF-recommended transition method, and in that context, no I not consider that the current dual stack recommendation includes NAT44*. It would certainly be possible to update RFC 4213 to mean that the new recommendation is to do NAT44* in combination with IPv6, though. But I don't think that's a good idea. We find ourselves in a hole, so maybe we should stop digging instead of getting ourselves a new shovel... >> As for additional help needed, well, I'm trying to put my money where my >> mouth is and coming up with a solution to these problems - you could >> help by reviewing my drafts. :-) The solution works, there is already >> running open-source code, so rough consensus is all that's missing... > > My gut feeling is that translating IPv4 packets to IPv6 or vise versa is > bad idea. Some thing will come up to make your life miserable. In some > sense it is very similar to tunneling. If you by tunneling are referring to the catastrophe that was 6to4, then I disagree. It is more like 6RD or MAP-E as it will typically contained within a single administrative domain. As for other things failing, if you have some concrete examples, please let me know. I'd certainly want to see if I can make those work, or if not, make sure the drafts properly document the limitations causing the failure. > I think it is safe to say that in your model you have enough public IPv4 > address to run your services. What your proposal eliminates is the need > for internal IPv4 addresses. That's right. No addresses lost due to network infrastructure, servers/applications performing internal tasks, unused addresses on LAN segments due to CIDR ^2 boundaries or space set aside for future growth. One public service per IPv4 address only. I'd imagine that most internet content providers have a much higher number of internal applications/servers than they have public service addresses, so this adds up to significant savings. > The question is then, why not simply run on RFC-1918 addresses internally? > Afterall, usually the goal is to provide IPv4 services. I'd like to to it Right from the start, and actually deploy IPv6. Changing to RFC1918 and NAT44 will do nothing to help me to deploy IPv6, if anything it would distract me from it. When I do get around to doing IPv6 as well, I'm stuck with the complexity of running two IP protocols in parallel, resulting in extra OpEx and reduced reliability I'd rather go without. (IMHO, IPv4-only is preferable to that, and it looking at the IPv6 availability graphs it would appear most operators share this view.) If I ever want to actually discontinue the IPv4+NAT44 stuff in order to get rid of that extra complexity and go IPv6-only, then that's another very time-consuming and non-revenue-generating project to look forward to. (Not.) In summary, IPv4 scarcity forces us to change the way we've always done stuff up until now. I'm not happy about it, but it is unfortunately inevitable. Considering I need to change all this stuff now anyway I'd much rather do it in a way that actually solves the problem long-term, and doesn't just line me up for another big and painful migration projects a few years down the road. > Maybe our setup is unique, but we have quite a few servers in remote > data centers that need to access internal servers. What we do is have > ACLs in the firewalls to only allow the addresses we know about and keep > the rest of the Internet out. > > In your model, any IPv4 address in a remote data center would either have to > translated to an IPv6 address (which of course nobody recognizes) or we > need an IPv4 firewall infront of the SIIT Gateway. Leaving the dual ACL > problem in place. Presumably you'll want a firewall inside of the SIIT gateway, to deal with IPv6 ACLs? If so, you only need one firewall and only one ACL. If you previously had an ACL that said something like in iptables syntax, where 192.0.2.100 is the trusted IP address you want to allow: --source 192.0.2.100 --protocol tcp --dport ssh -j ACCEPT ...with SIIT, you'd instead do, assuming 64:ff9b::/96 is the translation prefix): --source 64:ff9b::192.0.2.100 --protocol tcp --dport ssh -j ACCEPT The above IPv6 address with the embedded IPv4 dotted quad is syntactically valid, by the way, you don't even have to convert it to hex (cf. RFC4291 section 2.2). I would generally recommend locating the SIIT gateways as close to the edge of your network as possible. Ideally as a logical function located inside the border routers. That way, on the inside you can simply treat everything as IPv6, and have one IPv6 firewall, one IPv6 ACL, one IPv6 IGP topology, and so on, and so on. Tore From nobody Tue Aug 5 13:55: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 5DB581B2BBB for ; Tue, 5 Aug 2014 13:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25jB-AbBomqe for ; Tue, 5 Aug 2014 13:55:21 -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 AEFAF1B2B78 for ; Tue, 5 Aug 2014 13:55:21 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so2065799pac.18 for ; Tue, 05 Aug 2014 13:55:21 -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=LJhK6K2lpTPW/o6wwWcDx5Aw3MVgtKdQ7/kj3WM/sQQ=; b=rN2L3CEYRvMd/BWc1TmyLXbWMw+DuHjyBvAMg7KDPSYx39bgWmXnHBJVB2yOPi4QKf TOWVazuVlL27/KvBool9reIQeqlWMpm590UodEieDGWucBHfaRvM9jBBdEr9s4g/wtnN cpU14BiRJIkp6Xxype6FAd4cI17GjV4+RciKGyiA5nSFMdIjuQRTUT9wurVsHcSuejnP 92//gESVi+lu3sq1h4ADGJ5Xq9B8UP+Egeo+9bDoX2wsr7u08KRsPvm5jkWE1m8IXCIx 759lwk647aiSSTLShYGWR68svXQw4jAMW3YWn4i8wf7r348rRbTAHbbDvABQeQji/IzA O8Sg== X-Received: by 10.70.133.167 with SMTP id pd7mr6974922pdb.31.1407272121380; Tue, 05 Aug 2014 13:55:21 -0700 (PDT) Received: from [192.168.178.23] (135.199.69.111.dynamic.snap.net.nz. [111.69.199.135]) by mx.google.com with ESMTPSA id mn2sm2964698pbc.64.2014.08.05.13.55.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 13:55:20 -0700 (PDT) Message-ID: <53E144BA.1020300@gmail.com> Date: Wed, 06 Aug 2014 08:55:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <53E13A3B.4050303@fud.no> In-Reply-To: <53E13A3B.4050303@fud.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qAmuJ2pT-iEe_JN2qm2mB15RnnE Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 20:55:23 -0000 On 06/08/2014 08:10, Tore Anderson wrote: > * Philip Homburg >> If dual stack implies no NAT anywhere what is then the correct term for >> NAT44 or NAT444 along with native IPv6? >> >> Just curious. I would call that dual stack. But you don't appearently. > > The current IPv6 dual stack transition mechanism is defined in RFC 4213, > and it makes no reference to NAT whatsoever. Well, this is an interesting way of looking at things. Since IPv4 has been routinely NATted for most users for most of the time since broadband arrived, it had never occurred to me before this morning that some people interpret "dual stack" to mean no NAT44. RFC 4213 is agnostic about NAT afaik. It does assume that the ISP has a supply of IPv4 addresses, but it doesn't assume they are globally routeable. Also, its language doesn't say that it's *the* solution: The mechanisms defined here are intended to be the core of a "transition toolbox" -- a growing collection of techniques that implementations and users may employ to ease the transition. The tools may be used as needed. Implementations and sites decide which techniques are appropriate to their specific needs. When I mentioned operators (including my home ISP) that happily operate dual stack, I was certainly assuming CPE NAT, and operators that have enough IPv4 space for one-address-per-customer. Clearly operators that aren't in that position will make a different trade-off. That's been driving a great deal of work in the last few years: CGN for NAT444, 100.64.0.0/10, NAT64/DNS64, DS Lite, XLAT and more. I just don't see the point in defining some sort of "official" position of the IETF. Who does that help? Brian From nobody Tue Aug 5 14:06: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 934841B2BD1 for ; Tue, 5 Aug 2014 14:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRpQ5KNKj43B for ; Tue, 5 Aug 2014 14:05:56 -0700 (PDT) Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id 4D1FE1B2BBB for ; Tue, 5 Aug 2014 14:05:55 -0700 (PDT) Received: (qmail 77828 messnum 312478 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 5 Aug 2014 21:05:55 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail19.svc.cra.dublin.eircom.net (qp 77828) with SMTP; 5 Aug 2014 21:05:55 -0000 Received: from [192.168.43.190] ([86.43.53.4]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id b95q1o01D05SpG60195uhj; Tue, 05 Aug 2014 22:05:55 +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: <53E0C548.9050706@fud.no> Date: Tue, 5 Aug 2014 22:05:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> To: Tore Anderson , IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hVWuULNsEZpe26MBfw9NhGFV04o Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:05:58 -0000 On 5 Aug 2014, at 12:51, Tore Anderson wrote: > = http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/ma= ster/siit-dc.html >=20 > Comments, criticisms, suggestions, pull requests would be very = welcome! What=92s your position on NAPT44 being put in front of an IP service = address pool that used RFC1918 space? Not advocating for that but it would inevitably be tried.=20 Ross From nobody Tue Aug 5 14:07: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 C2A761B2BBB for ; Tue, 5 Aug 2014 14:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RT8oilndkIV for ; Tue, 5 Aug 2014 14:07:04 -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 043BA1B2BD9 for ; Tue, 5 Aug 2014 14:07:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XElwg-0000BbC; Tue, 5 Aug 2014 23:06:58 +0200 Message-Id: To: Gert Doering From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-reply-to: Your message of "Tue, 5 Aug 2014 21:54:02 +0200 ." <20140805195402.GO51793@Space.Net> Date: Tue, 05 Aug 2014 23:06:57 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QSYLN2ROqD9iIBd1a5ja2t3jL5U Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:07:07 -0000 In your letter dated Tue, 5 Aug 2014 21:54:02 +0200 you wrote: >On Tue, Aug 05, 2014 at 09:22:10PM +0200, Philip Homburg wrote: >> The question is then, why not simply run on RFC-1918 addresses internally? > >Why have dual everything inside, when single IPv6 is sufficient to >achieve service delivery? Dual everything is *dual* *work*, translating >to real money out in the real world. I think it is safe to say that providing good IPv4 service is the most important requirement. In many cases, it is perfectly fine to not provide any IPv6 if it cannot be provided at reasonable cost / performance. So what recent proposals are doing to make providing IPv4 more complex under the assumption that it is actually important to provide IPv6. (note, looking at this from business point of view. Not as somebody who care about the future of the internet). So instead of doing a relatively straightforward NAT44 or NAT444 and then let IPv6 pay for itself, you now make the cost of providing IPv6 part of the cost of providing IPv4. In essence, your IPv4 network now got more expensive. In some cases, mobile operators, very big cable ISPs that run out of RFC-1918, it makes sense to translate or tunnel IPv4. In other cases, this kind of complexity is likely to backfire some time in future. From nobody Tue Aug 5 14:40: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 905CD1B2BF8 for ; Tue, 5 Aug 2014 14:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qei4cb36K4fP for ; Tue, 5 Aug 2014 14:40:07 -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 2A2F41B2BF6 for ; Tue, 5 Aug 2014 14:40:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XEmSi-0000A8C; Tue, 5 Aug 2014 23:40:04 +0200 Message-Id: To: Tore Anderson From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <53E13A3B.4050303@fud.no> In-reply-to: Your message of "Tue, 05 Aug 2014 22:10:35 +0200 ." <53E13A3B.4050303@fud.no> Date: Tue, 05 Aug 2014 23:39:57 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J9i0riqM21sMyBktXgWc9vlbUpI Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:40:09 -0000 In your letter dated Tue, 05 Aug 2014 22:10:35 +0200 you wrote: >The current IPv6 dual stack transition mechanism is defined in RFC 4213, >and it makes no reference to NAT whatsoever. This thread started out by >Fred asking if we needed to update the consensus that dual stack is the >IETF-recommended transition method, and in that context, no I not >consider that the current dual stack recommendation includes NAT44*. > >It would certainly be possible to update RFC 4213 to mean that the new >recommendation is to do NAT44* in combination with IPv6, though. But I >don't think that's a good idea. We find ourselves in a hole, so maybe we >should stop digging instead of getting ourselves a new shovel... The IETF has ignored NAT44 for a very long time. Most home users don't actually have IPv4 access: they have a middle box that breaks things. Outside the IETF (and I assume to a large extent also inside the IETF) people will find this line of reasoning overly pedantic. To them, NAT44 is just part of the Internet. We can also be pedantic about 'dual stack' and refer to v6+v4 or v6+NAT44 or v6+NAT444. However I think the meaning of dual stack is the concept that IPv4 and IPv6 are independent. Neither is tunneled over or translated into the other. In that sense, whether IPv4 is native or behind a CGN is not relevant. We matter is that IPv6 is completely independent of that. >If you by tunneling are referring to the catastrophe that was 6to4, then >I disagree. It is more like 6RD or MAP-E as it will typically contained >within a single administrative domain. No operator likes tunnels. 6RD is not considered 'native IPv6', it is a second class citizen. Personally I think tunneling IPv6 locally over IPv4 works very well. But there seem to be very few people who agree with that point of view. >As for other things failing, if you have some concrete examples, please >let me know. I'd certainly want to see if I can make those work, or if >not, make sure the drafts properly document the limitations causing the >failure. The thing is that in the IPv4 world, probably every coding mistake you can imagine is out there somewhere. Anything that differs from the way IPv4 is normally done, may cause things to fail in some small fraction of systems. To give a concrete example. The obvious solution to a lower MTU is actually path MTU discovery, but that doesn't work, so we do MSS clamping. Out in the field are middle boxes that break MSS clamping. The reason those boxes work is that every server supports an MTU of 1500. If your server doesn't, things break. >> I think it is safe to say that in your model you have enough public IPv4 >> address to run your services. What your proposal eliminates is the need >> for internal IPv4 addresses. > >That's right. No addresses lost due to network infrastructure, >servers/applications performing internal tasks, unused addresses on LAN >segments due to CIDR ^2 boundaries or space set aside for future growth. >One public service per IPv4 address only. I'd imagine that most internet >content providers have a much higher number of internal >applications/servers than they have public service addresses, so this >adds up to significant savings. Except that any truely internal server, you can already run on IPv6-only. No need to change anything in your front-end to do that. >Presumably you'll want a firewall inside of the SIIT gateway, to deal >with IPv6 ACLs? If so, you only need one firewall and only one ACL. If >you previously had an ACL that said something like in iptables syntax, >where 192.0.2.100 is the trusted IP address you want to allow: > >--source 192.0.2.100 --protocol tcp --dport ssh -j ACCEPT > >...with SIIT, you'd instead do, assuming 64:ff9b::/96 is the translation >prefix): > >--source 64:ff9b::192.0.2.100 --protocol tcp --dport ssh -j ACCEPT Now we wait for somebody to type 64:ff9b::192.0.2.0/24 instead of 64:ff9b::192.0.2.0/120. Also, this not in canonical form. So any program that outputs these address uses a different syntax. Try grepping your firewall config for an address you see in tcpdump and not finding it. And I wonder howmany people understand this notation at all. From nobody Tue Aug 5 14:49: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 18D2D1B2BFC for ; Tue, 5 Aug 2014 14:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZbyK5MldYc0 for ; Tue, 5 Aug 2014 14:49:00 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694F91B2BFE for ; Tue, 5 Aug 2014 14:49:00 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4013D1B839B for ; Tue, 5 Aug 2014 14:49:00 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1EB5A190043; Tue, 5 Aug 2014 14:49:00 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 5 Aug 2014 14:49:00 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 5 Aug 2014 17:48:17 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2555EF68-9FCC-4C1C-9B54-39A69D090087@nominum.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <53E13A3B.4050303@fud.no> To: Philip Homburg X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zV0K6Ae5qNRbYpdmzX5JH9cszd0 Cc: Tore Anderson , IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:49:02 -0000 On Aug 5, 2014, at 5:39 PM, Philip Homburg = wrote: >> Presumably you'll want a firewall inside of the SIIT gateway, to deal >> with IPv6 ACLs? If so, you only need one firewall and only one ACL. = If >> you previously had an ACL that said something like in iptables = syntax, >> where 192.0.2.100 is the trusted IP address you want to allow: >>=20 >> --source 192.0.2.100 --protocol tcp --dport ssh -j ACCEPT >>=20 >> ...with SIIT, you'd instead do, assuming 64:ff9b::/96 is the = translation >> prefix): >>=20 >> --source 64:ff9b::192.0.2.100 --protocol tcp --dport ssh -j ACCEPT >=20 > Now we wait for somebody to type 64:ff9b::192.0.2.0/24 instead of > 64:ff9b::192.0.2.0/120. >=20 > Also, this not in canonical form. So any program that outputs these = address > uses a different syntax. Try grepping your firewall config for an = address > you see in tcpdump and not finding it. >=20 > And I wonder howmany people understand this notation at all. Gnaagh! I really hope people aren't configuring their firewalls this = way, but I don't have much operational involvement with firewalls, so = maybe they do? This seems hopelessly primitive and error-prone. From nobody Tue Aug 5 15:36: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 0604B1A0345 for ; Tue, 5 Aug 2014 15:36:46 -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 ZF_ShZ0a5CBS for ; Tue, 5 Aug 2014 15:36:44 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E489A1B2C14 for ; Tue, 5 Aug 2014 15:36:43 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id h136so1101582oig.35 for ; Tue, 05 Aug 2014 15:36:43 -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=ybEcZcBcEEa7ZKXgY9kw5C4Q0ExZXcgkoWk6rWazcfQ=; b=Pw+5nOD2B49j1FLzdCcPCNFRlorV0k1386wI6gWg6e2gYqXZRozszeEzwyHctcxjmH 2rpU9qMpDOSLoiE6dFSUFPKv7MhgTQJwaFhMZyOGtUrZ3VHuLM8gIh7XvXZAEp01vQQI NVoxVE/6MlbgtvzgLHpex1hWtT/x2O+vAsbpg4TwXZDvr03ZNZWNeDXVVa0KROZLOGj4 6Ssf8Ph1pOmFLcoQJiGtlFYieQ3NziH0ClLVCtWRBL3HLQ/dLPGvO9+oeJvSlIVUmLT+ nhgciGCIpa9HVz9NLICmnXsv+CvHlcXHd4IF0uRY4UIdb20yXUVkRJoNfz21qlyXbCFi hY1g== X-Received: by 10.60.51.9 with SMTP id g9mr10016260oeo.63.1407278203397; Tue, 05 Aug 2014 15:36:43 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id t2sm6502436obg.27.2014.08.05.15.36.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 15:36:42 -0700 (PDT) Message-ID: <53E15C7E.2040100@gmail.com> Date: Wed, 06 Aug 2014 10:36:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ross Chandler References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> In-Reply-To: <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QlfaNgcC3Av63T_BR8dfkXqzprY Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 22:36:46 -0000 On 06/08/2014 09:05, Ross Chandler wrote: > On 5 Aug 2014, at 12:51, Tore Anderson wrote: >=20 >> http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blo= b/master/siit-dc.html >> >> Comments, criticisms, suggestions, pull requests would be very welcome= ! >=20 > What=E2=80=99s your position on NAPT44 being put in front of an IP serv= ice address pool that used RFC1918 space? > Not advocating for that but it would inevitably be tried.=20 s/would be/has been/ That's exactly why 100.64.0.0/10 was reserved. Brian Brian From nobody Tue Aug 5 23:06: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 55B751B28E0 for ; Tue, 5 Aug 2014 23:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxFbz3nhBtMl for ; Tue, 5 Aug 2014 23:06:19 -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 08B4A1B2C7D for ; Tue, 5 Aug 2014 23:06:18 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=37642 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 1XEuMa-0005Bt-G1; Wed, 06 Aug 2014 08:06:16 +0200 Message-ID: <53E1C587.4000506@fud.no> Date: Wed, 06 Aug 2014 08:04:55 +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: Ross Chandler , IPv6 Ops WG References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> In-Reply-To: <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gK0UZN6sbOETtGELz8EKJGQB4QM Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 06:06:22 -0000 * Ross Chandler > What’s your position on NAPT44 being put in front of an IP service > address pool that used RFC1918 space? Not advocating for that but it > would inevitably be tried. I find this undesirable for several reasons. From the top of my head: 1) The NAPT44 device needs to maintain per-flow state for each flow. This creates some new undesirable scaling properties, in particular limitations on concurrent flow count and and flow initiation rate which generally are reached long before the available interface bandwidth is exhausted. This in turn typically makes such boxes be the first thing to stop working under DDoS attacks, as the flow table gets filled up with junk flow entries, and/or that new flow entries cannot be added to the table fast enough. 2) Related to #1, NAPT44 devices tends to be much more expensive than stateless devices, because they are much harder to implement and scale. A normal IP router that can forward, say, 50 Gbps of mostly HTTP traffic is quite affordable. A NAPT44 device/blade that can do the same gets much more expensive (and that extra expense would probably come in addition to the router that you're likely to need anyway). 3) All packets in a single flow must pass bi-directionally across a single NAPT44 instance. This causes a new set of challenges: 3a) You cannot scale the solution horizontally by adding more NAPT44 boxes and using e.g. ECMP to balance across them. If you've reached the limit of what your NAPT44 device can do, you'll have to buy a bigger one. 3b) The device might rewrite the source address of the end users to a pool assigned to the NAPT44 device itself. This ensures return traffic is routed back to the NAPT44 device, but also means that the source address of the end user is lost, and that the application has no way of doing stuff like Geo-Location or otherwise track users based on IP. 3c) If the device does not rewrite the source address, then you must point your default route at it, which means that all the traffic in your network must pass through it (even traffic that did not need to undergo NAT!) making it an even more attractive DDoS target. (Or, you could avoid this at the expense of added complexity, by having a separate VRF for NAPT44-bound traffic). 3d) You cannot do closest exit/hot potato routing, you must backhaul the return traffic to the NAT instance that handled the initial inbound packet. This can be avoided by buying NAPT44 devices for each location, which in turn will add to your CapEx and OpEx. 3e) Failure events are highly disruptive. If your primary NAPT44 box goes down and traffic is redirected onto the backup, every single flow is reset. Or, you could have an implementation that did some form of continuous replication of the state table from the primary to the backup, which complicates the implementation even more and probably makes it more expensive. 4) NAPT44 does absolutely nothing to help me deploy IPv6. Quite the contrary, such an undertaking actually be quite damaging to IPv6 deployment - my time and budgets are finite, and any time and budget that go into deploying and maintaining a NAPT44 solution is time and budget that won't get spent on deploying IPv6. However, the NAPT44 does not give me a pass on deploying IPv6, which means that I have that ordeal to look forward to anyway. I would much rather have to do only 1 painful migration project rather than 2 (or 3, if you count the eventual removal of IPv4 from throughout your infrastructure). For me, deploying NAPT44 seems like a terribly shortsighted effort that comes with a number of undesirable technical limitations. At best it would be akin to treading water; I'd much rather be swimming for shore. All of that said, YMMV; if you or anyone else use NAPT44 in your data centres, and are happy with it, then that's great, I have no philosophical/"religious" objections to that. I just need an alternative for myself, and preferably make it into one that others could use too, if they are in a situation similar to mine. Tore From nobody Tue Aug 5 23:59: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 6449E1B2CA2 for ; Tue, 5 Aug 2014 23:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBgcM8nhmEX5 for ; Tue, 5 Aug 2014 23:59:09 -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 BAF761B2CA1 for ; Tue, 5 Aug 2014 23:59:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5DC41A3; Wed, 6 Aug 2014 08:59:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1407308347; bh=ZEmbj2oYlIctLqNOBFz83dJ5hfilZWc3D+XeuabNExk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wGkPBpKCcLSWfha0x+B6HQZJrdDSo6sS3Om5HG1IsfwrLVaY9aOC5w5jZ7da5sSqg XUmw99Ez+Q8AR2undvoyB03jGXkNpZMKeVGos3W4n9OXXosvbN357VR94YfxQAHSzS pJL1umr7UKKqQChJ29gSqkfQARHmc3ZsQEHkvbVI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 53DF4A2; Wed, 6 Aug 2014 08:59:07 +0200 (CEST) Date: Wed, 6 Aug 2014 08:59:07 +0200 (CEST) From: Mikael Abrahamsson To: Tore Anderson In-Reply-To: <53E11795.7060305@fud.no> Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> 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/SRXba3LPYqcsSFJ2hscdVNYwzB4 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 06:59:12 -0000 On Tue, 5 Aug 2014, Tore Anderson wrote: > To be honest I've never quite understood what all the fuss is about > regarding IPv6 and 3GPP roaming. My personal experience, having been a > customer of Tele 2 Norway (formerly Network Norway) using their IPv6 > pilot for about two years, then moving to Telenor about six months ago, > is that IPv6 roaming Just Works. I've heard reports of platforms in use in southeast asia, I don't remember if it was Korea or some other country, would fail when presented with IPv4v6 capability. The reason why people are not going for IPv4v6 externally is because it breaks things, badly, it seems, due to bugs. So this is why IPv6 only bearer is so appealing, because it's been around for 5-10 years and very few things break with it. > I've not visited every country in the world, but I have been around a > bit, and I've made a point out of trying to establish an IPv6 data > bearer to every single PLMN I can register with. So far I've had 100% > success, including on Cameron's network... Thus enabling IPv6 roaming > doesn't seem like a scary proposition to me. I'm guessing perhaps > Telenor came to the same conclusion. The scary part isn't enabling IPv6, it's enabling IPv4v6 or capability to do so. When advertised as capability to visiting SGSN it might refuse to bring up any bearer at all. So this is why the draft suggests it might be a good idea to not advertise this to roaming partners. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 6 00: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 A7B891B2CAD for ; Wed, 6 Aug 2014 00:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCEWjuDvhTfZ for ; Wed, 6 Aug 2014 00:20:30 -0700 (PDT) Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id 1D8571B2CAC for ; Wed, 6 Aug 2014 00:20:29 -0700 (PDT) Received: (qmail 62152 messnum 326814 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 07:20:28 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail19.svc.cra.dublin.eircom.net (qp 62152) with SMTP; 6 Aug 2014 07:20:28 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bKLR1o0020mJ9Tz01KLUbg; Wed, 06 Aug 2014 08:20:28 +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: <53E1C587.4000506@fud.no> Date: Wed, 6 Aug 2014 08:20:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EC4EB99-F877-478D-BFE6-959F58127579@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1SvyoSyLNb-Ke3mOvu69dtqEGQQ Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 07:20:32 -0000 On 6 Aug 2014, at 07:04, Tore Anderson wrote: >> What=92s your position on NAPT44 being put in front of an IP service=20= >> address pool that used RFC1918 space? Not advocating for that but it >> would inevitably be tried. >=20 > I find this undesirable for several reasons. =46rom the top of my = head: > For me, deploying NAPT44 seems like a terribly shortsighted effort = that > comes with a number of undesirable technical limitations. At best it > would be akin to treading water; I'd much rather be swimming for = shore. >=20 > All of that said, YMMV; if you or anyone else use NAPT44 in your data > centres, and are happy with it, then that's great, I have no > philosophical/"religious" objections to that. I just need an = alternative > for myself, and preferably make it into one that others could use too, > if they are in a situation similar to mine. Good, glad that you cleared that up. Include them in the next revision = of your draft? =20 FWIW I can see this stateless approach being useful to people that have = chosen=20 to make their DCs IPv6 only but still need to let the IPv4 Internet = connect to public facing servers in it.=20 Ross From nobody Wed Aug 6 00:30: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 878901B28F5 for ; Wed, 6 Aug 2014 00:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYkYC24LiLjv for ; Wed, 6 Aug 2014 00:30:44 -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 E71A91B28F4 for ; Wed, 6 Aug 2014 00:30:43 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=38484 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 1XEvgH-0006wr-SY; Wed, 06 Aug 2014 09:30:41 +0200 Message-ID: <53E1D951.8030200@fud.no> Date: Wed, 06 Aug 2014 09:29:21 +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: Mikael Abrahamsson References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hUIZHga-C-AbgYaUCCFvhxmjLwA Cc: IPv6 Ops WG Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 07:30:45 -0000 (Changing the subject like Ross did.) * Mikael Abrahamsson > I've heard reports of platforms in use in southeast asia, I don't > remember if it was Korea or some other country, would fail when > presented with IPv4v6 capability. > > The reason why people are not going for IPv4v6 externally is because it > breaks things, badly, it seems, due to bugs. So this is why IPv6 only > bearer is so appealing, because it's been around for 5-10 years and very > few things break with it. Yep, and to be clear, Telenor Norway does not support the IPv4v6 on their IPv6-capable APN (nor does Tele2/Network Norway). Furthermore, Telenor only supports IPv6 (not IPv4), while Tele2/NwN supports both IPv6 and IPv4. Which leads me to a point I forgot to mention before, if Telenor had used Roaming Protocol = IPv4 as Ross suggested, or if the phone RIL did a similar fallback, it would actually ascertain failure, since the APN doesn't allow IPv4. If IPv6 fails, one would have to change to one of the IPv4-only APNs. > The scary part isn't enabling IPv6, it's enabling IPv4v6 or capability > to do so. When advertised as capability to visiting SGSN it might refuse > to bring up any bearer at all. So this is why the draft suggests it > might be a good idea to not advertise this to roaming partners. Yes, the -02 draft makes it much clearer than previous versions that this concern is applicable specifically for IPv4v6 and not for IPv6. In spite of this I see that some providers that are using IPv6 and home routing chose to set the Roaming Protocol to IPv4. This is what I don't quite understand the reason for. Perhaps due to a misunderstanding that the problems IPv4v6 also apply for IPv6, or some other problem I have yet to come across? I don't really know much about what's going on "under the hood" in mobile networks to be honest, but with my "dumb user" hat on I can conclude that IPv6 roaming seems to work just fine with the way Telenor and Tele2/NwN have implemented it. So I'm happy. :-) Tore From nobody Wed Aug 6 00:48: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 BC3D11B2CBF for ; Wed, 6 Aug 2014 00:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIATHNZxunSI for ; Wed, 6 Aug 2014 00:48:06 -0700 (PDT) Received: from mail14.svc.cra.dublin.eircom.net (mail14.svc.cra.dublin.eircom.net [159.134.118.30]) by ietfa.amsl.com (Postfix) with SMTP id 3A8C71B2CBC for ; Wed, 6 Aug 2014 00:48:06 -0700 (PDT) Received: (qmail 61159 messnum 2216682 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 07:48:04 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail14.svc.cra.dublin.eircom.net (qp 61159) with SMTP; 6 Aug 2014 07:48:04 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bKo01o01o0mJ9Tz01Ko4on; Wed, 06 Aug 2014 08:48:04 +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: Wed, 6 Aug 2014 08:47:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V5n8EhiZ-SYbvzDSeDdd7TfZMHk Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4v6 roaming X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 07:48:07 -0000 Subject line updated. On 6 Aug 2014, at 07:59, Mikael Abrahamsson wrote: > The scary part isn't enabling IPv6, it's enabling IPv4v6 or capability = to do so. When advertised as capability to visiting SGSN it might refuse = to bring up any bearer at all. So this is why the draft suggests it = might be a good idea to not advertise this to roaming partners. AFAIK the reports of problems that I assume the roaming-analysis draft = came out of are a couple of years old. It would be nice to have fresh measurements of how bad the problem is = now. If an operator with lots of roamers in the areas previously seen = affected to turn it on again for 15 minutes and see what happens. I contacted the vendor I heard mentioned. They said they weren=92t the = only one but that the problem dated from 2008 code which has long since = been patched. Ross From nobody Wed Aug 6 01:34: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 95DDB1B295A for ; Wed, 6 Aug 2014 01:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk2tGrz6jH38 for ; Wed, 6 Aug 2014 01:34:15 -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 174341B2928 for ; Wed, 6 Aug 2014 01:34:14 -0700 (PDT) Received: (qmail 10997 messnum 1891565 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 08:34:13 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail12.svc.cra.dublin.eircom.net (qp 10997) with SMTP; 6 Aug 2014 08:34:13 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bLaA1o0020mJ9Tz01LaDiv; Wed, 06 Aug 2014 09:34:13 +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: <53E1D951.8030200@fud.no> Date: Wed, 6 Aug 2014 09:34:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6CC50159-DCF7-441F-AB57-68EF34651D45@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pNTrNT_z5dcMzRH_EdrSIlM0OMM Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 08:34:16 -0000 On 6 Aug 2014, at 08:29, Tore Anderson wrote: > Furthermore, Telenor only supports IPv6 (not IPv4), while Tele2/NwN = supports both > IPv6 and IPv4. If it is a new IPv6 only APN, without the HLR/HSS settings to allow = fallback and they=92ve bilaterally confirmed with all their roaming = partners that IPv6 is allowed out it is more understandable. But I=92m = not sure that is what this is. =20 > In spite of this I see that some providers that are using IPv6 and = home > routing chose to set the Roaming Protocol to IPv4. This is what I = don't > quite understand the reason for. Perhaps due to a misunderstanding = that > the problems IPv4v6 also apply for IPv6, or some other problem I have > yet to come across? The two issues that I keep seeing mentioned are: The SGSN/MME has to = allow IPv6 in the user plane for visitors.=20 It isn=92t certain that it will. The CDR mediation system has to be not = fall over when it sees a 128-bit IPv6 address.=20 I haven=92t heard of anyone doing anything with the addresses in CDRs. = AFAIK they are usually (always?)=20 discarded by the mediation system. Regards, Ross From nobody Wed Aug 6 02:09: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 9D8841B2CE4 for ; Wed, 6 Aug 2014 02:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwFTNzCzi8LI for ; Wed, 6 Aug 2014 02:09:43 -0700 (PDT) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by ietfa.amsl.com (Postfix) with SMTP id 827EA1B292D for ; Wed, 6 Aug 2014 02:09:42 -0700 (PDT) Received: (qmail 78617 messnum 3253530 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 09:09:40 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail04.svc.cra.dublin.eircom.net (qp 78617) with SMTP; 6 Aug 2014 09:09:40 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bM9c1o00z0mJ9Tz01M9gmP; Wed, 06 Aug 2014 10:09:40 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_CFA3E79A-89A9-41B2-A396-9AD6EB720050" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Wed, 6 Aug 2014 10:09:35 +0100 Message-Id: References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/k63d3jPSI8bt5DIbrUnSw-MqQ90 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 09:09:44 -0000 --Apple-Mail=_CFA3E79A-89A9-41B2-A396-9AD6EB720050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 5 Aug 2014, at 16:53, Heatley, Nick wrote: > >So there=92s an argument to remove =93dual-stack deployment is = recommended in most cases=94 from this draft, particularly if it has = already been discussed and agreed not to promote any solution. > =20 > Agree. > =20 > Also the standards statement: > "A UE which is IPv6 and IPv4 capable shall request for PDN type = IPv4v6". > does not mean that the UE is placed into a dual stack mode of = operation. It is signalling to the network that it can support all = modes. > (We desire the UE to request IPv4v6 in the home network and we can let = the core network push the UE to IPv6-only mode of operation. > When on legacy small-cells, where the access-points do not support the = new PDN types, the device can gracefully fallback to IPv4, if it = requests IPv4v6.) > Nick Proposed update=20 4. Failure Case in Attachment Stage 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request both IPv4 and IPv6 within a single PDP/PDN request. is changed to 4. Failure Case in Attachment Stage 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE indicate = its capability to support dual-stack, both IPv4 and IPv6 with a single = or separate PDP/PDN connections. BR Ross= --Apple-Mail=_CFA3E79A-89A9-41B2-A396-9AD6EB720050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 5 Aug 2014, at 16:53, Heatley, Nick = <nick.heatley@ee.co.uk>= wrote:

>So there=92s an argument to = remove =93dual-stack deployment is recommended in most = cases=94 from this draft, particularly if it has already been discussed = and agreed not to promote any solution.
 
Agree.
 
Also the standards = statement:
"A UE = which is IPv6 and IPv4 capable shall request for PDN type IPv4v6".
does not mean that the UE is placed into a dual stack = mode of operation. It is signalling to the network that it can support = all modes.
(We desire the UE to request IPv4v6 in the home = network and we can let the core network push the UE to IPv6-only mode of = operation.
When on legacy small-cells, where the access-points = do not support the new PDN types, the device can gracefully fallback to = IPv4, if it requests IPv4v6.)
Nick

Proposed = update 


4.  =
Failure Case in Attachment Stage


   3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request
   both IPv4 and IPv6 within a single PDP/PDN request.


is changed to


4.  =
Failure Case in Attachment Stage


   3GPP specified PDP/PDN type IPv4v6 in order to allow a UE indicate =
its capability to support dual-stack, =
both IPv4 and IPv6 with a single or separate PDP/PDN =
connections.


BR
= Ross
= --Apple-Mail=_CFA3E79A-89A9-41B2-A396-9AD6EB720050-- From nobody Wed Aug 6 03:08: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 67ED51B2D02 for ; Wed, 6 Aug 2014 03:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-eZChU-ws91 for ; Wed, 6 Aug 2014 03:07:58 -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 E7EFC1B2CFE for ; Wed, 6 Aug 2014 03:07:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XEy8M-0000AXC; Wed, 6 Aug 2014 12:07:50 +0200 Message-Id: To: Tore Anderson From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> In-reply-to: Your message of "Wed, 06 Aug 2014 08:04:55 +0200 ." <53E1C587.4000506@fud.no> Date: Wed, 06 Aug 2014 12:07:45 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5Be8JmaXT6Up0ho_eBsDr-tK7BI Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 10:08:00 -0000 In your letter dated Wed, 06 Aug 2014 08:04:55 +0200 you wrote: >* Ross Chandler > >> What=92s your position on NAPT44 being put in front of an IP service = > >> address pool that used RFC1918 space? Not advocating for that but it >> would inevitably be tried. > >I find this undesirable for several reasons. From the top of my head: > >1) The NAPT44 device needs to maintain per-flow state for each flow. >This creates some new undesirable scaling properties, in particular >limitations on concurrent flow count and and flow initiation rate which >generally are reached long before the available interface bandwidth is >exhausted. This in turn typically makes such boxes be the first thing to >stop working under DDoS attacks, as the flow table gets filled up with >junk flow entries, and/or that new flow entries cannot be added to the >table fast enough. As far as I can tell, your proposal maps every public IPv4 address to a unique IPv6 address. In that context, why not just use, for example, host routes to route IPv4 traffic to the right interface of an IPv4 host. No need for any kind of NAT, translation or anything. I.e. in the situaiton you describe there are enough addresses that there is no need for NAT. From nobody Wed Aug 6 03:42: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 C9ED41B2923 for ; Wed, 6 Aug 2014 03:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKPtczw9IVYv for ; Wed, 6 Aug 2014 03:42:49 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445201B292E for ; Wed, 6 Aug 2014 03:42:46 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so2452916qgf.31 for ; Wed, 06 Aug 2014 03:42:45 -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=QM0Xg2zPlajZ4BOiaXEwL4Khq75TsNb0LVtml0Kb+hs=; b=V/OgTcO8UHDX3tPsEqvHrH0Iow2hymq36dD4EDjouWgIbI3/7Ke59Q0mqFt5zCXP9Z 9zDPcFQjyzFSfZnY+fkfNVNOIha2GJ0wYTBxPu514q6qtTj8kly4EIfJXR0faHiV6iFx BDN3KLc5cdPCx3DjYke4rY7FiJ8DK1Mt4rh1PA4JZu4mIqrHAaUe7t6e5YO/6M2Vp1tJ 2aoHSp/bpE6DYhgFFlAga6n9m5JWCk3swrNktey7ZEIL0674OuABO10NxsAh4wmn1/Qp 9sJgOJv+17o5NGmpHIK6t1ty8mrZs2wDYGBN37kzyelNsXpi5CkiXtrPRWaGAE/qjNSa TmCg== MIME-Version: 1.0 X-Received: by 10.224.119.193 with SMTP id a1mr15715484qar.18.1407321765331; Wed, 06 Aug 2014 03:42:45 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Wed, 6 Aug 2014 03:42:45 -0700 (PDT) In-Reply-To: <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Wed, 6 Aug 2014 18:42:45 +0800 Message-ID: From: GangChen To: "Heatley, Nick" , Ross Chandler Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JqMhk5Ro0rwhEkEUWyJ3NfGUFBQ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 10:42:50 -0000 Ross and Nick, The draft doesn't intend to advocate any deployment mode. To be clear, "dual-stack deployment is recommended in most cases" will be removed at the next update. Gang 2014-08-05 23:53 GMT+08:00, Heatley, Nick : >>So there's an argument to remove "dual-stack deployment is recommended in >> most cases" from this draft, particularly if it has already been discussed >> and agreed not to promote any solution. > > Agree. > > Also the standards statement: > "A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". > does not mean that the UE is placed into a dual stack mode of operation. It > is signalling to the network that it can support all modes. > (We desire the UE to request IPv4v6 in the home network and we can let the > core network push the UE to IPv6-only mode of operation. > When on legacy small-cells, where the access-points do not support the new > PDN types, the device can gracefully fallback to IPv4, if it requests > IPv4v6.) > Nick > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ross Chandler > Sent: 05 August 2014 12:33 > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-ipv6-roaming-analysis-02.txt > > > On 5 Aug 2014, at 11:53, Jouni > > wrote: > > > > On Aug 5, 2014, at 1:28 PM, GangChen wrote: > > > 2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson > >: > > > Section 7, discussions, says "dual-stack deployment is recommended in > most cases". > Is that still the consensus position? Going straight to single-stack IPv6 > is looking very viable now > when the UE supports a method of providing translated IPv4 access over the > IPv6 PDP/PDN > connection. > > I don't think there is consensus here. The draft could point out pros and > cons with each approach. > > I'm not a fan of dual-stack deployment. However, I have to point out > if you take look at TS23.060 or TS23.401, you may find the sentence "A > UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". > GSMA quotes the similar language from 3GPP for roaming guidance. > Therefore, that is at least a consensus in other SDOs. > > The draft intends to state the issues and potential workarounds in > various scenarios. Argument of selection of dual-stack or IPv6-only > may not be the goal of the draft. > > We had this discussion a long ago.. and back then we agreed not to promote > any specific solution (like XLAT etc) but just give facts how different > approaches work. > > - Jouni > > > The TS23.975 recommendations do allow for a second strategy. I can't find > TS23.975 explicitly saying dual-stack is preferred or recommended over > single stack. > Although at the time they were writing it they were probably implicitly > assuming that. TS23.975 mentions DS-Lite, NAT64 and BIH but was too early > for 464XLAT, or MAP-T/E. > > "The second strategy, consisting of providing the UE with IPv6-only > connectivity, can be considered as a first stage or an ultimate target > scenario for operators." > > So there's an argument to remove "dual-stack deployment is recommended in > most cases" from this draft, particularly if it has already been discussed > and agreed not to promote any solution. > > BR > Ross > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or use > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachments > are free from any virus, but it remains your responsibility to ensure that > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > From nobody Wed Aug 6 03:52: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 70FF11B293E for ; Wed, 6 Aug 2014 03:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGgfZGAxrQdd for ; Wed, 6 Aug 2014 03:51:56 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BD61B290E for ; Wed, 6 Aug 2014 03:51:55 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=45056 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 1XEyp0-0002xc-Hx; Wed, 06 Aug 2014 12:51:54 +0200 Message-ID: <53E20879.4020509@fud.no> Date: Wed, 06 Aug 2014 12:50:33 +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: Philip Homburg References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4ZvjKDS8amuY_4Abo3DuGFH2EYY Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 10:51:58 -0000 * Philip Homburg > As far as I can tell, your proposal maps every public IPv4 address to a > unique IPv6 address. Correct. > In that context, why not just use, for example, host routes to route IPv4 > traffic to the right interface of an IPv4 host. That would work, but there's a few reasons why I don't consider that optimal either: - It would not help me with IPv6 deployment at all, it distracts me from it. Having a fully IPv6-enabled infrastructure is the goal I want to be moving towards. SIIT-DC, like MAP and DS-Lite, *requires* IPv6. - I'd still need to maintain IPv4 throughout my infrastructure. If I'm also doing IPv6 at the same time, this means I incur extra operational overhead and cost compared to single stack - "dual everything", as Gert said. - There would be no way to aggregate all the host routes, it would severely pollute my IGP as every single /32 route must be distributed throughout my network. SIIT-DC, on the other hand, requires no host routes, as IPv4 traffic will be typically be translated to the server's primary IPv6 address, creating no extra IGP routes beyond the /64 or whatever that's routed to the LAN segment anyway. - You get interesting routing challenges if the servers need occasional Internet access through a stateful NAT (e.g., to download software updates). You'll want to route the traffic sourced from the public address directly out to the Internet, while traffic from RFC1918 sources needs to be routed through the NAT instance. But both the NAT and no-NAT route must necessarily be represented as an IPv4 default route. I'm sure this could be solved with the use of PBR and/or VRFs, but that incurs extra complexity. An SIIT gateway is on the other hand reached with a normal /96 route, and does not need to interfere with default routing at all. Same goes for a NAT64 instance that could be used for occasional Internet access analogous to the above. - You'll actually need special configuration on the servers, setting up and monitoring a secondary service address. With SIIT-DC, there is no need to touch the servers at all, except in the case where a host agent is needed to facilitate applications that do not support NAT and/or IPv6. - The host routes would need to be installed on each the upstream routers serving as default gateways for the servers' LAN segments, which scatters these assignments all over the place. With SIIT-DC, the SIIT gateways have a complete overview of all configured mappings and what service addresse are available. All in all it feels to me more like a stop-gap solution that only deals with IPv4 depletion, rather than something that also facilitates real progress towards an single-stack IPv6 infrastructure. (BTW: I've made the assumption that you mean that the server's primary IPv4 addresses is a private/RFC1918 one, which is then used as the next-hop for a public /32 assigned to the loopback interface. Let me know if this assumption was incorrect.) Tore From nobody Wed Aug 6 04:14: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 DF61A1A01A8 for ; Wed, 6 Aug 2014 04:14:43 -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 eLXchgwZ07rK for ; Wed, 6 Aug 2014 04:14:42 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCAC1A0AF3 for ; Wed, 6 Aug 2014 04:14:42 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so2452993qgf.6 for ; Wed, 06 Aug 2014 04:14:41 -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=OLH8WXYOZ41sc5diqrNue+NOZiq3GWZVIq8cD1AXA6I=; b=ZLJpFTsgztXq7RqiF5OkIHtvmFueTbET1CV0jyRrxx7DP5D8Gnm0/tCIycGXq/LP3p LYqfsBBwspnwjr8whNVwqYhc9EgRXzeXumbq39k1RzMltCW3aeFFSlDWShWKik4oXMuP opeF2E4nBKeOit5+5P8V/sjQOppGPjJFG9a2VkjUBKo42+OusP1ZmlpWkcrBCMLPKyRI wd8ZCw6LAefWcXYRMW0y2v5fRY5JHEOLpZyMAL2EARkJ9rx7ms5pSIVB6o/dqNxz+2+a Ck6xA1f0hVzFdnv1M5rJoU1OWyUOdyHnrH9iPMrXQk/luVQSxMyb4lJt5JkPQXBykZ1n DiUA== MIME-Version: 1.0 X-Received: by 10.224.123.8 with SMTP id n8mr15714473qar.40.1407323681342; Wed, 06 Aug 2014 04:14:41 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Wed, 6 Aug 2014 04:14:41 -0700 (PDT) In-Reply-To: References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Wed, 6 Aug 2014 19:14:41 +0800 Message-ID: From: GangChen To: Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Bmu9fDmdM1JJiCoqR3cxfYfd5zE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 11:14:44 -0000 2014-08-06 17:09 GMT+08:00, Ross Chandler : > > On 5 Aug 2014, at 16:53, Heatley, Nick wrote: > >> >So there=E2=80=99s an argument to remove =E2=80=9Cdual-stack deployment= is recommended in >> > most cases=E2=80=9D from this draft, particularly if it has already be= en >> > discussed and agreed not to promote any solution. >> >> Agree. >> >> Also the standards statement: >> "A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6". >> does not mean that the UE is placed into a dual stack mode of operation. >> It is signalling to the network that it can support all modes. >> (We desire the UE to request IPv4v6 in the home network and we can let t= he >> core network push the UE to IPv6-only mode of operation. >> When on legacy small-cells, where the access-points do not support the n= ew >> PDN types, the device can gracefully fallback to IPv4, if it requests >> IPv4v6.) >> Nick > > Proposed update > > > 4. Failure Case in Attachment Stage > > 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request > both IPv4 and IPv6 within a single PDP/PDN request. > > > is changed to > > > 4. Failure Case in Attachment Stage > > 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE indicate its > capability to support dual-stack, both IPv4 and IPv6 with a single or > separate PDP/PDN connections. It may could say "PDP/PDN type IPv4v6 implicitly allow network to assign IPv4-only, IPv6-only, IPv4+IPv6 in single PDP/PDN bearer, IPv4+IPv6 in separated PDP/PDN bearers." However, I don't think that is the purpose of introducing IPv4v6 PDP/PDN. The essential of IPv4v6 is to allow UE get IPv4 and IPv6 on a single bearer so as to reduce network costs. RFC6459 also has similar description, i.e. This enables parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6)" Gang > > BR > Ross From nobody Wed Aug 6 04:51: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 53B181A0033 for ; Wed, 6 Aug 2014 04:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EHcM42E6QC2 for ; Wed, 6 Aug 2014 04:51:01 -0700 (PDT) Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id B9D251A0022 for ; Wed, 6 Aug 2014 04:51:00 -0700 (PDT) Received: (qmail 96157 messnum 12472217 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 11:50:58 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail06.svc.cra.dublin.eircom.net (qp 96157) with SMTP; 6 Aug 2014 11:50:58 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bPqu1o0350mJ9Tz01PqyNS; Wed, 06 Aug 2014 12:50:58 +0100 From: Ross Chandler Content-Type: multipart/alternative; boundary="Apple-Mail=_363AA6D0-7066-475F-9EB4-26110600162C" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 6 Aug 2014 12:50:53 +0100 References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> To: GangChen , IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FP6nlTW-RfWtsMAaUyj1N5JhqjE Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 11:51:03 -0000 --Apple-Mail=_363AA6D0-7066-475F-9EB4-26110600162C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 6 Aug 2014, at 12:14, GangChen wrote: >>>=20 >>=20 >> Proposed update >>=20 >>=20 >> 4. Failure Case in Attachment Stage >>=20 >> 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request >> both IPv4 and IPv6 within a single PDP/PDN request. >>=20 >>=20 >> is changed to >>=20 >>=20 >> 4. Failure Case in Attachment Stage >>=20 >> 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE indicate = its >> capability to support dual-stack, both IPv4 and IPv6 with a single or >> separate PDP/PDN connections. >=20 Gang, Shouldn=92t the draft make both points. It is a capability indication (or otherwise expressed as implicit = allow) from the UE that it can > " allow network to > assign IPv4-only, IPv6-only, IPv4+IPv6 in single PDP/PDN bearer, > IPv4+IPv6 in separated PDP/PDN bearers.=94 And this point. > However, I don't think that > is the purpose of introducing IPv4v6 PDP/PDN. The essential of IPv4v6 > is to allow UE get IPv4 and IPv6 on a single bearer so as to reduce > network costs. RFC6459 also has similar description, i.e. This enables > parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6)=94 BR=20 Ross= --Apple-Mail=_363AA6D0-7066-475F-9EB4-26110600162C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 6 Aug 2014, at 12:14, GangChen = <phdgang@gmail.com> = wrote:


Proposed update


4. =  Failure Case in Attachment Stage

  3GPP specified = PDP/PDN type IPv4v6 in order to allow a UE request
  both = IPv4 and IPv6 within a single PDP/PDN request.


is changed = to


4.  Failure Case in Attachment = Stage

  3GPP specified PDP/PDN type IPv4v6 in order to = allow a UE indicate its
capability to support dual-stack, both IPv4 = and IPv6 with a single or
separate PDP/PDN = connections.


Gang,

Shouldn=92t the draft make both = points.

 It is a capability indication (or = otherwise expressed as implicit allow) from the UE that it = can

" allow network = to
assign IPv4-only, IPv6-only, IPv4+IPv6 in single PDP/PDN = bearer,
IPv4+IPv6 in separated PDP/PDN = bearers.=94

And this = point.

However, I = don't think that
is the purpose of introducing IPv4v6 PDP/PDN. =  The essential of IPv4v6
is to allow UE get IPv4 and IPv6 on a = single bearer so as to reduce
network costs. RFC6459 also has similar = description, i.e. This enables
parallel use of both IPv4 and IPv6 on = a single bearer = (IPv4v6)=94

BR 
Ross
= --Apple-Mail=_363AA6D0-7066-475F-9EB4-26110600162C-- From nobody Wed Aug 6 05:32: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 9E1901B29F4 for ; Wed, 6 Aug 2014 05:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhM4MYG-v316 for ; Wed, 6 Aug 2014 05:32:46 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A798C1A007E for ; Wed, 6 Aug 2014 05:32:46 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E5E0860960 for ; Wed, 6 Aug 2014 14:32:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id ABB246093F for ; Wed, 6 Aug 2014 14:32:43 +0200 (CEST) Received: (qmail 83318 invoked by uid 1007); 6 Aug 2014 14:32:43 +0200 Date: Wed, 6 Aug 2014 14:32:43 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20140806123243.GU51793@Space.Net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/biksKLCdH8JL4NJ4AGX6XEqmq8M Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 12:32:48 -0000 Hi, On Wed, Aug 06, 2014 at 12:07:45PM +0200, Philip Homburg wrote: > As far as I can tell, your proposal maps every public IPv4 address to a > unique IPv6 address. > > In that context, why not just use, for example, host routes to route IPv4 > traffic to the right interface of an IPv4 host. Why do you find it so hard to accept that "dual-stack inside" is not a desirable property? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Aug 6 05:39: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 818EA1B29AF for ; Wed, 6 Aug 2014 05:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNqB51xbxWqE for ; Wed, 6 Aug 2014 05:39:41 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0671B29A5 for ; Wed, 6 Aug 2014 05:39:39 -0700 (PDT) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Tore Anderson , Mikael Abrahamsson Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt Thread-Index: AQHPsUhsF/ChxSljdUaZmsTWKszVy5vDezSw Date: Wed, 6 Aug 2014 12:39:35 +0000 Message-ID: <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> In-Reply-To: <53E1D951.8030200@fud.no> Accept-Language: en-GB, cs-CZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.57.29] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Loop: 2 X-CFilter-Loop: Forwarded Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KPt87Ey9njFdqH2fgm-r91DWKig Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 12:39:43 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore > Anderson > Sent: Wednesday, August 06, 2014 9:29 AM > To: Mikael Abrahamsson > Cc: IPv6 Ops WG > Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming- > analysis-02.txt > Yep, and to be clear, Telenor Norway does not support the > IPv4v6 on their IPv6-capable APN (nor does Tele2/Network > Norway). Furthermore, Telenor only supports IPv6 (not IPv4), > while Tele2/NwN supports both > IPv6 and IPv4. > > Which leads me to a point I forgot to mention before, if > Telenor had used Roaming Protocol =3D IPv4 as Ross suggested, > or if the phone RIL did a similar fallback, it would actually > ascertain failure, since the APN doesn't allow IPv4. If IPv6 > fails, one would have to change to one of the IPv4-only APNs. Tore, Let me try to clarify. The APN settings set at the UE (handset) are telling the UE what to 'request' from the mobile network (e.g. APN name to connect to, PDP type ipv4 or ipv6 or ipv4v6...). The mobile network is than comparing what was 'requested' by the UE/subscriber with subscriber's profile at the HLR/HSS. I can be that the network will allow both IPv4/IPv6, but the UE will be configured to request IPv6 at home and IPv4 while roaming, so it won't break. Some UEs such as Android since some version I cannot recall offer to specify the Home network PDP Type to control what will the UE request while at the Home network and a dedicated PDP Type setting for roaming, so that a different PDP Type can be used if necessary. > Tore Ales Z=E1sady komunikace, kter=E9 spole=E8nost T-Mobile Czech Republic a.s. u=BE= =EDv=E1 p=F8i sjedn=E1v=E1n=ED smluv, jsou uvedeny zde http://www.t-mobile= .cz/zasady. Nen=ED-li v z=E1sad=E1ch uvedeno jinak, nep=F8edstavuje tato zp= r=E1va kone=E8n=FD n=E1vrh na uzav=F8en=ED =E8i zm=ECnu smlouvy ani p=F8ije= t=ED takov=E9ho n=E1vrhu. The communication principles which T-Mobile Czech= Republic a.s. applies when negotiating contracts are defined here http://w= ww.t-mobile.cz/principles. Unless otherwise stated in the principles, this = message does not constitute the final offer to contract or an amendment of = a contract or acceptance of such offer. From nobody Wed Aug 6 05:41: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 4A4621B29C2 for ; Wed, 6 Aug 2014 05:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFz4n1pyTOo0 for ; Wed, 6 Aug 2014 05:41:47 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0507C1B29A5 for ; Wed, 6 Aug 2014 05:41:47 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 96E3060961 for ; Wed, 6 Aug 2014 14:41:45 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 25BE86097A for ; Wed, 6 Aug 2014 14:41:45 +0200 (CEST) Received: (qmail 85156 invoked by uid 1007); 6 Aug 2014 14:41:45 +0200 Date: Wed, 6 Aug 2014 14:41:45 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20140806124145.GV51793@Space.Net> References: <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AQTanNRm4FKPIqNf" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5R5qs3NpVZwFJCQijnAr7yMF9dY Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 12:41:49 -0000 --AQTanNRm4FKPIqNf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 05, 2014 at 11:06:57PM +0200, Philip Homburg wrote: > In your letter dated Tue, 5 Aug 2014 21:54:02 +0200 you wrote: > >On Tue, Aug 05, 2014 at 09:22:10PM +0200, Philip Homburg wrote: > >> The question is then, why not simply run on RFC-1918 addresses interna= lly? > > > >Why have dual everything inside, when single IPv6 is sufficient to=20 > >achieve service delivery? Dual everything is *dual* *work*, translating > >to real money out in the real world. >=20 > I think it is safe to say that providing good IPv4 service is the most > important requirement. In many cases, it is perfectly fine to not provide > any IPv6 if it cannot be provided at reasonable cost / performance. Uh. Welcome to 2014. Please take a look at current internet offerings at mass market are still growing - what you'll see is "native IPv6 plus DS-Lite (or other NAT444) for IPv4". If someone cares about their content, they will aim to avoid the=20 instabilities added by the NAT444 box on the eyeball side. As Lorenzo predicted about 10 years ago. > (note, looking at this from business point of view. Not as somebody who > care about the future of the internet). *Especially* from a business point of view, adding a focus on IPv4 is very short sighted... > So instead of doing a relatively straightforward NAT44 or NAT444 and then > let IPv6 pay for itself, you now make the cost of providing IPv6 part of = the > cost of providing IPv4. =2E.. and a "relatively straightforward NAT44" on the server side *is not*, as soon as you have a data center and traffic of any noticeable volume -=20 see Tore's mail about details why that is almost always undesirable. (You might want to check the amount of money Cisco takes for a 40G-NAT44- Card...) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --AQTanNRm4FKPIqNf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU+IiiN9WwGXkzn/FAQJrRg/+J5PQk50ML5bJuPHMeQvvWd8QKidqyzPJ 5ZZcQrhx8TlboR/OIGUWYI1Fx87kYBiz3+si/FYLONwimQM1yAnFNf6LQjjDHB0Z 8dimQbJB/yJlHQJcsOYqUg06wbeKEnF7mb77clMItBr1rJmJMpoTn9trw6+eXDFp HmpywLrlDU89/dFA9ixGMAU5pWm08eYz3+YwSoKWaLxm4H0CgVK/xZEz22+mKB+P +QXSjduiQBcrIVBIOw+e0MeIIPWjYXkVtpQA1heMXYXIqin2ygM8ftjA6JbGCy+p JzdDwhLLf/4zKgver8I7D1yCBZZR46AiFtotk8uGwhdCiJ135fLNpVAfvL1UzHn0 iAJjBD9t7irG/jF3oKDB+RwAVvlj6vQ23O8svf7Q7qYi2Bb7ImHR9P7NrzNNcuH3 kyf0bBuOGQgLigNUvPo/hQgZsl/qZo7A1nAOoqTcKZRjVlSmP3ZNO7XRrPMWr+V8 bYXWbM8JEgiBzPrSybJmAzzWyurPyfO9V/0TAUHTcP3cMEfn2gKB3iu5Qs/UyhPz +Fa6CET4H6mPJOo83udPolbfsm+w8jTseVpi78320AI+uKpWRkVfmCiODLODYw4l XTGHJFtIDXZg4tqCsfr+FjI6387qVAFYZoWkkLbdE0+77ERLcBWSne2SivUaYL0S ggVlSckuiho= =5/9q -----END PGP SIGNATURE----- --AQTanNRm4FKPIqNf-- From nobody Wed Aug 6 06:18: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 D08881B2D2F; Wed, 6 Aug 2014 06:18:22 -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 tVyejYA7BfAF; Wed, 6 Aug 2014 06:18:20 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BA01B2D2D; Wed, 6 Aug 2014 06:18:20 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so2584787qgd.23 for ; Wed, 06 Aug 2014 06:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=BwG9skkJXMqHqTnmo6hZUyuPSH3LjVfQB36zKgWGqAU=; b=zkU7nT3AUimNP/YQEIz3rXScYTyUdt+gMG44vRTEkon7Gj57OGa8TsQsvOH0lBQ8HL BLgO5eQS/PN1BhvXycgkN+aMyWJ5X0j7tscJJDi6MjtMMpK596j+trPXrIfCqm9TCCg+ rlY/G+iE3kVg6UeaaCU6Q6Z1+STPVQs7S+fu9ePcV7jtxl/jhQI942RZu8ezqmFg+NYr cd2i3vJgHF6tC1GCBS5kf35ubaxHGP2mddpxqBIgur2E5eElE/qvDkoMlu+KpWvuxsUZ 06L+JzK7vOuS0Igxou7LPiaG5J5f7krdWAHdtiDOsUpYiac9G8g/Z/FPmEbVgvdnh4UG 1OfQ== X-Received: by 10.224.67.2 with SMTP id p2mr16865407qai.37.1407331099671; Wed, 06 Aug 2014 06:18:19 -0700 (PDT) Received: from [10.30.20.8] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id m42sm979341qga.21.2014.08.06.06.18.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 06:18:19 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Aug 2014 09:18:19 -0400 Message-Id: <2678F1EB-D3D1-4CD8-B243-F500F474E61F@gmail.com> To: opsec@ietf.org, v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZmQ9U_5SPwkIFjvhgHhZ1DK1KW0 Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 13:18:23 -0000 Earlier, on 18th July 2014, Warren Kumari wrote: > Related to this is >=20 > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 > -- Why > Operators Filter Fragments and What It Implies >=20 > This expired, but I suspect we may need to revive it... >=20 > W (ASIDE: I've trimmed off the int-area list to reduce list cross-posting. My sense is that between v6ops and opsec,=20 the applicable audience will be covered adequately.) I agree that the above draft ought to be revived. As a community, it would be very helpful to have an Informational status RFC describing "Why Operators Filter Fragments and What it Implies". =46rom my point of view, this need not be an IETF-track document. It would serve the purpose equally well as an ISE-track document with Informational status. =20 (Just to be clear, I don't object to it being IETF-track, but the ISE-track has a faster time-to-RFC and generally is a lower-overhead process.) Yours, Ran Atkinson From nobody Wed Aug 6 07:44: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 086AF1B2A3E for ; Wed, 6 Aug 2014 07:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEvyBnJ-JqJe for ; Wed, 6 Aug 2014 07:44:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE71B27F8 for ; Wed, 6 Aug 2014 07:44:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XF2Rg-0000BRC; Wed, 6 Aug 2014 16:44:04 +0200 Message-Id: To: Gert Doering From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <20140806123243.GU51793@Space.Net> In-reply-to: Your message of "Wed, 6 Aug 2014 14:32:43 +0200 ." <20140806123243.GU51793@Space.Net> Date: Wed, 06 Aug 2014 16:44:03 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MiUZBOBWu7OXzlZqB7gQ17k9UX0 Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:44:10 -0000 In your letter dated Wed, 6 Aug 2014 14:32:43 +0200 you wrote: >Why do you find it so hard to accept that "dual-stack inside" is not >a desirable property? I find that very easy to accept. Except that from my point of view the proposals presented to avoid dual stack are worse. The way I see it, translating IPv4 into IPv6 is just going to bite you. Now, tunneling IPv4 over IPv6 may work, if the tunneling is local and if the tunnel preserves a 1500 octet MTU for IPv4. At the end of the day, all externally visible stuff still has to have IPv4. That is dual stack, no matter how you slice it. From nobody Wed Aug 6 07:54: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 77FCC1B2A4A for ; Wed, 6 Aug 2014 07:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU4zl-exwN5r for ; Wed, 6 Aug 2014 07:54:00 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8551B2D61 for ; Wed, 6 Aug 2014 07:53:47 -0700 (PDT) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Philip Homburg , Gert Doering Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsYTdKp4cYlfWs0iK+WcgE96R8pvDqCcQ Date: Wed, 6 Aug 2014 14:53:44 +0000 Message-ID: <9d8382d1b10f482f81fd26c6e31e602d@srvhk403.rdm.cz> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <20140806123243.GU51793@Space.Net> In-Reply-To: Accept-Language: en-GB, cs-CZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.57.29] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Loop: 2 X-CFilter-Loop: Forwarded Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nxU8KIlSX1p1VEe-tcbG1qQCCaw Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:54:03 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > Philip Homburg > Sent: Wednesday, August 06, 2014 4:44 PM > To: Gert Doering > Cc: IPv6 Ops WG; Tore Anderson > Subject: Re: [v6ops] Operational Consensus on deployment > > In your letter dated Wed, 6 Aug 2014 14:32:43 +0200 you > wrote: > >Why do you find it so hard to accept that "dual-stack > inside" is not a > >desirable property? > > I find that very easy to accept. Except that from my point of > view the proposals presented to avoid dual stack are worse. > > The way I see it, translating IPv4 into IPv6 is just going to > bite you. > > Now, tunneling IPv4 over IPv6 may work, if the tunneling is > local and if the tunnel preserves a 1500 octet MTU for IPv4. I guess you're talking about a softwire, so let me cite RFC5565: Transmitting a packet through a softwire always requires that an encapsulation header be added to the original packet. The resulting packet is therefore always longer than the encapsulation payload. As an operational matter, the Maximum Transmission Unit (MTU) of the softwire's path SHOULD be large enough so that (a) no packet will need to be fragmented before being encapsulated, and (b) no encapsulated packet will need to be fragmented while it is being forwarded along a softwire. A general discussion of MTU issues in the context of tunneled forwarding may be found in [RFC4459]. > At the end of the day, all externally visible stuff still has > to have IPv4. > That is dual stack, no matter how you slice it. I think that Tore's work is showing that there are alternatives to dual-sta= ck. Ales Z=E1sady komunikace, kter=E9 spole=E8nost T-Mobile Czech Republic a.s. u=BE= =EDv=E1 p=F8i sjedn=E1v=E1n=ED smluv, jsou uvedeny zde http://www.t-mobile= .cz/zasady. Nen=ED-li v z=E1sad=E1ch uvedeno jinak, nep=F8edstavuje tato zp= r=E1va kone=E8n=FD n=E1vrh na uzav=F8en=ED =E8i zm=ECnu smlouvy ani p=F8ije= t=ED takov=E9ho n=E1vrhu. The communication principles which T-Mobile Czech= Republic a.s. applies when negotiating contracts are defined here http://w= ww.t-mobile.cz/principles. Unless otherwise stated in the principles, this = message does not constitute the final offer to contract or an amendment of = a contract or acceptance of such offer. From nobody Wed Aug 6 11:34: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 BE20B1ABD18 for ; Wed, 6 Aug 2014 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-VTJA5D8cAx for ; Wed, 6 Aug 2014 11:34:14 -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 38EBF1ACAD6 for ; Wed, 6 Aug 2014 11:34:14 -0700 (PDT) Received: from cm-84.209.85.233.getinternet.no ([84.209.85.233]:33511 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XF62N-0004ME-7c; Wed, 06 Aug 2014 20:34:11 +0200 Message-ID: <53E27522.4070901@fud.no> Date: Wed, 06 Aug 2014 20:34:10 +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: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , Mikael Abrahamsson References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> In-Reply-To: <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bzi-x8aRRgc_ybiBCrhaJBgApqE Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 18:34:15 -0000 * Vízdal Aleą > The APN settings set at the UE (handset) are telling the UE > what to 'request' from the mobile network (e.g. APN name to > connect to, PDP type ipv4 or ipv6 or ipv4v6...). The mobile > network is than comparing what was 'requested' by the UE/subscriber > with subscriber's profile at the HLR/HSS. I can be that the > network will allow both IPv4/IPv6, but the UE will be configured > to request IPv6 at home and IPv4 while roaming, so it won't break. > > Some UEs such as Android since some version I cannot recall > offer to specify the Home network PDP Type to control what > will the UE request while at the Home network and a dedicated > PDP Type setting for roaming, so that a different PDP Type > can be used if necessary. Yes, I think I've understood this part. My point is that since Telenor's APN does not support the IPv4 PDP type, then it won't work to use IPv4 as the Roaming PDP type, as was suggested earlier in the thread. (Nor as the Home PDP type, for that matter.) So the only sensible setting in this case would be to use PDP type IPv6 for both the Roaming and Home PDP type settings. If on the other hand the APN supports both IPv4 and IPv6 (like Tele2/NwN's does), then that is a different story, and having the UE use IPv4 when roaming makes sense (if the roaming partners break IPv6 for some reason). At least that's how I understand it... Tore From nobody Wed Aug 6 11:56: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 72FB61A008E for ; Wed, 6 Aug 2014 11:56:33 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0Lgg-0hpzcx for ; Wed, 6 Aug 2014 11:56:31 -0700 (PDT) Received: from mail14.svc.cra.dublin.eircom.net (mail14.svc.cra.dublin.eircom.net [159.134.118.30]) by ietfa.amsl.com (Postfix) with SMTP id EA45D1A003A for ; Wed, 6 Aug 2014 11:56:30 -0700 (PDT) Received: (qmail 89793 messnum 2097245 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 18:56:30 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail14.svc.cra.dublin.eircom.net (qp 89793) with SMTP; 6 Aug 2014 18:56:30 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bWwS1o00Y0mJ9Tz01WwVhq; Wed, 06 Aug 2014 19:56:29 +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: <53E13A3B.4050303@fud.no> Date: Wed, 6 Aug 2014 19:55:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <27E6D704-7BDB-49A4-81F7-9A046527BC4F@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <53E13A3B.4050303@fud.no> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tEPjD0EEIWRzFscv1EQERHIIJHE Cc: Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 18:56:33 -0000 On 5 Aug 2014, at 21:10, Tore Anderson wrote: > I would generally recommend locating the SIIT gateways as close to the > edge of your network as possible. Ideally as a logical function = located > inside the border routers. That way, on the inside you can simply = treat > everything as IPv6, and have one IPv6 firewall, one IPv6 ACL, one IPv6 > IGP topology, and so on, and so on. Another reason why the firewall should normally be on the IPv6 side is = that asymmetric traffic might be flowing through the stateless SIIT = gateway. Assuming that there=92s more than one of them in different = parts of the network. Ross From nobody Wed Aug 6 12:46: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 CFEB81B27EB for ; Wed, 6 Aug 2014 12:46:14 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s36sEb5ahKPG for ; Wed, 6 Aug 2014 12:46:10 -0700 (PDT) Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by ietfa.amsl.com (Postfix) with SMTP id 5846B1A0115 for ; Wed, 6 Aug 2014 12:46:09 -0700 (PDT) Received: (qmail 95535 messnum 9964132 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 19:46:08 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail07.svc.cra.dublin.eircom.net (qp 95535) with SMTP; 6 Aug 2014 19:46:08 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bXm51o00E0mJ9Tz01Xm8WC; Wed, 06 Aug 2014 20:46:08 +0100 Content-Type: text/plain; charset=windows-1250 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: <53E27522.4070901@fud.no> Date: Wed, 6 Aug 2014 20:46:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3BV5gg8CM05QPtrQkpopQjsVc-A Cc: Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 19:46:15 -0000 On 6 Aug 2014, at 19:34, Tore Anderson wrote: > Yes, I think I've understood this part. My point is that since = Telenor's > APN does not support the IPv4 PDP type, then it won't work to use IPv4 > as the Roaming PDP type, as was suggested earlier in the thread. (Nor = as > the Home PDP type, for that matter.) So the only sensible setting in > this case would be to use PDP type IPv6 for both the Roaming and Home > PDP type settings. >=20 > If on the other hand the APN supports both IPv4 and IPv6 (like > Tele2/NwN's does), then that is a different story, and having the UE = use > IPv4 when roaming makes sense (if the roaming partners break IPv6 for > some reason). >=20 > At least that=92s how I understand it... It might be that when the UE visits a network that doesn=92t allow IPv6 = in the user-plane Android behaviour is kicking in. I=92ve been told that Android treats all APNs as =93roughly equal=94.=20 If the new IPv6-only-without-IPv4-fallback APN fails then Android might = be trying the IPv4 one. BR Ross= From nobody Wed Aug 6 13: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 AD7A01A010C for ; Wed, 6 Aug 2014 13:23:41 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwNXuX1Qf6Uv for ; Wed, 6 Aug 2014 13:23:36 -0700 (PDT) Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by ietfa.amsl.com (Postfix) with SMTP id 982101A00F2 for ; Wed, 6 Aug 2014 13:23:36 -0700 (PDT) Received: (qmail 26460 messnum 13270984 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 6 Aug 2014 20:23:34 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail05.svc.cra.dublin.eircom.net (qp 26460) with SMTP; 6 Aug 2014 20:23:34 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bYPX1o00R0mJ9Tz01YPaAq; Wed, 06 Aug 2014 21:23:34 +0100 Content-Type: text/plain; charset=windows-1250 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> Date: Wed, 6 Aug 2014 21:23:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4uYEehV5H0AlqWfJmcH_OMR7D2g Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Wed, 06 Aug 2014 20:23:42 -0000 On 6 Aug 2014, at 20:46, Ross Chandler wrote: >=20 > It might be that when the UE visits a network that doesn=92t allow = IPv6 in the user-plane Android behaviour is kicking in. >=20 > I=92ve been told that Android treats all APNs as =93roughly equal=94.=20= >=20 > If the new IPv6-only-without-IPv4-fallback APN fails then Android = might be trying the IPv4 one. If this is what=92s going on in Telenor case the plus is it maximises = the number of roaming partners that come up with IPv6 but at the = possible cost of indeterminism on which APN the UE settles on using when = it gets back home. Ross= From nobody Wed Aug 6 18:30: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 D2CFB1A03B5 for ; Wed, 6 Aug 2014 18:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-NmTe18bWAf for ; Wed, 6 Aug 2014 18:30:16 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08CE1A03B4 for ; Wed, 6 Aug 2014 18:30:15 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id v10so3263008qac.26 for ; Wed, 06 Aug 2014 18:30:15 -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=CvNZPkKZ+rJMLp65H4hKcF1cnW01is4bKe3X45pL++U=; b=GSn893P6CjFkT8Nt4r4Uae1IGjHUFtnaC2lmSXKEhJoy/MOIMaw3kB40Sv09I7qBN3 LhXygl2kO2XI2+L4bhiO9N7jX0d7zeorwfWnNRQEe3AAuSEYVX0W5HcrlgkYKGDKzIOw yqqjQywqv59Srad0N94s0pq+zK4ijPbgeRc1FdEMCwWT5/CYlGz+cYKYP/R7Wqcgv5ZH TFgzE+V4ArGjjn1RMTBa0i0zhhN7FyB/pJqkEOitO+7R7gvOf18mSz2KIctmNwqs7vg8 KGnPjL+CGPshhClmzyNAJAfB9JBUP4DOub000Wb783ArIrg79q24yL6/utDwwzKKELAp 66Bg== MIME-Version: 1.0 X-Received: by 10.224.88.71 with SMTP id z7mr22828006qal.94.1407375014932; Wed, 06 Aug 2014 18:30:14 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Wed, 6 Aug 2014 18:30:14 -0700 (PDT) In-Reply-To: References: <20140804010755.5662.75071.idtracker@ietfa.amsl.com> <8E890204-B4A8-4EDC-BFF6-FC33A2C30FC6@eircom.net> <6536E263028723489CCD5B6821D4B21303B6F82C@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Thu, 7 Aug 2014 09:30:14 +0800 Message-ID: From: GangChen To: Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/E-PS-6nVKX6KEgravR3y95XiMCo Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 01:30:20 -0000 2014-08-06 19:50 GMT+08:00, Ross Chandler : > > On 6 Aug 2014, at 12:14, GangChen wrote: >>>> >>> >>> Proposed update >>> >>> >>> 4. Failure Case in Attachment Stage >>> >>> 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request >>> both IPv4 and IPv6 within a single PDP/PDN request. >>> >>> >>> is changed to >>> >>> >>> 4. Failure Case in Attachment Stage >>> >>> 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE indicate it= s >>> capability to support dual-stack, both IPv4 and IPv6 with a single or >>> separate PDP/PDN connections. >> > > Gang, > > Shouldn=E2=80=99t the draft make both points. > > It is a capability indication (or otherwise expressed as implicit allow) > from the UE that it can > >> " allow network to >> assign IPv4-only, IPv6-only, IPv4+IPv6 in single PDP/PDN bearer, >> IPv4+IPv6 in separated PDP/PDN bearers.=E2=80=9D > > And this point. > >> However, I don't think that >> is the purpose of introducing IPv4v6 PDP/PDN. The essential of IPv4v6 >> is to allow UE get IPv4 and IPv6 on a single bearer so as to reduce >> network costs. RFC6459 also has similar description, i.e. This enables >> parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6)=E2=80=9D Sure. It will be added > BR > Ross From nobody Wed Aug 6 22:29: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 A2AD61A0ACC for ; Wed, 6 Aug 2014 22:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy8_6IkdD8jb for ; Wed, 6 Aug 2014 22:29:46 -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 D0C201A0ABA for ; Wed, 6 Aug 2014 22:29:45 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=54048 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 1XFGGj-0001hW-J3; Thu, 07 Aug 2014 07:29:41 +0200 Message-ID: <53E30E74.7050502@fud.no> Date: Thu, 07 Aug 2014 07:28:20 +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: Ross Chandler , IPv6 Ops WG References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> In-Reply-To: <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/deBzXgaD6XWnDDsWhSUfxIEstZI Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 05:29:47 -0000 * Ross Chandler >> It might be that when the UE visits a network that doesn’t allow >> IPv6 in the user-plane Android behaviour is kicking in. >> >> I’ve been told that Android treats all APNs as “roughly equal”. >> >> If the new IPv6-only-without-IPv4-fallback APN fails then Android >> might be trying the IPv4 one. > > If this is what’s going on in Telenor case the plus is it maximises > the number of roaming partners that come up with IPv6 but at the > possible cost of indeterminism on which APN the UE settles on using > when it gets back home. I'm fairly certain there is no such indeterminism. Basically the UEs get set up to request IPv6 PDP type both home and when roaming. So when they establish a data bearer they get IPv6 (+464XLAT) no matter where in the world they are, or they get no data bearer at all (if there's some sort of problem somewhere). That Telenor feels confident in doing it in this manner is very good news, I think. It reminds me of the World IPv6 Launch, actually - where it was decided that the bugs and issues that had previously made it unsafe to deploy IPv6 on a global scale (as opposed to a select few known good networks, corresponding well to "the home PLMN only" in the mobile case), has been sufficiently solved so that IPv6 can be made generally available instead. I guess now it's up to Cameron and Michał to follow suit. ;-) Tore From nobody Wed Aug 6 22:47: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 5491A1A0AF4 for ; Wed, 6 Aug 2014 22:47:13 -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, HTML_NONELEMENT_30_40=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEpGvx3C7CAA for ; Wed, 6 Aug 2014 22:47:10 -0700 (PDT) Received: from mail16.svc.cra.dublin.eircom.net (mail16.svc.cra.dublin.eircom.net [159.134.118.215]) by ietfa.amsl.com (Postfix) with SMTP id 7DB191A0AD8 for ; Wed, 6 Aug 2014 22:47:10 -0700 (PDT) Received: (qmail 6347 messnum 3413145 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 05:47:08 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail16.svc.cra.dublin.eircom.net (qp 6347) with SMTP; 7 Aug 2014 05:47:08 -0000 Received: from [159.134.196.38] ([159.134.196.38]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bhn51o00N0qBAUn01hn8kv; Thu, 07 Aug 2014 06:47:08 +0100 Date: Thu, 07 Aug 2014 06:47:06 +0100 Message-ID: Importance: normal From: Ross Chandler To: Tore Anderson , IPv6 Ops WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_181462436976050" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JgOwbriNidQw0BGU_lDoKCOWf20 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 05:47:13 -0000 ----_com.android.email_181462436976050 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V2VsbCBUZWxlbm9yIGhhdmUgZG9uZSB1cyBhbGwgYSBzZXJ2aWNlLiBUaGV5J3ZlIG1hZGUgaXQg c2ltcGxlLiBXZSBhbGwgbm93IGhhdmUgdG8gdHVybiBvbiBJUHY2IGluIHRoZSB1c2VyLXBsYW5l LgpSb3NzCgo8ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2 PkZyb206IFRvcmUgQW5kZXJzb24gPHRvcmVAZnVkLm5vPiA8L2Rpdj48ZGl2PkRhdGU6MDcvMDgv MjAxNCAgNjoyOCBhLm0uICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBSb3NzIENoYW5kbGVy IDxyb3NzQGVpcmNvbS5uZXQ+LElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4gPC9kaXY+PGRp dj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWlwdjYt cm9hbWluZy1hbmFseXNpcy0wMi50eHQgPC9kaXY+PGRpdj4KPC9kaXY+KiBSb3NzIENoYW5kbGVy Cgo+PiBJdCBtaWdodCBiZSB0aGF0IHdoZW4gdGhlIFVFIHZpc2l0cyBhIG5ldHdvcmsgdGhhdCBk b2VzbuKAmXQgYWxsb3cKPj4gSVB2NiBpbiB0aGUgdXNlci1wbGFuZSBBbmRyb2lkIGJlaGF2aW91 ciBpcyBraWNraW5nIGluLgo+PiAKPj4gSeKAmXZlIGJlZW4gdG9sZCB0aGF0IEFuZHJvaWQgdHJl YXRzIGFsbCBBUE5zIGFzIOKAnHJvdWdobHkgZXF1YWzigJ0uCj4+IAo+PiBJZiB0aGUgbmV3IElQ djYtb25seS13aXRob3V0LUlQdjQtZmFsbGJhY2sgQVBOIGZhaWxzIHRoZW4gQW5kcm9pZAo+PiBt aWdodCBiZSB0cnlpbmcgdGhlIElQdjQgb25lLgo+IAo+IElmIHRoaXMgaXMgd2hhdOKAmXMgZ29p bmcgb24gaW4gVGVsZW5vciBjYXNlIHRoZSBwbHVzIGlzIGl0IG1heGltaXNlcwo+IHRoZSBudW1i ZXIgb2Ygcm9hbWluZyBwYXJ0bmVycyB0aGF0IGNvbWUgdXAgd2l0aCBJUHY2IGJ1dCBhdCB0aGUK PiBwb3NzaWJsZSBjb3N0IG9mIGluZGV0ZXJtaW5pc20gb24gd2hpY2ggQVBOIHRoZSBVRSBzZXR0 bGVzIG9uIHVzaW5nCj4gd2hlbiBpdCBnZXRzIGJhY2sgaG9tZS4KCkknbSBmYWlybHkgY2VydGFp biB0aGVyZSBpcyBubyBzdWNoIGluZGV0ZXJtaW5pc20uCgpCYXNpY2FsbHkgdGhlIFVFcyBnZXQg c2V0IHVwIHRvIHJlcXVlc3QgSVB2NiBQRFAgdHlwZSBib3RoIGhvbWUgYW5kIHdoZW4Kcm9hbWlu Zy4gU28gd2hlbiB0aGV5IGVzdGFibGlzaCBhIGRhdGEgYmVhcmVyIHRoZXkgZ2V0IElQdjYgKCs0 NjRYTEFUKQpubyBtYXR0ZXIgd2hlcmUgaW4gdGhlIHdvcmxkIHRoZXkgYXJlLCBvciB0aGV5IGdl dCBubyBkYXRhIGJlYXJlciBhdCBhbGwKKGlmIHRoZXJlJ3Mgc29tZSBzb3J0IG9mIHByb2JsZW0g c29tZXdoZXJlKS4KClRoYXQgVGVsZW5vciBmZWVscyBjb25maWRlbnQgaW4gZG9pbmcgaXQgaW4g dGhpcyBtYW5uZXIgaXMgdmVyeSBnb29kCm5ld3MsIEkgdGhpbmsuIEl0IHJlbWluZHMgbWUgb2Yg dGhlIFdvcmxkIElQdjYgTGF1bmNoLCBhY3R1YWxseSAtIHdoZXJlCml0IHdhcyBkZWNpZGVkIHRo YXQgdGhlIGJ1Z3MgYW5kIGlzc3VlcyB0aGF0IGhhZCBwcmV2aW91c2x5IG1hZGUgaXQKdW5zYWZl IHRvIGRlcGxveSBJUHY2IG9uIGEgZ2xvYmFsIHNjYWxlIChhcyBvcHBvc2VkIHRvIGEgc2VsZWN0 IGZldwprbm93biBnb29kIG5ldHdvcmtzLCBjb3JyZXNwb25kaW5nIHdlbGwgdG8gInRoZSBob21l IFBMTU4gb25seSIgaW4gdGhlCm1vYmlsZSBjYXNlKSwgaGFzIGJlZW4gc3VmZmljaWVudGx5IHNv bHZlZCBzbyB0aGF0IElQdjYgY2FuIGJlIG1hZGUKZ2VuZXJhbGx5IGF2YWlsYWJsZSBpbnN0ZWFk LgoKSSBndWVzcyBub3cgaXQncyB1cCB0byBDYW1lcm9uIGFuZCBNaWNoYcWCIHRvIGZvbGxvdyBz dWl0LiA7LSkKClRvcmUK ----_com.android.email_181462436976050 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5XZWxsIFRlbGVub3IgaGF2 ZSBkb25lIHVzIGFsbCBhIHNlcnZpY2UuIFRoZXkndmUgbWFkZSBpdCBzaW1wbGUuIFdlIGFsbCBu b3cgaGF2ZSB0byB0dXJuIG9uIElQdjYgaW4gdGhlIHVzZXItcGxhbmUuPC9kaXY+PGRpdj5Sb3Nz PC9kaXY+PGJyPjxicj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rp dj48ZGl2PkZyb206IFRvcmUgQW5kZXJzb24gPHRvcmVAZnVkLm5vPiA8L2Rpdj48ZGl2PkRhdGU6 MDcvMDgvMjAxNCAgNjoyOCBhLm0uICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBSb3NzIENo YW5kbGVyIDxyb3NzQGVpcmNvbS5uZXQ+LElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4gPC9k aXY+PGRpdj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3Bz LWlwdjYtcm9hbWluZy1hbmFseXNpcy0wMi50eHQgPC9kaXY+PGRpdj48YnI+PC9kaXY+KiBSb3Nz IENoYW5kbGVyPGJyPjxicj4mZ3Q7Jmd0OyBJdCBtaWdodCBiZSB0aGF0IHdoZW4gdGhlIFVFIHZp c2l0cyBhIG5ldHdvcmsgdGhhdCBkb2VzbuKAmXQgYWxsb3c8YnI+Jmd0OyZndDsgSVB2NiBpbiB0 aGUgdXNlci1wbGFuZSBBbmRyb2lkIGJlaGF2aW91ciBpcyBraWNraW5nIGluLjxicj4mZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsgSeKAmXZlIGJlZW4gdG9sZCB0aGF0IEFuZHJvaWQgdHJlYXRzIGFsbCBB UE5zIGFzIOKAnHJvdWdobHkgZXF1YWzigJ0uPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBJZiB0 aGUgbmV3IElQdjYtb25seS13aXRob3V0LUlQdjQtZmFsbGJhY2sgQVBOIGZhaWxzIHRoZW4gQW5k cm9pZDxicj4mZ3Q7Jmd0OyBtaWdodCBiZSB0cnlpbmcgdGhlIElQdjQgb25lLjxicj4mZ3Q7IDxi cj4mZ3Q7IElmIHRoaXMgaXMgd2hhdOKAmXMgZ29pbmcgb24gaW4gVGVsZW5vciBjYXNlIHRoZSBw bHVzIGlzIGl0IG1heGltaXNlczxicj4mZ3Q7IHRoZSBudW1iZXIgb2Ygcm9hbWluZyBwYXJ0bmVy cyB0aGF0IGNvbWUgdXAgd2l0aCBJUHY2IGJ1dCBhdCB0aGU8YnI+Jmd0OyBwb3NzaWJsZSBjb3N0 IG9mIGluZGV0ZXJtaW5pc20gb24gd2hpY2ggQVBOIHRoZSBVRSBzZXR0bGVzIG9uIHVzaW5nPGJy PiZndDsgd2hlbiBpdCBnZXRzIGJhY2sgaG9tZS48YnI+PGJyPkknbSBmYWlybHkgY2VydGFpbiB0 aGVyZSBpcyBubyBzdWNoIGluZGV0ZXJtaW5pc20uPGJyPjxicj5CYXNpY2FsbHkgdGhlIFVFcyBn ZXQgc2V0IHVwIHRvIHJlcXVlc3QgSVB2NiBQRFAgdHlwZSBib3RoIGhvbWUgYW5kIHdoZW48YnI+ cm9hbWluZy4gU28gd2hlbiB0aGV5IGVzdGFibGlzaCBhIGRhdGEgYmVhcmVyIHRoZXkgZ2V0IElQ djYgKCs0NjRYTEFUKTxicj5ubyBtYXR0ZXIgd2hlcmUgaW4gdGhlIHdvcmxkIHRoZXkgYXJlLCBv ciB0aGV5IGdldCBubyBkYXRhIGJlYXJlciBhdCBhbGw8YnI+KGlmIHRoZXJlJ3Mgc29tZSBzb3J0 IG9mIHByb2JsZW0gc29tZXdoZXJlKS48YnI+PGJyPlRoYXQgVGVsZW5vciBmZWVscyBjb25maWRl bnQgaW4gZG9pbmcgaXQgaW4gdGhpcyBtYW5uZXIgaXMgdmVyeSBnb29kPGJyPm5ld3MsIEkgdGhp bmsuIEl0IHJlbWluZHMgbWUgb2YgdGhlIFdvcmxkIElQdjYgTGF1bmNoLCBhY3R1YWxseSAtIHdo ZXJlPGJyPml0IHdhcyBkZWNpZGVkIHRoYXQgdGhlIGJ1Z3MgYW5kIGlzc3VlcyB0aGF0IGhhZCBw cmV2aW91c2x5IG1hZGUgaXQ8YnI+dW5zYWZlIHRvIGRlcGxveSBJUHY2IG9uIGEgZ2xvYmFsIHNj YWxlIChhcyBvcHBvc2VkIHRvIGEgc2VsZWN0IGZldzxicj5rbm93biBnb29kIG5ldHdvcmtzLCBj b3JyZXNwb25kaW5nIHdlbGwgdG8gInRoZSBob21lIFBMTU4gb25seSIgaW4gdGhlPGJyPm1vYmls ZSBjYXNlKSwgaGFzIGJlZW4gc3VmZmljaWVudGx5IHNvbHZlZCBzbyB0aGF0IElQdjYgY2FuIGJl IG1hZGU8YnI+Z2VuZXJhbGx5IGF2YWlsYWJsZSBpbnN0ZWFkLjxicj48YnI+SSBndWVzcyBub3cg aXQncyB1cCB0byBDYW1lcm9uIGFuZCBNaWNoYcWCIHRvIGZvbGxvdyBzdWl0LiA7LSk8YnI+PGJy PlRvcmU8YnI+PC9ib2R5Pg== ----_com.android.email_181462436976050-- From nobody Wed Aug 6 22:59: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 5CA601A0B11 for ; Wed, 6 Aug 2014 22:59:00 -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 EoaxzGNl9KQ0 for ; Wed, 6 Aug 2014 22:58:58 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B5E1A854B for ; Wed, 6 Aug 2014 22:58:58 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so3942971qge.30 for ; Wed, 06 Aug 2014 22:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w+Oc8VyDTOHSqZ7M+DyBAo5xqxgU4jEWKm0jjb+C6gk=; b=PaPuSs8LY2yJgwpHfaQ/vVD5yjf4rpOb99nJnOQoaBoqkz4y+z05RIxCItJwIurbOh zL58sSy8stTopZmDIjNDSuUKUBvafKz36jNTP3NT4cUhUt1jkr/v20y0tqRZwcAkgQQr bkWNe7s0pK+yNgOESQIutgpwJ0toR6zVhcVRVx2smZ3N4pdpa0Q53qUEhLwslYWDKLSf X/xD23Eiz4IyOxNyboKMoIHvhrf80/mGRUlD2mcRvsqFjPV1kPr0ZvEjGi6U9Pv27N3B VsQjIbQBOpPaD2e5qnsj7H11hIlAnDX/0h/jrETny/NFURP8XTRsi/jLxce1oTPflzd9 1uCA== MIME-Version: 1.0 X-Received: by 10.224.119.193 with SMTP id a1mr24167745qar.18.1407391137324; Wed, 06 Aug 2014 22:58:57 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Wed, 6 Aug 2014 22:58:57 -0700 (PDT) In-Reply-To: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> Date: Thu, 7 Aug 2014 13:58:57 +0800 Message-ID: From: GangChen To: Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BQd9lXQZBpka7LWUnFBxlwKWyRM Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 05:59:00 -0000 2014-08-06 2:22 GMT+08:00, Ross Chandler : > Subject line change as this has turned more appropriate to the > roaming-analysis draft. > > On 5 Aug 2014, at 18:42, Tore Anderson wrote: > >>> The APN roaming protocol setting for =E2=80=9Ctelenor.mobil=E2=80=9D li= sted at that >>> URL says it is IPv6. >>> >>> Is that really their setting? AFAIK the Android UE or more >>> accurately the RIL it calls doesn=E2=80=99t fallback to IPv4 when IPv6 = is >>> explicitly requested. >> >> Yes, that's their setting. No need for fallback when IPv6 works, right? >> >> To be honest I've never quite understood what all the fuss is about >> regarding IPv6 and 3GPP roaming. My personal experience, having been a >> customer of Tele 2 Norway (formerly Network Norway) using their IPv6 >> pilot for about two years, then moving to Telenor about six months ago, >> is that IPv6 roaming Just Works. >> >> I've not visited every country in the world, but I have been around a >> bit, and I've made a point out of trying to establish an IPv6 data >> bearer to every single PLMN I can register with. So far I've had 100% >> success, including on Cameron's network... Thus enabling IPv6 roaming >> doesn't seem like a scary proposition to me. I'm guessing perhaps >> Telenor came to the same conclusion. > > According to the manual my SGSN-MMEs have an =E2=80=9CAllowIPv6ForAllVisi= tors=E2=80=9D > parameter that has to be set true to allow IPv6 PDP/PDN connections be > set-up be visitors. > > Out of the box the SGSN-MME had userplane IPv6 enabled for home users. It > needed the DAF flag to be set (to allow dual-stack in a single bearer). > > Proposal for addition to the draft - it should mention =E2=80=9CIPv6 Roa= ming > friendly operator=E2=80=9D settings (user plane IPv6 allowed, DAF=3D1 if = possible) on > how to make your network friendly for visitors. It make sense. I guess the meaning of =E2=80=9CAllowIPv6ForAllVisitors=E2= =80=9D parameter is to enable SGSN validating the Activate PDP Context Request with IPv6-only PDP type and sending a Create PDP Context Request with IPv6-only PDP to GGSN/PGW. Gang > Ross > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Aug 6 23:50: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 B8B241B27F7 for ; Wed, 6 Aug 2014 23:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxCgoScV5s2y for ; Wed, 6 Aug 2014 23:50:50 -0700 (PDT) Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by ietfa.amsl.com (Postfix) with SMTP id 9CBEF1B27EE for ; Wed, 6 Aug 2014 23:50:50 -0700 (PDT) Received: (qmail 63023 messnum 10311055 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 06:50:49 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail07.svc.cra.dublin.eircom.net (qp 63023) with SMTP; 7 Aug 2014 06:50:49 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id biql1o02S0mJ9Tz01iqo63; Thu, 07 Aug 2014 07:50:49 +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: Thu, 7 Aug 2014 07:50:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> To: GangChen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KAj_OVDh0LaGvRjX_o7FFG6NnjM Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 06:50:52 -0000 On 7 Aug 2014, at 06:58, GangChen wrote: >> According to the manual my SGSN-MMEs have an = =93AllowIPv6ForAllVisitors=94 >> parameter that has to be set true to allow IPv6 PDP/PDN connections = be >> set-up be visitors. >>=20 >> Out of the box the SGSN-MME had userplane IPv6 enabled for home = users. It >> needed the DAF flag to be set (to allow dual-stack in a single = bearer). >>=20 >> Proposal for addition to the draft - it should mention =93IPv6 = Roaming >> friendly operator=94 settings (user plane IPv6 allowed, DAF=3D1 if = possible) on >> how to make your network friendly for visitors. >=20 > It make sense. I guess the meaning of =93AllowIPv6ForAllVisitors=94 > parameter is to enable SGSN validating the Activate PDP Context > Request with IPv6-only PDP type and sending a Create PDP Context > Request with IPv6-only PDP to GGSN/PGW. Yes. That command is from an Ericsson SGSN-MME. It is set with the = modify_ne command. It would be good if the vendors now make this on by = default. It is also necessary to have IPv6 user-plane allowed for home users but = that is already on by default.=20 The draft should also clearly make the point that the operator doesn=92t = have to yet be at the stage of offering IPv6 or IPv4v6 based Internet = through their own GGSN/PGW. Ironically it is easier to let others use your RANs for IPv6 than it is = to do it yourself. BR Ross From nobody Thu Aug 7 00:18: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 A95CC1B286A for ; Thu, 7 Aug 2014 00:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg6TbUYuYFdn for ; Thu, 7 Aug 2014 00:18:06 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4881B2855 for ; Thu, 7 Aug 2014 00:18:06 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so4017840qgf.3 for ; Thu, 07 Aug 2014 00:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xxzhhpH+fHE72yUZ7k6fvd6LhngSxlpovnJWqP433F8=; b=hrUMfYneUD7wuyyDiNb70rtW3d+Indvh4Gc68zkEztLttodI6TXb28q/k9TlPsbmAq csd7GZIaS2nAcpwbD5ECE6gvoGfq3F53sQiubRXHK4gxPel3hnoV/SuHc4BOSjKZnL4n x1x52+jwgLl6PBCN4W7lUvQYCc8KZksfuGYd3ZETmIN8qcxoufapkEEDPMykB/OgbJGp 8WNJL2hFBhPzWvv/dZGo5SZXlXRUXFZ6UnoIMBB2xtmQINrXzo/97TSOoMBroccP4FQ6 g1qW1+nWjekzgXow2w4FuUl27F+s+W4VHrHV/krh4Pm8919w/NHpfGxkqk73Ni/3NLCn U1GA== MIME-Version: 1.0 X-Received: by 10.140.48.234 with SMTP id o97mr8548444qga.10.1407395885484; Thu, 07 Aug 2014 00:18:05 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Thu, 7 Aug 2014 00:18:05 -0700 (PDT) In-Reply-To: <53E1D951.8030200@fud.no> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> Date: Thu, 7 Aug 2014 15:18:05 +0800 Message-ID: From: GangChen To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VdcebaJ9NHhhbzap_v7AM25VQWg Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 07:18:08 -0000 2014-08-06 15:29 GMT+08:00, Tore Anderson : > (Changing the subject like Ross did.) > > * Mikael Abrahamsson > >> I've heard reports of platforms in use in southeast asia, I don't >> remember if it was Korea or some other country, would fail when >> presented with IPv4v6 capability. >> >> The reason why people are not going for IPv4v6 externally is because it >> breaks things, badly, it seems, due to bugs. So this is why IPv6 only >> bearer is so appealing, because it's been around for 5-10 years and very >> few things break with it. > > Yep, and to be clear, Telenor Norway does not support the IPv4v6 on > their IPv6-capable APN (nor does Tele2/Network Norway). Furthermore, > Telenor only supports IPv6 (not IPv4), while Tele2/NwN supports both > IPv6 and IPv4. > > Which leads me to a point I forgot to mention before, if Telenor had > used Roaming Protocol = IPv4 as Ross suggested, or if the phone RIL did > a similar fallback, it would actually ascertain failure, since the APN > doesn't allow IPv4. If IPv6 fails, one would have to change to one of > the IPv4-only APNs. > >> The scary part isn't enabling IPv6, it's enabling IPv4v6 or capability >> to do so. When advertised as capability to visiting SGSN it might refuse >> to bring up any bearer at all. So this is why the draft suggests it >> might be a good idea to not advertise this to roaming partners. > > Yes, the -02 draft makes it much clearer than previous versions that > this concern is applicable specifically for IPv4v6 and not for IPv6. > > In spite of this I see that some providers that are using IPv6 and home > routing chose to set the Roaming Protocol to IPv4. This is what I don't > quite understand the reason for. Perhaps due to a misunderstanding that > the problems IPv4v6 also apply for IPv6, or some other problem I have > yet to come across? Setting roaming APN with IPv4 is recommended in local breakout mode. As described in http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-02#section-5.3, IPv6-only PDP/PDN can't be failed over to IPv4. In your case, I guess traffic is home routed. When a Telenor customer roams Tele2/NwN, All PDP/PDN request and traffic will back to Telenor network. Therefore, it works. However, it increases the international data roaming fees to customers, since Telenor has to pay GRX/IPX carrier for the international traffic transit. In order to reduce the cost, local breakout is an optimized approach. It will save the charge for GRX/IPX transit and improve data service performance. In that case, I guess the Telenor customer has to check if roaming APN set to IPv4-only, since the visited network may not able to allocate IPv6 to customers. BRs Gang > I don't really know much about what's going on "under the hood" in > mobile networks to be honest, but with my "dumb user" hat on I can > conclude that IPv6 roaming seems to work just fine with the way Telenor > and Tele2/NwN have implemented it. So I'm happy. :-) > > Tore > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Aug 7 00:28: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 A6C621B2855 for ; Thu, 7 Aug 2014 00:28: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 sQNNwlORweC8 for ; Thu, 7 Aug 2014 00:28:05 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116C21B286B for ; Thu, 7 Aug 2014 00:28:04 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so3583962qaq.24 for ; Thu, 07 Aug 2014 00:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=33JKZ8CtKwKdOjkB//coxG1zel8LrorovAWfaciMN/I=; b=O5dayjEFVivxPugo2BwpAWe34gHs0bxiW5+jvhSelI8s5N0HhqPsRwpfoW4uk5/rbJ OH6YFRFSg//CiNYnCE2K2fjEo8bNKsXYVdhQWErK3Vhk2jsBba/3Dyta2DV7xUjuFaIZ 3D887ta1lwWTsGsle7HwxHaBwyFg33obWvPYwTc+CFzcwmofSqVQYfZ7jzQEEpeIoB+Z Q89H7YTsCZgMC+iwFA8nWNGylpO8XEjaMBUi9Np4/Qg+Wg3a431clb4YtfWzZ3MzP3dx mhJ32bxha7lT532PAfzbtZDKATwPJnoyqIoJc94MCBO1RtTi8G5RePrI6aDXyyAWhLCR 1GNg== MIME-Version: 1.0 X-Received: by 10.224.119.193 with SMTP id a1mr24787529qar.18.1407396484235; Thu, 07 Aug 2014 00:28:04 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Thu, 7 Aug 2014 00:28:04 -0700 (PDT) In-Reply-To: <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> Date: Thu, 7 Aug 2014 15:28:04 +0800 Message-ID: From: GangChen To: Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pALryxgwJxq5lTiNZam0JAV-30g Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 07:28:06 -0000 2014-08-07 14:50 GMT+08:00, Ross Chandler : > > The draft should also clearly make the point that the operator doesn=E2= =80=99t have > to yet be at the stage of offering IPv6 or IPv4v6 based Internet through > their own GGSN/PGW. > Ironically it is easier to let others use your RANs for IPv6 than it is t= o > do it yourself. You mean apps could use ipv6 over ipv4 to use RAN? In my experience, it may not be able to get good performance compared to native implementation of IPv6 support in the mobile phone. For example, RAN performs IPv6 header compression to optimize the performance. apps can't get those benefits. Gang > > BR > Ross > > > From nobody Thu Aug 7 00:38: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 0CE691B28DE for ; Thu, 7 Aug 2014 00:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWILjOhy38S0 for ; Thu, 7 Aug 2014 00:38:56 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D111B28BD for ; Thu, 7 Aug 2014 00:38:56 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=55840 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 1XFIHm-0004NT-7V; Thu, 07 Aug 2014 09:38:54 +0200 Message-ID: <53E32CBD.8070601@fud.no> Date: Thu, 07 Aug 2014 09:37:33 +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: GangChen References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/De8Koc7sCvwZWxsVI5OVPNn9OeA Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 07:38:58 -0000 * GangChen > In your case, I guess traffic is home routed. When a Telenor customer > roams Tele2/NwN, All PDP/PDN request and traffic will back to Telenor > network. Therefore, it works. Yep, exactly. I am assigned addresses from Telenor's prefixes when I roam (both for IPv4 and IPv6 APNs). Same thing for Tele2/NwN. > However, it increases the international data roaming fees to > customers, since Telenor has to pay GRX/IPX carrier for the > international traffic transit. In order to reduce the cost, local > breakout is an optimized approach. I don't think any of the Norwegian providers allow/support their subscribers to do local breakout. I assume this is a service the visited network cannot offer to the roamer without the home network's blessing? [ If the visited network can do this without the home network's blessing, that would have made for a extremely nice product for travelers. Imagine if I could just have entered a new APN name "internet.gangchen" when I visit your country and roam in your PLMN, punch in my credit card details in a captive portal and from then on been able to use mobile internet at reasonable local rates... No more bothering with getting pre-paid data SIMs from local providers and such anymore..! ] > It will save the charge for > GRX/IPX transit and improve data service performance. I think Telenor (and all the other providers around here for that matter) are happily enjoying near-criminal profit margins on those expenses, so I'm kind of doubting I'll see local breakout being offered or encouraged anytime soon...but I guess time will tell. Tore From nobody Thu Aug 7 01:27: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 C7C5A1B29D6 for ; Thu, 7 Aug 2014 01:27:10 -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_84=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 tBnbrNh_Rg0o for ; Thu, 7 Aug 2014 01:27:09 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6B11B29B8 for ; Thu, 7 Aug 2014 01:27:09 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so3982300qgf.6 for ; Thu, 07 Aug 2014 01:27:08 -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=ge0x9Ry9Oh8Im5IDqfJqtm6oV600YK6JDSE9OVv/vkA=; b=B/q67EoHLIajVbm9WbH2eL/bY/bjlLIBFgYnCEa+6U5ekByJBN28UdZUlCS0eaKUXf S0YCdXzFSEjDaYU9Mv6XAeTR3IAXjLHRtwyvLD43qBww0W38ZExhIkF6u4HvAZwIltlx ms3N+S9xpsCxnKBZWytqHJCeYLEL3+UK8H+Cn2VUi/dUUHO/d5TutEHmCarZlwpojgVQ O3ohz1zQRqAPm23ZlYyyXEAoKfRr/0KJtEI84FjKFBVmO6pUkQ6UAfS8B2TBMahxJcy/ vYP7KqpgVF6ZyabYHcH1pUIL8bAV1O5OHtA+5hmCLxCGsaXPC161f5QkTifjgcKevCbF 2rEg== MIME-Version: 1.0 X-Received: by 10.229.59.67 with SMTP id k3mr24656611qch.26.1407400028809; Thu, 07 Aug 2014 01:27:08 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Thu, 7 Aug 2014 01:27:08 -0700 (PDT) In-Reply-To: <53E32CBD.8070601@fud.no> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <53E32CBD.8070601@fud.no> Date: Thu, 7 Aug 2014 16:27:08 +0800 Message-ID: From: GangChen To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kSyLuEl3hGeQ47Ri0V2Odo2CdYg Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 08:27:10 -0000 2014-08-07 15:37 GMT+08:00, Tore Anderson : > * GangChen > >> In your case, I guess traffic is home routed. When a Telenor customer >> roams Tele2/NwN, All PDP/PDN request and traffic will back to Telenor >> network. Therefore, it works. > > Yep, exactly. I am assigned addresses from Telenor's prefixes when I > roam (both for IPv4 and IPv6 APNs). Same thing for Tele2/NwN. > >> However, it increases the international data roaming fees to >> customers, since Telenor has to pay GRX/IPX carrier for the >> international traffic transit. In order to reduce the cost, local >> breakout is an optimized approach. > > I don't think any of the Norwegian providers allow/support their > subscribers to do local breakout. I assume this is a service the visited > network cannot offer to the roamer without the home network's blessing? It's a business matter more than technical concern. Most operators adopt home routed because it facilitates charging. GGSN/PGW in the home land could get precise traffic volume a customer generates. Other consideration is for lawful interception. > [ If the visited network can do this without the home network's > blessing, that would have made for a extremely nice product for > travelers. Imagine if I could just have entered a new APN name > "internet.gangchen" when I visit your country and roam in your PLMN, > punch in my credit card details in a captive portal and from then on > been able to use mobile internet at reasonable local rates... No more > bothering with getting pre-paid data SIMs from local providers and such > anymore..! ] That is exact experience EU-Roaming-III would like to achieve. >> It will save the charge for >> GRX/IPX transit and improve data service performance. > > I think Telenor (and all the other providers around here for that > matter) are happily enjoying near-criminal profit margins on those > expenses, so I'm kind of doubting I'll see local breakout being offered > or encouraged anytime soon...but I guess time will tell. Voice traffic based on IMS does local breakout mode as per GSMA regulation. For the data service, China Mobile adopts local breakout mode when customers perform Intra-PLMN mobility(more detailed is described in section 2 of the draft). There is also ongoing effort to promote local breakout for data roaming in Asian area. Anyway, that is the topic mainly regarding to business perspective. Gang > Tore > From nobody Thu Aug 7 01:39: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 501401B29FB for ; Thu, 7 Aug 2014 01:39:23 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f5TCW7D8HDF for ; Thu, 7 Aug 2014 01:39:21 -0700 (PDT) Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by ietfa.amsl.com (Postfix) with SMTP id A1DE41B28DB for ; Thu, 7 Aug 2014 01:39:20 -0700 (PDT) Received: (qmail 80578 messnum 5665524 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 08:39:19 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail09.svc.cra.dublin.eircom.net (qp 80578) with SMTP; 7 Aug 2014 08:39:19 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bkfC1o00a0mJ9Tz01kfHiz; Thu, 07 Aug 2014 09:39:19 +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: Thu, 7 Aug 2014 09:39:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> To: GangChen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BbSgtZPBM-1ViQh_wOQF4yGZaLs Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 08:39:23 -0000 On 7 Aug 2014, at 08:28, GangChen wrote: > 2014-08-07 14:50 GMT+08:00, Ross Chandler : >>=20 >> The draft should also clearly make the point that the operator = doesn=92t have >> to yet be at the stage of offering IPv6 or IPv4v6 based Internet = through >> their own GGSN/PGW. >> Ironically it is easier to let others use your RANs for IPv6 than it = is to >> do it yourself. >=20 > You mean apps could use ipv6 over ipv4 to use RAN? In my experience, > it may not be able to get good performance compared to native > implementation of IPv6 support in the mobile phone. For example, RAN > performs IPv6 header compression to optimize the performance. apps > can't get those benefits. No. I=92m noting that the first stage for a Mobile operator in adopting = IPv6 in the user plane is to prepare their RANs and SGSN/MMEs for it. When that is done an easy next step is to let visitors from other = operators that are ahead in deploying IPv6 establish IPv6 PDP/PDN = connections to their home GGSN/PGW. That scenario can happen, and is happening, already, as per Tore=92s and = others comments. Ross =20= From nobody Thu Aug 7 02:21: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 315271B2A27 for ; Thu, 7 Aug 2014 02:21:42 -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 Fkc41hDIZ72b for ; Thu, 7 Aug 2014 02:21:40 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBE01B2966 for ; Thu, 7 Aug 2014 02:21:40 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so4128858qga.1 for ; Thu, 07 Aug 2014 02:21:39 -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=Hgv2Lzh3GiivYNIhX2/BgtjNN2mUDWX8va1DJ/G5lXM=; b=oChSP5qlGlEEKfhTnLo+BQaSubg7y9OhkG1IDNHC+Was7fZQq+gW6xxhZAmGquijrS ebhGQZXw5Bf/go1F0yr7slUYHihE577F0sPFnr2MmIqSk6fVCdG7AI69dTj1fiMl//fc 3q4ph/zigPqwAfUWI5T5Vd+OIzbmENlWpDENVRV05RKREJ5xLyNof+g2+/idwvWKY8BQ CoXG+4GD/KdIg6bQftSGt3K70jg9r6Uvgy5jL4kIiJh0MgyvtXLN6tLcyfjEA+xc7c56 94kufQ4rFhO1hLnUjskdGZGOSUbcfF7GRkdZjTkvvNNVjAvBtYCRGO9uhHm7QQLYubWJ cDoA== MIME-Version: 1.0 X-Received: by 10.224.123.8 with SMTP id n8mr25322971qar.40.1407403299804; Thu, 07 Aug 2014 02:21:39 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Thu, 7 Aug 2014 02:21:39 -0700 (PDT) In-Reply-To: <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> Date: Thu, 7 Aug 2014 17:21:39 +0800 Message-ID: From: GangChen To: Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PNkYTbN-mJCY8jo5gJG39fH6vJQ Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 09:21:42 -0000 2014-08-07 16:39 GMT+08:00, Ross Chandler : > > No. I=E2=80=99m noting that the first stage for a Mobile operator in ado= pting IPv6 > in the user plane is to prepare their RANs and SGSN/MMEs for it. > > When that is done an easy next step is to let visitors from other operato= rs > that are ahead in deploying IPv6 establish IPv6 PDP/PDN connections to th= eir > home GGSN/PGW. > > That scenario can happen, and is happening, already, as per Tore=E2=80=99= s and > others comments. I guess I get your point. Whether the first stage can be done is depending on the business contract. Let's say, if the SGSN in visited networks can't support IPv6 and RAN can't do ROHC, the visited operator have to pay for each function. I guess the business negotiation is probably going to IPv4. But I guess we could try to add sentences in the draft to state how to support IPv6-only roamer. Gang > Ross > > From nobody Thu Aug 7 02:41: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 30F251A01EA for ; Thu, 7 Aug 2014 02:41:25 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mlbkzCuSycC for ; Thu, 7 Aug 2014 02:41:23 -0700 (PDT) Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by ietfa.amsl.com (Postfix) with SMTP id 372951A0648 for ; Thu, 7 Aug 2014 02:41:22 -0700 (PDT) Received: (qmail 87099 messnum 5670159 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 09:41:22 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail09.svc.cra.dublin.eircom.net (qp 87099) with SMTP; 7 Aug 2014 09:41:22 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id blhH1o00W0mJ9Tz01lhMPP; Thu, 07 Aug 2014 10:41:22 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Thu, 7 Aug 2014 10:41:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/elPQdhuEW-jY0WprVEPwuQby6gY Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 09:41:25 -0000 On 7 Aug 2014, at 10:21, GangChen wrote: >=20 > I guess I get your point. Whether the first stage can be done is > depending on the business contract. Let's say, if the SGSN in visited > networks can't support IPv6 and RAN can't do ROHC, the visited > operator have to pay for each function. I guess the business > negotiation is probably going to IPv4. But I guess we could try to add > sentences in the draft to state how to support IPv6-only roamer. >=20 Yes, I think we should. On the commercial aspects RFC 6540 requires IPv6 support in all = IP-Capable nodes.=20 So I assume vendors will support the default IP protocol and not look = for extra payments on top of business as usual spending. My own experience was that all the features I need (except the HLR = PDP-Ext-Type restriction) were just there. Ross From nobody Thu Aug 7 03:47:48 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 21FDC1B2A53 for ; Thu, 7 Aug 2014 03:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 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.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 SRFmMZkuTe_4 for ; Thu, 7 Aug 2014 03:47:45 -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 7E6B61B2A49 for ; Thu, 7 Aug 2014 03:47:44 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP; 07 Aug 2014 12:47:42 +0200 X-IronPort-AV: E=Sophos;i="5.01,817,1400018400"; d="scan'208";a="116972090" Received: from he111510.emea1.cds.t-internal.com ([10.206.92.113]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 07 Aug 2014 12:47:42 +0200 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111510.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 7 Aug 2014 12:47:42 +0200 From: To: Date: Thu, 7 Aug 2014 12:47:40 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt Thread-Index: Ac+yGzETJvCIDhJRRVCPEePdBfKrfgAEYmVA Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> In-Reply-To: <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g8HjQN-QxettB9uodMVx0GjZoMY Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 10:47:47 -0000 > No. I'm noting that the first stage for a Mobile operator in adopting IP= v6 in the user plane is to prepare=20 > their RANs and SGSN/MMEs for it. > When that is done an easy next step is to let visitors from other operato= rs that are ahead in deploying IPv6=20 > establish IPv6 PDP/PDN connections to their home GGSN/PGW. But then, ticking the correct "I am IPv6 capable" and "I am IPv4v6 capable"= boxes in the IR.21 database should not be forgotten... Holger --=20 Holger Metschulat=20 Deutsche Telekom Technik GmbH=20 Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt=20 +49 6151 58 - 18671 (Tel.)=20 +49 160 901 35443 (Mobil)=20 E-Mail: holger.metschulat@telekom.de=20 http://www.telekom.de=20 Erleben, was verbindet.=A0=20 Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtang= aben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken.=20 From nobody Thu Aug 7 03:54: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 7E3521B2A5F for ; Thu, 7 Aug 2014 03:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgxL_zz-xUyW for ; Thu, 7 Aug 2014 03:53:56 -0700 (PDT) Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by ietfa.amsl.com (Postfix) with SMTP id 50AA71B2A5B for ; Thu, 7 Aug 2014 03:53:56 -0700 (PDT) Received: (qmail 6069 messnum 5469359 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 10:53:55 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail01.svc.cra.dublin.eircom.net (qp 6069) with SMTP; 7 Aug 2014 10:53:55 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bmtr1o01C0mJ9Tz01mtujD; Thu, 07 Aug 2014 11:53:55 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Thu, 7 Aug 2014 11:53:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E4A4E4A-321E-4821-85EF-8E1AC29C8528@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> To: holger.metschulat@telekom.de X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/exrzjaUEqCR7TaJCIF7_HnFZYME Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 10:53:58 -0000 On 7 Aug 2014, at 11:47, = wrote: >> No. I'm noting that the first stage for a Mobile operator in = adopting IPv6 in the user plane is to prepare=20 >> their RANs and SGSN/MMEs for it. >=20 >> When that is done an easy next step is to let visitors from other = operators that are ahead in deploying IPv6=20 >> establish IPv6 PDP/PDN connections to their home GGSN/PGW. >=20 > But then, ticking the correct "I am IPv6 capable" and "I am IPv4v6 = capable" boxes in the IR.21 database should not be forgotten... >=20 > Holger Yes. There should be a reference to their IR.21 responsibilities.=20 Ross= From nobody Thu Aug 7 03:57: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 4C13D1B2A6B for ; Thu, 7 Aug 2014 03:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak6nZlDC5wew for ; Thu, 7 Aug 2014 03:57:19 -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 ABACE1B2A5D for ; Thu, 7 Aug 2014 03:57:19 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=60683 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 1XFLNm-00008T-6F; Thu, 07 Aug 2014 12:57:18 +0200 Message-ID: <53E35B3D.3080903@fud.no> Date: Thu, 07 Aug 2014 12:55:57 +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: Ross Chandler References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <3EC4EB99-F877-478D-BFE6-959F58127579@eircom.net> In-Reply-To: <3EC4EB99-F877-478D-BFE6-959F58127579@eircom.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9k7MV_af4kinJsYqlV9YLK2cMdM Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 10:57:21 -0000 * Ross Chandler > Good, glad that you cleared that up. Include them in the next > revision of your draft? Certainly - what do you think about this? http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.appendix.B Tore From nobody Thu Aug 7 04:16: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 761791B2A74 for ; Thu, 7 Aug 2014 04:16:37 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxmWdxQTrqJW for ; Thu, 7 Aug 2014 04:16:36 -0700 (PDT) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by ietfa.amsl.com (Postfix) with SMTP id AC0FD1B2A6D for ; Thu, 7 Aug 2014 04:16:35 -0700 (PDT) Received: (qmail 7344 messnum 3261140 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 11:16:34 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail04.svc.cra.dublin.eircom.net (qp 7344) with SMTP; 7 Aug 2014 11:16:34 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bnGX1o00y0mJ9Tz01nGao8; Thu, 07 Aug 2014 12:16:34 +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: Thu, 7 Aug 2014 12:16:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8Tq_30dbBdhzvLhe8UgPZoSmMso Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 11:16:37 -0000 On 7 Aug 2014, at 11:47, = wrote: > But then, ticking the correct =93I am IPv6 capable" and "I am IPv4v6 = capable" boxes in the IR.21 database should not be forgotten... AFAIK the latest version of IR.21 is version 9.1 (05 July 2013) Relevant sections look like: Section ID: 16 on Packet Data Services Information Section ID: 20 on LTE Roaming Information Both are optional sections, but it is clearly good practise to update = them, and seeing entries being made should help encourage other = operators to also deploy IPv6. Ross= From nobody Thu Aug 7 05:42: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 3A8541A02ED for ; Thu, 7 Aug 2014 05:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, GB_I_LETTER=-2, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 qswZXDdWNJRR for ; Thu, 7 Aug 2014 05:42:30 -0700 (PDT) Received: from atl4mhob16.myregisteredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.109]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF111A0169 for ; Thu, 7 Aug 2014 05:42:22 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob16.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s77CgKhH035844 for ; Thu, 7 Aug 2014 08:42:20 -0400 Received: (qmail 9513 invoked by uid 0); 7 Aug 2014 12:42:20 -0000 X-TCPREMOTEIP: 204.235.115.166 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.71.36.22?) (lee@asgard.org@204.235.115.166) by 0 with ESMTPA; 7 Aug 2014 12:42:19 -0000 User-Agent: Microsoft-MacOutlook/14.4.2.140509 Date: Wed, 06 Aug 2014 19:52:07 -0600 From: Lee Howard To: Philip Homburg , Gert Doering Message-ID: Thread-Topic: [v6ops] Operational Consensus on deployment References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I22e7iM7ULkrhf_M0nhb8lB6j4o Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 12:42:32 -0000 On 8/5/14 3:06 PM, "Philip Homburg" wrote: >In your letter dated Tue, 5 Aug 2014 21:54:02 +0200 you wrote: >>On Tue, Aug 05, 2014 at 09:22:10PM +0200, Philip Homburg wrote: >>> The question is then, why not simply run on RFC-1918 addresses >>>internally? >> >>Why have dual everything inside, when single IPv6 is sufficient to >>achieve service delivery? Dual everything is *dual* *work*, translating >>to real money out in the real world. > >I think it is safe to say that providing good IPv4 service is the most >important requirement. In many cases, it is perfectly fine to not provide >any IPv6 if it cannot be provided at reasonable cost / performance. Is that safe to say? Based on the current discussion, I can't tell if that's the consensus. For instance, is it fine not to provide any IPv4 if it cannot be provided at reasonable cost/performance? I generally say, "IPv6 is not the goal--connectivity is the goal. IPv6 is the solution." The implication is that IPv6 is the solution when IPv4 does not acceptable connectivity (good/fast/cheap enough). > >So what recent proposals are doing to make providing IPv4 more complex >under >the assumption that it is actually important to provide IPv6. > >(note, looking at this from business point of view. Not as somebody who >care about the future of the internet). Layer 8 considerations aren't always appropriate for IETF documents, but it is generally useful to bear them in mind when writing them. So, is there a way to phrase this appropriately? For instance, if growth (for example) is forcing IPv4 to become more complex (or expensive, or to perform poorly), then a proposal that makes IPv4 more complex than it currently is might actually reduce complexity in the future. That could be included as a consideration, use case, or recommendation, if there's consensus for it. > >So instead of doing a relatively straightforward NAT44 or NAT444 and then >let IPv6 pay for itself, you now make the cost of providing IPv6 part of >the >cost of providing IPv4. > >In essence, your IPv4 network now got more expensive. > >In some cases, mobile operators, very big cable ISPs that run out of >RFC-1918, >it makes sense to translate or tunnel IPv4. > >In other cases, this kind of complexity is likely to backfire some time in >future. If, indeed, we're talking specifically about Tore's SIIT document, it would be more useful if we could describe the cases where it does and does not make sense. Would you find it to be useful, then? Lee From nobody Thu Aug 7 05:56: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 4520B1B2A2C for ; Thu, 7 Aug 2014 05:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk00120i0Ddo for ; Thu, 7 Aug 2014 05:56:31 -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 C7D331B29B1 for ; Thu, 7 Aug 2014 05:56:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XFNF3-0000BjC; Thu, 7 Aug 2014 14:56:25 +0200 Message-Id: To: Lee Howard From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-reply-to: Your message of "Wed, 06 Aug 2014 19:52:07 -0600 ." Date: Thu, 07 Aug 2014 14:56:22 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/y7bwlmX4-BEisPKVPa1E3VkI6HI Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 12:56:33 -0000 In your letter dated Wed, 06 Aug 2014 19:52:07 -0600 you wrote: >If, indeed, we're talking specifically about Tore's SIIT document, it >would be more useful if we could describe the cases where it does and does >not make sense. Would you find it to be useful, then? One of my replies to Tore already contains an example. Middle box implements MSS clamping wrong. This breaks IPv4 for any service that has a path MTU of less then the PPPoE MTU. So this would break with the proposed SIIT solution. From nobody Thu Aug 7 05:57: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 89BD71B2ACD for ; Thu, 7 Aug 2014 05:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enxgd6c6Facm for ; Thu, 7 Aug 2014 05:57:02 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c: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 D399F1B2AD6 for ; Thu, 7 Aug 2014 05:57:00 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so4143143wes.28 for ; Thu, 07 Aug 2014 05:56:59 -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=LD2sfIWCAJLWD/aPQUiG1XRYlix0P8vYRB81ohf7mys=; b=BkgCw93TwI99zZLL6UosZL/BGABDrxAQHPkW5Iv45fBbFSG/58Kc0pSMSbX4SByGmg QGyRBc23q6/P5PnGmYgMAICy+Avul1XKfL2ki98MZ1OWfhjXZY0NK/c1BkXo/tmvyW9n 7JlIF5uI5+QVjpIEujtp34Jjn9nK3ZZTYRTPr5wqStp2I34nBEpDUL0259cGX0Jf3bTZ ZaHXb0erAxmC49d34Ycd5+9daY9TUZfEIeKbfBat+ZLeH1k8XE31x9vg9SiHnhgm3UE/ VWDvfe/0wMKmdGUiCRwRnXILmMn3dFreOEJohKEP3yfz0fjtGf5adA6GC1uhrsqAZqBS TIFw== MIME-Version: 1.0 X-Received: by 10.180.81.234 with SMTP id d10mr24478124wiy.79.1407416219488; Thu, 07 Aug 2014 05:56:59 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 05:56:59 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 05:56:59 -0700 (PDT) In-Reply-To: <53E30E74.7050502@fud.no> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> Date: Thu, 7 Aug 2014 05:56:59 -0700 Message-ID: From: Ca By To: Tore Anderson Content-Type: multipart/alternative; boundary=f46d04428134d059eb0500099fd4 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iKwEkAEezSKdgFzSV6_OunqFjHY Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 12:57:08 -0000 --f46d04428134d059eb0500099fd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Aug 6, 2014 10:29 PM, "Tore Anderson" wrote: > > * Ross Chandler > > >> It might be that when the UE visits a network that doesn=E2=80=99t all= ow > >> IPv6 in the user-plane Android behaviour is kicking in. > >> > >> I=E2=80=99ve been told that Android treats all APNs as =E2=80=9Croughl= y equal=E2=80=9D. > >> > >> If the new IPv6-only-without-IPv4-fallback APN fails then Android > >> might be trying the IPv4 one. > > > > If this is what=E2=80=99s going on in Telenor case the plus is it maxim= ises > > the number of roaming partners that come up with IPv6 but at the > > possible cost of indeterminism on which APN the UE settles on using > > when it gets back home. > > I'm fairly certain there is no such indeterminism. > > Basically the UEs get set up to request IPv6 PDP type both home and when > roaming. So when they establish a data bearer they get IPv6 (+464XLAT) > no matter where in the world they are, or they get no data bearer at all > (if there's some sort of problem somewhere). > > That Telenor feels confident in doing it in this manner is very good > news, I think. It reminds me of the World IPv6 Launch, actually - where > it was decided that the bugs and issues that had previously made it > unsafe to deploy IPv6 on a global scale (as opposed to a select few > known good networks, corresponding well to "the home PLMN only" in the > mobile case), has been sufficiently solved so that IPv6 can be made > generally available instead. > > I guess now it's up to Cameron and Micha=C5=82 to follow suit. ;-) > > Tore > > I agree, for my own phone, i roam internationally with no issue on ipv6. CB _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f46d04428134d059eb0500099fd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 6, 2014 10:29 PM, "Tore Anderson" <tore@fud.no> wrote:
>
> * Ross Chandler
>
> >> It might be that when the UE visits a network that doesn=E2= =80=99t allow
> >> IPv6 in the user-plane Android behaviour is kicking in.
> >>
> >> I=E2=80=99ve been told that Android treats all APNs as =E2=80= =9Croughly equal=E2=80=9D.
> >>
> >> If the new IPv6-only-without-IPv4-fallback APN fails then And= roid
> >> might be trying the IPv4 one.
> >
> > If this is what=E2=80=99s going on in Telenor case the plus is it= maximises
> > the number of roaming partners that come up with IPv6 but at the<= br> > > possible cost of indeterminism on which APN the UE settles on usi= ng
> > when it gets back home.
>
> I'm fairly certain there is no such indeterminism.
>
> Basically the UEs get set up to request IPv6 PDP type both home and wh= en
> roaming. So when they establish a data bearer they get IPv6 (+464XLAT)=
> no matter where in the world they are, or they get no data bearer at a= ll
> (if there's some sort of problem somewhere).
>
> That Telenor feels confident in doing it in this manner is very good > news, I think. It reminds me of the World IPv6 Launch, actually - wher= e
> it was decided that the bugs and issues that had previously made it > unsafe to deploy IPv6 on a global scale (as opposed to a select few > known good networks, corresponding well to "the home PLMN only&qu= ot; in the
> mobile case), has been sufficiently solved so that IPv6 can be made > generally available instead.
>
> I guess now it's up to Cameron and Micha=C5=82 to follow suit. ;-)=
>
> Tore
>
>

I agree, for my own phone, i roam internationally with no is= sue on ipv6.

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

--f46d04428134d059eb0500099fd4-- From nobody Thu Aug 7 06:07: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 8CFF81B29E3 for ; Thu, 7 Aug 2014 06:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-WrV6SAXOrM for ; Thu, 7 Aug 2014 06:06:58 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c: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 55A5C1B29CB for ; Thu, 7 Aug 2014 06:06:58 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so4085035wes.23 for ; Thu, 07 Aug 2014 06:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+JCerpvJ2tF+WxaVGC7JFYr9gnOUWUZ9XCqVwOijP5E=; b=utijv8c5e6+a0e+paXwalnbO7n5FVB2svkMDI66ECdP3KCIoE/A+ZC7HZa1smKWHAa bWjomltUZapKAXA9SYL83Tk1k1WM7iMhL1xj8btdJgr3PlsHCMp1okctHAyP10q6WXIK F+3J3MAMGLPqkDz0YmRAt/u3CGGDVBKsGL+f4n893ymvciDz9hmFGh99n00YwsS7SbZN 1P8k+u5ZEkMzVFM4J3bqt2YmPXQIYk7c6q5rHekbYBrLADJ8SLO07uFGN9pP/lD3VF/T gDdUrkPW0HZ/u0JIq0VONkoMmAhVIlwf1VvJiuXlJ6g6JmArKA9PukiJi3l835P/BW9Z br7w== MIME-Version: 1.0 X-Received: by 10.194.222.197 with SMTP id qo5mr25316704wjc.78.1407416816256; Thu, 07 Aug 2014 06:06:56 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 06:06:55 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 06:06:55 -0700 (PDT) In-Reply-To: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> Date: Thu, 7 Aug 2014 06:06:55 -0700 Message-ID: From: Ca By To: Lee Howard Content-Type: multipart/alternative; boundary=001a11c3a99a624f6e050009c33c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/s8zJk7wznnAmtXRHWZEH4RTk2QM Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 13:07:07 -0000 --001a11c3a99a624f6e050009c33c Content-Type: text/plain; charset=UTF-8 On Aug 7, 2014 5:42 AM, "Lee Howard" wrote: > > > > On 8/5/14 3:06 PM, "Philip Homburg" wrote: > > >In your letter dated Tue, 5 Aug 2014 21:54:02 +0200 you wrote: > >>On Tue, Aug 05, 2014 at 09:22:10PM +0200, Philip Homburg wrote: > >>> The question is then, why not simply run on RFC-1918 addresses > >>>internally? > >> > >>Why have dual everything inside, when single IPv6 is sufficient to > >>achieve service delivery? Dual everything is *dual* *work*, translating > >>to real money out in the real world. > > > >I think it is safe to say that providing good IPv4 service is the most > >important requirement. In many cases, it is perfectly fine to not provide > >any IPv6 if it cannot be provided at reasonable cost / performance. > > Is that safe to say? No. 20% of my subscribers are ipv6-only and for them the majority of the traffic is ipv6. For these subscribers, it is quantitatively most important that ipv6 works. Qualitatively, it is most important the most impactful services like facebook, google, and netflix work on ipv6. I am guessing by the end of the year the 20% of subscribers number goes closer to 50%. The 'x factor' is iPhone adopting 464xlat or not. Apple -- please support rfc6877 Regards, CB PS. thanks to msft, windows phone now supports 464xlat. https://dev.windowsphone.com/en-US/OEM/docs/Customization/Additional_Internet_APN_settings :) > Based on the current discussion, I can't tell if that's the consensus. > For instance, is it fine not to provide any IPv4 if it cannot be provided > at reasonable cost/performance? > > I generally say, "IPv6 is not the goal--connectivity is the goal. IPv6 is > the solution." The implication is that IPv6 is the solution when IPv4 > does not acceptable connectivity (good/fast/cheap enough). > > > > >So what recent proposals are doing to make providing IPv4 more complex > >under > >the assumption that it is actually important to provide IPv6. > > > >(note, looking at this from business point of view. Not as somebody who > >care about the future of the internet). > > Layer 8 considerations aren't always appropriate for IETF documents, but > it is generally useful to bear them in mind when writing them. So, is > there a way to phrase this appropriately? > > For instance, if growth (for example) is forcing IPv4 to become more > complex (or expensive, or to perform poorly), then a proposal that makes > IPv4 more complex than it currently is might actually reduce complexity > in the future. That could be included as a consideration, use case, or > recommendation, if there's consensus for it. > > > > > >So instead of doing a relatively straightforward NAT44 or NAT444 and then > >let IPv6 pay for itself, you now make the cost of providing IPv6 part of > >the > >cost of providing IPv4. > > > >In essence, your IPv4 network now got more expensive. > > > >In some cases, mobile operators, very big cable ISPs that run out of > >RFC-1918, > >it makes sense to translate or tunnel IPv4. > > > >In other cases, this kind of complexity is likely to backfire some time in > >future. > > If, indeed, we're talking specifically about Tore's SIIT document, it > would be more useful if we could describe the cases where it does and does > not make sense. Would you find it to be useful, then? > > Lee > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a11c3a99a624f6e050009c33c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2014 5:42 AM, "Lee Howard" <Lee@asgard.org> wrote:
>
>
>
> On 8/5/14 3:06 PM, "Philip Homburg" <pch-v6ops-3@u-1.phicoh.com> wrote:
>
> >In your letter dated Tue, 5 Aug 2014 21:54:02 +0200 you wrote:
> >>On Tue, Aug 05, 2014 at 09:22:10PM +0200, Philip Homburg wrote= :
> >>> The question is then, why not simply run on RFC-1918 addr= esses
> >>>internally?
> >>
> >>Why have dual everything inside, when single IPv6 is sufficien= t to
> >>achieve service delivery? =C2=A0Dual everything is *dual* *wor= k*, translating
> >>to real money out in the real world.
> >
> >I think it is safe to say that providing good IPv4 service is the = most
> >important requirement. In many cases, it is perfectly fine to not = provide
> >any IPv6 if it cannot be provided at reasonable cost / performance= .
>
> Is that safe to say?

No.

20% of my subscribers are ipv6-only and for them the majorit= y of the traffic is ipv6. For these subscribers, it is quantitatively most = important that ipv6 works. Qualitatively, it is most important the most imp= actful services like facebook, google, and netflix work on ipv6.

I am guessing by the end of the year the 20% of subscribers = number goes closer to 50%. The 'x factor' is iPhone adopting 464xla= t or not.

Apple -- please support rfc6877

Regards,

CB

PS. thanks to msft, windows phone now supports 464xlat.

https://dev.windowsphone.com/en-= US/OEM/docs/Customization/Additional_Internet_APN_settings

:)

> Based on the current discussion, I can't tell if th= at's the consensus.
> For instance, is it fine not to provide any IPv4 if it cannot be provi= ded
> at reasonable cost/performance?
>
> I generally say, "IPv6 is not the goal--connectivity is the goal.= IPv6 is
> the solution." =C2=A0The implication is that IPv6 is the solution= when IPv4
> does not acceptable connectivity (good/fast/cheap enough).
>
> >
> >So what recent proposals are doing to make providing IPv4 more com= plex
> >under
> >the assumption that it is actually important to provide IPv6.
> >
> >(note, looking at this from business point of view. Not as somebod= y who
> >care about the future of the internet).
>
> Layer 8 considerations aren't always appropriate for IETF document= s, but
> it is generally useful to bear them in mind when writing them. So, is<= br> > there a way to phrase this appropriately?
>
> For instance, if growth (for example) is forcing IPv4 to become more > complex (or expensive, or to perform poorly), then a proposal that mak= es
> IPv4 more complex than it currently is =C2=A0might actually reduce com= plexity
> in the future. =C2=A0That could be included as a consideration, use ca= se, or
> recommendation, if there's consensus for it.
>
>
> >
> >So instead of doing a relatively straightforward NAT44 or NAT444 a= nd then
> >let IPv6 pay for itself, you now make the cost of providing IPv6 p= art of
> >the
> >cost of providing IPv4.
> >
> >In essence, your IPv4 network now got more expensive.
> >
> >In some cases, mobile operators, very big cable ISPs that run out = of
> >RFC-1918,
> >it makes sense to translate or tunnel IPv4.
> >
> >In other cases, this kind of complexity is likely to backfire some= time in
> >future.
>
> If, indeed, we're talking specifically about Tore's SIIT docum= ent, it
> would be more useful if we could describe the cases where it does and = does
> not make sense. Would you find it to be useful, then?
>
> Lee
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a11c3a99a624f6e050009c33c-- From nobody Thu Aug 7 06:14: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 D751B1B29E1 for ; Thu, 7 Aug 2014 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZijvXCeXS30I for ; Thu, 7 Aug 2014 06:14:07 -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 B9A491B2A3D for ; Thu, 7 Aug 2014 06:13:24 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so10307251igb.3 for ; Thu, 07 Aug 2014 06:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GPtfIke/e8e/hUIdpsVv5X+YwUvBVQoW02g6GJDlPwA=; b=FS4K6DS64WY26UkYOPUdDU+lYy8d8wRQSdro0Q+aKL2imZLMStor74jTmdxanLqm8S CHo+XZu2KYW1zD5pwLM4A7T/ok+qYOXCri9LG6Q8qyPoGRb+X6zrLPULfZSfSqdcqIB0 Nd4dq6hlYfSUpCbaYzPv9vSvVOmKQicjAdmq7F118oCLPj0duFgbw6xMM9zDVn1YRchV ueuiqZdwmZ3zrnSpddh4y34/y+Cg5DtFgoKZaEIujimWDcLR7ZEPzQRJpAa6tb+dXTvP mMkhJ0OlYQL/No+yyDA0tEHll5EnZ/IkJg/pER0GC0UflJqoUbZnBIhUYaRpwGxt3fFj KH4w== 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=GPtfIke/e8e/hUIdpsVv5X+YwUvBVQoW02g6GJDlPwA=; b=Ciz8B5oYtgAge/eQPr+f/qT98Dwc4AOSot8zrojhmXjvbKetvFni/6WlYZ/g3Mz0rN Top9ASqgSMZ9tMSTJwgge6p8/Ki2AADZOm1Xitj8/w3QSQE+7VgBhou0LYR/e5WVo1ZZ tfAgQRJo88YHDaKm4hAkdBlmez+LxucGtAoAfBzQL4ikJEe7XONluUcszvrD+dJAvWrv ZGM4VVRhXiKi1Nx6yWMQcQoA5z2+prcGkA6Uf58HElvf9iN6B9ppm+VHeCPKcs2rmLiV u3wf1j7Irm1uusIqsN2l9YcH9QP83ZetHrVgOTxognOP82Qedfyihgf3jgI2HX+7GS1V 0Jtg== X-Gm-Message-State: ALoCoQnxe1TIE/LG3Ib7bkMimSnbp62oDolj0xfDCNQEtsVoNdOZk6xfeSWH9gfiiUHOZVzZXQwd X-Received: by 10.50.117.106 with SMTP id kd10mr28691856igb.5.1407417204005; Thu, 07 Aug 2014 06:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.5.6 with HTTP; Thu, 7 Aug 2014 06:13:02 -0700 (PDT) In-Reply-To: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Aug 2014 22:13:02 +0900 Message-ID: To: Ca By Content-Type: multipart/alternative; boundary=089e0139fb627f0e76050009da9a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Gd4JScyoRzP_4Vf8ftAKcVXiIJM Cc: Tore Anderson , IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 13:14:09 -0000 --089e0139fb627f0e76050009da9a Content-Type: text/plain; charset=UTF-8 On Thu, Aug 7, 2014 at 10:06 PM, Ca By wrote: > > >I think it is safe to say that providing good IPv4 service is the most > > >important requirement. In many cases, it is perfectly fine to not > provide > > >any IPv6 if it cannot be provided at reasonable cost / performance. > > > > Is that safe to say? > > No. > > 20% of my subscribers are ipv6-only and for them the majority of the > traffic is ipv6. For these subscribers, it is quantitatively most important > that ipv6 works. Qualitatively, it is most important the most impactful > services like facebook, google, and netflix work on ipv6. > Right. An operator cannot afford not to provide IPv4, because "that's not Internet". But if the majority of traffic is IPv6, then the operator can provide proportionally lower quality of service to IPv4 without disrupting user experience. A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's only used for 5% of traffic, then the operator might just say, "Who cares? I don't; and if somebody else does, they're free to use IPv6." --089e0139fb627f0e76050009da9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 7, 2014 at 10:06 PM, Ca By <cb.list6@gmail.com> wro= te:

> >I think it is safe to say that prov= iding good IPv4 service is the most
> >important requirement. In many cases, it is perfectly fine to not = provide
> >any IPv6 if it cannot be provided at reasonable cost / performance= .
>
> Is that safe to say?

No.

20% of my subscribers are ipv6-only and for them the majorit= y of the traffic is ipv6. For these subscribers, it is quantitatively most = important that ipv6 works. Qualitatively, it is most important the most imp= actful services like facebook, google, and netflix work on ipv6.

Right. An operator cannot afford not to provide IPv4, bec= ause "that's not Internet". But if the majority of traffic is= IPv6, then the operator can provide proportionally lower quality of servic= e to IPv4 without disrupting user experience.

A 4G handset with 464xlat will have ~50% of traffic nat= ive IPv6, ~45% NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle,= but if it's only used for 5% of traffic, then the operator might just = say, "Who cares? I don't; and if somebody else does, they're f= ree to use IPv6."
--089e0139fb627f0e76050009da9a-- From nobody Thu Aug 7 06:17: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 590C71B2A3D for ; Thu, 7 Aug 2014 06:16:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 eKanKN196tcQ for ; Thu, 7 Aug 2014 06:16:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2231B2AD6 for ; Thu, 7 Aug 2014 06:16:16 -0700 (PDT) Received: from BLUPR04MB596.namprd04.prod.outlook.com (10.141.202.147) by BLUPR04MB008.namprd04.prod.outlook.com (10.255.210.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 13:16:07 +0000 Received: from BLUPR04MB596.namprd04.prod.outlook.com (10.141.202.147) by BLUPR04MB596.namprd04.prod.outlook.com (10.141.202.147) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 7 Aug 2014 13:16:05 +0000 Received: from BLUPR04MB596.namprd04.prod.outlook.com ([10.141.202.147]) by BLUPR04MB596.namprd04.prod.outlook.com ([10.141.202.147]) with mapi id 15.00.1005.008; Thu, 7 Aug 2014 13:16:05 +0000 From: Dave Michaud To: Ca By , Tore Anderson Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt Thread-Index: AQHPsj8hdINvZr24nUuvFzCdc8KDrJvFHcZg Date: Thu, 7 Aug 2014 13:16:05 +0000 Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [162.208.80.15] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(377454003)(55674003)(19580395003)(19580405001)(83322001)(101416001)(46102001)(106356001)(81542001)(106116001)(19273905006)(85306004)(19625215002)(19300405004)(93886004)(15202345003)(107046002)(105586002)(33646002)(15975445006)(99286002)(19617315012)(95666004)(74316001)(76576001)(20776003)(64706001)(4396001)(80022001)(21056001)(66066001)(76176999)(81342001)(50986999)(76482001)(54356999)(87936001)(77982001)(86362001)(16236675004)(85852003)(83072002)(99396002)(2656002)(74502001)(74662001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR04MB596; H:BLUPR04MB596.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; LANG:en; Content-Type: multipart/alternative; boundary="_000_f6347a8cb7cf49f19bc994efc6b66a25BLUPR04MB596namprd04pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: rci.rogers.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/t8jy32W9RaiEFE6vJt76elPmMeA Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 13:16:28 -0000 X-List-Received-Date: Thu, 07 Aug 2014 13:16:28 -0000 --_000_f6347a8cb7cf49f19bc994efc6b66a25BLUPR04MB596namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SVB2NHY2IGlzIGJyb2tlbiB3aGVuIHJvYW1pbmcsIHRoYXQgaXMgYSBmYWN0IGFuZCBJIGhhdmUg YSBodWdlIGxpc3Qgb2YgcHJvdmlkZXJzIHRoYXQgYXJlIGJyb2tlbiBpbiB0aGF0IHNjZW5hcmlv Lg0KDQpBcyBmb3IgSVB2NiB3aGlsZSByb2FtaW5nLCBpdCBoYXMgYmVlbiBzdXBwb3J0ZWQgZm9y IGEgbG9uZyB0aW1lIGJ1dCB0aGVyZSBpcyBzdGlsbCBhIGZhaXIgc2hhcmUgb2Ygb3BlcmF0b3Jz IHdobyBmb3IgdmFyaW91cyByZWFzb25zIGRvbuKAmXQgYWxsb3cgaXQuDQoNCldoZW4gSeKAmW0g YWJyb2FkLCBJIGFsd2F5cyBtYWtlIGEgcG9pbnQgdG8gdGVzdCBhbGwgb3BlcmF0b3JzIG9uIElQ djYtb25seSBhbmQgYWx3YXlzIHNlZSBhIGxvdCBvZiBmYWlsdXJlLiBUaGlzIGJlY29tZXMgZXNw ZWNpYWxseSBhcHBhcmVudCBpZiB0aGUgaG9tZSBvcGVyYXRvciBwZXJmb3JtcyBzb21lIHN0ZWVy aW5nIG9mIHJvYW1pbmcgdGFyZ2V0ZWQgdG8gYW4gb3BlcmF0b3IgdGhhdCBkb2VzbuKAmXQgYWxs b3cgSVB2Ni4NCg0KVGhhdOKAmXMgd2h5IGluIHRoZSBtZWFudGltZSwgd2UgYXJlIGRvaW5nIElQ djYgYXQgaG9tZSBhbmQgSVB2NCB3aGlsZSByb2FtaW5nICh3aXRoIHRoZSBBUE4gY29uZmlndXJl ZCB0byBzdXBwb3J0IGJvdGggb24gdGhlIGNvcmUgbmV0d29yaykuDQoNCkRhdmUgTWljaGF1ZA0K DQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBDYSBCeQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAxNCA4OjU3IEFNDQpUbzogVG9y ZSBBbmRlcnNvbg0KQ2M6IElQdjYgT3BzIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWlwdjYtcm9hbWluZy1hbmFseXNpcy0wMi50eHQNCg0KDQpP biBBdWcgNiwgMjAxNCAxMDoyOSBQTSwgIlRvcmUgQW5kZXJzb24iIDx0b3JlQGZ1ZC5ubzxtYWls dG86dG9yZUBmdWQubm8+PiB3cm90ZToNCj4NCj4gKiBSb3NzIENoYW5kbGVyDQo+DQo+ID4+IEl0 IG1pZ2h0IGJlIHRoYXQgd2hlbiB0aGUgVUUgdmlzaXRzIGEgbmV0d29yayB0aGF0IGRvZXNu4oCZ dCBhbGxvdw0KPiA+PiBJUHY2IGluIHRoZSB1c2VyLXBsYW5lIEFuZHJvaWQgYmVoYXZpb3VyIGlz IGtpY2tpbmcgaW4uDQo+ID4+DQo+ID4+IEnigJl2ZSBiZWVuIHRvbGQgdGhhdCBBbmRyb2lkIHRy ZWF0cyBhbGwgQVBOcyBhcyDigJxyb3VnaGx5IGVxdWFs4oCdLg0KPiA+Pg0KPiA+PiBJZiB0aGUg bmV3IElQdjYtb25seS13aXRob3V0LUlQdjQtZmFsbGJhY2sgQVBOIGZhaWxzIHRoZW4gQW5kcm9p ZA0KPiA+PiBtaWdodCBiZSB0cnlpbmcgdGhlIElQdjQgb25lLg0KPiA+DQo+ID4gSWYgdGhpcyBp cyB3aGF04oCZcyBnb2luZyBvbiBpbiBUZWxlbm9yIGNhc2UgdGhlIHBsdXMgaXMgaXQgbWF4aW1p c2VzDQo+ID4gdGhlIG51bWJlciBvZiByb2FtaW5nIHBhcnRuZXJzIHRoYXQgY29tZSB1cCB3aXRo IElQdjYgYnV0IGF0IHRoZQ0KPiA+IHBvc3NpYmxlIGNvc3Qgb2YgaW5kZXRlcm1pbmlzbSBvbiB3 aGljaCBBUE4gdGhlIFVFIHNldHRsZXMgb24gdXNpbmcNCj4gPiB3aGVuIGl0IGdldHMgYmFjayBo b21lLg0KPg0KPiBJJ20gZmFpcmx5IGNlcnRhaW4gdGhlcmUgaXMgbm8gc3VjaCBpbmRldGVybWlu aXNtLg0KPg0KPiBCYXNpY2FsbHkgdGhlIFVFcyBnZXQgc2V0IHVwIHRvIHJlcXVlc3QgSVB2NiBQ RFAgdHlwZSBib3RoIGhvbWUgYW5kIHdoZW4NCj4gcm9hbWluZy4gU28gd2hlbiB0aGV5IGVzdGFi bGlzaCBhIGRhdGEgYmVhcmVyIHRoZXkgZ2V0IElQdjYgKCs0NjRYTEFUKQ0KPiBubyBtYXR0ZXIg d2hlcmUgaW4gdGhlIHdvcmxkIHRoZXkgYXJlLCBvciB0aGV5IGdldCBubyBkYXRhIGJlYXJlciBh dCBhbGwNCj4gKGlmIHRoZXJlJ3Mgc29tZSBzb3J0IG9mIHByb2JsZW0gc29tZXdoZXJlKS4NCj4N Cj4gVGhhdCBUZWxlbm9yIGZlZWxzIGNvbmZpZGVudCBpbiBkb2luZyBpdCBpbiB0aGlzIG1hbm5l ciBpcyB2ZXJ5IGdvb2QNCj4gbmV3cywgSSB0aGluay4gSXQgcmVtaW5kcyBtZSBvZiB0aGUgV29y bGQgSVB2NiBMYXVuY2gsIGFjdHVhbGx5IC0gd2hlcmUNCj4gaXQgd2FzIGRlY2lkZWQgdGhhdCB0 aGUgYnVncyBhbmQgaXNzdWVzIHRoYXQgaGFkIHByZXZpb3VzbHkgbWFkZSBpdA0KPiB1bnNhZmUg dG8gZGVwbG95IElQdjYgb24gYSBnbG9iYWwgc2NhbGUgKGFzIG9wcG9zZWQgdG8gYSBzZWxlY3Qg ZmV3DQo+IGtub3duIGdvb2QgbmV0d29ya3MsIGNvcnJlc3BvbmRpbmcgd2VsbCB0byAidGhlIGhv bWUgUExNTiBvbmx5IiBpbiB0aGUNCj4gbW9iaWxlIGNhc2UpLCBoYXMgYmVlbiBzdWZmaWNpZW50 bHkgc29sdmVkIHNvIHRoYXQgSVB2NiBjYW4gYmUgbWFkZQ0KPiBnZW5lcmFsbHkgYXZhaWxhYmxl IGluc3RlYWQuDQo+DQo+IEkgZ3Vlc3Mgbm93IGl0J3MgdXAgdG8gQ2FtZXJvbiBhbmQgTWljaGHF giB0byBmb2xsb3cgc3VpdC4gOy0pDQo+DQo+IFRvcmUNCj4NCj4NCg0KSSBhZ3JlZSwgZm9yIG15 IG93biBwaG9uZSwgaSByb2FtIGludGVybmF0aW9uYWxseSB3aXRoIG5vIGlzc3VlIG9uIGlwdjYu DQoNCkNCIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LnJvZ2Vycy5jb20vd2ViL2NvbnRlbnQvZW1h aWxub3RpY2U8aHR0cDovL3d3dy5yb2dlcnMuY29tL3dlYi9jb250ZW50L2VtYWlsbm90aWNlPg0K DQoNCg0KQ2UgbWVzc2FnZSBlc3QgY29uZmlkZW50aWVsLiBOb3RyZSB0cmFuc21pc3Npb24gZXQg csOpY2VwdGlvbiBkZSBjb3VycmllbHMgc2UgZmFpdCBzdHJpY3RlbWVudCBzdWl2YW50IGxlcyBt b2RhbGl0w6lzIMOpbm9uY8OpZXMgZGFucyBs4oCZYXZpcyBwdWJsacOpIMOgIHd3dy5yb2dlcnMu Y29tL2F2aXNjb3VycmllbCA8aHR0cDovL3d3dy5yb2dlcnMuY29tL2F2aXNjb3VycmllbD4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= --_000_f6347a8cb7cf49f19bc994efc6b66a25BLUPR04MB596namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDZW50dXJ5IEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA1IDIgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JUHY0djYgaXMgYnJva2VuIHdoZW4gcm9hbWluZywgdGhh dCBpcyBhIGZhY3QgYW5kIEkgaGF2ZSBhIGh1Z2UgbGlzdCBvZiBwcm92aWRlcnMgdGhhdCBhcmUg YnJva2VuIGluIHRoYXQgc2NlbmFyaW8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBmb3IgSVB2NiB3aGlsZSByb2Ft aW5nLCBpdCBoYXMgYmVlbiBzdXBwb3J0ZWQgZm9yIGEgbG9uZyB0aW1lIGJ1dCB0aGVyZSBpcyBz dGlsbCBhIGZhaXIgc2hhcmUgb2Ygb3BlcmF0b3JzIHdobyBmb3IgdmFyaW91cyByZWFzb25zIGRv buKAmXQgYWxsb3cgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuIEnigJltIGFicm9hZCwgSSBhbHdheXMgbWFr ZSBhIHBvaW50IHRvIHRlc3QgYWxsIG9wZXJhdG9ycyBvbiBJUHY2LW9ubHkgYW5kIGFsd2F5cyBz ZWUgYSBsb3Qgb2YgZmFpbHVyZS4gVGhpcyBiZWNvbWVzIGVzcGVjaWFsbHkgYXBwYXJlbnQgaWYg dGhlIGhvbWUgb3BlcmF0b3INCiBwZXJmb3JtcyBzb21lIHN0ZWVyaW5nIG9mIHJvYW1pbmcgdGFy Z2V0ZWQgdG8gYW4gb3BlcmF0b3IgdGhhdCBkb2VzbuKAmXQgYWxsb3cgSVB2Ni48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoYXTigJlzIHdoeSBpbiB0aGUgbWVhbnRpbWUsIHdlIGFyZSBkb2luZyBJUHY2IGF0IGhvbWUg YW5kIElQdjQgd2hpbGUgcm9hbWluZyAod2l0aCB0aGUgQVBOIGNvbmZpZ3VyZWQgdG8gc3VwcG9y dCBib3RoIG9uIHRoZSBjb3JlIG5ldHdvcmspLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2VudHVyeSBHb3RoaWMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+RGF2ZSBNaWNoYXVkPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNhIEJ5PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBBdWd1c3QgMDcsIDIwMTQgODo1NyBBTTxicj4NCjxiPlRvOjwvYj4gVG9yZSBBbmRlcnNvbjxi cj4NCjxiPkNjOjwvYj4gSVB2NiBPcHMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9w c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LXJvYW1pbmctYW5hbHlzaXMtMDIu dHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PGJyPg0KT24gQXVnIDYsIDIwMTQgMTA6 MjkgUE0sICZxdW90O1RvcmUgQW5kZXJzb24mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3Jl QGZ1ZC5ubyI+dG9yZUBmdWQubm88L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAq IFJvc3MgQ2hhbmRsZXI8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJdCBtaWdodCBiZSB0 aGF0IHdoZW4gdGhlIFVFIHZpc2l0cyBhIG5ldHdvcmsgdGhhdCBkb2VzbuKAmXQgYWxsb3c8YnI+ DQomZ3Q7ICZndDsmZ3Q7IElQdjYgaW4gdGhlIHVzZXItcGxhbmUgQW5kcm9pZCBiZWhhdmlvdXIg aXMga2lja2luZyBpbi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJ4oCZ dmUgYmVlbiB0b2xkIHRoYXQgQW5kcm9pZCB0cmVhdHMgYWxsIEFQTnMgYXMg4oCccm91Z2hseSBl cXVhbOKAnS48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJZiB0aGUgbmV3 IElQdjYtb25seS13aXRob3V0LUlQdjQtZmFsbGJhY2sgQVBOIGZhaWxzIHRoZW4gQW5kcm9pZDxi cj4NCiZndDsgJmd0OyZndDsgbWlnaHQgYmUgdHJ5aW5nIHRoZSBJUHY0IG9uZS48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgdGhpcyBpcyB3aGF04oCZcyBnb2luZyBvbiBpbiBUZWxl bm9yIGNhc2UgdGhlIHBsdXMgaXMgaXQgbWF4aW1pc2VzPGJyPg0KJmd0OyAmZ3Q7IHRoZSBudW1i ZXIgb2Ygcm9hbWluZyBwYXJ0bmVycyB0aGF0IGNvbWUgdXAgd2l0aCBJUHY2IGJ1dCBhdCB0aGU8 YnI+DQomZ3Q7ICZndDsgcG9zc2libGUgY29zdCBvZiBpbmRldGVybWluaXNtIG9uIHdoaWNoIEFQ TiB0aGUgVUUgc2V0dGxlcyBvbiB1c2luZzxicj4NCiZndDsgJmd0OyB3aGVuIGl0IGdldHMgYmFj ayBob21lLjxicj4NCiZndDs8YnI+DQomZ3Q7IEknbSBmYWlybHkgY2VydGFpbiB0aGVyZSBpcyBu byBzdWNoIGluZGV0ZXJtaW5pc20uPGJyPg0KJmd0Ozxicj4NCiZndDsgQmFzaWNhbGx5IHRoZSBV RXMgZ2V0IHNldCB1cCB0byByZXF1ZXN0IElQdjYgUERQIHR5cGUgYm90aCBob21lIGFuZCB3aGVu PGJyPg0KJmd0OyByb2FtaW5nLiBTbyB3aGVuIHRoZXkgZXN0YWJsaXNoIGEgZGF0YSBiZWFyZXIg dGhleSBnZXQgSVB2NiAoJiM0Mzs0NjRYTEFUKTxicj4NCiZndDsgbm8gbWF0dGVyIHdoZXJlIGlu IHRoZSB3b3JsZCB0aGV5IGFyZSwgb3IgdGhleSBnZXQgbm8gZGF0YSBiZWFyZXIgYXQgYWxsPGJy Pg0KJmd0OyAoaWYgdGhlcmUncyBzb21lIHNvcnQgb2YgcHJvYmxlbSBzb21ld2hlcmUpLjxicj4N CiZndDs8YnI+DQomZ3Q7IFRoYXQgVGVsZW5vciBmZWVscyBjb25maWRlbnQgaW4gZG9pbmcgaXQg aW4gdGhpcyBtYW5uZXIgaXMgdmVyeSBnb29kPGJyPg0KJmd0OyBuZXdzLCBJIHRoaW5rLiBJdCBy ZW1pbmRzIG1lIG9mIHRoZSBXb3JsZCBJUHY2IExhdW5jaCwgYWN0dWFsbHkgLSB3aGVyZTxicj4N CiZndDsgaXQgd2FzIGRlY2lkZWQgdGhhdCB0aGUgYnVncyBhbmQgaXNzdWVzIHRoYXQgaGFkIHBy ZXZpb3VzbHkgbWFkZSBpdDxicj4NCiZndDsgdW5zYWZlIHRvIGRlcGxveSBJUHY2IG9uIGEgZ2xv YmFsIHNjYWxlIChhcyBvcHBvc2VkIHRvIGEgc2VsZWN0IGZldzxicj4NCiZndDsga25vd24gZ29v ZCBuZXR3b3JrcywgY29ycmVzcG9uZGluZyB3ZWxsIHRvICZxdW90O3RoZSBob21lIFBMTU4gb25s eSZxdW90OyBpbiB0aGU8YnI+DQomZ3Q7IG1vYmlsZSBjYXNlKSwgaGFzIGJlZW4gc3VmZmljaWVu dGx5IHNvbHZlZCBzbyB0aGF0IElQdjYgY2FuIGJlIG1hZGU8YnI+DQomZ3Q7IGdlbmVyYWxseSBh dmFpbGFibGUgaW5zdGVhZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGd1ZXNzIG5vdyBpdCdzIHVw IHRvIENhbWVyb24gYW5kIE1pY2hhxYIgdG8gZm9sbG93IHN1aXQuIDstKTxicj4NCiZndDs8YnI+ DQomZ3Q7IFRvcmU8YnI+DQomZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhZ3Jl ZSwgZm9yIG15IG93biBwaG9uZSwgaSByb2FtIGludGVybmF0aW9uYWxseSB3aXRoIG5vIGlzc3Vl IG9uIGlwdjYuPG86cD48L286cD48L3A+DQo8cD5DQiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8aHIg d2lkdGg9IjEwMCUiPg0KVGhpcyBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gV2Ugb25s eSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91 dCBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5yb2dlcnMuY29tL3dlYi9jb250ZW50L2VtYWlsbm90 aWNlIj53d3cucm9nZXJzLmNvbS93ZWIvY29udGVudC9lbWFpbG5vdGljZTwvYT48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpDZSBtZXNzYWdlIGVzdCBjb25maWRlbnRpZWwuIE5vdHJlIHRyYW5zbWlz c2lvbiBldCByw6ljZXB0aW9uIGRlIGNvdXJyaWVscyBzZSBmYWl0IHN0cmljdGVtZW50IHN1aXZh bnQgbGVzIG1vZGFsaXTDqXMgw6lub25jw6llcyBkYW5zIGzigJlhdmlzIHB1Ymxpw6kgw6ANCjxh IGhyZWY9Imh0dHA6Ly93d3cucm9nZXJzLmNvbS9hdmlzY291cnJpZWwNCiI+d3d3LnJvZ2Vycy5j b20vYXZpc2NvdXJyaWVsIDwvYT4NCjxociB3aWR0aD0iMTAwJSI+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_f6347a8cb7cf49f19bc994efc6b66a25BLUPR04MB596namprd04pro_-- From nobody Thu Aug 7 06:18: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 19DC51B2AF7 for ; Thu, 7 Aug 2014 06:18:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk09qCG9rjhz for ; Thu, 7 Aug 2014 06:18:32 -0700 (PDT) Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by ietfa.amsl.com (Postfix) with SMTP id 44E321B2AF3 for ; Thu, 7 Aug 2014 06:17:51 -0700 (PDT) Received: (qmail 96755 messnum 13147585 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 13:17:50 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail05.svc.cra.dublin.eircom.net (qp 96755) with SMTP; 7 Aug 2014 13:17:50 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bpHm1o00q0mJ9Tz01pHpx6; Thu, 07 Aug 2014 14:17:50 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_0BC3573E-3E73-45E4-AFD7-F4CF1DBF1C9C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Thu, 7 Aug 2014 14:17:45 +0100 Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> To: Ca By , IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CXLiyG21pX-Wr5RxD567NnmU8c4 Cc: Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 13:18:47 -0000 --Apple-Mail=_0BC3573E-3E73-45E4-AFD7-F4CF1DBF1C9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Aug 2014, at 13:56, Ca By wrote: > I agree, for my own phone, i roam internationally with no issue on = ipv6. >=20 > CB=20 >=20 Cameron, Are you saying the support for IPv6 in the user-plane for visitors is = good enough for enthuasists willing to toggle their APN protocol setting = when they roam or that the position is already so good that we can all = start copying Telenor? BR Ross= --Apple-Mail=_0BC3573E-3E73-45E4-AFD7-F4CF1DBF1C9C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 7 Aug 2014, at 13:56, Ca By <cb.list6@gmail.com> wrote:

I agree, for my own phone, i roam internationally with no issue on ipv6.

CB 

Cameron,

Are you saying the support for IPv6 in the user-plane for visitors is good enough for enthuasists willing to toggle their APN protocol setting when they roam or that the position is already so good that we can all start copying Telenor?

BR
Ross
--Apple-Mail=_0BC3573E-3E73-45E4-AFD7-F4CF1DBF1C9C-- From nobody Thu Aug 7 06:35: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 614F11B2B1A for ; Thu, 7 Aug 2014 06:35:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKV9lr8OwxIq for ; Thu, 7 Aug 2014 06:35:40 -0700 (PDT) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by ietfa.amsl.com (Postfix) with SMTP id 609E81B2B20 for ; Thu, 7 Aug 2014 06:35:40 -0700 (PDT) Received: (qmail 25385 messnum 3163334 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 13:35:39 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail04.svc.cra.dublin.eircom.net (qp 25385) with SMTP; 7 Aug 2014 13:35:39 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bpbb1o00m0mJ9Tz01pbf7j; Thu, 07 Aug 2014 14:35:39 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_156F181D-0E26-40FA-A440-458069E6D198" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Thu, 7 Aug 2014 14:35:34 +0100 Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> To: Dave Michaud , IPv6 Ops WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qF1NeScTByHKXTUNCOvRXv54CK0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 13:35:45 -0000 --Apple-Mail=_156F181D-0E26-40FA-A440-458069E6D198 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 7 Aug 2014, at 14:16, Dave Michaud = wrote: > When I=92m abroad, I always make a point to test all operators on = IPv6-only and always see a lot of failure. This becomes especially = apparent if the home operator performs some steering of roaming targeted = to an operator that doesn=92t allow IPv6. > Dave Michaud Steering of roaming sounds like a failure mode that should be mentioned = in the draft. BR Ross --Apple-Mail=_156F181D-0E26-40FA-A440-458069E6D198 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

= --Apple-Mail=_156F181D-0E26-40FA-A440-458069E6D198-- From nobody Thu Aug 7 06:59: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 CC1D61B2B3D for ; Thu, 7 Aug 2014 06:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7cmizuHJuQ4 for ; Thu, 7 Aug 2014 06:58:57 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 7127F1B2B3B for ; Thu, 7 Aug 2014 06:58:57 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so5073564wib.11 for ; Thu, 07 Aug 2014 06:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IY8KEtlq79nhNwXYvK5v7ESlZdM5bBFfzzGZxG66tDA=; b=Z/B7q3bxh7jD7yff3GWf0LreeTINMAfIjV4EgOEZA5njUzUuBCqb+Vqzj/V4q/cgKe CADd8hM68csKWa0vNUgOEFfHeOa/WaMJgwWahd6fAoOQtFm76HTYV03llOSt9iMG9fbz k5v5SOHOv5ixELKV4v8mKsiQQauTIiW3/0hyohoc5WMVpc7veOdSH50g3ZlfDd1IIBuO i+9+2TZ7x0AANNxmMStLS/gwQrjq9KVgjuo0FyHfKMNXm5Es0z9PW6Bq9F4W1AQarDFp X0iYbIZN2M5lvDzj0pSSNooZotnP6h+sFpgBcw3el/wbnnc1CKatU+yWcfBVyARvIZqH j0wQ== MIME-Version: 1.0 X-Received: by 10.194.89.106 with SMTP id bn10mr24787895wjb.121.1407419936091; Thu, 07 Aug 2014 06:58:56 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 06:58:55 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 06:58:55 -0700 (PDT) In-Reply-To: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> Date: Thu, 7 Aug 2014 06:58:55 -0700 Message-ID: From: Ca By To: Ross Chandler Content-Type: multipart/alternative; boundary=089e0102e29857361905000a7d2e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jdb7gpWeH4eMcIRNesyRUDJ8ctU Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 13:58:59 -0000 --089e0102e29857361905000a7d2e Content-Type: text/plain; charset=UTF-8 On Aug 7, 2014 6:17 AM, "Ross Chandler" wrote: > > > On 7 Aug 2014, at 13:56, Ca By wrote: > >> I agree, for my own phone, i roam internationally with no issue on ipv6. >> >> CB > > Cameron, > > Are you saying the support for IPv6 in the user-plane for visitors is good enough for enthuasists willing to toggle their APN protocol setting when they roam or that the position is already so good that we can all start copying Telenor? > > BR > Ross If Telenor has taken this leadership position, then i expect those few lingering issues to be resolved quickly with the problem network operators. It is worth revisiting the data before changing default settings. In my own network, roaming makes up for a very small percentage of ip address usage, so the benefit is not very high CB --089e0102e29857361905000a7d2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2014 6:17 AM, "Ross Chandler" <ross@eircom.net> wrote:
>
>
> On 7 Aug 2014, at 13:56, Ca By <cb.list6@gmail.com> wrote:
>
>> I agree, for my own phone, i roam internationally with no issue on= ipv6.
>>
>> CB=C2=A0
>
> Cameron,
>
> Are you saying the support for IPv6 in the user-plane for visitors is = good enough for enthuasists willing to toggle their APN protocol setting wh= en they roam or that the position is already so good that we can all start = copying Telenor?
>
> BR
> Ross

If Telenor has taken this leadership position, then i expect= those few lingering issues to be resolved quickly with the problem network= operators.

It is worth revisiting the data before changing default sett= ings.

In my own network,=C2=A0 roaming makes up for a very small p= ercentage of ip address usage, so the benefit is not very high

CB

--089e0102e29857361905000a7d2e-- From nobody Thu Aug 7 08:32: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 F1F131B2C0D for ; Thu, 7 Aug 2014 08:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY79Esd3fdOP for ; Thu, 7 Aug 2014 08:32:38 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565691B2B34 for ; Thu, 7 Aug 2014 08:32:37 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1F7DE60979 for ; Thu, 7 Aug 2014 17:32:21 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E160160965 for ; Thu, 7 Aug 2014 17:32:20 +0200 (CEST) Received: (qmail 3316 invoked by uid 1007); 7 Aug 2014 17:32:20 +0200 Date: Thu, 7 Aug 2014 17:32:20 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20140807153220.GN51793@Space.Net> References: <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m00IWhzRExnxmaci" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sYGN0VaKRqeDabECyDzsi-wBwUE Cc: Tore Anderson , IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:32:44 -0000 --m00IWhzRExnxmaci Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi, On Thu, Aug 07, 2014 at 02:56:22PM +0200, Philip Homburg wrote: > One of my replies to Tore already contains an example. Middle box impleme= nts > MSS clamping wrong. This breaks IPv4 for any service that has a path MTU = of > less then the PPPoE MTU. "Broken Middleboxes break Service Delivery", news at 11. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --m00IWhzRExnxmaci Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU+OcBN9WwGXkzn/FAQKYsRAAk1aVALzQMoV/oJIxqVYXt9fAc3qI32cc yttKiP5GTS/EaM5HK9fl4JLVqi5ysnNQfNoV2qnxQRxV9QTKjy9gkCLCdnBg1bKZ YRVYC+a5jh+IFjnLwzQQhtsFhvlEOVAeGnxY3tLhWWBT0m3zCEgJ51+mK2uxvxOO ewE6UsNr4EkMGeC8FZ8GHGB9Dead77ALe/1Px62+I51IcIWEvb3wQLW3pZ4miIE5 vZSJZK5AAyzl2RrafFOzFpZtTMPjUx7xS9hdg+873CGFxrRkYFmzy5wK+cGgsovf RqHWUwXxjm1E5vfyEheV1ckx9lIjPihr6TbO11Y32D6IjT0qLQzqWYRtvjFxu7QM KMAqFF8o5C/eaBx2KKUidSffcTOYzszEuQmYjGwhJu7PAdYLML0uPR0LGtujCl3R sHCwXGnIyru97IX4ptnpj3CP80D6WrA76nobe2y4whUdjSfliqsAgxCzfdEkjNv+ BFsRe+jG2e4/rHtoxSdZADF/1NBs3cPalsnMHMG6sK7ZLFfLq7xGXGECBohB6vm6 JuaGsuIuOSkmWfbfjHBx3yw6S3fXr7svFvS4ur+N2HHMOE2RbHYN7f0VlUpgf4e3 2wFl9dqxByBFFxbiq1xtC/utd9dUs0wy6bdwXMfLwtmmRSq4pn1dQ0Z6Ss6Uh5Ck 5IOLMBsXkgk= =0FCP -----END PGP SIGNATURE----- --m00IWhzRExnxmaci-- From nobody Thu Aug 7 09:06: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 719DD1B2DF2 for ; Thu, 7 Aug 2014 09:06:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgsDAu3xiRiJ for ; Thu, 7 Aug 2014 09:06:39 -0700 (PDT) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by ietfa.amsl.com (Postfix) with SMTP id 8911B1B282D for ; Thu, 7 Aug 2014 09:06:39 -0700 (PDT) Received: (qmail 46499 messnum 3159332 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 7 Aug 2014 16:06:38 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail04.svc.cra.dublin.eircom.net (qp 46499) with SMTP; 7 Aug 2014 16:06:38 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bs6a1o01U0mJ9Tz01s6dwu; Thu, 07 Aug 2014 17:06:38 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_ED2989C1-6E2E-4EDF-96D2-07F3EA35C9CC" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Thu, 7 Aug 2014 17:06:33 +0100 Message-Id: <820FDCAA-016D-4CA8-A90B-AE39473A0CCC@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> To: Ca By X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8PHee44zuwRlV4Zup6J_IPTyjjI Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 07 Aug 2014 16:06:41 -0000 --Apple-Mail=_ED2989C1-6E2E-4EDF-96D2-07F3EA35C9CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Aug 2014, at 14:58, Ca By wrote: > If Telenor has taken this leadership position, then i expect those few = lingering issues to be resolved quickly with the problem network = operators. >=20 Exciting times. This should be a further catalyst for progress. Ross= --Apple-Mail=_ED2989C1-6E2E-4EDF-96D2-07F3EA35C9CC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 7 Aug 2014, at 14:58, Ca By <cb.list6@gmail.com> wrote:

If Telenor has taken this leadership position, then i expect those few lingering issues to be resolved quickly with the problem network operators.

Exciting times. This should be a further catalyst for progress.

Ross
--Apple-Mail=_ED2989C1-6E2E-4EDF-96D2-07F3EA35C9CC-- From nobody Thu Aug 7 11:13: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 AFB571A0368 for ; Thu, 7 Aug 2014 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtgGYta2vMUp for ; Thu, 7 Aug 2014 11:12:49 -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 10D871A032A for ; Thu, 7 Aug 2014 11:12:49 -0700 (PDT) Received: from [2a02:fe0:c411:a000::1] (port=37274 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XFSB4-0001XU-8B; Thu, 07 Aug 2014 20:12:38 +0200 Message-ID: <53E3C195.9070205@fud.no> Date: Thu, 07 Aug 2014 20:12:37 +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: Philip Homburg , Lee Howard References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OoaMaYO5HTMM6vJpOUrD5OMaaGY Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 18:12:51 -0000 * Philip Homburg > One of my replies to Tore already contains an example. Middle box > implements MSS clamping wrong. This breaks IPv4 for any service that > has a path MTU of less then the PPPoE MTU. You're quite right that the header size difference between IPv4 and IPv6 is something one would need to consider. This consideration is similar to that to other tunneling or translation mechanisms like GRE, DS-Lite, MAP, 6RD, PPPoE and so forth. There are some differences though: - It is only really a concern for packets flowing in the client->server direction (IPv4->IPv6), as a 1500 byte large packet originated by the IPv6 server would be translated into a 1480 byte large IPv4 packet, which isn't problematic. (For content providers, most large packets go in the unproblematic server->client direction.) - All potential issues can be mitigated by raising the MTU by 20 bytes (to 1520) in the IPv6 domain (to 1520). While this is of course true for all the other mechanisms I mentioned too, actually doing it is likely to be easier to do in a data centre environment than e.g. in an ISP's access network. - There is no need for TCP MSS clamping, as the IPv6 servers will advertise an appropriate TCP MSS to the clients (1440). This causes the IPv4 clients to limit their packet size to 1480, which translates into 1500 byte large IPv6 packets. - Finally, for protocols other than TCP (and other protocols that have a mechanism similar to TCP's MSS), there are two things that can happen for IPv4 packets larger than 1480 bytes destined for an IPv6 server (assuming the IPv6 domain's MTU is 1500): - If the DF flag is set, it's PMTUD time, as the SIIT gateway will emit an ICMPv4 Fragmentation Needed packet. This is likely unreliable. - If the DF flag isn't set, it results in a fragmented IPv6 packet. This can be reliable, as the fragmented packets do not propagate out of the data centre, and as such the operator can ensure that they work. In any case, the draft already discusses this: http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.section.3.8 Please let me know if you find any of the text there is incorrect, confusing, incomplete, or if you have other suggestions on how to improve it. Tore From nobody Thu Aug 7 17:26: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 191DE1A03CA for ; Thu, 7 Aug 2014 17:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20F4vJY42VIe for ; Thu, 7 Aug 2014 17:26:43 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98E21A0361 for ; Thu, 7 Aug 2014 17:26:43 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rl12so5421890iec.24 for ; Thu, 07 Aug 2014 17:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MhNLj4EXOf31SwGo0M0AQT0tfQwdPI4UE3L0MIHQyj8=; b=WUGwDwAuER+w9r9s3Se3wWTR6PPrrs9AtPweisInuLQTKDGgLLQRTS7Uq6NJyxR8cU XAKWpiUJ+mRUVkJCxFFQbqpafw58HBwDy0sUDAQ55NrubFv7ZacOgZeDtVGjWUlkCoZL ZjvclzHVsxvUjxuUiKYf9lLi/LzwV8z5VPR8aKy49sk2HSDkXSrtF5Xq6aCteM5QAgro 57+dNlC563vJ6G409H/1tqvBc96NlC7pdLz0qtSBfvB3SeXpWqQ93R5IPc7EuokTsHQ6 1+Ym/1aTbL/wauk9TvB/k4Z3V5ggG9t9uTtkbzKA7/NmJURXQTX8kXDCvPln1mGnHaXO 5OxA== 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=MhNLj4EXOf31SwGo0M0AQT0tfQwdPI4UE3L0MIHQyj8=; b=bAtz9vL/r5I6+jUd74g50RBpwpUL4CzlFSZ1hcymwxbKVUrepi44AMVrivhluo1OSL 1Vtax762WMqbvA2O37ed6rvUqlfzeprqqOsSNUu3bcmS67oWXBu43duInpS1gDAfHpxb Bz9aYs9TpcKcioewOB/s5q9ppxjVgWS03z/5zN0IAEljc+jQ9WHWM5JHqGB3GruMB+UR hzDX4LvQ/TtbvQMO7j2DMh0FPGfMftJqUGKWWo3U0ldc70fbdb0vOa11Dsulycqi5ooc n/0BGhtgPNB6lKtm3BGXVboI/Y8fTS6+4FF9jHoA8fwPk66c9ELER3XRQ3Tp72FKd5+5 X1ow== X-Gm-Message-State: ALoCoQl7QaU8InRO6OhmjvfAYOW6ke6wePh1YXhYkRITWFrH/hOnNcMJaFWgsPp7sbxCjtguxD6G X-Received: by 10.42.230.212 with SMTP id jn20mr7837122icb.59.1407457602935; Thu, 07 Aug 2014 17:26:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.5.6 with HTTP; Thu, 7 Aug 2014 17:26:22 -0700 (PDT) In-Reply-To: <53E11795.7060305@fud.no> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> From: Lorenzo Colitti Date: Fri, 8 Aug 2014 09:26:22 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=001a11c3e37a75c03a0500134287 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mtrOlNVr8omowK31IS3JYNav7OY Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 00:26:45 -0000 --001a11c3e37a75c03a0500134287 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 6, 2014 at 2:42 AM, Tore Anderson wrote: > I've not visited every country in the world, but I have been around a > bit, and I've made a point out of trying to establish an IPv6 data > bearer to every single PLMN I can register with. So far I've had 100% > success, including on Cameron's network... Thus enabling IPv6 roaming > doesn't seem like a scary proposition to me. I'm guessing perhaps > Telenor came to the same conclusion. I know for sure it doesn't work with on NTT docomo. It used not to work on Softbank either. That was 2 out of 2 GSM operators in Japan, so if you had a GSM handset, well, no Internet for you. --001a11c3e37a75c03a0500134287 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 6, 2014 at 2:42 AM, Tore Anderson <tore@fud.no> wrote:
=
I've not visited every country in the world, but I have been around a bit, and I've made a point out of trying to establish an IPv6 data
bearer to every single PLMN I can register with. So far I've had 100% success, including on Cameron's network... Thus enabling IPv6 roaming doesn't seem like a scary proposition to me. I'm guessing perhaps Telenor came to the same conclusion.

I know= for sure it doesn't work with on NTT docomo. It used not to work on So= ftbank either. That was 2 out of 2 GSM operators in Japan, so if you had a = GSM handset, well, no Internet for you.
--001a11c3e37a75c03a0500134287-- From nobody Thu Aug 7 17:52: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 0C25C1B279B for ; Thu, 7 Aug 2014 17:51: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 JjIF12nuISjS for ; Thu, 7 Aug 2014 17:51:56 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BC21B2794 for ; Thu, 7 Aug 2014 17:51:56 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so5388899qge.11 for ; Thu, 07 Aug 2014 17:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QdsaRxLxayDVKN8cEgUUmhED8w8ybM0vhX8jeRleki4=; b=lPkifDE6ZnnKZ0ozHKm5YG4COKxkk+kHkANZIB+SycjM8HhwHDaVJyYPDPnHGnY2ZE q9uYtfLRtwh2Ugvl/k7vnk/Xl+/56KgYBx7ckfg0j6WvybTDpxwzSiOUxLNgX6P209Qk NFVZ8HAAqvOlJqqakLC9F6KTNi7LTtYWZNGqq95YO4Pb3xKzGh8la0fixmaEI9nFFKUs fos6P/RYjrLkreDXMjVkkEEVtbL/BKkRXXf0XyV7AUoEPNL+6FCQMiALUfvtD6JyinwV Fv21Dnh9/Ui5wOepvKtmi9m8M6M37C8Gij0WO/l1dtPib3FuylFnDL43kyvLeDxxsOCN HyVw== MIME-Version: 1.0 X-Received: by 10.140.40.210 with SMTP id x76mr18269828qgx.61.1407459115405; Thu, 07 Aug 2014 17:51:55 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Thu, 7 Aug 2014 17:51:55 -0700 (PDT) In-Reply-To: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> Date: Fri, 8 Aug 2014 08:51:55 +0800 Message-ID: From: GangChen To: Ross Chandler , Dave Michaud Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ms77MCH6Y41lglbEOZX5V9sKpv4 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 08 Aug 2014 00:51:58 -0000 2014-08-07 21:35 GMT+08:00, Ross Chandler : > > On 7 Aug 2014, at 14:16, Dave Michaud wrote= : > >> When I=E2=80=99m abroad, I always make a point to test all operators on = IPv6-only >> and always see a lot of failure. This becomes especially apparent if the >> home operator performs some steering of roaming targeted to an operator >> that doesn=E2=80=99t allow IPv6. >> Dave Michaud > > Steering of roaming sounds like a failure mode that should be mentioned i= n > the draft. Are you using VPLMN-Dynamic-Address-Allowed flag to steer roaming? > BR > Ross > From nobody Thu Aug 7 18:24: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 554FC1B28F9 for ; Thu, 7 Aug 2014 18:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hMJ8hNm1M_E for ; Thu, 7 Aug 2014 18:24:12 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D671A1A037C for ; Thu, 7 Aug 2014 18:24:10 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so4977283wgh.5 for ; Thu, 07 Aug 2014 18:24:09 -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=BXivhYXCA9BuaMVsmvPlvz5FWrPAsE6Td0HH+y/mgtA=; b=XIxubW96Nr0NsT9DNPq4ovJdhNYJj68z15YVSiHvDLCKC4hzEuCX0EpFAlPBTxcYhl K3rU6OnCEPCcJDpokF1CELlKOk4ItaBdJa58MjpPxfVXoANIR1lOtiiz3MfJt2e3TEbF YNqsCf/n8a9gbDRqaIZjwJaum+3YLPcxBcOydtnqBnrMqO3F7FklsG2DfZ/hfQBA3yX6 SxLkvM86qRkBQbcEzdxo+Onxl8kqkspmt+kgaxJo98JYIbTGWPvk1rYeCOTmOYw0AbTo 3wYYkV1BseatfvtJZPaxnYGxuLL2fxRsRkeKS8A8PKyUMdGGSdAH0iGBZbqAjyKzsd8f cVGg== MIME-Version: 1.0 X-Received: by 10.194.200.229 with SMTP id jv5mr28002152wjc.90.1407461049550; Thu, 07 Aug 2014 18:24:09 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 18:24:09 -0700 (PDT) Received: by 10.216.49.133 with HTTP; Thu, 7 Aug 2014 18:24:09 -0700 (PDT) In-Reply-To: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> Date: Thu, 7 Aug 2014 18:24:09 -0700 Message-ID: From: Ca By To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7bb70b68e4ce300500140f18 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SzsMdrThuAvJHW7YAi0AifDGT9Y Cc: Tore Anderson , IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 01:24:13 -0000 --047d7bb70b68e4ce300500140f18 Content-Type: text/plain; charset=UTF-8 On Aug 7, 2014 5:26 PM, "Lorenzo Colitti" wrote: > > On Wed, Aug 6, 2014 at 2:42 AM, Tore Anderson wrote: >> >> I've not visited every country in the world, but I have been around a >> bit, and I've made a point out of trying to establish an IPv6 data >> bearer to every single PLMN I can register with. So far I've had 100% >> success, including on Cameron's network... Thus enabling IPv6 roaming >> doesn't seem like a scary proposition to me. I'm guessing perhaps >> Telenor came to the same conclusion. > > > I know for sure it doesn't work with on NTT docomo. It used not to work on Softbank either. That was 2 out of 2 GSM operators in Japan, so if you had a GSM handset, well, no Internet for you. A fix is to choose softbank as a roaming partner and to bar ntt CB --047d7bb70b68e4ce300500140f18 Content-Type: text/html; charset=UTF-8


On Aug 7, 2014 5:26 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Wed, Aug 6, 2014 at 2:42 AM, Tore Anderson <tore@fud.no> wrote:
>>
>> I've not visited every country in the world, but I have been around a
>> bit, and I've made a point out of trying to establish an IPv6 data
>> bearer to every single PLMN I can register with. So far I've had 100%
>> success, including on Cameron's network... Thus enabling IPv6 roaming
>> doesn't seem like a scary proposition to me. I'm guessing perhaps
>> Telenor came to the same conclusion.
>
>
> I know for sure it doesn't work with on NTT docomo. It used not to work on Softbank either. That was 2 out of 2 GSM operators in Japan, so if you had a GSM handset, well, no Internet for you.

A fix is to choose softbank as a roaming partner and to bar ntt

CB

--047d7bb70b68e4ce300500140f18-- From nobody Thu Aug 7 18:25: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 0589F1B28FE for ; Thu, 7 Aug 2014 18:25:15 -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 peBaviXYGHth for ; Thu, 7 Aug 2014 18:25:13 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781071A037C for ; Thu, 7 Aug 2014 18:25:13 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so5250434qge.25 for ; Thu, 07 Aug 2014 18:25:12 -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=UtB8iq36CFANdLWOZjq3xbJ11zKrE9JHF3y/6KO0s5g=; b=A7AmFKIjTbnszAbFLSTVuNmiyckKO/UijJI3pN8UQDyWICsVSGeAsPF7hiYQxwUCWu VGkcMeH9JaxDcwolHkUSAvIttOJWoGb1xRrXVH+KMg8tKxP13L63zgO0fPLt+5NEI5tr bcywfSIovZVxUgcpSSMitw41l3fLS7LkCTxubtzizUuxodF8WoutgZj2CiuQTCbM2KNZ kWG9fQk1bDwEAIQ4WdIJAiMrNCfWvEx4rigxP97ZpUkxCY6tUcAdS/DNQ0AdyK1zcml/ +0zdj9U/Au4o9jMDw80BFgP0bx229IE5vW18GQAdJE8EEzyHNJDeCYEQ6m7Jq0IbJKUr 14Ag== MIME-Version: 1.0 X-Received: by 10.140.31.246 with SMTP id f109mr19550662qgf.8.1407461112736; Thu, 07 Aug 2014 18:25:12 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Thu, 7 Aug 2014 18:25:12 -0700 (PDT) In-Reply-To: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <3B143C5A-875A-4E6F-B34A-A354758E1893@eircom.net> <3268A775-40CE-4FEA-9B09-846D35376ADD@eircom.net> Date: Fri, 8 Aug 2014 09:25:12 +0800 Message-ID: From: GangChen To: "holger.metschulat" , Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i_ak10Np-ZU8whO7F7Iowc-a1Jg Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 08 Aug 2014 01:25:15 -0000 2014-08-07 19:16 GMT+08:00, Ross Chandler : > > On 7 Aug 2014, at 11:47, > wrote: > >> But then, ticking the correct =E2=80=9CI am IPv6 capable" and "I am IPv4= v6 >> capable" boxes in the IR.21 database should not be forgotten... > > AFAIK the latest version of IR.21 is version 9.1 (05 July 2013) > > Relevant sections look like: > > Section ID: 16 on Packet Data Services Information > > Section ID: 20 on LTE Roaming Information > > Both are optional sections, but it is clearly good practise to update the= m, > and seeing entries being made should help encourage other operators to al= so > deploy IPv6. Yes. Uploading your IR.21 database with IPv6 capable and IPv4v6 capable is definitely helpful. Should this be encouraged in the draft? Gang > Ross > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Aug 7 21:05: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 30EB11A00E5 for ; Thu, 7 Aug 2014 21:05:56 -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 kEd8bkbABlvE for ; Thu, 7 Aug 2014 21:05:53 -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 50F861A00ED for ; Thu, 7 Aug 2014 21:05:53 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XFbR8-0001Od-Vy; Fri, 08 Aug 2014 06:05:51 +0200 Message-ID: <53E44C55.9020306@si6networks.com> Date: Fri, 08 Aug 2014 00:04:37 -0400 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 References: <20140808035717.19737.51768.idtracker@ietfa.amsl.com> In-Reply-To: <20140808035717.19737.51768.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140808035717.19737.51768.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sz1hYdsWfPOJWpqQjxsohDp8CC8 Subject: [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, 08 Aug 2014 04:05:56 -0000 Folks, We have published a new I-D on the topic of IPv6 Extension Headers (EHs). The I-D is available at: . 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 From nobody Thu Aug 7 21:17: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 527921A017C for ; Thu, 7 Aug 2014 21:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZcA7bhcl59W for ; Thu, 7 Aug 2014 21:17:48 -0700 (PDT) Received: from mail14.svc.cra.dublin.eircom.net (mail14.svc.cra.dublin.eircom.net [159.134.118.30]) by ietfa.amsl.com (Postfix) with SMTP id 072301A0178 for ; Thu, 7 Aug 2014 21:17:47 -0700 (PDT) Received: (qmail 53431 messnum 2037442 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 8 Aug 2014 04:17:46 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail14.svc.cra.dublin.eircom.net (qp 53431) with SMTP; 8 Aug 2014 04:17:46 -0000 Received: from [159.134.196.38] ([159.134.196.38]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id c4Hj1o0060qBAUn014HmBW; Fri, 08 Aug 2014 05:17:46 +0100 Date: Fri, 08 Aug 2014 05:17:43 +0100 Message-ID: Importance: normal From: Ross Chandler To: GangChen , "holger.metschulat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_424316178875830" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/H6HhlEaKwIsGJuv41xtOMVobwLE Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 08 Aug 2014 04:17:50 -0000 ----_com.android.email_424316178875830 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgR2FuZywKSW4gYSBkcmFmdCBhYm91dCAzZ3BwIHJvYW1pbmcgZmFpbHVyZSBtb2RlcyB3aGVu IHVzaW5nIElQdjYgb3IgSVB2NHY2IFBEUC9QRE4gY29ubmVjdGlvbnMgaXQgaXMgZmFpcmx5IG5h dHVyYWwgdG8gaGF2ZSBzb21lIHJlZmVyZW5jZXMgbGlrZSB0aGF0LiBJdCBjYW4gcHJvYmFibHkg YmUgZG9uZSBpbiBhIHdheSB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgbm9ybWFsIGZvcm0g b2YgYW4gSS1ELgpCUgpSb3NzCgo8ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0t LS08L2Rpdj48ZGl2PkZyb206IEdhbmdDaGVuIDxwaGRnYW5nQGdtYWlsLmNvbT4gPC9kaXY+PGRp dj5EYXRlOjA4LzA4LzIwMTQgIDI6MjUgYS5tLiAgKEdNVCswMDowMCkgPC9kaXY+PGRpdj5Ubzog ImhvbGdlci5tZXRzY2h1bGF0IiA8aG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5kZT4sUm9zcyBD aGFuZGxlciA8cm9zc0BlaXJjb20ubmV0PiA8L2Rpdj48ZGl2PkNjOiBJUHY2IE9wcyBXRyA8djZv cHNAaWV0Zi5vcmc+IDwvZGl2PjxkaXY+U3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LXJvYW1pbmctYW5hbHlzaXMtMDIudHh0IDwvZGl2PjxkaXY+ CjwvZGl2PjIwMTQtMDgtMDcgMTk6MTYgR01UKzA4OjAwLCBSb3NzIENoYW5kbGVyIDxyb3NzQGVp cmNvbS5uZXQ+Ogo+Cj4gT24gNyBBdWcgMjAxNCwgYXQgMTE6NDcsIDxob2xnZXIubWV0c2NodWxh dEB0ZWxla29tLmRlPgo+IDxob2xnZXIubWV0c2NodWxhdEB0ZWxla29tLmRlPiB3cm90ZToKPgo+ PiBCdXQgdGhlbiwgdGlja2luZyB0aGUgY29ycmVjdCDigJxJIGFtIElQdjYgY2FwYWJsZSIgYW5k ICJJIGFtIElQdjR2Ngo+PiBjYXBhYmxlIiBib3hlcyBpbiB0aGUgSVIuMjEgZGF0YWJhc2Ugc2hv dWxkIG5vdCBiZSBmb3Jnb3R0ZW4uLi4KPgo+IEFGQUlLIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBJ Ui4yMSBpcyB2ZXJzaW9uIDkuMSAoMDUgSnVseSAyMDEzKQo+Cj4gUmVsZXZhbnQgc2VjdGlvbnMg bG9vayBsaWtlOgo+Cj4gU2VjdGlvbiBJRDogMTYgICBvbiBQYWNrZXQgRGF0YSBTZXJ2aWNlcyBJ bmZvcm1hdGlvbgo+Cj4gU2VjdGlvbiBJRDogMjAgICBvbiBMVEUgUm9hbWluZyBJbmZvcm1hdGlv bgo+Cj4gQm90aCBhcmUgb3B0aW9uYWwgc2VjdGlvbnMsIGJ1dCBpdCBpcyBjbGVhcmx5IGdvb2Qg cHJhY3Rpc2UgdG8gdXBkYXRlIHRoZW0sCj4gYW5kIHNlZWluZyBlbnRyaWVzIGJlaW5nIG1hZGUg c2hvdWxkIGhlbHAgZW5jb3VyYWdlIG90aGVyIG9wZXJhdG9ycyB0byBhbHNvCj4gZGVwbG95IElQ djYuCgpZZXMuIFVwbG9hZGluZyB5b3VyIElSLjIxIGRhdGFiYXNlIHdpdGggSVB2NiBjYXBhYmxl IGFuZCBJUHY0djYKY2FwYWJsZSBpcyBkZWZpbml0ZWx5IGhlbHBmdWwuIFNob3VsZCB0aGlzIGJl IGVuY291cmFnZWQgaW4gdGhlIGRyYWZ0PwoKR2FuZwoKPiBSb3NzCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiB2Nm9wcyBtYWlsaW5nIGxpc3QKPiB2 Nm9wc0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHMKPgo= ----_com.android.email_424316178875830 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5IaSBHYW5nLDwvZGl2Pjxk aXY+SW4gYSBkcmFmdCBhYm91dCAzZ3BwIHJvYW1pbmcgZmFpbHVyZSBtb2RlcyB3aGVuIHVzaW5n IElQdjYgb3IgSVB2NHY2IFBEUC9QRE4gY29ubmVjdGlvbnMgaXQgaXMgZmFpcmx5IG5hdHVyYWwg dG8gaGF2ZSBzb21lIHJlZmVyZW5jZXMgbGlrZSB0aGF0LiBJdCBjYW4gcHJvYmFibHkgYmUgZG9u ZSBpbiBhIHdheSB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgbm9ybWFsIGZvcm0gb2YgYW4g SS1ELjwvZGl2PjxkaXY+QlI8L2Rpdj48ZGl2PlJvc3M8L2Rpdj48YnI+PGJyPjxkaXY+LS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogR2FuZ0NoZW4gPHBo ZGdhbmdAZ21haWwuY29tPiA8L2Rpdj48ZGl2PkRhdGU6MDgvMDgvMjAxNCAgMjoyNSBhLm0uICAo R01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiAiaG9sZ2VyLm1ldHNjaHVsYXQiIDxob2xnZXIubWV0 c2NodWxhdEB0ZWxla29tLmRlPixSb3NzIENoYW5kbGVyIDxyb3NzQGVpcmNvbS5uZXQ+IDwvZGl2 PjxkaXY+Q2M6IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4gPC9kaXY+PGRpdj5TdWJqZWN0 OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWlwdjYtcm9hbWluZy1h bmFseXNpcy0wMi50eHQgPC9kaXY+PGRpdj48YnI+PC9kaXY+MjAxNC0wOC0wNyAxOToxNiBHTVQr MDg6MDAsIFJvc3MgQ2hhbmRsZXIgJmx0O3Jvc3NAZWlyY29tLm5ldCZndDs6PGJyPiZndDs8YnI+ Jmd0OyBPbiA3IEF1ZyAyMDE0LCBhdCAxMTo0NywgJmx0O2hvbGdlci5tZXRzY2h1bGF0QHRlbGVr b20uZGUmZ3Q7PGJyPiZndDsgJmx0O2hvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGUmZ3Q7IHdy b3RlOjxicj4mZ3Q7PGJyPiZndDsmZ3Q7IEJ1dCB0aGVuLCB0aWNraW5nIHRoZSBjb3JyZWN0IOKA nEkgYW0gSVB2NiBjYXBhYmxlIiBhbmQgIkkgYW0gSVB2NHY2PGJyPiZndDsmZ3Q7IGNhcGFibGUi IGJveGVzIGluIHRoZSBJUi4yMSBkYXRhYmFzZSBzaG91bGQgbm90IGJlIGZvcmdvdHRlbi4uLjxi cj4mZ3Q7PGJyPiZndDsgQUZBSUsgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIElSLjIxIGlzIHZlcnNp b24gOS4xICgwNSBKdWx5IDIwMTMpPGJyPiZndDs8YnI+Jmd0OyBSZWxldmFudCBzZWN0aW9ucyBs b29rIGxpa2U6PGJyPiZndDs8YnI+Jmd0OyBTZWN0aW9uIElEOiAxNiZuYnNwOyZuYnNwOyBvbiBQ YWNrZXQgRGF0YSBTZXJ2aWNlcyBJbmZvcm1hdGlvbjxicj4mZ3Q7PGJyPiZndDsgU2VjdGlvbiBJ RDogMjAmbmJzcDsmbmJzcDsgb24gTFRFIFJvYW1pbmcgSW5mb3JtYXRpb248YnI+Jmd0Ozxicj4m Z3Q7IEJvdGggYXJlIG9wdGlvbmFsIHNlY3Rpb25zLCBidXQgaXQgaXMgY2xlYXJseSBnb29kIHBy YWN0aXNlIHRvIHVwZGF0ZSB0aGVtLDxicj4mZ3Q7IGFuZCBzZWVpbmcgZW50cmllcyBiZWluZyBt YWRlIHNob3VsZCBoZWxwIGVuY291cmFnZSBvdGhlciBvcGVyYXRvcnMgdG8gYWxzbzxicj4mZ3Q7 IGRlcGxveSBJUHY2Ljxicj48YnI+WWVzLiBVcGxvYWRpbmcgeW91ciBJUi4yMSBkYXRhYmFzZSB3 aXRoIElQdjYgY2FwYWJsZSBhbmQgSVB2NHY2PGJyPmNhcGFibGUgaXMgZGVmaW5pdGVseSBoZWxw ZnVsLiBTaG91bGQgdGhpcyBiZSBlbmNvdXJhZ2VkIGluIHRoZSBkcmFmdD88YnI+PGJyPkdhbmc8 YnI+PGJyPiZndDsgUm9zczxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPiZndDsgdjZvcHNA aWV0Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzPGJyPiZndDs8YnI+PC9ib2R5Pg== ----_com.android.email_424316178875830-- From nobody Thu Aug 7 21:45: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 41CAF1A01F6 for ; Thu, 7 Aug 2014 21:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUIjdRgL_5ui for ; Thu, 7 Aug 2014 21:45:26 -0700 (PDT) Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by ietfa.amsl.com (Postfix) with SMTP id 8A56D1A01E8 for ; Thu, 7 Aug 2014 21:45:26 -0700 (PDT) Received: (qmail 7933 messnum 13336793 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 8 Aug 2014 04:45:25 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail05.svc.cra.dublin.eircom.net (qp 7933) with SMTP; 8 Aug 2014 04:45:25 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id c4lM1o00y0mJ9Tz014lQoU; Fri, 08 Aug 2014 05:45:25 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Fri, 8 Aug 2014 05:45:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> To: GangChen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UdwahXgH0CftjjsPal8ETKXSvKw Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 08 Aug 2014 04:45:31 -0000 On 8 Aug 2014, at 01:51, GangChen wrote: >> Steering of roaming sounds like a failure mode that should be = mentioned in >> the draft. >=20 >=20 > Are you using VPLMN-Dynamic-Address-Allowed flag to steer roaming? AFAIK in this case it is an aggressive process of snooping on Gr and = rejecting networks until on you like comes up. Ross= From nobody Thu Aug 7 21:45: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 657FB1A0242 for ; Thu, 7 Aug 2014 21:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6OmP7VM2JIc for ; Thu, 7 Aug 2014 21:45:41 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3011A0263 for ; Thu, 7 Aug 2014 21:45:40 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id u10so1503146lbd.18 for ; Thu, 07 Aug 2014 21:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F6gn6c+Q9ZXo6Ht7kn39oo7nO+wXasT/3N7YJywqj90=; b=C0192sDWXW1Xg69yPSZh3z4Vr1guUMSPHDFJRO1vpum3EU8YSROl93milQzVIwHTg+ 9G2zCxr6WtjfRQMzoHX9LBvbqLuVxer8MA6dWwlaSWQemIGA4faPqxNK7eCvXnLLHuLe zjwEtQM5hGWitRz5yUH3F6BLIfAoCx7egyAxIRws2FXceebQgBdqJ/24lij+nAFQKQts I5PNog4MyTzXYAMPn53w2VD2Ybzjy2pnJZMWbbSShdfTGTIj6NfUl/PSgoKYFoxXhhsl OxfV4YdY6ATuFx52XgPMjghM6EYGG+evgUv/0QvzfXJ5Ejl72nO9ADvavDd49ABrephM CzFQ== X-Received: by 10.112.148.10 with SMTP id to10mr55501lbb.77.1407473139254; Thu, 07 Aug 2014 21:45:39 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:c455:102:aa6c:4e7e? ([2001:1bc8:101:f101:c455:102:aa6c:4e7e]) by mx.google.com with ESMTPSA id yg3sm2808433lbb.13.2014.08.07.21.45.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 21:45:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: Date: Fri, 8 Aug 2014 07:45:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <77260D8E-AB97-4845-90C6-2551F044CF81@gmail.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> To: GangChen X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Swsy95ostg0Yp7MvhEltIzXeHkU Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 08 Aug 2014 04:45:45 -0000 On Aug 8, 2014, at 3:51 AM, GangChen wrote: > 2014-08-07 21:35 GMT+08:00, Ross Chandler : >>=20 >> On 7 Aug 2014, at 14:16, Dave Michaud = wrote: >>=20 >>> When I=92m abroad, I always make a point to test all operators on = IPv6-only >>> and always see a lot of failure. This becomes especially apparent if = the >>> home operator performs some steering of roaming targeted to an = operator >>> that doesn=92t allow IPv6. >>> Dave Michaud >>=20 >> Steering of roaming sounds like a failure mode that should be = mentioned in >> the draft. >=20 >=20 > Are you using VPLMN-Dynamic-Address-Allowed flag to steer roaming? Without knowing the details in this case but steering of roaming usually means affecting the PLMN selection the UE does.. e.g. by purposely failing signaling on the network side until a desired PLMN gets selected or some other means. - Jouni >=20 >=20 >=20 >> BR >> Ross >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 8 04:47: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 E11001B2A45 for ; Fri, 8 Aug 2014 04:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYTMmwuq2x3Q for ; Fri, 8 Aug 2014 04:47:03 -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 527311B2A34 for ; Fri, 8 Aug 2014 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=218; q=dns/txt; s=iport; t=1407498423; x=1408708023; h=date:from:message-id:to:subject; bh=WRndl6Zf+M2NrTjDc0EcI3mT8MdbOzjC26BBlfSTVdI=; b=FbQy+aiAFdpygohfBMl6lzYUTiJvHqgy4lujpbrIUXQyyzXo9gdgRyDs uRVwbML2CHfsbOdgAN97RSiQNKk+vXQGCYMeZSFZC3jffPIM/bpLaj7Kf fhriJW62b6UzsfVsiXJkgVvQvZ9sVqzU+u9uLHE7w+kqlDdXR5cMHDFoj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHAKO35FOtJV2T/2dsb2JhbABagw1SGj2xKAGbP4hdFneFPzRhiEEBDaAOpS8Xj2mENQWLGIofiEKTHoN3TA X-IronPort-AV: E=Sophos;i="5.01,824,1400025600"; d="scan'208";a="67546023" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 08 Aug 2014 11:47:02 +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 s78Bl2XF021163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Aug 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 s78Bl1gi012484 for ; Fri, 8 Aug 2014 04:47:01 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s78Bl1fV012480 for v6ops@ietf.org; Fri, 8 Aug 2014 04:47:01 -0700 Date: Fri, 8 Aug 2014 04:47:01 -0700 From: fred@cisco.com Message-Id: <201408081147.s78Bl1fV012480@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1D8UE-vAEricbloR4N7sVXgujB4 Subject: [v6ops] new draft: 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: Fri, 08 Aug 2014 11:47:05 -0000 ~c draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org A new draft has been posted, at http://datatracker.ietf.org/wg/v6ops/charter/draft-gont-v6ops-ipv6-ehs-in-real-world. Please take a look at it and comment. From nobody Fri Aug 8 05:12: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 4DDE81B2A86 for ; Fri, 8 Aug 2014 05:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2RDLE9oLJm2 for ; Fri, 8 Aug 2014 05:12:01 -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 4A92D1B2A94 for ; Fri, 8 Aug 2014 05:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2311; q=dns/txt; s=iport; t=1407499912; x=1408709512; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WSeUjLIXjC9NcbKMEgcOUg9qWwL5svT7nAJ0e8rnhRs=; b=bsaOfvkOCdpSwl5EE0KvKb05XmR61nWI/fRZ+DmCwFR6u6M38idW+PDI maLVb3FZE4eV23EoTqAXBpug3za8S0bn5cE2deOVjkkMQNotJjj9e/fL8 24f/SXWK/Wk6T4M3grm22O6K7ZSAeg6dQ0H3IDvYZ2oQlGexeX0qSmqo+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAHO95FOtJV2a/2dsb2JhbABagkcjI4EpBNQxAYEWFneEBAEBBHkQAgEIBAEQKgcyFBECBA4FFogsAcVOF49MB4RLBYUAAowSixGUcoNXbIFG X-IronPort-AV: E=Sophos; i="5.01,824,1400025600"; d="scan'208,217"; a="67552891" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 08 Aug 2014 12:11:51 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s78CBopw003342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 12:11:50 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 07:11:50 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvBHf4AgAAE0QCAABWsAIAD4cnggABacICAAAG1AIABosKA Date: Fri, 8 Aug 2014 12:11:49 +0000 Message-ID: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.76] Content-Type: multipart/alternative; boundary="_000_D00A8AFF26D18evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/03IYO01Qu56b9CgQ6Co5oosKy68 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 12:12:03 -0000 --_000_D00A8AFF26D18evynckeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo For my education, do you have a pointer for a data point on: From: Lorenzo Colitti > A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% NAT64= , and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's only us= ed for 5% of traffic, then the operator might just say, "Who cares? I don't= ; and if somebody else does, they're free to use IPv6." --_000_D00A8AFF26D18evynckeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <141DAB8260EE464EAAE58E81A5DDF001@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Lorenzo

For my education, do you have a pointer for a data point on:

From: Lorenzo Colitti <lorenzo@google.com>
A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% = NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's on= ly used for 5% of traffic, then the operator might just say, "Who care= s? I don't; and if somebody else does, they're free to use IPv6."
 --_000_D00A8AFF26D18evynckeciscocom_-- From nobody Fri Aug 8 05:21: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 7BE751B2AA2 for ; Fri, 8 Aug 2014 05:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6cvQ39ruAEoi for ; Fri, 8 Aug 2014 05:21:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D688C1B2A71 for ; Fri, 8 Aug 2014 05:21:13 -0700 (PDT) Received: from BLUPR04MB596.namprd04.prod.outlook.com (10.141.202.147) by BLUPR04MB595.namprd04.prod.outlook.com (10.141.202.143) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 8 Aug 2014 12:21:04 +0000 Received: from BLUPR04MB596.namprd04.prod.outlook.com ([10.141.202.147]) by BLUPR04MB596.namprd04.prod.outlook.com ([10.141.202.147]) with mapi id 15.00.1005.008; Fri, 8 Aug 2014 12:21:03 +0000 From: Dave Michaud To: Jouni , GangChen Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt Thread-Index: AQHPsqL1ZJZVDhJMBEmr770crE3SNpvGIemAgAB+ULA= Date: Fri, 8 Aug 2014 12:21:03 +0000 Message-ID: <445cc00e45ea4621944e31ff2ecbe590@BLUPR04MB596.namprd04.prod.outlook.com> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> <77260D8E-AB97-4845-90C6-2551F044CF81@gmail.com> In-Reply-To: <77260D8E-AB97-4845-90C6-2551F044CF81@gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [162.208.80.15] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(189002)(199002)(377454003)(13464003)(101416001)(21056001)(50986999)(54356999)(106356001)(106116001)(46102001)(33646002)(15974865002)(105586002)(76576001)(99396002)(93886004)(2656002)(76176999)(85306004)(87936001)(83072002)(85852003)(74662001)(4396001)(74502001)(81542001)(15975445006)(79102001)(86362001)(74316001)(19580405001)(80022001)(107046002)(64706001)(19580395003)(19273905006)(99286002)(95666004)(76482001)(66066001)(20776003)(77982001)(15202345003)(83322001)(81342001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR04MB595; H:BLUPR04MB596.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rci.rogers.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TR-2yzNocqio5k_NNkkn9Gxnmgs Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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, 08 Aug 2014 12:21:16 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb3VuaSBbbWFpbHRvOmpvdW5p Lm5vc3BhbUBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDA4LCAyMDE0IDEyOjQ2 IEFNDQoNCg0KPiBXaXRob3V0IGtub3dpbmcgdGhlIGRldGFpbHMgaW4gdGhpcyBjYXNlIGJ1dCBz dGVlcmluZyBvZiByb2FtaW5nDQo+IHVzdWFsbHkgbWVhbnMgYWZmZWN0aW5nIHRoZSBQTE1OIHNl bGVjdGlvbiB0aGUgVUUgZG9lcy4uIGUuZy4gYnkNCj4gcHVycG9zZWx5IGZhaWxpbmcgc2lnbmFs aW5nIG9uIHRoZSBuZXR3b3JrIHNpZGUgdW50aWwgYSBkZXNpcmVkDQo+IFBMTU4gZ2V0cyBzZWxl Y3RlZCBvciBzb21lIG90aGVyIG1lYW5zLg0KPg0KPiAtIEpvdW5pDQo+DQoNClRoYXQgaXMgZXhh Y3RseSB3aGF0IEkgd2FzIHJlZmVycmluZyB0by4gSW4gYSBnaXZlbiBjb3VudHJ5LCBzb21lIG9w ZXJhdG9ycyBtYXkgc3VwcG9ydCBJUHY2IGFuZCBzb21lIG1heSBub3QuIElmIHN0ZWVyaW5nIG9m IHJvYW1pbmcgcHVzaGVzIG1lIHRvd2FyZHMgYW4gb3BlcmF0b3IgdGhhdCBkb2Vzbid0IGhhdmUg SVB2NiBzdXBwb3J0LCB0aGVuIEknbSBvdXQgb2YgbHVjay4NCg0KVGhlIGRlY2lzaW9uIG9uIHdo aWNoIG9wZXJhdG9yIGdldHMgcHJlZmVyZW50aWFsIHRyZWF0bWVudCBpcyBwdXJlbHkgYnVzaW5l c3MgZHJpdmVuIGJhc2VkIG9uIGNvbW1lcmNpYWwgYWdyZWVtZW50LiBJIGhhdmUgbGl0dGxlIHdl aWdodCBpbnRvIHRlbGxpbmcgdGhlIGJ1c2luZXNzIHRvIHBpY2sgSVB2Ni1mcmllbmRseSBvcGVy YXRvci4NCg0KVGhlbiB0aGVyZSBpcyB0aGUgY2FzZSB3aGVyZSBhbGwgdGhlIG9wZXJhdG9ycyBp biBhIGdpdmVuIGNvdW50cnkgYXJlIG5vdCBJUHY2IHJlYWR5LiBUaGlzIHNlZW1zIHRvIGJlIG1v cmUgY29tbW9uIGluIHRoZSBDYXJpYmJlYW4uDQoNCkRhdmUNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRoaXMgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1z IHNldCBvdXQgYXQgd3d3LnJvZ2Vycy5jb20vd2ViL2NvbnRlbnQvZW1haWxub3RpY2U8aHR0cDov L3d3dy5yb2dlcnMuY29tL3dlYi9jb250ZW50L2VtYWlsbm90aWNlPg0KDQoNCg0KQ2UgbWVzc2Fn ZSBlc3QgY29uZmlkZW50aWVsLiBOb3RyZSB0cmFuc21pc3Npb24gZXQgcsOpY2VwdGlvbiBkZSBj b3VycmllbHMgc2UgZmFpdCBzdHJpY3RlbWVudCBzdWl2YW50IGxlcyBtb2RhbGl0w6lzIMOpbm9u Y8OpZXMgZGFucyBs4oCZYXZpcyBwdWJsacOpIMOgIHd3dy5yb2dlcnMuY29tL2F2aXNjb3Vycmll bCA8aHR0cDovL3d3dy5yb2dlcnMuY29tL2F2aXNjb3VycmllbD4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo= From nobody Fri Aug 8 05:22: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 D36501B2AA7 for ; Fri, 8 Aug 2014 05:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUZ9JuUBJuE8 for ; Fri, 8 Aug 2014 05:22:33 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEA61B2A71 for ; Fri, 8 Aug 2014 05:22:33 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id c1so912330igq.13 for ; Fri, 08 Aug 2014 05:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5V7PqJ/oy+wQ7m70QRlIsp3OV/o5eKfbCLUy8E8FFkg=; b=izdOfQtH0gxXx4YOCbAC5yxVybAg9nlq6ixi2WT67WmF27azd0XlqQ57yO7sg6b2Gh iKoTV2Bk9IFxjyuRRjqlNJ1+ZgeC2sbKOQHYXfSMkW/uH0t1GVYd3DKmthrrUcm66kkY DuOsvtEl0a+5sRcRTnJvFsgbDFJvBKjlwQDvPMoZgjCrrJ7tDUDAMjaIsiVS0Sq/e4xW OywaMp3U3xd1qRoE+NDYQzUuHlLk9fFGdrb7LPhNffBi5uRQv/Q7jJqmxbFH9rGfzrA9 4yX1bYxMhNVJnHgjg+cUN6qEvwlx6aFQrzrBthHz0js6cBWPXxqCqF59KDelR2gmXj/U s7nQ== 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=5V7PqJ/oy+wQ7m70QRlIsp3OV/o5eKfbCLUy8E8FFkg=; b=ljJV0TIqxmSPB7MaXTAyY0uQkvVC78Nm42HgjPwBkjlkDsTcFi6eN/W3IuOz42TIi7 QKrJeg37SL4QnJT+o2KnQ4CywjO/miCgyqtealKVNGRK1D94r8cABCLLYKP3JLhTlBvK JCL4gkrBmG/H4iual14XUu7TletcO1ZadkxH4LSsbPEVYr39QPy1yw+fmEKHTLRIQC9w 4p3d/DGXsB3bbLqf8rQ1frC6oP9aWpSYFDHoB3yS3hxlYQEeyFk151a6YGTf5MzZET96 hwn0dvINTWqOHG64bcSAUuRfCXh8D2f01dESMirxVajMHIxzk/SevxfzfH8iaqELRT6S i+Uw== X-Gm-Message-State: ALoCoQkLIwNKq7XnU9P1LggcLrIlpyJSXYZECgwvJbN+dqFkjBn07YKnLjuaFTyLpAAydfoG/FLc X-Received: by 10.50.128.234 with SMTP id nr10mr4593779igb.3.1407500552378; Fri, 08 Aug 2014 05:22:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.5.6 with HTTP; Fri, 8 Aug 2014 05:22:12 -0700 (PDT) In-Reply-To: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> From: Lorenzo Colitti Date: Fri, 8 Aug 2014 21:22:12 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=047d7b10d131736a4e05001d428a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wPeMh2PJN2a5o-XT8XVi3-_AhHw Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 12:22:35 -0000 --047d7b10d131736a4e05001d428a Content-Type: text/plain; charset=UTF-8 https://www.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf Slide 4: "Over 50% of IPv6-user traffic is end-to-end IPv6 (no translation needed)" The 5% number is just a guess. If you only look at the handset, then t's just traffic from IPv4-only apps, and at least in the Android case, it's quite hard to write an IPv4-only app - you have to really go out of your way to do it in Java, or use native C/C++ code via JNI. The Netflix app used to be that way, and now I think the major one is Pandora. It sort of depends on the market though - from what I've seen on T-Mobile's deployment it didn't take that long for the major apps to get IPv6 support (with the exception of Skype and maybe Google Hangouts). Tethering is still IPv4-only on T-Mobile (and on many devices), and that's probably more than 5%. Cameron, do you have a better estimate of how much traffic uses 464xlat? On Fri, Aug 8, 2014 at 9:11 PM, Eric Vyncke (evyncke) wrote: > Lorenzo > > For my education, do you have a pointer for a data point on: > > From: Lorenzo Colitti > > A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% > NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's > only used for 5% of traffic, then the operator might just say, "Who cares? > I don't; and if somebody else does, they're free to use IPv6." > > --047d7b10d131736a4e05001d428a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://www.nanog.org/sites/default= /files/wednesday_general_byrne_breakingfree_11.pdf

Slide 4: "Over 50% of IPv6-user traffic is end-to-end IPv6 (no transla= tion needed)"

The 5% number is just a guess. = If you only look at the handset, then t's just traffic from IPv4-only a= pps, and at least in the Android case, it's quite hard to write an IPv4= -only app - you have to really go out of your way to do it in Java, or use = native C/C++ code via JNI. The Netflix app used to be that way, and now I t= hink the major one is Pandora. It sort of depends on the market though - fr= om what I've seen on T-Mobile's deployment it didn't take that = long for the major apps to get IPv6 support (with the exception of Skype an= d maybe Google Hangouts).

Tethering is still IPv4-only on T-Mobile (and on many d= evices), and that's probably more than 5%.

Cam= eron, do you have a better estimate of how much traffic uses 464xlat?


On Fri,= Aug 8, 2014 at 9:11 PM, Eric Vyncke (evyncke) <evyncke@cisco.com><= /span> wrote:
Lorenzo

For my education, do you have a pointer for a data point on:

From: Lorenzo Colitti <lorenzo@google.com>=
A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% = NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle, but if it'= s only used for 5% of traffic, then the operator might just say, "Who = cares? I don't; and if somebody else does, they're free to use IPv6."

--047d7b10d131736a4e05001d428a-- From nobody Fri Aug 8 07:20: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 147841B2BF4 for ; Fri, 8 Aug 2014 07:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.186 X-Spam-Level: * X-Spam-Status: No, score=1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, 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 EDLvJhBsLA2w for ; Fri, 8 Aug 2014 07:20:08 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D101D1B2C0B for ; Fri, 8 Aug 2014 07:20:06 -0700 (PDT) Received: from 10.236.62.138 (EHLO OPE10HT04.tp.gk.corp.tepenet) ([10.236.62.138]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id CHJ84207; Fri, 08 Aug 2014 16:20:00 +0200 (CEST) From: Kossut Tomasz - Hurt To: "Eric Vyncke (evyncke)" , Lorenzo Colitti Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPswOAM/qTgbBXv06rbKkXEA41n5vGrYlQ Date: Fri, 8 Aug 2014 14:19:28 +0000 Message-ID: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE744ADOPE10MB06tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.8.8.130619:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, ECARD_KNOWN_DOMAINS, __STOCK_PHRASE_7, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __HAS_HTML, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __RATWARE_SIGNATURE_3_N1, __URI_NS, HTML_70_90 X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0203.53E4DC90.015B, 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.0A0C0203.53E4DC90.015B, 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: 3b4cc769aff48891f03de6b30b037e7c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qpKA6_rmmfRnGbY9JmepKvo2nhI Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:20:10 -0000 --_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE744ADOPE10MB06tpgkco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Internet traffic for OPL ipv6 -464xlat users (3G/4G) Traffic till mid-July: Ipv6 -60% (78% to Google) Nat64 -40% Traffic from mid-July up to now: Ipv6 - 40%* (50% to Google) Nat64- 60% *On W28 we noticed abnormal drop of AAAA queries generated by users. It loo= ks like some DS servers becomes Ipv4 only, or web browser ipv4 fallback tak= es place more often.. (we analyzing data) Regards, Tomasz From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] Sent: Friday, August 08, 2014 2:12 PM To: Lorenzo Colitti Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment Lorenzo For my education, do you have a pointer for a data point on: From: Lorenzo Colitti > A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% NAT64= , and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's only us= ed for 5% of traffic, then the operator might just say, "Who cares? I don't= ; and if somebody else does, they're free to use IPv6." --_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE744ADOPE10MB06tpgkco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Internet t= raffic for OPL ipv6 -464xlat users (3G/4G)

Traffic ti= ll mid-July:

Ipv6 -60% = (78% to Google)

Nat64 -40%=

Traffic fr= om mid-July up to now:

Ipv6 ̵= 1; 40%* (50% to Google)

Nat64- 60%=

 = ;

*On W28 we= noticed abnormal drop of AAAA queries generated by users. It looks like so= me DS servers becomes Ipv4 only, or web browser ipv4 fallback takes place more often.. (we analyzing data)

 = ;

Regards,

Tomasz

 = ;

From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]
Sent: Friday, August 08, 2014 2:12 PM
To: Lorenzo Colitti
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Operational Consensus on deployment<= /span>

 

Lorenzo

 

For my education, do you ha= ve a pointer for a data point on:

 

From: Lorenzo Colitti <lorenzo@google.com>

A 4G handset with 464xlat w= ill have ~50% of traffic native IPv6, ~45% NAT64, and ~5% 464xlat. 464 conv= ersion is lossy and brittle, but if it's only used for 5% of traffic, then the operator might just say, "Who cares? I don't; an= d if somebody else does, they're free to use IPv6."<= /p>

--_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE744ADOPE10MB06tpgkco_-- From nobody Fri Aug 8 09:41: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 705951B2BA8 for ; Fri, 8 Aug 2014 09:41:11 -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 uG_ihom8krUu for ; Fri, 8 Aug 2014 09:41:10 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8C11B2BA7 for ; Fri, 8 Aug 2014 09:41:09 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so1330893wib.2 for ; Fri, 08 Aug 2014 09:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=sJMf/nou80WcRjozZdPPWHB4IPvXqo6r+hL4q4MGL1U=; b=K4dk6bgd2cMdRuhzgpVxFW56V5CZuCN5Q92+xzRN6ylK3DMsTFD7n4h/EpLOVQK82R sNuogJbO7Oio9BCEOVgEYc/PUo/aRblz1ztZhDAGlRCotMuvNG0ipEfUEHj8mm+93GOW 32qVguSjq6grKHJFmzMnhga9S8VnRY3m++Xv6pxaiz+jQ8Iu/u62bb34625cgZyMt2Gw v4GoMAtID3FTxtIOLFTLi2A/Y3dKhc2Yu9HqkpXkDDt7Tc41TufPuUzYaOAOeF9qw2Ks gL5WOZ9NdB5jyB15iLl0oFKe772vEOOmY0vNB7svc0RwGDYxt+mcVeof7cQjq34CIBih UirA== MIME-Version: 1.0 X-Received: by 10.180.12.38 with SMTP id v6mr323356wib.31.1407516068338; Fri, 08 Aug 2014 09:41:08 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Fri, 8 Aug 2014 09:41:08 -0700 (PDT) Date: Fri, 8 Aug 2014 09:41:08 -0700 X-Google-Sender-Auth: cJi_BghWxdIBo-VPY_UKmKB1zbQ Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jXAXlbDxxrzgbqImMkO4byOGUGw Cc: "v6ops@ietf.org" Subject: [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: Fri, 08 Aug 2014 16:41:11 -0000 I've read the draft and have a few comments on it: Section 4: for the probing measurement you should have sent packets without the extension headers in question to identify the point where the packets are dropped and make it more likely that it's dropped because of that extension header. It may be easily inferred from the context, but I think it's helpful to note that explicitly. As I read the rest of the draft I found it would probably just suffice to refer to Appendix A.1 from this section. Section 4 Packets dropped by the destination AS are less of a concern, since they can be assumed to be the result of an explicit policy of the organization to which the packets are destined (who can make its own decision regarding what kind of traffic is "acceptable"). I agree with the sense of this sentence, but I think the "since" clause is a bit too strong. For cases like ordinary household users connected to ISPs, the situation shouldn't be so different from the case where the packet is dropped in a transit AS in practice. Section 4: the numbers in tables 1 and 2 are confusing to me. For example, in the following cell of table 1: +--------------+-----------------+ | Dataset | DO8 | +--------------+-----------------+ | Web | 11.88% | | | (17.60%-20.80%) | +--------------+-----------------+ What exactly do these numbers represent? I guess '11.88%' is the percentage of the dropped packets against the total number or probe packets. The meaning of the "range" values were explained in the draft, but it's still not clear enough to me...is 17.60% the percentage of...what, for example? Editorial nits: - Section 3.1: s/patch/path/ ? Processing a large amounts of traffic in the slow patch may cause the - Section 3.2: s/same same/same/ for the RA-Guard case, but same same techniques can be employed for - Section 4: s/list/list)/ o Mail servers (MX -> AAAA of such list - Section 4: s/A.2/A.2)/ (?) to which a specific router belongs (see Appendix A.2, our - Section 5.2: s/forged an/forged/ sending a forged an ICMPv6 Packet Too Big [RFC4443] error message to - A.1: s/dropping/dropped/ (?) Let us assume that we find that IPv6 EHs are dropping on their way to -- JINMEI, Tatuya From nobody Fri Aug 8 13:17: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 287311A0A9D for ; Fri, 8 Aug 2014 13:17:01 -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 ImaJ40LS-4WR for ; Fri, 8 Aug 2014 13:17:00 -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 81C7A1A044F for ; Fri, 8 Aug 2014 13:16:59 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so7831613pad.36 for ; Fri, 08 Aug 2014 13:16:59 -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=ma2bjz41DI8lcF3FxfY+BzbuZVHt1NmqAfnycymhEj4=; b=aUNj3ZlQMdlTlP/TruRhydxpV8Yem9SwKvEsP1m9Ug4vv1qLgIrb5w1sfpYLAlkTuR AEpt/WGJzClVYJBoiECpUnEfjATCRoRArs/zF4Hee2bz6dVP/QTwb3hFNFbri9TaVpL0 Ewmx0p3/EoYJBkoHdHFRZF84bAHmQIt8TR0poHDwfBeJg0u/pNY3Kxx6jpx/lACevMBB kZ3v6X/LngNny0x8uNzguTKJlPS8xgNUjVWJ1IHRV3M/EBOoTsXGUWHNZ2Bk9mZ7Hh/X wa+M9G7ar/MLAGloMSfPN5FXB7/9XK0km9gl0xQ0TMmDsYLof7UOLsdAQCSCGl9ig4nA +dOg== X-Received: by 10.70.89.76 with SMTP id bm12mr10446800pdb.40.1407529019175; Fri, 08 Aug 2014 13:16:59 -0700 (PDT) Received: from [192.168.178.23] (146.197.69.111.dynamic.snap.net.nz. [111.69.197.146]) by mx.google.com with ESMTPSA id gm1sm3859547pbc.40.2014.08.08.13.16.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:16:58 -0700 (PDT) Message-ID: <53E53044.7060604@gmail.com> Date: Sat, 09 Aug 2014 08:17:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OU2TF_toSjboii5grJnH29A_N4I Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, "v6ops@ietf.org" 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: Fri, 08 Aug 2014 20:17:01 -0000 Hi, On 09/08/2014 04:41, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: =2E.. > Section 4 > Packets dropped by the destination AS are less of a > concern, since they can be assumed to be the result of an explicit > policy of the organization to which the packets are destined (who ca= n > make its own decision regarding what kind of traffic is > "acceptable"). > I agree with the sense of this sentence,=20 Actually, I disagree. You cannot assume that the network managers have taken a conscious decision; the only safe assumption is that they have accepted the vendor default of their firewall or load balancer product. (Which is why I for one care a lot about the recommendations in draft-gont-opsec-ipv6-eh-filtering.) > but I think the "since" > clause is a bit too strong. For cases like ordinary household users > connected to ISPs, the situation shouldn't be so different from the > case where the packet is dropped in a transit AS in practice. Indeed; the user is a victim of ISP policy. Brian From nobody Fri Aug 8 13:51:20 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 CC03F1A064C for ; Fri, 8 Aug 2014 13:51:18 -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 T7mBT__uci8E for ; Fri, 8 Aug 2014 13:51:16 -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 6F4A71A0197 for ; Fri, 8 Aug 2014 13:51:15 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XFr83-0006qi-1m; Fri, 08 Aug 2014 22:51:11 +0200 Message-ID: <53E5382E.3010302@si6networks.com> Date: Fri, 08 Aug 2014 16:50:54 -0400 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?56We5piO6YGU5ZOJ?= , draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zvE7cMp_0ZLRB59kEgrx-ZFSEYM Cc: "v6ops@ietf.org" 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: Fri, 08 Aug 2014 20:51:19 -0000 Ji, Jinmei, Thanks so much for your feedback! -- Please find my comments in-line... On 08/08/2014 12:41 PM, 神ćŽé”哉 wrote: > I've read the draft and have a few comments on it: > > Section 4: for the probing measurement you should have sent packets > without the extension headers in question to identify the point where > the packets are dropped and make it more likely that it's dropped > because of that extension header. Yes, that's exactly what we did. > It may be easily inferred from the > context, but I think it's helpful to note that explicitly. As I read > the rest of the draft I found it would probably just suffice to refer > to Appendix A.1 from this section. Will do. > Section 4 > Packets dropped by the destination AS are less of a > concern, since they can be assumed to be the result of an explicit > policy of the organization to which the packets are destined (who can > make its own decision regarding what kind of traffic is > "acceptable"). > I agree with the sense of this sentence, but I think the "since" > clause is a bit too strong. For cases like ordinary household users > connected to ISPs, the situation shouldn't be so different from the > case where the packet is dropped in a transit AS in practice. Agreed. Although in this case we were testing servers, as opposed to clients. > > Section 4: the numbers in tables 1 and 2 are confusing to me. For > example, in the following cell of table 1: > > +--------------+-----------------+ > | Dataset | DO8 | > +--------------+-----------------+ > | Web | 11.88% | > | | (17.60%-20.80%) | > +--------------+-----------------+ > > What exactly do these numbers represent? 11.88% is the packet drop rate when using IPv6 D08. i.e., for 11.88% of destinations, communications fail if you employ DO8. What's withing parenthesis is the rate of packet drops occurring in different ASes. That is, when packet drops do occur, between 17.60% and 20% of such drops occur in a different AS (the reason for the "range" is explained in the appendix). You're not the first to be confused by this table, though :-(. Any ideas on how to make this more clear? Maybe add a paragraph explaining one of the cells? (inclufing "mean and varince" wouldn't be much of an improvement in terms of clarity, I think) > I guess '11.88%' is the > percentage of the dropped packets against the total number or probe > packets. The meaning of the "range" values were explained in the > draft, but it's still not clear enough to me...is 17.60% the > percentage of...what, for example? 17.60% is the percentage of the aforementioned packet drops that occurred in a different AS than the destination AS (failing on the side of "we assume the drop occurs in the dest AS" when in doubt). 20.80% represents the same value, but assuming "the drop occurs in the dest AS" when in doubt. > Editorial nits: > > - Section 3.1: s/patch/path/ ? > Processing a large amounts of traffic in the slow patch may cause the Yep. Thanks! > > - Section 3.2: s/same same/same/ > for the RA-Guard case, but same same techniques can be employed for > > - Section 4: s/list/list)/ > o Mail servers (MX -> AAAA of such list > > - Section 4: s/A.2/A.2)/ (?) > to which a specific router belongs (see Appendix A.2, our > > - Section 5.2: s/forged an/forged/ > sending a forged an ICMPv6 Packet Too Big [RFC4443] error message to > > - A.1: s/dropping/dropped/ (?) > Let us assume that we find that IPv6 EHs are dropping on their way to You're right about all of these. We will fix them in the next revision. 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 Fri Aug 8 14:02: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 4EAE81A03B1 for ; Fri, 8 Aug 2014 14:01:59 -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 g_AXxc1yxf5V for ; Fri, 8 Aug 2014 14:01: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 93F0A1A0158 for ; Fri, 8 Aug 2014 14:01:57 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XFrIP-0006t3-Oo; Fri, 08 Aug 2014 23:01:54 +0200 Message-ID: <53E53AB2.5060206@si6networks.com> Date: Fri, 08 Aug 2014 17:01:38 -0400 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 , =?UTF-8?B?56We5piO6YGU?= =?UTF-8?B?5ZOJ?= References: <53E53044.7060604@gmail.com> In-Reply-To: <53E53044.7060604@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VhAuiGrC06cpvBuxtVKkuVxj_KY Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, "v6ops@ietf.org" 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: Fri, 08 Aug 2014 21:01:59 -0000 Hi, Brian, On 08/08/2014 04:17 PM, Brian E Carpenter wrote: > > On 09/08/2014 04:41, 神ćŽé”哉 wrote: > ... >> Section 4 >> Packets dropped by the destination AS are less of a >> concern, since they can be assumed to be the result of an explicit >> policy of the organization to which the packets are destined (who can >> make its own decision regarding what kind of traffic is >> "acceptable"). >> I agree with the sense of this sentence, > > Actually, I disagree. Some rationale: When we presented our initial results showing just the packet drop-rate, some folks kind of noted that 'well, that may not be that bad if the drops occur at the destination as..'. So you might argue that, to some extent, we tried to be optimistic here. If you ask me, the fact that they are dropped by anyone other than the very destination *system* (rather than AS) should be taken as an indication that there's a problem with usability of IPv6 EHs... > You cannot assume that the network managers have > taken a conscious decision; the only safe assumption is that they have > accepted the vendor default of their firewall or load balancer product. Yes. We should have just said something along the lines of "this is the best-case scenario, since at least the packet drops are under the control of the same org as the destination system". --- although this is still tricky.. you may have a VPS, or rack and it is the ISP the one dropping the packets. i.e., even if dest AS == dropping AS, the org running the server may be different than that dropping the packets. > (Which is why I for one care a lot about the recommendations in > draft-gont-opsec-ipv6-eh-filtering.) Agreed. >> but I think the "since" >> clause is a bit too strong. For cases like ordinary household users >> connected to ISPs, the situation shouldn't be so different from the >> case where the packet is dropped in a transit AS in practice. > > Indeed; the user is a victim of ISP policy. Some preliminar data seems to indicate that there's also an issue with buggy (?) CPEs that drop packets with IPv6 EHs. Hopefully we will have more data available soon. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Aug 9 12:08: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 A117E1A001A for ; Sat, 9 Aug 2014 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rlXZ1487hmVr for ; Sat, 9 Aug 2014 12:08:18 -0700 (PDT) Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id B24EB1A02BE for ; Sat, 9 Aug 2014 12:08:14 -0700 (PDT) Received: (qmail 30586 messnum 12535637 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 9 Aug 2014 19:08:12 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail06.svc.cra.dublin.eircom.net (qp 30586) with SMTP; 9 Aug 2014 19:08:12 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id cj891o00e0mJ9Tz01j8Cm9; Sat, 09 Aug 2014 20:08:12 +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: <53E35B3D.3080903@fud.no> Date: Sat, 9 Aug 2014 20:07:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3A1BBD31-FEE7-4656-8C5F-041A959BA0A6@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <3EC4EB99-F877-478D-BFE6-959F58127579@eircom.net> <53E35B3D.3080903@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yQN7nJZy95bp-JFbhZv4jvK0el0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 19:08:21 -0000 On 7 Aug 2014, at 11:55, Tore Anderson wrote > what do you think about this? >=20 > = http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/ma= ster/siit-dc.html#rfc.appendix.B I=92m still liking it, as the advantages of an IPv6-only DC will be = high. How about the case of an IPv6-only DC network with multiple separate = SIIT-DC translation prefixes (mentioned in Sec 3.4). Which translation = prefix will be used in the case where DNS64 (Sec 3.3) is also being = used? It seems like DNS64 might only work easily with a single = translation prefix.=20 Ross From nobody Sat Aug 9 20:58: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 41E9B1A044F for ; Sat, 9 Aug 2014 20:57:58 -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 R4jbmTpv4L1k for ; Sat, 9 Aug 2014 20:57:56 -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 97D081A044D for ; Sat, 9 Aug 2014 20:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1669; q=dns/txt; s=iport; t=1407643076; x=1408852676; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0DsUXkFBjBj8NC2zGLHWCKNMGTrI8Ru/MJ3VJDoa3j0=; b=AkpyLJmx8RNsgSkblJsoEpxMbXOChXCMl44gcbKx0d8ttme4v8+1Dhds 1L52MeNC8YNtbdqqeScPwygHFpq0iUdd8xllWhpwxXh/cSaKcJqjgDf8x NEytczOh5NIG1CsLfzoW38WTUM75fHGfiGxGmLLHw+aIWvNpFLwLohH1U I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOPs5lOtJV2c/2dsb2JhbABZgw1SVwTNHIdEAYEEFneEBAEBAwF5EAIBCEYyJQIEDgUOiCADCQgNvxwKhWMXj0wHgy+BHQWRGYF/gUpchnGBV5Mkg1xsAQEBAYFD X-IronPort-AV: E=Sophos;i="5.01,834,1400025600"; d="asc'?scan'208";a="346331213" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Aug 2014 03:57:55 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7A3vsEV008266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Aug 2014 03:57:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Sat, 9 Aug 2014 22:57:54 -0500 From: "Fred Baker (fred)" To: Ross Chandler Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPtE85Q9MgV+ch0ke/DCbii8mM+g== Date: Sun, 10 Aug 2014 03:57:37 +0000 Message-ID: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <3EC4EB99-F877-478D-BFE6-959F58127579@eircom.net> <53E35B3D.3080903@fud.no> <3A1BBD31-FEE7-4656-8C5F-041A959BA0A6@eircom.net> In-Reply-To: <3A1BBD31-FEE7-4656-8C5F-041A959BA0A6@eircom.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.11.160] Content-Type: multipart/signed; boundary="Apple-Mail=_F6372948-D08E-4351-BDDD-F1D27F69A50F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CqS9BLZ5T2qoMBhxpsBXUd-M230 Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 03:57:58 -0000 --Apple-Mail=_F6372948-D08E-4351-BDDD-F1D27F69A50F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 9, 2014, at 12:07 PM, Ross Chandler wrote: >=20 > On 7 Aug 2014, at 11:55, Tore Anderson wrote >> what do you think about this? >>=20 >> = http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/ma= ster/siit-dc.html#rfc.appendix.B >=20 > I=92m still liking it, as the advantages of an IPv6-only DC will be = high. >=20 > How about the case of an IPv6-only DC network with multiple separate = SIIT-DC translation prefixes (mentioned in Sec 3.4). Which translation = prefix will be used in the case where DNS64 (Sec 3.3) is also being = used? It seems like DNS64 might only work easily with a single = translation prefix.=20 RFC 6147 is designed for one translation prefix. One could imagine a = translation prefix per tenant, and you would (at least in concept) need = a DNS64 per tenant. That is unless you got smart and looked at the = source address of the packet to see which tenant it came from. --Apple-Mail=_F6372948-D08E-4351-BDDD-F1D27F69A50F 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 iD8DBQFT5u2zbjEdbHIsm0MRApSyAKCZ76b8AcTzOE1D4kp9lqKA56pANgCg3Rfe WDXnjbWb61aYk9XLLagKHsE= =9+PN -----END PGP SIGNATURE----- --Apple-Mail=_F6372948-D08E-4351-BDDD-F1D27F69A50F-- From nobody Sat Aug 9 23:36: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 9D8951A02DA; Sat, 9 Aug 2014 23:36:11 -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 K58Zduwcun7W; Sat, 9 Aug 2014 23:36:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CCC1A065F; Sat, 9 Aug 2014 23:36:09 -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: <20140810063609.27376.15781.idtracker@ietfa.amsl.com> Date: Sat, 09 Aug 2014 23:36:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xwF726vevlN9sZqp0Jdh9WJE_bI Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Sun, 10 Aug 2014 06:36:12 -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-03.txt Pages : 16 Date : 2014-08-09 Abstract: This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The investigations on those failed cases reveal the causes in order to notice improper configurations, equipment's incomplete functions or inconsistent IPv6 introduction strategy. 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-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 Sat Aug 9 23:42: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 127521A066D for ; Sat, 9 Aug 2014 23:42:39 -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 WmnLqvhTEhYn for ; Sat, 9 Aug 2014 23:42:37 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E0F1A0669 for ; Sat, 9 Aug 2014 23:42:37 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id k15so7038526qaq.13 for ; Sat, 09 Aug 2014 23:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZiatkTq5OO7gkzb4qIleR9HQsEeqiu7oPlCU4YAjdc4=; b=BzfkfVjMSlDee94kNae4PdlD7f+GFnBATqFp+mhv8T44Zeg9kC8FYkVtIefhSfv0Aa mRzGNpkneHVJnBkAkJUirWK6VgSopCwkf64rLlA8ZP3bELrUWmOMxZSKVaOwhLbHX030 aHuXAFkg5DkRBUpSfEQ62BUdtbfKMpqyc9+TLWTZUh7XVklfP+8MtsYXOUCVvKps12F7 fh6j1Q2QrJfoR38rU70PdcZAapUpB61g71PHFcJrfzlEqcxVmKFgRuLZaJAMTuRxSJcd mfqYLx4maYVZgrkaqEjubu1jCkQkbeWIpchPPyrMz4PNTU/XckBi6srbcecU/0Tt9zd9 v3Ow== MIME-Version: 1.0 X-Received: by 10.229.235.133 with SMTP id kg5mr51847813qcb.24.1407652956603; Sat, 09 Aug 2014 23:42:36 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Sat, 9 Aug 2014 23:42:36 -0700 (PDT) In-Reply-To: <20140810063609.27376.15781.idtracker@ietfa.amsl.com> References: <20140810063609.27376.15781.idtracker@ietfa.amsl.com> Date: Sun, 10 Aug 2014 14:42:36 +0800 Message-ID: From: GangChen To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CXCnP3DkkUVYSCPvGe1mJOhNOR0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Sun, 10 Aug 2014 06:42:39 -0000 WG, We have uploaded the new ID to address the WGLC comments. Please kindly check. Many thanks Gang 2014-08-10 14:36 GMT+08:00, internet-drafts@ietf.org : > > 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-03.txt > Pages : 16 > Date : 2014-08-09 > > Abstract: > This document identifies a set of failure cases that may be > encountered by IPv6-enabled mobile customers in roaming scenarios. > The investigations on those failed cases reveal the causes in order > to notice improper configurations, equipment's incomplete functions > or inconsistent IPv6 introduction strategy. > > > 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-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Mon Aug 11 00:26: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 72F0D1A0353 for ; Mon, 11 Aug 2014 00:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TGDEKw3eU6P3 for ; Mon, 11 Aug 2014 00:26:47 -0700 (PDT) Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by ietfa.amsl.com (Postfix) with SMTP id 907861A0350 for ; Mon, 11 Aug 2014 00:26:46 -0700 (PDT) Received: (qmail 36373 messnum 5485650 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 11 Aug 2014 07:26:44 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail09.svc.cra.dublin.eircom.net (qp 36373) with SMTP; 11 Aug 2014 07:26:44 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id dKSg1o00K0mJ9Tz01KSjVy; Mon, 11 Aug 2014 08:26:44 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_194EFC56-B9BC-4158-B04A-89DBD9C4ECD8" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Mon, 11 Aug 2014 08:26:35 +0100 Message-Id: <016DA482-E7B0-47BE-B15A-8B9D11A21E87@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> To: Geir Egeland X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BvwO6s6cMiszf8itY_hKKL-DnGI Cc: Tore Anderson , IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Mon, 11 Aug 2014 07:26:49 -0000 --Apple-Mail=_194EFC56-B9BC-4158-B04A-89DBD9C4ECD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 Aug 2014, at 07:14, Geir Egeland wrote: > So let me try to shed some light on what we are thinking in Telenor = Norway. >=20 > Even though we have launched an IPv6-only APN, our main strategy for = the home network is to support the Ext. PDP type. Also, both our fixed = and mobile network architectures are based on DS. >=20 > We are currently working on putting the final pieces together for = enabling DS. Roaming brokeness caused by the ext. PDP is a major concern = for us. DS will affect our whole customer base, so it will take a while = with testing before we are comfortable launching this. >=20 > Telenor Norway has been piloting NAT64/464XLAT for some time now with = no major issues. We see that we need to support all scenarios for mobile = devices, i.e. IPv4-only, IPv6-only and DS. We chose to launch IPv6 on a = few selected devices as a gradual introduction of IPv6 in our mobile = network.=20 >=20 > By enabling IPv6-only on a few handsets, we can identify those mobile = operators that do not support IPv6-roaming and we use this opportunity = to contact them through commercial and technical channels, urging them = to enable IPv6 support on their SGSN. If this is unsuccessful, we will = consider steering the roaming traffic away from those operators during a = transition period if necessary. >=20 IMHO this will really help the IPv6 community as it provides an easy to = understand message for the business on why we need to enable IPv6 in the = user plane for visitors. The draft should probably mention this risk of being steered away from = by an operator that wants IPv6. At the moment the draft just mentions = this in the context of the home operator=92s own business steering = traffic to an operator that doesn=92t support IPv6 in the user-plane.=20 On enabling IPv6 in the user plane the draft currently says =93it=92s = expected that visited network is IPv6 roaming friendly to enable the = functions on SGSN/MME by default=94. Do operators with it on, have it enabled for all IMSI series or do it by = IMSI series? I=92d like to turn it on by default for all. > We believe it is important to take an active stand on this instead of = waiting for everyone to get around to enable IPv6. As many people on the = mailing list have mentioned, there are cases where roaming on IPv6 = fails. This is also our experience, but it is something we are willing = to accept.=20 >=20 > As Tore has mentioned, our customers are free to use one of our = IPv4-only APNs, however, we have not had any such requests. >=20 > BR, >=20 > Geir Egeland > Telenor Group/Telenor Norway BR=20 Ross --Apple-Mail=_194EFC56-B9BC-4158-B04A-89DBD9C4ECD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 11 Aug 2014, at 07:14, Geir Egeland = <geir.egeland@gmail.com> = wrote:

So let me try to shed some = light on what we are thinking in Telenor Norway.

Even though we = have launched an IPv6-only APN, our main strategy for the home network is to support the Ext. PDP type. = Also, both our fixed and mobile network architectures are based on DS.

We are currently working on = putting the final pieces together for enabling DS. Roaming brokeness caused by the ext. = PDP is a major concern for us. DS will affect our whole customer base, so it will = take a while with testing before we are comfortable launching this. =

Telenor Norway has been = piloting NAT64/464XLAT for some time now with no major issues. We see that we need to support = all scenarios for mobile devices, i.e. IPv4-only, IPv6-only and DS. We chose to launch = IPv6 on a few selected devices as a gradual introduction of IPv6 in our = mobile network. 

By = enabling IPv6-only on a few handsets, we can identify those mobile operators that do not support IPv6-roaming and we use this opportunity to contact them through = commercial and technical channels, urging them to enable IPv6 support on their SGSN. If = this is unsuccessful, we will consider steering the roaming traffic away from = those operators during a transition period if necessary. =

IMHO this will really help the IPv6 = community as it provides an easy to understand message for the business = on why we need to enable IPv6 in the user plane for = visitors.

The draft should probably mention = this risk of being steered away from by an operator that wants IPv6. At = the moment the draft just mentions this in the context of the home = operator=92s own business steering traffic to an operator that doesn=92t = support IPv6 in the user-plane. 

On = enabling IPv6 in the user plane the draft currently says =93it=92s expected that visited network is = IPv6 roaming friendly to enable the functions on SGSN/MME by = default=94.
Do = operators with it on, have it enabled for all IMSI series or do it by = IMSI series? I=92d like to turn it on by default for = all.

We = believe it is important to take an active stand on this instead of waiting for everyone to get = around to enable IPv6. As many people on the mailing list have mentioned, there = are cases where roaming on IPv6 fails. This is also our experience, but it = is something we are willing to accept. 

As Tore has mentioned, our customers are free to use one of our IPv4-only APNs, however, we = have not had any such requests.

BR,

Geir Egeland
Telenor = Group/Telenor Norway
=


BR = ;
Ross


= --Apple-Mail=_194EFC56-B9BC-4158-B04A-89DBD9C4ECD8-- From nobody Mon Aug 11 00:30: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 14A041A035A for ; Mon, 11 Aug 2014 00:30:46 -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 V5GfHt2wb6Mn for ; Mon, 11 Aug 2014 00:30:44 -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 986A41A0359 for ; Mon, 11 Aug 2014 00:30:44 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=54917 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 1XGk3x-0006Oa-Tb; Mon, 11 Aug 2014 09:30:37 +0200 Message-ID: <53E870CB.9030803@fud.no> Date: Mon, 11 Aug 2014 09:29:15 +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: "Fred Baker (fred)" , Ross Chandler References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <3EC4EB99-F877-478D-BFE6-959F58127579@eircom.net> <53E35B3D.3080903@fud.no> <3A1BBD31-FEE7-4656-8C5F-041A959BA0A6@eircom.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ad-hcXa9UyHLp1gA3efh9CsmuBE Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 07:30:46 -0000 * Fred Baker (fred) > On Aug 9, 2014, at 12:07 PM, Ross Chandler wrote: > >> How about the case of an IPv6-only DC network with multiple >> separate SIIT-DC translation prefixes (mentioned in Sec 3.4). Which >> translation prefix will be used in the case where DNS64 (Sec 3.3) >> is also being used? It seems like DNS64 might only work easily with >> a single translation prefix. > > RFC 6147 is designed for one translation prefix. One could imagine a > translation prefix per tenant, and you would (at least in concept) > need a DNS64 per tenant. That is unless you got smart and looked at > the source address of the packet to see which tenant it came from. I'm thinking that multiple instances is an advanced topic that would be better documented in a separate draft. I'd preferably like to keep this draft concise and to the point, thus making it easy to read and understand. In any case, multiple SIIT instances should be relatively straightforward. If the applications in questions are server-style ones that are merely responding to client traffic (think HTTP) then it's really a no-brainer, as the inbound client traffic will already have a source IPv6 address within the appropriate SIIT instance's translation prefix, to which the server will respond accordingly automatically. If on the other hand it's the IPv6 application that is responsible for initiating traffic to IPv4 destinations, then it would need to choose the appropriate translation prefix for synthesising the IPv4-mapped IPv6 address to initiate communication to. It would have to do that even if there is only one SIIT instance, too.) If the application is using DNS, then DNS64 could be used for this purpose, which could be deployed in a number of ways (locally on the server itself, dedicated DNS64 servers per SIIT instance, one DNS64 server but with multiple views per SIIT instance, ...). Other options would be for the application to synthesise the IPv4-mapped addresses itself according to RFC6052, in which case the choice of translation prefix (and thus the SIIT instance) would be a configuration options; or finally, you could use the host agent approach, in which case the translation prefix (and thus the SIIT instance) becomes part of the host agent's configuration instead. Tore From nobody Mon Aug 11 00:58: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 0AC471A0366 for ; Mon, 11 Aug 2014 00:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tx5LcjKszTIR for ; Mon, 11 Aug 2014 00:58:07 -0700 (PDT) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by ietfa.amsl.com (Postfix) with SMTP id 366381A0365 for ; Mon, 11 Aug 2014 00:58:06 -0700 (PDT) Received: (qmail 26877 messnum 4580674 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 11 Aug 2014 07:58:05 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail04.svc.cra.dublin.eircom.net (qp 26877) with SMTP; 11 Aug 2014 07:58:05 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id dKy11o00N0mJ9Tz01Ky5tc; Mon, 11 Aug 2014 08:58:05 +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: <53E870CB.9030803@fud.no> Date: Mon, 11 Aug 2014 08:58:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F7DB0F0-6DF4-4630-A84D-44C764B2865F@eircom.net> References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <3EC4EB99-F877-478D-BFE6-959F58127579@eircom.net> <53E35B3D.3080903@fud.no> <3A1BBD31-FEE7-4656-8C5F-041A959BA0A6@eircom.net> <53E870CB.9030803@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UCi01LsxDsfgYp6g_2XTzMRAWLw Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 07:58:09 -0000 On 11 Aug 2014, at 08:29, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> On Aug 9, 2014, at 12:07 PM, Ross Chandler wrote: >>=20 >>> How about the case of an IPv6-only DC network with multiple >>> separate SIIT-DC translation prefixes (mentioned in Sec 3.4). Which >>> translation prefix will be used in the case where DNS64 (Sec 3.3) >>> is also being used? It seems like DNS64 might only work easily with >>> a single translation prefix. >>=20 >> RFC 6147 is designed for one translation prefix. One could imagine a >> translation prefix per tenant, and you would (at least in concept) >> need a DNS64 per tenant. That is unless you got smart and looked at >> the source address of the packet to see which tenant it came from. >=20 > I'm thinking that multiple instances is an advanced topic that would = be > better documented in a separate draft. I'd preferably like to keep = this > draft concise and to the point, thus making it easy to read and = understand. >=20 > In any case, multiple SIIT instances should be relatively > straightforward. If the applications in questions are server-style = ones > that are merely responding to client traffic (think HTTP) then it's > really a no-brainer, as the inbound client traffic will already have a > source IPv6 address within the appropriate SIIT instance's translation > prefix, to which the server will respond accordingly automatically. >=20 > If on the other hand it's the IPv6 application that is responsible for > initiating traffic to IPv4 destinations, then it would need to choose > the appropriate translation prefix for synthesising the IPv4-mapped = IPv6 > address to initiate communication to. It would have to do that even if > there is only one SIIT instance, too.) >=20 > If the application is using DNS, then DNS64 could be used for this > purpose, which could be deployed in a number of ways (locally on the > server itself, dedicated DNS64 servers per SIIT instance, one DNS64 > server but with multiple views per SIIT instance, ...). >=20 > Other options would be for the application to synthesise the = IPv4-mapped > addresses itself according to RFC6052, in which case the choice of > translation prefix (and thus the SIIT instance) would be a = configuration > options; or finally, you could use the host agent approach, in which > case the translation prefix (and thus the SIIT instance) becomes part = of > the host agent=92s configuration instead. That approach to documenting it sounds fine to me.=20 Ross= From nobody Mon Aug 11 06:21: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 653081A0172; Mon, 11 Aug 2014 06:21:11 -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 Yh45VnFF32S4; Mon, 11 Aug 2014 06:21:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F261A06FC; Mon, 11 Aug 2014 06:21:08 -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: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 06:21:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8EoGzajyOVwSqoiSnbhsuJL1RnY Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 13:21:11 -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 Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-08.txt Pages : 18 Date : 2014-08-11 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 11 09:27: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 7245D1A06C7 for ; Mon, 11 Aug 2014 09:27:14 -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 q5DqSEXuOGut for ; Mon, 11 Aug 2014 09:27:13 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c: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 44A201A06A1 for ; Mon, 11 Aug 2014 09:27:13 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so8801807wev.41 for ; Mon, 11 Aug 2014 09:27:11 -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=EVAG1+Jo4QurK7CmByIq1oULhb9VtTpvNH0KUhQU40k=; b=G85AmJCFqNIVxlAHEd9D/NeScH7hMqZ9SMeVT3o8KiHeFlwFQv/MUTg7VMuJ0pkGPs Po/gw2roo9Bfo75pk5CE7QQ/UZYycx+5gSU+POJAs3/wRUO2wWLVwNdPpUivifmcg4ZW 36ccT2N99fBA6RA1Oh6ytNzqTbfWkFYhmup+uOWw2hNnyXXn6vXkI57JH91BlfpChiy9 Tiw0h+juBSRaIc/p6Cq3XMttEnExOOVrk7Cz/DFfHs4xLZi0Bxz3KpXmlyRd2Dmiq4US pozcuqbv2wZ0HeVU5+0DLf6Tc/4i4w8cUIioxj5fWGZrg1u95zzZqZOb5jJSdaEK3vOd XEqw== MIME-Version: 1.0 X-Received: by 10.180.75.49 with SMTP id z17mr26113126wiv.80.1407774431854; Mon, 11 Aug 2014 09:27:11 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Mon, 11 Aug 2014 09:27:11 -0700 (PDT) In-Reply-To: <53E53044.7060604@gmail.com> References: <53E53044.7060604@gmail.com> Date: Mon, 11 Aug 2014 09:27:11 -0700 X-Google-Sender-Auth: UfzFjcKTtzsW1ISD86JcjVr-4HU 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/KX-6ZNTh9_Aq2naC7vP3hOWb370 Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, "v6ops@ietf.org" 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: Mon, 11 Aug 2014 16:27:14 -0000 At Sat, 09 Aug 2014 08:17:08 +1200, Brian E Carpenter wrote: > > Section 4 > > Packets dropped by the destination AS are less of a > > concern, since they can be assumed to be the result of an explicit > > policy of the organization to which the packets are destined (who can > > make its own decision regarding what kind of traffic is > > "acceptable"). > > I agree with the sense of this sentence, > > Actually, I disagree. You cannot assume that the network managers have > taken a conscious decision; the only safe assumption is that they have > accepted the vendor default of their firewall or load balancer product. > (Which is why I for one care a lot about the recommendations in > draft-gont-opsec-ipv6-eh-filtering.) I guess I was just not clear enough. The "sense" I saw in the draft text is that there can be a noticeable difference between packets dropped in the middle and packets dropped in the destination AS (and it makes some sense to measure the packet drop rate for these cases separately): in the latter case it's *possible* that the same organization manages the entire AS including the packet's final destination and dropping the packet is actually the intended behavior of the administrator. I noted that it's still not *always* the case in the "but" below, and in that sense I think we are actually on the same page. > > but I think the "since" > > clause is a bit too strong. For cases like ordinary household users > > connected to ISPs, the situation shouldn't be so different from the > > case where the packet is dropped in a transit AS in practice. > > Indeed; the user is a victim of ISP policy. -- JINMEI, Tatuya From nobody Mon Aug 11 09:43: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 C5CBE1A0317 for ; Sun, 10 Aug 2014 23:14:07 -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 kKp6AAyk_Ja8 for ; Sun, 10 Aug 2014 23:14:04 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010: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 E36F91A0323 for ; Sun, 10 Aug 2014 23:14:03 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gf5so6271636lab.23 for ; Sun, 10 Aug 2014 23:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :message-id:references:to; bh=9q/BQXhaNv/OM8X1DDEkesOOZ92jP3YegZCRciC2cuU=; b=rTJ/aH83hitmZrIo29a8KIeIvdMN75oRX9wKXwTZ7P0Yf5eTFkRsYn2YY5fRpA5Hb3 mQ653XvJTE/tP/fi49bXrtaI1fx5iYOueQfIMrwgs1Jg49lFJ7kl0jbiHFxAjvHtc4S5 UxiitCER/0BrCawiocuuy0BIaRumrx+4tkLBjMVhHHPiPYkaHXGMjDwzRwWsF3GN5Cvt aYYTF2x/F3bsPP/n4GR+kbJfnyB09C1/qdibyYFgPQu4F3xp2x0lBOR3hx7Y23f5CpTP TrgkQL9r590n8NafhMaA71e6zdwqIuxOpQWkMO3GCZ6MUUeknMQLHoVnYg4bQISPVLPt g2lg== X-Received: by 10.112.255.36 with SMTP id an4mr34899749lbd.31.1407737642139; Sun, 10 Aug 2014 23:14:02 -0700 (PDT) Received: from [192.168.1.15] (ti0125a400-0205.bb.online.no. [88.91.212.206]) by mx.google.com with ESMTPSA id tj1sm16833656lbb.40.2014.08.10.23.14.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Aug 2014 23:14:01 -0700 (PDT) From: Geir Egeland X-Google-Original-From: Geir Egeland Content-Type: multipart/alternative; boundary="Apple-Mail=_299A0781-02E1-4A2B-9D54-7BB8A84919E5" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) In-Reply-To: Date: Mon, 11 Aug 2014 08:14:00 +0200 Message-Id: References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <94146541-768B-4853-A011-7558655C361C@eircom.net> <53E11795.7060305@fud.no> <53E1D951.8030200@fud.no> <3f59106bc21840dfb144c7933215294f@srvhk403.rdm.cz> <53E27522.4070901@fud.no> <84A403BD-7E93-4D99-8C11-FB7F91B68154@eircom.net> <0CEE83E4-FA58-4D85-B753-1F218540C624@eircom.net> <53E30E74.7050502@fud.no> To: Ca By X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vCXLtV2BTJXMPw_mpjMx_EiKPMo X-Mailman-Approved-At: Mon, 11 Aug 2014 09:43:08 -0700 Cc: Tore Anderson , IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-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: Mon, 11 Aug 2014 06:14:08 -0000 --Apple-Mail=_299A0781-02E1-4A2B-9D54-7BB8A84919E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, So let me try to shed some light on what we are thinking in Telenor = Norway. Even though we have launched an IPv6-only APN, our main strategy for the = home network is to support the Ext. PDP type. Also, both our fixed and = mobile network architectures are based on DS. We are currently working on putting the final pieces together for = enabling DS. Roaming brokeness caused by the ext. PDP is a major concern = for us. DS will affect our whole customer base, so it will take a while = with testing before we are comfortable launching this. Telenor Norway has been piloting NAT64/464XLAT for some time now with no = major issues. We see that we need to support all scenarios for mobile = devices, i.e. IPv4-only, IPv6-only and DS. We chose to launch IPv6 on a = few selected devices as a gradual introduction of IPv6 in our mobile = network. By enabling IPv6-only on a few handsets, we can identify those = mobile operators that do not support IPv6-roaming and we use this = opportunity to contact them through commercial and technical channels, = urging them to enable IPv6 support on their SGSN. If this is = unsuccessful, we will consider steering the roaming traffic away from = those operators during a transition period if necessary. We believe it = is important to take an active stand on this instead of waiting for = everyone to get around to enable IPv6. As many people on the mailing = list have mentioned, there are cases where roaming on IPv6 fails. This = is also our experience, but it is something we are willing to accept.=20 As Tore has mentioned, our customers are free to use one of our = IPv4-only APNs, however, we have not had any such requests. BR, Geir Egeland Telenor Group/Telenor Norway On 07-08-14, at 15:58 , Ca By wrote: >=20 > On Aug 7, 2014 6:17 AM, "Ross Chandler" wrote: > > > > > > On 7 Aug 2014, at 13:56, Ca By wrote: > > > >> I agree, for my own phone, i roam internationally with no issue on = ipv6. > >> > >> CB=20 > > > > Cameron, > > > > Are you saying the support for IPv6 in the user-plane for visitors = is good enough for enthuasists willing to toggle their APN protocol = setting when they roam or that the position is already so good that we = can all start copying Telenor? > > > > BR > > Ross >=20 > If Telenor has taken this leadership position, then i expect those few = lingering issues to be resolved quickly with the problem network = operators. >=20 > It is worth revisiting the data before changing default settings. >=20 > In my own network, roaming makes up for a very small percentage of ip = address usage, so the benefit is not very high >=20 > CB >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_299A0781-02E1-4A2B-9D54-7BB8A84919E5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Hi,

So let me try to shed some light on what we are thinking in Telenor Norway.

Even though we have launched an IPv6-only APN, our main strategy for the home network is to support the Ext. PDP type. Also, both our fixed and mobile network architectures are based on DS.

We are currently working on putting the final pieces together for enabling DS. Roaming brokeness caused by the ext. PDP is a major concern for us. DS will affect our whole customer base, so it will take a while with testing before we are comfortable launching this.

Telenor Norway has been piloting NAT64/464XLAT for some time now with no major issues. We see that we need to support all scenarios for mobile devices, i.e. IPv4-only, IPv6-only and DS. We chose to launch IPv6 on a few selected devices as a gradual introduction of IPv6 in our mobile network.  By enabling IPv6-only on a few handsets, we can identify those mobile operators that do not support IPv6-roaming and we use this opportunity to contact them through commercial and technical channels, urging them to enable IPv6 support on their SGSN. If this is unsuccessful, we will consider steering the roaming traffic away from those operators during a transition period if necessary. We believe it is important to take an active stand on this instead of waiting for everyone to get around to enable IPv6. As many people on the mailing list have mentioned, there are cases where roaming on IPv6 fails. This is also our experience, but it is something we are willing to accept. 

As Tore has mentioned, our customers are free to use one of our IPv4-only APNs, however, we have not had any such requests.

BR,

Geir Egeland
Telenor Group/Telenor Norway

On 07-08-14, at 15:58 , Ca By <cb.list6@gmail.com> wrote:


On Aug 7, 2014 6:17 AM, "Ross Chandler" <ross@eircom.net> wrote:
>
>
> On 7 Aug 2014, at 13:56, Ca By <cb.list6@gmail.com> wrote:
>
>> I agree, for my own phone, i roam internationally with no issue on ipv6.
>>
>> CB 
>
> Cameron,
>
> Are you saying the support for IPv6 in the user-plane for visitors is good enough for enthuasists willing to toggle their APN protocol setting when they roam or that the position is already so good that we can all start copying Telenor?
>
> BR
> Ross

If Telenor has taken this leadership position, then i expect those few lingering issues to be resolved quickly with the problem network operators.

It is worth revisiting the data before changing default settings.

In my own network,  roaming makes up for a very small percentage of ip address usage, so the benefit is not very high

CB

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

--Apple-Mail=_299A0781-02E1-4A2B-9D54-7BB8A84919E5-- From nobody Mon Aug 11 10:04:48 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 B893F1A0461 for ; Mon, 11 Aug 2014 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 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, J_CHICKENPOX_42=0.6, 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 mBMaQO_taKgu for ; Mon, 11 Aug 2014 10:04:46 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E831A0661 for ; Mon, 11 Aug 2014 10:04:46 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so4597871wib.8 for ; Mon, 11 Aug 2014 10:04: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=j3IqRe8djDfuit6vnAJuzWrcHVkhXU9jDN6B1gL1eJU=; b=mHrS/QCQ8ngbBVUKJlDunptn29FELOxbpj+vRtRWa3QL6pOI9/WP8Vj6Fc9eIoBfMU CW29vZdrkh21/pOTbikD2SaVslLOOBhF3gSK8A6LppQC+Hb6r51e0toNhmYk8tHok50L ULvzxWbtlKov4UApx5LQUGY4NoshqMOcHuKNKHtB2H73Ni3V/AcibZWXNoYN8eNxJ9Ca rRe1t4x9T4r29CoFQpnsyQlzHnSwntdFS0HbKxaHVUBNjWC++qo2O5DUB4P5VWWIxt3q Qr9v2927tREuyQVn5aXLIqEZ3uSNv6PxlL6gOY37DgluyDBk7VOKv9kTUJzTbxVWCLMr ZBfg== MIME-Version: 1.0 X-Received: by 10.180.184.99 with SMTP id et3mr21613904wic.31.1407776684796; Mon, 11 Aug 2014 10:04:44 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Mon, 11 Aug 2014 10:04:44 -0700 (PDT) In-Reply-To: <53E5382E.3010302@si6networks.com> References: <53E5382E.3010302@si6networks.com> Date: Mon, 11 Aug 2014 10:04:44 -0700 X-Google-Sender-Auth: Z-qSyymF_flNktZnkaTT66qyHOg Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Brg_tQetqkXh4TNf_RhTMPZQFQU Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, "v6ops@ietf.org" 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: Mon, 11 Aug 2014 17:04:47 -0000 At Fri, 08 Aug 2014 16:50:54 -0400, Fernando Gont wrote: > > Section 4 > > Packets dropped by the destination AS are less of a > > concern, since they can be assumed to be the result of an explicit > > policy of the organization to which the packets are destined (who can > > make its own decision regarding what kind of traffic is > > "acceptable"). > > I agree with the sense of this sentence, but I think the "since" > > clause is a bit too strong. For cases like ordinary household users > > connected to ISPs, the situation shouldn't be so different from the > > case where the packet is dropped in a transit AS in practice. > > Agreed. Although in this case we were testing servers, as opposed to > clients. I thought these sentences (more specifically, "Packets dropped by the intended destination...are dropped by a transit AS.") talk about a general observation, rather than something very specific to the measurement. Besides, I believe my comment also applies to "servers" in that the admin of the destination AS may not always be the admin of the destination server. > > Section 4: the numbers in tables 1 and 2 are confusing to me. For > > example, in the following cell of table 1: > > > > +--------------+-----------------+ > > | Dataset | DO8 | > > +--------------+-----------------+ > > | Web | 11.88% | > > | | (17.60%-20.80%) | > > +--------------+-----------------+ > > > > What exactly do these numbers represent? > > 11.88% is the packet drop rate when using IPv6 D08. i.e., for 11.88% of > destinations, communications fail if you employ DO8. This one is pretty clear to me, and I interpreted it that way. The confusing part is the numbers in the parentheses. > What's withing parenthesis is the rate of packet drops occurring in > different ASes. That is, when packet drops do occur, between 17.60% and > 20% of such drops occur in a different AS (the reason for the "range" is > explained in the appendix). So, for example, if you sent out 10,000 packets with IPv6 DO8: - 1188 packets were dropped - Out of these 1188 dropped packets, 209 to 237 packets seem to have been dropped in an different AS ? It would be very difficult to reach this understanding just from the text and the table, at least to me:-) > You're not the first to be confused by this table, though :-(. Any ideas > on how to make this more clear? Maybe add a paragraph explaining one of > the cells? (inclufing "mean and varince" wouldn't be much of an > improvement in terms of clarity, I think) One easy improvement that would have worked for me is to add more description to the tables, e.g. "Table 1: WIPv6LD dataset: Packet drop rate for different destination types (upper) and estimated percentage of dropped packets that were deemed to be dropped in a different AS (lower, in parentheses)". 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. But, now that I understand what it actually means, I'm not in a good position of proposing a good suggestion anymore; it's already impossible for me to see how it works for first-time readers. -- JINMEI, Tatuya From nobody Mon Aug 11 11:54: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 418BA1A005D for ; Mon, 11 Aug 2014 11:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, 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 NtSNkUmk-JCX for ; Mon, 11 Aug 2014 11:54: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 62C1A1A0025 for ; Mon, 11 Aug 2014 11:54:14 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XGujS-0007Yj-FX; Mon, 11 Aug 2014 20:54:10 +0200 Message-ID: <53E90FBA.8030701@si6networks.com> Date: Mon, 11 Aug 2014 14:47:22 -0400 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?56We5piO6YGU5ZOJ?= References: <53E5382E.3010302@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/S_BhT_SYr7iESgSaECzwfFkVvFI Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, "v6ops@ietf.org" 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: Mon, 11 Aug 2014 18:54:16 -0000 On 08/11/2014 01:04 PM, 神ćŽé”哉 wrote: > At Fri, 08 Aug 2014 16:50:54 -0400, > Fernando Gont wrote: > >>> Section 4 >>> Packets dropped by the destination AS are less of a >>> concern, since they can be assumed to be the result of an explicit >>> policy of the organization to which the packets are destined (who can >>> make its own decision regarding what kind of traffic is >>> "acceptable"). >>> I agree with the sense of this sentence, but I think the "since" >>> clause is a bit too strong. For cases like ordinary household users >>> connected to ISPs, the situation shouldn't be so different from the >>> case where the packet is dropped in a transit AS in practice. >> >> Agreed. Although in this case we were testing servers, as opposed to >> clients. > > I thought these sentences (more specifically, "Packets dropped by > the intended destination...are dropped by a transit AS.") talk about > a general observation, rather than something very specific to the > measurement. Besides, I believe my comment also applies to "servers" > in that the admin of the destination AS may not always be the admin of > the destination server. Agreed. We will not this in the next rev of the document. >>> Section 4: the numbers in tables 1 and 2 are confusing to me. For >>> example, in the following cell of table 1: >>> >>> +--------------+-----------------+ >>> | Dataset | DO8 | >>> +--------------+-----------------+ >>> | Web | 11.88% | >>> | | (17.60%-20.80%) | >>> +--------------+-----------------+ >>> >>> What exactly do these numbers represent? >> >> 11.88% is the packet drop rate when using IPv6 D08. i.e., for 11.88% of >> destinations, communications fail if you employ DO8. > > This one is pretty clear to me, and I interpreted it that way. The > confusing part is the numbers in the parentheses. > >> What's withing parenthesis is the rate of packet drops occurring in >> different ASes. That is, when packet drops do occur, between 17.60% and >> 20% of such drops occur in a different AS (the reason for the "range" is >> explained in the appendix). > > So, for example, if you sent out 10,000 packets with IPv6 DO8: > > - 1188 packets were dropped > - Out of these 1188 dropped packets, 209 to 237 packets seem to have > been dropped in an different AS > > ? Yes. > It would be very difficult to reach this understanding just from > the text and the table, at least to me:-) > >> You're not the first to be confused by this table, though :-(. Any ideas >> on how to make this more clear? Maybe add a paragraph explaining one of >> the cells? (inclufing "mean and varince" wouldn't be much of an >> improvement in terms of clarity, I think) > > One easy improvement that would have worked for me is to add more > description to the tables, e.g. "Table 1: WIPv6LD dataset: Packet drop > rate for different destination types (upper) and estimated percentage > of dropped packets that were deemed to be dropped in a different AS > (lower, in parentheses)". Ok. Do you think it might help clarify things if we "split" each table into two tables: one with the drop rate, and another with the "rate of packet drops by different AS"? > 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. Thanks so much! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 12 02:55: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 900801A0395; Tue, 12 Aug 2014 02:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Sae6n3tOOUA1; Tue, 12 Aug 2014 02:55: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 1BBF71A081B; Tue, 12 Aug 2014 02:55:34 -0700 (PDT) Received: from [2001:5c0:1400:a::63f] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XH8ni-0003bI-6c; Tue, 12 Aug 2014 11:55:32 +0200 Message-ID: <53E9E42F.50102@si6networks.com> Date: Tue, 12 Aug 2014 05:53:51 -0400 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: Mikael Abrahamsson , draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/x0Zju-E5GLEHP3xQrTY7qBBl0Ww Cc: opsec@ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 09:55:43 -0000 Hi, Mikael, Thanks so much for your feedback! Comments in-line... On 07/14/2014 02:55 AM, Mikael Abrahamsson wrote: > > I find this document advocates dropping things way too much. Actually, of the top of my head, the only EH that we were advocated dropping (from the standard set) is/was HBH (this is to be changed in the upcoming rev of the document). > It uses the > term "intermediate" devices. I would like this split up into two types > of devices, a "pure packet forwarding device" (=core router), and a > "security inspection device" (=device that might have ACLs or being a > stateful firewall). Me, I'd probably stick to intermmediate device, or maybe "forwarding node" or "router". If you bring "firewalls" into the game, reality is that a firewall will typically be "default deny". > I believe a core router which just forwards packets, should not drop > packets because of options it can't handle very well. If it can't handle > a lot of hop-by-hop header packets, then don't inspect these hop-by-hop > header packets, just forward the packets without looking at them. We're trying to provide advice to the same sort of devices that are dropping packets in draft-gont-v6ops-ipv6-ehs-in-real-world.... > The thought of our core networks limiting what we can and can't do in > the future with IPv6, makes me a sad panda. I can understand devices > that enforce some kind of security to drop packets they don't > understand, but generally recommending blanket dropping of some packets > in the core because of potential edge problems, that just doesn't make > sense to me. That's not what we're doing (modulo HBH, as noted above). Please let us know if there are specific portions of the document that you're objecting to or that you'd like to be clarified. 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 Tue Aug 12 03:32: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 AEDC41A0832; Tue, 12 Aug 2014 03:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 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.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 vdeGp8ExASQK; Tue, 12 Aug 2014 03:32:12 -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 EC9301A03A5; Tue, 12 Aug 2014 03:32:11 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 372E9A1; Tue, 12 Aug 2014 12:32:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1407839530; bh=iQHWV8O0aXxJwgTZL/5lf7X0PHbFmfinGsy1w5xpaS4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=x8A6Jd8dY6yzUCEMmZ5BJUKCFVQ/2/AN4imVa+n32YmJnaK8OFkIszK8SYUwlQOwb gnvkwsUAKcxG7q0Y9fTQHtTzinYg9tRH569k+Kiu8z4mQa/NWIiwpnAKSWYySH4BCa 2g0qzs6jbCAGuBQoV9JDlPhfHjLmCtSBie331B38= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2C2B79F; Tue, 12 Aug 2014 12:32:10 +0200 (CEST) Date: Tue, 12 Aug 2014 12:32:10 +0200 (CEST) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <53E9E42F.50102@si6networks.com> Message-ID: References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53E9E42F.50102@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mp0QgF_TbUl1Mq1oa-IQGEYNL-g Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 10:32:14 -0000 On Tue, 12 Aug 2014, Fernando Gont wrote: > Hi, Mikael, > > Thanks so much for your feedback! Comments in-line... > > On 07/14/2014 02:55 AM, Mikael Abrahamsson wrote: >> >> I find this document advocates dropping things way too much. > > Actually, of the top of my head, the only EH that we were advocated > dropping (from the standard set) is/was HBH (this is to be changed in > the upcoming rev of the document). Ok, good! Another thing I don't know if I mentioned, is that there is a mix of different ways of saying the same thing in the advice section, sometimes it's "pass", sometimes it's "do not drop". Are you fixing that as well? Anyhow, I'll wait until the next rev and give it a complete read-through. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 12 03:42: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 09DA91A03A5; Tue, 12 Aug 2014 03:42:37 -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 i5q2W-4mm9Cg; Tue, 12 Aug 2014 03:42:34 -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 BC70F1A03A6; Tue, 12 Aug 2014 03:42:34 -0700 (PDT) Received: from [2001:5c0:1400:a::63f] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XH9XE-0003iQ-Fl; Tue, 12 Aug 2014 12:42:32 +0200 Message-ID: <53E9EF24.4020100@si6networks.com> Date: Tue, 12 Aug 2014 06:40:36 -0400 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: Mikael Abrahamsson References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53E9E42F.50102@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ftj-tnHECXRyv6WAePp1MbPC-XA Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 10:42:37 -0000 Hi, Mikael, On 08/12/2014 06:32 AM, Mikael Abrahamsson wrote: >>> I find this document advocates dropping things way too much. >> >> Actually, of the top of my head, the only EH that we were advocated >> dropping (from the standard set) is/was HBH (this is to be changed in >> the upcoming rev of the document). > > Ok, good! Another thing I don't know if I mentioned, is that there is a > mix of different ways of saying the same thing in the advice section, > sometimes it's "pass", sometimes it's "do not drop". Are you fixing that > as well? I wasn't... but now I will. > Anyhow, I'll wait until the next rev and give it a complete read-through. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 12 07:41: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 7CECF1A0764 for ; Tue, 12 Aug 2014 07:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 944OiZ2fFRZz for ; Tue, 12 Aug 2014 07:41:41 -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 1CE121A073C for ; Tue, 12 Aug 2014 07:41:40 -0700 (PDT) Received: (qmail 34604 messnum 1758080 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 12 Aug 2014 14:41:39 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail12.svc.cra.dublin.eircom.net (qp 34604) with SMTP; 12 Aug 2014 14:41:39 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id dqhb1o0250mJ9Tz01qhfRs; Tue, 12 Aug 2014 15:41:39 +0100 From: Ross Chandler Content-Type: multipart/alternative; boundary="Apple-Mail=_21DEEBFA-6EE9-422F-AD03-39BADC42B973" Message-Id: <693E53F1-4EA8-4CEF-91AE-D9F8E00DD05A@eircom.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 12 Aug 2014 15:41:10 +0100 References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> To: IPv6 Ops WG In-Reply-To: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IZfplkZroyjXyXL1lsMpCcHTHwY Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 14:41:43 -0000 --Apple-Mail=_21DEEBFA-6EE9-422F-AD03-39BADC42B973 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 Aug 2014, at 14:21, 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. >=20 > Title : An Internet Protocol Version 6 (IPv6) Profile = for 3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-08.txt > Pages : 18 > Date : 2014-08-11 Hi All, I support this useful draft. An item I=92d like to see added to the =93Connectivity Recommendations=94 = list after C_REC#12 is. C_REC#??: Because of the potential for separate parallel IPv4 and=20 IPv6 PDP/PDN connections when the network or subscriber=20 profile does not support IPv4v6 PDP-Contexts, the cellular host must be able to be configured to exclude this type from the available options. For example if the list was just IPv4 or IPv6 (with 464XLAT implied) = then the cellular host=20 would only ever attempt to set-up a single stack connection.=20 I note that with: Android the options are IPv4, IPv6 and IPv4/IPv6. Windows Phone 8.1 the options are IPv4, IPv6, IPv4v6 and = IPv4v6XLAT Best regards, Ross= --Apple-Mail=_21DEEBFA-6EE9-422F-AD03-39BADC42B973 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 11 Aug 2014, at 14:21, 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 =           : An = Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices
=        Authors =         : David Binet
=             &n= bsp;           &nbs= p;Mohamed Boucadair
=             &n= bsp;           &nbs= p;Ales Vizdal
=             &n= bsp;           &nbs= p;Cameron Byrne
=             &n= bsp;           &nbs= p;Gang Chen
= Filename        : = draft-ietf-v6ops-mobile-device-profile-08.txt
Pages =           : = 18
= Date =            : = 2014-08-11


Hi = All,

I support this useful draft.

An item I=92d like to see added to the =93Connectivity = Recommendations=94 list after C_REC#12 is.

   C_REC#??:  Because of the potential for separate = parallel IPv4 and 
    =           IPv6 PDP/PDN connections when the = network or subscriber 
  =             profile does not support = IPv4v6 PDP-Contexts, the cellular
  =     host must be able to be configured to exclude this = type
          =     from the available options.

For = example if the list was just IPv4 or IPv6 (with 464XLAT implied) then = the cellular host 
would only ever = attempt to set-up a single stack connection. 

I note that = with:
Android the options are IPv4, = IPv6 and IPv4/IPv6.
Windows = Phone 8.1 the options are IPv4, IPv6, IPv4v6 and IPv4v6XLAT


Best regards,
Ross
= --Apple-Mail=_21DEEBFA-6EE9-422F-AD03-39BADC42B973-- From nobody Tue Aug 12 07:44: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 3DED41A0764; Tue, 12 Aug 2014 07:44:44 -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 TDnf5or7eGHk; Tue, 12 Aug 2014 07:44:38 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BC71A08F5; Tue, 12 Aug 2014 07:44:38 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s7CEiYIV020114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2014 09:44:34 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 3F6FD1E006B; Tue, 12 Aug 2014 08:44:29 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2251A1E0067; Tue, 12 Aug 2014 08:44:29 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s7CEiSqs028800; Tue, 12 Aug 2014 08:44:28 -0600 (MDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s7CEiSFG028787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 08:44:28 -0600 (MDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 08:44:28 -0600 From: "Smith, Donald" To: Fernando Gont , Mikael Abrahamsson Thread-Topic: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt Thread-Index: AQHPnxxKV3vKyI8r0kmDCuWMZ5DgUZufh4CAgC3FgICAAAq0AIAAAlwA///dN7c= Date: Tue, 12 Aug 2014 14:44:27 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D24BD339A@PDDCWMBXEX503.ctl.intranet> References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53E9E42F.50102@si6networks.com> , <53E9EF24.4020100@si6networks.com> In-Reply-To: <53E9EF24.4020100@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_6p_ElKhiccwdW4YXsZUEA57kIo Cc: "opsec@ietf.org" , "draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org" , IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 14:44:44 -0000 We have language for that in other rfcs. Drop usually means silent drop. So is drop a silent drop or a reject? http://tools.ietf.org/html/rfc3871 "Ability to Specify Filter Actions Requirement. The device MUST provide a mechanism to allow the specification of the action to be taken when a filter rule matches. Actions MUST include "permit" (allow the traffic), "reject" (drop with appropriate notification to sender), and "drop" (drop with no notification to sender). Also see Section 2.7.7 and Section 2.9" Are there cases where reject (with notification) makes more sense then drop= ? Or where the end user should get to choose one over the other? (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: OPSEC [opsec-bounces@ietf.org] on behalf of Fernando Gont [fgont@si6n= etworks.com] Sent: Tuesday, August 12, 2014 4:40 AM To: Mikael Abrahamsson Cc: opsec@ietf.org; draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org; IPv6= Operations Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt Hi, Mikael, On 08/12/2014 06:32 AM, Mikael Abrahamsson wrote: >>> I find this document advocates dropping things way too much. >> >> Actually, of the top of my head, the only EH that we were advocated >> dropping (from the standard set) is/was HBH (this is to be changed in >> the upcoming rev of the document). >=20 > Ok, good! Another thing I don't know if I mentioned, is that there is a > mix of different ways of saying the same thing in the advice section, > sometimes it's "pass", sometimes it's "do not drop". Are you fixing that > as well? I wasn't... but now I will. > Anyhow, I'll wait until the next rev and give it a complete read-through. Thanks so much! Best regards, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec= From nobody Tue Aug 12 11:47: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 349451A06B6 for ; Tue, 12 Aug 2014 11:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 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, J_CHICKENPOX_42=0.6, 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 33puaxXmxobz for ; Tue, 12 Aug 2014 11:46:57 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF14D1A06DA for ; Tue, 12 Aug 2014 11:46:56 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p10so10513933wes.2 for ; Tue, 12 Aug 2014 11:46:55 -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=sQitW0+Kz7dSu8vtNN/L+imldVqZ5srBbmjD47Jbe9w=; b=aOuBZ+WAisDMfgYgqSf5ukGYuV82NRCajiCDAO9RLBYTjQUgORZ2MZqemdIktSdmTZ 07PtFidMSL4EJqHo9XP4B2Hep+nbVRFCWD0rzpewr18LfTroZSWuV8rrsCNll/JLx40u w0dTMrHWycpv88OlckBp6MXWqO9CqsmNTHlZ52A6UYuWR4swVh4jeNqmS5yRVVAVwlOA z8KiSHsfkEkN6dYjs2yuXNi4W7cSOH6tnmXGtM/S6tm3ah8enN1HmBMKo7izW4qPncev JqhoYNOa+mBDsfqsGMgO1TIoCCfsPRDkmJLOIbtLTakW80DFZC1K0a24r1BgcgTTPhyQ 7mFw== MIME-Version: 1.0 X-Received: by 10.180.86.1 with SMTP id l1mr471526wiz.62.1407869215247; Tue, 12 Aug 2014 11:46:55 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Tue, 12 Aug 2014 11:46:55 -0700 (PDT) In-Reply-To: <53E90FBA.8030701@si6networks.com> References: <53E5382E.3010302@si6networks.com> <53E90FBA.8030701@si6networks.com> Date: Tue, 12 Aug 2014 11:46:55 -0700 X-Google-Sender-Auth: wqY22RIyqWifP7NAeNEYpu0UoDI Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/idE4cmFYQx69Bxp6ABYLbtXVisY Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, "v6ops@ietf.org" 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, 12 Aug 2014 18:46:58 -0000 At Mon, 11 Aug 2014 14:47:22 -0400, Fernando Gont wrote: > > One easy improvement that would have worked for me is to add more > > description to the tables, e.g. "Table 1: WIPv6LD dataset: Packet drop > > rate for different destination types (upper) and estimated percentage > > of dropped packets that were deemed to be dropped in a different AS > > (lower, in parentheses)". > > Ok. Do you think it might help clarify things if we "split" each table > into two tables: one with the drop rate, and another with the "rate of > packet drops by different AS"? Maybe. But I think the most important point is to clearly describe the meaning of these range numbers *in some way*. Separating tables seems to be a minor detail to me in that sense. -- JINMEI, Tatuya From nobody Wed Aug 13 03:53: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 0C4721A0823 for ; Wed, 13 Aug 2014 03:53:17 -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 I_auvkXGvPEw for ; Wed, 13 Aug 2014 03:53:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB08E1A081D for ; Wed, 13 Aug 2014 03:53:13 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id A2C96C0570; Wed, 13 Aug 2014 12:53:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7810D15804E; Wed, 13 Aug 2014 12:53:11 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.234]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 12:53:11 +0200 From: To: Ross Chandler Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt Thread-Index: AQHPtjuTP8ex53zggkS1+QR7dAVhwpvOGpog Date: Wed, 13 Aug 2014 10:53:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004DF89@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> <693E53F1-4EA8-4CEF-91AE-D9F8E00DD05A@eircom.net> In-Reply-To: <693E53F1-4EA8-4CEF-91AE-D9F8E00DD05A@eircom.net> 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_787AE7BB302AE849A7480A190F8B933004DF89OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.13.90919 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5vxw8GFRfPc8vLmwvU_xNfxHKYo Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 10:53:17 -0000 --_000_787AE7BB302AE849A7480A190F8B933004DF89OPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ross, Thank you for the support. As for your proposed REC, wouldn't be appropriate to generalize the recomme= ndation? e.g.: C_REC#x: The cellular host must be able to be configured to limit PDP type(s) for a given APN. The default mode is to allow all supported PDP types. Note, C_REC#3 discusses the default behavior for requesting PDP-Context type(s). If needed, the text can call out why this is needed (v4v6 not supported, su= bscriber profile, service-specific constraints (e.g., VoLTE), etc. BTW, C_REC#12 already hints that PDP types can be limited. I'm particularly= referring to this sentence: "Note, distinct PDP type(s) can be configured for home and roaming cases." Cheers, Med De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ross Chandler Envoy=E9 : mardi 12 ao=FBt 2014 16:41 =C0 : IPv6 Ops WG Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.t= xt On 11 Aug 2014, at 14:21, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for = 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-08.txt Pages : 18 Date : 2014-08-11 Hi All, I support this useful draft. An item I'd like to see added to the "Connectivity Recommendations" list af= ter C_REC#12 is. C_REC#??: Because of the potential for separate parallel IPv4 and IPv6 PDP/PDN connections when the network or subscriber profile does not support IPv4v6 PDP-Contexts, the cellular host must be able to be configured to exclude this type from the available options. For example if the list was just IPv4 or IPv6 (with 464XLAT implied) then t= he cellular host would only ever attempt to set-up a single stack connection. I note that with: Android the options are IPv4, IPv6 and IPv4/IPv6. Windows Phone 8.1 the options are IPv4, IPv6, IPv4v6 and IPv4= v6XLAT Best regards, Ross --_000_787AE7BB302AE849A7480A190F8B933004DF89OPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 

Thank you for the support.=

 

As for your proposed REC, wouldn’t be = appropriate to generalize the recommendation? e.g.:

 

   C_REC#x:   The cellular host must b= e able to be configured to limit

         &nbs= p;    PDP type(s) for a given APN.  The default mode is= to allow

         &nbs= p;    all supported PDP types.  Note, C_REC#3 discusses= the

         &nbs= p;    default behavior for requesting PDP-Context type(s).

 

If needed, the text can call out why this is= needed (v4v6 not supported, subscriber profile, service-specific constrain= ts (e.g., VoLTE), etc.

 

BTW, C_REC#12 already hints that PDP types c= an be limited. I’m particularly referring to this sentence:

 

“Note, distinct PDP type(s) can

       &n= bsp;      be configured for home and roaming cases= .”

 

Cheers,

Med

 

De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ross Chandler
Envoy=E9 : mardi 12 ao=FBt 2014 16:41
=C0 : IPv6 Ops WG
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-= profile-08.txt

 

 

On 11 Aug 2014, at 14:21, internet-drafts@ietf.org wrote:

 

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

       Title     &nb= sp;     : An Internet Protocol Version 6 (IPv6) Pr= ofile for 3GPP Mobile Devices
       Authors     &= nbsp;   : David Binet
            &nb= sp;            = Mohamed Boucadair
            &nb= sp;            = Ales Vizdal
            &nb= sp;            = Cameron Byrne
            &nb= sp;            = Gang Chen
       &n= bsp;  Filename        : draf= t-ietf-v6ops-mobile-device-profile-08.txt
       &n= bsp;  Pages         &nb= sp; : 18
       &n= bsp;  Date         &nbs= p;  : 2014-08-11

 

 

Hi All,

 

I support this useful draft.<= /p>

 

An item I’d like to see added to the R= 20;Connectivity Recommendations” list after C_REC#12 is.

 

   C_REC#??:  Because of the pot= ential for separate parallel IPv4 and 

             = ; IPv6 PDP/PDN connections when the network or subscriber <= /span>

             = ; profile does not support IPv4v6 PDP-Contexts, the cellular

  &nbs= p;                 host must be able to be configured = to exclude this type

             = ; from the available options.

 

For example if the list was just IPv4 or IPv6 (= with 464XLAT implied) then the cellular host 

would only ever attempt to set-up a single stac= k connection. 

 

I note that with:

  &nbs= p;           Android the options are IPv4, IPv6 and IPv4/IPv6.

  &nbs= p;           Windows Phone 8.1 the options are IPv4, IPv6, IPv4v6 and= IPv4v6XLAT

 

 

Best regards,

Ross

--_000_787AE7BB302AE849A7480A190F8B933004DF89OPEXCLILM23corpor_-- From nobody Wed Aug 13 04:36: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 315A21A86F7 for ; Wed, 13 Aug 2014 04:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rmb6aA2NSMsL for ; Wed, 13 Aug 2014 04:36:14 -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 BFB641A085C for ; Wed, 13 Aug 2014 04:36:13 -0700 (PDT) Received: (qmail 26606 messnum 6679486 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 13 Aug 2014 11:36:12 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail11.svc.cra.dublin.eircom.net (qp 26606) with SMTP; 13 Aug 2014 11:36:12 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id eBc71o0200mJ9Tz01BcByP; Wed, 13 Aug 2014 12:36:12 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_D1E2C098-E986-4968-AFC5-03D725E4450F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: <787AE7BB302AE849A7480A190F8B933004DF89@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Wed, 13 Aug 2014 12:28:24 +0100 Message-Id: References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> <693E53F1-4EA8-4CEF-91AE-D9F8E00DD05A@eircom.net> <787AE7BB302AE849A7480A190F8B933004DF89@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YMWmGy7ZdBQbX7Aul6FwB6tca2w Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 11:36:17 -0000 --Apple-Mail=_D1E2C098-E986-4968-AFC5-03D725E4450F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Med, I agree it would be more appropriate to have it as a generalised = recommendation, with the text explaining the situation where it might be = considered useful to have it. The reason I worded it like that was modelled on C_REC#12 which has an = opening sentence explaining why it is needed, rather than just stating = the requirement and having the explanation in the text. I suggested that = it be placed after C_REC#12 in recognition that it is a similar type of = recommendation. Generalised this C_REC might also be useful when it comes to sunseting = requests for IPv4 from UEs in 3GPP networks. BR Ross On 13 Aug 2014, at 11:53, = wrote: > Hi Ross, > =20 > Thank you for the support. > =20 > As for your proposed REC, wouldn=92t be appropriate to generalize the = recommendation? e.g.: > =20 > C_REC#x: The cellular host must be able to be configured to limit > PDP type(s) for a given APN. The default mode is to = allow > all supported PDP types. Note, C_REC#3 discusses the > default behavior for requesting PDP-Context type(s). > =20 > If needed, the text can call out why this is needed (v4v6 not = supported, subscriber profile, service-specific constraints (e.g., = VoLTE), etc. > =20 > BTW, C_REC#12 already hints that PDP types can be limited. I=92m = particularly referring to this sentence: > =20 > =93Note, distinct PDP type(s) can > be configured for home and roaming cases.=94 > =20 > Cheers, > Med > =20 > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ross Chandler > Envoy=E9 : mardi 12 ao=FBt 2014 16:41 > =C0 : IPv6 Ops WG > Objet : Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-08.txt > =20 > =20 > On 11 Aug 2014, at 14:21, 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 : An Internet Protocol Version 6 (IPv6) Profile = for 3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : = draft-ietf-v6ops-mobile-device-profile-08.txt > Pages : 18 > Date : 2014-08-11 > =20 > =20 > Hi All, > =20 > I support this useful draft. > =20 > An item I=92d like to see added to the =93Connectivity = Recommendations=94 list after C_REC#12 is. > =20 > C_REC#??: Because of the potential for separate parallel IPv4 and=20= > IPv6 PDP/PDN connections when the network or subscriber=20= > profile does not support IPv4v6 PDP-Contexts, the = cellular > host must be able to be configured to exclude this = type > from the available options. > =20 > For example if the list was just IPv4 or IPv6 (with 464XLAT implied) = then the cellular host=20 > would only ever attempt to set-up a single stack connection.=20 > =20 > I note that with: > Android the options are IPv4, IPv6 and IPv4/IPv6. > Windows Phone 8.1 the options are IPv4, IPv6, IPv4v6 and = IPv4v6XLAT > =20 > =20 > Best regards, > Ross --Apple-Mail=_D1E2C098-E986-4968-AFC5-03D725E4450F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi Med,

I agree it = would be more appropriate to have it as a generalised recommendation, = with the text explaining the situation where it might be considered = useful to have it.

The reason I worded it like = that was modelled on C_REC#12 which has an opening sentence explaining = why it is needed, rather than just stating the requirement and having = the explanation in the text. I suggested that it be placed after = C_REC#12 in recognition that it is a similar type of = recommendation.

Generalised this C_REC might = also be useful when it comes to sunseting requests for IPv4 from UEs in = 3GPP = networks.

BR
Ross

<= div>


Hi Ross,
 
Thank you for the support.
 
As for your proposed REC, = wouldn=92t be appropriate to generalize the recommendation? = e.g.:
 
   = C_REC#x:   The cellular host must be able to be configured to = limit
           &= nbsp;  PDP type(s) for a given APN.  The default mode is to = allow
           &= nbsp;  all supported PDP types.  Note, C_REC#3 discusses = the
           &= nbsp;  default behavior for requesting PDP-Context = type(s).
 
If needed, the text can call = out why this is needed (v4v6 not supported, subscriber profile, = service-specific constraints (e.g., VoLTE), = etc.
 
BTW, C_REC#12 already hints that PDP types can be limited. I=92m = particularly referring to this sentence:
 
=93Note, distinct PDP type(s) = can
           &= nbsp;  be configured for home and roaming = cases.=94
 
Cheers,
Med
 
De : v6ops [mailto:v6ops-bounces@ietf.org]<= span class=3D"Apple-converted-space"> De la part = de Ross = Chandler
Envoy=E9 : mardi 12 ao=FBt 2014 = 16:41
=C0 : IPv6 Ops = WG
Objet : Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-08.txt
 
 
On 11 Aug 2014, at 14:21, 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 =           : An = Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile = Devices
       Authors =         : David = Binet
           = ;            &= nbsp; Mohamed = Boucadair
          &= nbsp;           &nb= sp;  Ales = Vizdal
          &nbs= p;            =   Cameron = Byrne
           = ;            &= nbsp; Gang Chen
        &= nbsp; Filename =        : = draft-ietf-v6ops-mobile-device-profile-08.txt
        &= nbsp; Pages =           : = 18
        &= nbsp; Date =            : = 2014-08-11
 
 
Hi = All,
 
I support this = useful draft.
 
An item I=92d = like to see added to the =93Connectivity Recommendations=94 list after = C_REC#12 is.
 
   = C_REC#??:  Because of the potential for separate parallel IPv4 = and 
              IPv6 PDP/PDN = connections when the network or = subscriber 
              profile does = not support IPv4v6 PDP-Contexts, the = cellular
           =        =   host must be able to be configured to exclude this = type
    =           from the available = options.
 
For example if = the list was just IPv4 or IPv6 (with 464XLAT implied) then the cellular = host 
would only ever attempt to set-up a single stack = connection. 
 
I note that = with:
           =    Android the = options are IPv4, IPv6 and = IPv4/IPv6.
           =    Windows Phone 8.1 = the options are IPv4, IPv6, IPv4v6 and = IPv4v6XLAT
 
 
Best = regards,
Ross
=

= --Apple-Mail=_D1E2C098-E986-4968-AFC5-03D725E4450F-- From nobody Wed Aug 13 05:59: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 7AB111A0055 for ; Wed, 13 Aug 2014 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yMeR3kcos7Vb for ; Wed, 13 Aug 2014 05:59:54 -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 69F831A0045 for ; Wed, 13 Aug 2014 05:59:53 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7498E3243C9; Wed, 13 Aug 2014 14:59:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4F18D238059; Wed, 13 Aug 2014 14:59:49 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.234]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 14:59:49 +0200 From: To: Ross Chandler Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt Thread-Index: AQHPturJ1Fq2arzbkkmtZl9xbOFURZvOfpEg Date: Wed, 13 Aug 2014 12:59:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004E181@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> <693E53F1-4EA8-4CEF-91AE-D9F8E00DD05A@eircom.net> <787AE7BB302AE849A7480A190F8B933004DF89@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004E181OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/c80tsHc8441i0iS_W6hqb8KSLqo Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 12:59:57 -0000 --_000_787AE7BB302AE849A7480A190F8B933004E181OPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I updated my local copy with this NEW text: C_REC#12: The cellular host must be able to be configured to limit PDP type(s) for a given APN. The default mode is to allow all supported PDP types. Note, C_REC#3 discusses the default behavior for requesting PDP-Context type(s). This feature is useful to drive the behavior of the UE to be aligned with: (1) service-specific constraints such as the use of IPv6-only for VoLTE (Voice over LTE), (2) network conditions with regards to the support of specific PDP types (e.g., IPv4v6 PDP-Context is not supported), (3) IPv4 sunset objectives, (4) subscription data, etc. Please let me know if this is OK or more text is needed. Thank you. Cheers, Med De : Ross Chandler [mailto:ross@eircom.net] Envoy=E9 : mercredi 13 ao=FBt 2014 13:28 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : IPv6 Ops WG Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.t= xt Hi Med, I agree it would be more appropriate to have it as a generalised recommenda= tion, with the text explaining the situation where it might be considered u= seful to have it. The reason I worded it like that was modelled on C_REC#12 which has an open= ing sentence explaining why it is needed, rather than just stating the requ= irement and having the explanation in the text. I suggested that it be plac= ed after C_REC#12 in recognition that it is a similar type of recommendatio= n. Generalised this C_REC might also be useful when it comes to sunseting requ= ests for IPv4 from UEs in 3GPP networks. BR Ross On 13 Aug 2014, at 11:53, > > wrote: Hi Ross, Thank you for the support. As for your proposed REC, wouldn't be appropriate to generalize the recomme= ndation? e.g.: C_REC#x: The cellular host must be able to be configured to limit PDP type(s) for a given APN. The default mode is to allow all supported PDP types. Note, C_REC#3 discusses the default behavior for requesting PDP-Context type(s). If needed, the text can call out why this is needed (v4v6 not supported, su= bscriber profile, service-specific constraints (e.g., VoLTE), etc. BTW, C_REC#12 already hints that PDP types can be limited. I'm particularly= referring to this sentence: "Note, distinct PDP type(s) can be configured for home and roaming cases." Cheers, Med De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ross Chandler Envoy=E9 : mardi 12 ao=FBt 2014 16:41 =C0 : IPv6 Ops WG Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.t= xt On 11 Aug 2014, at 14:21, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for = 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-08.txt Pages : 18 Date : 2014-08-11 Hi All, I support this useful draft. An item I'd like to see added to the "Connectivity Recommendations" list af= ter C_REC#12 is. C_REC#??: Because of the potential for separate parallel IPv4 and IPv6 PDP/PDN connections when the network or subscriber profile does not support IPv4v6 PDP-Contexts, the cellular host must be able to be configured to exclude this type from the available options. For example if the list was just IPv4 or IPv6 (with 464XLAT implied) then t= he cellular host would only ever attempt to set-up a single stack connection. I note that with: Android the options are IPv4, IPv6 and IPv4/IPv6. Windows Phone 8.1 the options are IPv4, IPv6, IPv4v6 and IPv4= v6XLAT Best regards, Ross --_000_787AE7BB302AE849A7480A190F8B933004E181OPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I updated my local copy with this NEW text:<= o:p>

 

   C_REC#12:  The cellular host must be abl= e to be configured to limit

         &nbs= p;    PDP type(s) for a given APN.  The default mode is= to allow

         &nbs= p;    all supported PDP types.  Note, C_REC#3 discusses= the

         &nbs= p;    default behavior for requesting PDP-Context type(s).

 

         &nbs= p;       This feature is useful to drive the = behavior of the UE

         &nbs= p;       to be aligned with: (1) service-spec= ific constraints

         &nbs= p;       such as the use of IPv6-only for VoL= TE (Voice over

         &nbs= p;       LTE), (2) network conditions with re= gards to the

         &nbs= p;       support of specific PDP types (e.g.,= IPv4v6 PDP-Context

         &nbs= p;       is not supported), (3) IPv4 sunset o= bjectives, (4)

         &nbs= p;       subscription data, etc.

 

Please let me know if this is OK or more tex= t is needed.

 

Thank you.

 

Cheers,

Med

 

De : Ross Chandler [mailto:ross@eircom.net]
Envoy=E9 : mercredi 13 ao=FBt 2014 13:28
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc : IPv6 Ops WG
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-= profile-08.txt

 

 

Hi Med,

 

I agree it would be more appropriate to have it as a= generalised recommendation, with the text explaining the situation where i= t might be considered useful to have it.

 

The reason I worded it like that was modelled on C_R= EC#12 which has an opening sentence explaining why it is needed, rather tha= n just stating the requirement and having the explanation in the text. I su= ggested that it be placed after C_REC#12 in recognition that it is a similar type of recommendation.

 

Generalised this C_REC might also be useful when it = comes to sunseting requests for IPv4 from UEs in 3GPP networks.<= /p>

 

BR

Ross

 

 

 

On 13 Aug 2014, at 11:53, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com&g= t; wrote:



Hi Ross,

 

Thank you for the support.=

 

As for your proposed REC, wouldn’t be = appropriate to generalize the recommendation? e.g.:

 

   C_REC#x:   The cellular host must b= e able to be configured to limit

         &nbs= p;    PDP type(s) for a given APN.  The default mode is= to allow

         &nbs= p;    all supported PDP types.  Note, C_REC#3 discusses= the

         &nbs= p;    default behavior for requesting PDP-Context type(s).

 

If needed, the text can call out why this is= needed (v4v6 not supported, subscriber profile, service-specific constrain= ts (e.g., VoLTE), etc.

 

BTW, C_REC#12 already hints that PDP types c= an be limited. I’m particularly referring to this sentence:

 

“Note, distinct PDP type(s) can=

       &n= bsp;      be configured for home and roaming cases= .”

 

Cheers,

Med

 

 

 

 

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

       Title     &nb= sp;     : An Internet Protocol Version 6 (IPv6) Pr= ofile for 3GPP Mobile Devices
       Authors     &= nbsp;   : David Binet
            &nb= sp;            = Mohamed Boucadair
            &nb= sp;            = Ales Vizdal
            &nb= sp;            = Cameron Byrne
            &nb= sp;            = Gang Chen
       &n= bsp;  Filenam= e        : draft-ietf-v6ops-mobile-devic= e-profile-08.txt
       &n= bsp;  Pages &= nbsp;         : 18
       &n= bsp;  Date &n= bsp;          : 2014-08-1= 1

 

 

Hi All,

 

I support this useful draft.<= /p>

 

An item I’d like to see added to the R= 20;Connectivity Recommendations” list after C_REC#12 is.<= /o:p>

 

   C_REC#??:  Because of the pot= ential for separate parallel IPv4 and 

             = ; IPv6 PDP/PDN connections when the network or subscriber =

             = ; profile does not support IPv4v6 PDP-Contexts, the cellular

  &nbs= p;                 host must be able to be configured to exclude this type

             = ; from the available options.

 

For example if the list was just IPv4 or IPv6 (= with 464XLAT implied) then the cellular host 

would only ever attempt to set-up a single stac= k connection. 

 

I note that with:

  &nbs= p;           Androi= d the options are IPv4, IPv6 and IPv4/IPv6.

  &nbs= p;           Window= s Phone 8.1 the options are IPv4, IPv6, IPv4v6 and IPv4v6XLAT

 

 

Best regards,

Ross

 

--_000_787AE7BB302AE849A7480A190F8B933004E181OPEXCLILM23corpor_-- From nobody Wed Aug 13 06:15: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 150961A00A9 for ; Wed, 13 Aug 2014 06:15:10 -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 mvr5Qz1znJGT for ; Wed, 13 Aug 2014 06:15:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BB71A005D for ; Wed, 13 Aug 2014 06:15:02 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 434C918C30F; Wed, 13 Aug 2014 15:15:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2620C35C045; Wed, 13 Aug 2014 15:15:00 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.234]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 15:15:00 +0200 From: To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt Thread-Index: AQHPtWcocWhd/tnNhkGgh8KAbejgspvOhO3g Date: Wed, 13 Aug 2014 13:14:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004E1CD@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> In-Reply-To: <20140811132108.5976.52069.idtracker@ietfa.amsl.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: 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.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6lBd4Li12ZuA_xUWGFG8MNQod4s Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 13:15:10 -0000 Dear all, Joel has kindly provided suggestions to address some concerns raised during= the IETF LC. Those suggestions have been implemented in this new version. We hope to see the document advance in the publication process.=20 Cheers, Med >-----Message d'origine----- >De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de internet- >drafts@ietf.org >Envoy=E9=A0: lundi 11 ao=FBt 2014 15:21 >=C0=A0: i-d-announce@ietf.org >Cc=A0: v6ops@ietf.org >Objet=A0: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.tx= t > > >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 fo= r >3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-08.txt > Pages : 18 > Date : 2014-08-11 > >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-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-= 08 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Aug 13 06:48: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 763041A024E for ; Wed, 13 Aug 2014 06:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4W3gtf4kT0mm for ; Wed, 13 Aug 2014 06:48:30 -0700 (PDT) Received: from mail14.svc.cra.dublin.eircom.net (mail14.svc.cra.dublin.eircom.net [159.134.118.30]) by ietfa.amsl.com (Postfix) with SMTP id 1B81B1A01F4 for ; Wed, 13 Aug 2014 06:48:28 -0700 (PDT) Received: (qmail 85444 messnum 2175925 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 13 Aug 2014 13:48:26 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail14.svc.cra.dublin.eircom.net (qp 85444) with SMTP; 13 Aug 2014 13:48:26 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id eDoN1o00v0mJ9Tz01DoSGN; Wed, 13 Aug 2014 14:48:26 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_209CD5D8-9A0A-40EC-97DA-CA5AD01CEA20" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: <787AE7BB302AE849A7480A190F8B933004E181@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Wed, 13 Aug 2014 14:48:22 +0100 Message-Id: References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> <693E53F1-4EA8-4CEF-91AE-D9F8E00DD05A@eircom.net> <787AE7BB302AE849A7480A190F8B933004DF89@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004E181@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BN-fnBBTA9tvh-oWe4TivW8guL8 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 13:48:44 -0000 --Apple-Mail=_209CD5D8-9A0A-40EC-97DA-CA5AD01CEA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 13 Aug 2014, at 13:59, = wrote: > Re-, > =20 > I updated my local copy with this NEW text: > =20 > C_REC#12: The cellular host must be able to be configured to limit > PDP type(s) for a given APN. The default mode is to = allow > all supported PDP types. Note, C_REC#3 discusses the > default behavior for requesting PDP-Context type(s). > =20 > This feature is useful to drive the behavior of the = UE > to be aligned with: (1) service-specific constraints > such as the use of IPv6-only for VoLTE (Voice over > LTE), (2) network conditions with regards to the > support of specific PDP types (e.g., IPv4v6 = PDP-Context > is not supported), (3) IPv4 sunset objectives, (4) > subscription data, etc. > =20 > Please let me know if this is OK or more text is needed. Hi Med, That looks good.=20 I understand the existing C_REC#12 remains in the document and the two = are listed together. BR=20 Ross > De : Ross Chandler [mailto:ross@eircom.net]=20 > Envoy=E9 : mercredi 13 ao=FBt 2014 13:28 > =C0 : BOUCADAIR Mohamed IMT/OLN > Cc : IPv6 Ops WG > Objet : Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-08.txt > =20 > =20 > Hi Med, > =20 > I agree it would be more appropriate to have it as a generalised = recommendation, with the text explaining the situation where it might be = considered useful to have it. > =20 > The reason I worded it like that was modelled on C_REC#12 which has an = opening sentence explaining why it is needed, rather than just stating = the requirement and having the explanation in the text. I suggested that = it be placed after C_REC#12 in recognition that it is a similar type of = recommendation. > =20 > Generalised this C_REC might also be useful when it comes to sunseting = requests for IPv4 from UEs in 3GPP networks. > =20 > BR > Ross > =20 > =20 > =20 > On 13 Aug 2014, at 11:53, = wrote: >=20 >=20 > Hi Ross, > =20 > Thank you for the support. > =20 > As for your proposed REC, wouldn=92t be appropriate to generalize the = recommendation? e.g.: > =20 > C_REC#x: The cellular host must be able to be configured to limit > PDP type(s) for a given APN. The default mode is to = allow > all supported PDP types. Note, C_REC#3 discusses the > default behavior for requesting PDP-Context type(s). > =20 > If needed, the text can call out why this is needed (v4v6 not = supported, subscriber profile, service-specific constraints (e.g., = VoLTE), etc. > =20 > BTW, C_REC#12 already hints that PDP types can be limited. I=92m = particularly referring to this sentence: > =20 > =93Note, distinct PDP type(s) can > be configured for home and roaming cases.=94 > =20 > Cheers, > Med > =20 > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ross Chandler > Envoy=E9 : mardi 12 ao=FBt 2014 16:41 > =C0 : IPv6 Ops WG > Objet : Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-08.txt > =20 > =20 > On 11 Aug 2014, at 14:21, 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 : An Internet Protocol Version 6 (IPv6) Profile = for 3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : = draft-ietf-v6ops-mobile-device-profile-08.txt > Pages : 18 > Date : 2014-08-11 > =20 > =20 > Hi All, > =20 > I support this useful draft. > =20 > An item I=92d like to see added to the =93Connectivity = Recommendations=94 list after C_REC#12 is. > =20 > C_REC#??: Because of the potential for separate parallel IPv4 and=20= > IPv6 PDP/PDN connections when the network or subscriber=20= > profile does not support IPv4v6 PDP-Contexts, the = cellular > host must be able to be configured to exclude this = type > from the available options. > =20 > For example if the list was just IPv4 or IPv6 (with 464XLAT implied) = then the cellular host=20 > would only ever attempt to set-up a single stack connection.=20 > =20 > I note that with: > Android the options are IPv4, IPv6 and IPv4/IPv6. > Windows Phone 8.1 the options are IPv4, IPv6, IPv4v6 and = IPv4v6XLAT > =20 > =20 > Best regards, > Ross --Apple-Mail=_209CD5D8-9A0A-40EC-97DA-CA5AD01CEA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Re-,
 
I updated my local copy with this NEW = text:
 
   = C_REC#12:  The cellular host must be able to be configured to = limit
           &= nbsp;  PDP type(s) for a given APN.  The default mode is to = allow
           &= nbsp;  all supported PDP types.  Note, C_REC#3 discusses = the
           &= nbsp;  default behavior for requesting PDP-Context = type(s).
 
           &= nbsp;     This feature is useful to drive the = behavior of the UE
           &= nbsp;     to be aligned with: (1) service-specific = constraints
           &= nbsp;     such as the use of IPv6-only for VoLTE = (Voice over
           &= nbsp;     LTE), (2) network conditions with regards = to the
           &= nbsp;     support of specific PDP types (e.g., = IPv4v6 PDP-Context
           &= nbsp;     is not supported), (3) IPv4 sunset = objectives, (4)
           &= nbsp;     subscription data, = etc.
 
Please let me know if this is OK or more text is = needed.

Hi = Med,

That looks = good. 

I understand the existing C_REC#12 = remains in the document and the two are listed = together.

BR 
Ross

<= /div>





De : Ross Chandler [mailto:ross@eircom.net] 
Envoy=E9 : mercredi 13 ao=FBt 2014 = 13:28
=C0 : BOUCADAIR Mohamed = IMT/OLN
Cc : IPv6 Ops = WG
Objet : Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-08.txt
 
 
Hi Med,
 
I = agree it would be more appropriate to have it as a generalised = recommendation, with the text explaining the situation where it might be = considered useful to have it.
 
The reason I worded it like that was modelled on = C_REC#12 which has an opening sentence explaining why it is needed, = rather than just stating the requirement and having the explanation in = the text. I suggested that it be placed after C_REC#12 in recognition = that it is a similar type of = recommendation.
 
Generalised this C_REC might also be useful when it comes to = sunseting requests for IPv4 from UEs in 3GPP = networks.
 
BR
Ross
 
 
 
On 13 = Aug 2014, at 11:53, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> = wrote:


Hi Ross,
 
Thank you for the = support.
 
As for your proposed REC, wouldn=92t be = appropriate to generalize the recommendation? = e.g.:
 
   C_REC#x:   The cellular host must be able = to be configured to limit
           &= nbsp;  PDP type(s) for a given APN.  The default mode is to = allow
           &= nbsp;  all supported PDP types.  Note, C_REC#3 discusses = the
           &= nbsp;  default behavior for requesting PDP-Context = type(s).
 
If needed, the text can call out why this is = needed (v4v6 not supported, subscriber profile, service-specific = constraints (e.g., VoLTE), etc.
 
BTW, C_REC#12 already hints that PDP types can = be limited. I=92m particularly referring to this = sentence:
 
=93Note, distinct PDP type(s) = can
           &= nbsp;  be configured for home and roaming = cases.=94
 
Cheers,
Med
 
De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ross = Chandler
Envoy=E9 : mardi 12 ao=FBt 2014 = 16:41
=C0 : IPv6 Ops = WG
Objet : Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-08.txt
 
 
On 11 Aug 2014, at 14:21, 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 =           : An = Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile = Devices
       Authors =         : David = Binet
           = ;            &= nbsp; Mohamed = Boucadair
          &= nbsp;           &nb= sp;  Ales = Vizdal
          &nbs= p;            =   Cameron = Byrne
           = ;            &= nbsp; Gang Chen
        &= nbsp; Filename =        : = draft-ietf-v6ops-mobile-device-profile-08.txt
        &= nbsp; Pages =           : = 18
        &= nbsp; Date =            : = 2014-08-11
 
 
Hi = All,
 
I = support this useful draft.
 
An = item I=92d like to see added to the =93Connectivity Recommendations=94 = list after C_REC#12 is.
 
   C_REC#??:  Because of the potential for = separate parallel IPv4 and 
              IPv6 PDP/PDN = connections when the network or = subscriber 
              profile does = not support IPv4v6 PDP-Contexts, the = cellular
           =          host must be able to be = configured to exclude this type
              from the = available options.
 
For = example if the list was just IPv4 or IPv6 (with 464XLAT implied) then = the cellular host 
would only ever attempt to set-up a single stack = connection. 
 
I = note that with:
           =    Android the options are IPv4, IPv6 and = IPv4/IPv6.
           =    Windows Phone 8.1 the options are IPv4, = IPv6, IPv4v6 and IPv4v6XLAT
 
 
Best regards,
Ross
<= /div>

= --Apple-Mail=_209CD5D8-9A0A-40EC-97DA-CA5AD01CEA20-- From nobody Wed Aug 13 06:54: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 42A711A0233 for ; Wed, 13 Aug 2014 06:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0iTTgVK8H-dX for ; Wed, 13 Aug 2014 06:54:09 -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 27EA81A020A for ; Wed, 13 Aug 2014 06:54:08 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C1C9218C29E; Wed, 13 Aug 2014 15:54:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A4B464C063; Wed, 13 Aug 2014 15:54:06 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.234]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 15:54:06 +0200 From: To: Ross Chandler Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt Thread-Index: AQHPtv0/1pwg5Sj5bEmEzCqzL8dxXpvOjdRQ Date: Wed, 13 Aug 2014 13:54:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004E25D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> <693E53F1-4EA8-4CEF-91AE-D9F8E00DD05A@eircom.net> <787AE7BB302AE849A7480A190F8B933004DF89@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004E181@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004E25DOPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-B61ZhZa3CQ8Rs9T493O2OKldqg Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 13:54:11 -0000 --_000_787AE7BB302AE849A7480A190F8B933004E25DOPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Yes, I confirm. A new version with this new item will be available online soon. Thank you. Cheers, Med De : Ross Chandler [mailto:ross@eircom.net] Envoy=E9 : mercredi 13 ao=FBt 2014 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : IPv6 Ops WG Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.t= xt On 13 Aug 2014, at 13:59, > > wrote: Re-, I updated my local copy with this NEW text: C_REC#12: The cellular host must be able to be configured to limit PDP type(s) for a given APN. The default mode is to allow all supported PDP types. Note, C_REC#3 discusses the default behavior for requesting PDP-Context type(s). This feature is useful to drive the behavior of the UE to be aligned with: (1) service-specific constraints such as the use of IPv6-only for VoLTE (Voice over LTE), (2) network conditions with regards to the support of specific PDP types (e.g., IPv4v6 PDP-Context is not supported), (3) IPv4 sunset objectives, (4) subscription data, etc. Please let me know if this is OK or more text is needed. Hi Med, That looks good. I understand the existing C_REC#12 remains in the document and the two are = listed together. BR Ross De : Ross Chandler [mailto:ross@eircom.net] Envoy=E9 : mercredi 13 ao=FBt 2014 13:28 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : IPv6 Ops WG Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.t= xt Hi Med, I agree it would be more appropriate to have it as a generalised recommenda= tion, with the text explaining the situation where it might be considered u= seful to have it. The reason I worded it like that was modelled on C_REC#12 which has an open= ing sentence explaining why it is needed, rather than just stating the requ= irement and having the explanation in the text. I suggested that it be plac= ed after C_REC#12 in recognition that it is a similar type of recommendatio= n. Generalised this C_REC might also be useful when it comes to sunseting requ= ests for IPv4 from UEs in 3GPP networks. BR Ross On 13 Aug 2014, at 11:53, > > wrote: Hi Ross, Thank you for the support. As for your proposed REC, wouldn't be appropriate to generalize the recomme= ndation? e.g.: C_REC#x: The cellular host must be able to be configured to limit PDP type(s) for a given APN. The default mode is to allow all supported PDP types. Note, C_REC#3 discusses the default behavior for requesting PDP-Context type(s). If needed, the text can call out why this is needed (v4v6 not supported, su= bscriber profile, service-specific constraints (e.g., VoLTE), etc. BTW, C_REC#12 already hints that PDP types can be limited. I'm particularly= referring to this sentence: "Note, distinct PDP type(s) can be configured for home and roaming cases." Cheers, Med De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ross Chandler Envoy=E9 : mardi 12 ao=FBt 2014 16:41 =C0 : IPv6 Ops WG Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.t= xt On 11 Aug 2014, at 14:21, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for = 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-08.txt Pages : 18 Date : 2014-08-11 Hi All, I support this useful draft. An item I'd like to see added to the "Connectivity Recommendations" list af= ter C_REC#12 is. C_REC#??: Because of the potential for separate parallel IPv4 and IPv6 PDP/PDN connections when the network or subscriber profile does not support IPv4v6 PDP-Contexts, the cellular host must be able to be configured to exclude this type from the available options. For example if the list was just IPv4 or IPv6 (with 464XLAT implied) then t= he cellular host would only ever attempt to set-up a single stack connection. I note that with: Android the options are IPv4, IPv6 and IPv4/IPv6. Windows Phone 8.1 the options are IPv4, IPv6, IPv4v6 and IPv4= v6XLAT Best regards, Ross --_000_787AE7BB302AE849A7480A190F8B933004E25DOPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Yes, I confirm.

 

A new version with this new item will be ava= ilable online soon.

 

Thank you.

 

Cheers,

Med

 

De : Ross Chandler [mailto:ross@eircom.net]
Envoy=E9 : mercredi 13 ao=FBt 2014 15:48
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc : IPv6 Ops WG
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-= profile-08.txt

 

 

On 13 Aug 2014, at 13:59, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com&g= t; wrote:



Re-,

 

I updated my local copy with this NEW text:<= /span>

 

   C_REC#12:  The cellular host must be abl= e to be configured to limit

         &nbs= p;    PDP type(s) for a given APN.  The default mode is= to allow

         &nbs= p;    all supported PDP types.  Note, C_REC#3 discusses= the

         &nbs= p;    default behavior for requesting PDP-Context type(s).

 

         &nbs= p;       This feature is useful to drive the = behavior of the UE

         &nbs= p;       to be aligned with: (1) service-spec= ific constraints

         &nbs= p;       such as the use of IPv6-only for VoL= TE (Voice over

         &nbs= p;       LTE), (2) network conditions with re= gards to the

         &nbs= p;       support of specific PDP types (e.g.,= IPv4v6 PDP-Context

         &nbs= p;       is not supported), (3) IPv4 sunset o= bjectives, (4)

         &nbs= p;       subscription data, etc.<= /o:p>

 

Please let me know if this is OK or more tex= t is needed.

 

Hi Med,

 

That looks good. 

 

I understand the existing C_REC#12 remains in the do= cument and the two are listed together.

 

BR 

Ross

 

 

 

 

 



De : Ross Chandler [= mailto:ross@eircom.net]&nb= sp;
Envoy=E9 : me= rcredi 13 ao=FBt 2014 13:28
=C0 : BOUCADA= IR Mohamed IMT/OLN
Cc : IPv6 Ops= WG
Objet : Re: [= v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt

 

 

Hi Med,

 

I agree it would be more appropriate to have it as a= generalised recommendation, with the text explaining the situation where i= t might be considered useful to have it.

 

The reason I worded it like that was modelled on C_R= EC#12 which has an opening sentence explaining why it is needed, rather tha= n just stating the requirement and having the explanation in the text. I su= ggested that it be placed after C_REC#12 in recognition that it is a similar type of recommendation.

 

Generalised this C_REC might also be useful when it = comes to sunseting requests for IPv4 from UEs in 3GPP networks.<= /p>

 

BR

Ross

 

 

 

On 13 Aug 2014, at 11:53, <mohamed.boucadair@or= ange.com> <mohamed.boucadair@orange.com> wrote:




Hi Ross,

 

Thank you for the support.=

 

As for your proposed REC, wouldn’t be = appropriate to generalize the recommendation? e.g.:

 

   C_REC#x:   The cellular host must b= e able to be configured to limit

         &nbs= p;    PDP type(s) for a given APN.  The default mode is= to allow

         &nbs= p;    all supported PDP types.  Note, C_REC#3 discusses= the

         &nbs= p;    default behavior for requesting PDP-Context type(s).

 

If needed, the text can call out why this is= needed (v4v6 not supported, subscriber profile, service-specific constrain= ts (e.g., VoLTE), etc.

 

BTW, C_REC#12 already hints that PDP types c= an be limited. I’m particularly referring to this sentence:

 

“Note, distinct PDP type(s) can=

       &n= bsp;      be configured for home and roaming cases= .”

 

Cheers,

Med

 

De : v6ops [ma= ilto:v6ops-bounces@ietf.org] De la part de&n= bsp;Ross Chandler
Envoy=E9 : ma= rdi 12 ao=FBt 2014 16:41
=C0 : IPv6 Op= s WG
Objet : Re: [= v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt

 

 

On 11 Aug 2014, at 14:21, internet-drafts@ietf.org wrote:

 

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

       Title     &nb= sp;     : An Internet Protocol Version 6 (IPv6) Pr= ofile for 3GPP Mobile Devices
       Authors     &= nbsp;   : David Binet
            &nb= sp;            = Mohamed Boucadair
            &nb= sp;            = Ales Vizdal
            &nb= sp;            = Cameron Byrne
            &nb= sp;            = Gang Chen
       &n= bsp;  Filenam= e        : draft-ietf-v6ops-mobile-devic= e-profile-08.txt
       &n= bsp;  Pages &= nbsp;         : 18
       &n= bsp;  Date &n= bsp;          : 2014-08-1= 1

 

 

Hi All,

 

I support this useful draft.<= /p>

 

An item I’d like to see added to the R= 20;Connectivity Recommendations” list after C_REC#12 is.<= /o:p>

 

   C_REC#??:  Because of the pot= ential for separate parallel IPv4 and 

             = ; IPv6 PDP/PDN connections when the network or subscriber =

             = ; profile does not support IPv4v6 PDP-Contexts, the cellular

  &nbs= p;                 host must be able to be configured to exclude this type

             = ; from the available options.

 

For example if the list was just IPv4 or IPv6 (= with 464XLAT implied) then the cellular host 

would only ever attempt to set-up a single stac= k connection. 

 

I note that with:

  &nbs= p;           Androi= d the options are IPv4, IPv6 and IPv4/IPv6.

  &nbs= p;           Window= s Phone 8.1 the options are IPv4, IPv6, IPv4v6 and IPv4v6XLAT

 

 

Best regards,

Ross

 

--_000_787AE7BB302AE849A7480A190F8B933004E25DOPEXCLILM23corpor_-- From nobody Wed Aug 13 07:04:48 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 988B91A02F8; Wed, 13 Aug 2014 07:04:46 -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 bdk0g_d4eFMe; Wed, 13 Aug 2014 07:04:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 625491A0334; Wed, 13 Aug 2014 07:04:38 -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: <20140813140438.24520.15804.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 07:04:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z4lD05Udddfm8tiIAVGGfVOiPys Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-09.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, 13 Aug 2014 14:04:46 -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 Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-09.txt Pages : 18 Date : 2014-08-13 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-09 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 Aug 13 20:30: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 8A1311A0761 for ; Wed, 13 Aug 2014 20:30:33 -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 Cu3pm8Zgh4qt for ; Wed, 13 Aug 2014 20:30:27 -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 7FEAF1A0759 for ; Wed, 13 Aug 2014 20:30:27 -0700 (PDT) Received: from mb-aye.local (c-67-171-230-191.hsd1.wa.comcast.net [67.171.230.191]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s7E3UQUN020224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Aug 2014 03:30:26 GMT (envelope-from joelja@bogus.com) Message-ID: <53EC2D4D.4000207@bogus.com> Date: Wed, 13 Aug 2014 20:30:21 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "v6ops@ietf.org" References: <20140811132108.5976.52069.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933004E1CD@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004E1CD@OPEXCLILM23.corporate.adroot.infra.ftgroup> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b3TMg3rahVbpQuPE1aSXKIjhfsGw6LTdO" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Aug 2014 03:30:27 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QdRkhTtaVJXbBEvZvkqjBN68HVU Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 03:30:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b3TMg3rahVbpQuPE1aSXKIjhfsGw6LTdO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/13/14 6:14 AM, mohamed.boucadair@orange.com wrote: > Dear all, >=20 > Joel has kindly provided suggestions to address some concerns raised du= ring the IETF LC. Those suggestions have been implemented in this new ver= sion. >=20 > We hope to see the document advance in the publication process.=20 Thank the authors for their diligent efforts. I think some of the explanatory text as the beginning of each section goes a ways towards establishing a rational for the recommendations. I now fine it very hard to read as normative requirements (this is a good thing), so I would hope that we can look at the substance of the recommendations with the stakes reduced. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de internet- >> drafts@ietf.org >> Envoy=E9 : lundi 11 ao=FBt 2014 15:21 >> =C0 : i-d-announce@ietf.org >> Cc : v6ops@ietf.org >> Objet : [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-08.= txt >> >> >> 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 >> Cameron Byrne >> Gang Chen >> Filename : draft-ietf-v6ops-mobile-device-profile-08.txt >> Pages : 18 >> Date : 2014-08-11 >> >> 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 IEE= E >> 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-profil= e/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-08 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-prof= ile-08 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --b3TMg3rahVbpQuPE1aSXKIjhfsGw6LTdO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPsLU4ACgkQ8AA1q7Z/VrLEbwCfZmbdCUqon9qjNjhuFmF+4tCa Ey0AnRVtNzvOmEYuB8AsAxWbnYG/fRww =HEP9 -----END PGP SIGNATURE----- --b3TMg3rahVbpQuPE1aSXKIjhfsGw6LTdO-- From nobody Sat Aug 16 04:37: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 94A3D1A8769 for ; Sat, 16 Aug 2014 04:37:23 -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 k-K7f6-VL13I for ; Sat, 16 Aug 2014 04:37:21 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B01631A8762 for ; Sat, 16 Aug 2014 04:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DD32387153B; Sat, 16 Aug 2014 13:37:20 +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 sXpYKfcMN0wN; Sat, 16 Aug 2014 13:37:20 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:2c3d:d324:45ec:29d7]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id A3DA287153A; Sat, 16 Aug 2014 13:37:20 +0200 (CEST) Message-ID: <53EF4255.80908@globis.net> Date: Sat, 16 Aug 2014 13:36:53 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tore Anderson References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> In-Reply-To: <53E0C548.9050706@fud.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jMArCo2cYgkwDP84ojE8Ay7k_fY Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 11:37:23 -0000 Tore Anderson wrote: > * Tore Anderson > >> Eerily good timing... I just started working on this again today, as it >> happens. What I'm looking at now is two drafts, the one that's already >> there for a single-translation network-only implementation, plus another >> one describing an extension very similar to 464XLAT that would allow >> NAT-incompatible and/or IPv4-only applications to be used in an >> otherwise IPv6-only data centre. > > Here you go: > > http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html > http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc-2xlat.html > > XML sources and .txt formats at https://github.com/toreanderson/ietf/. > > They're work in progress obviously, I haven't uploaded them to the I-D > repository yet. It would be nice if you and Lee could have a chat with > the sunset4 chairs and agree on which WG is the most appropriate first. > (I have no particular preference, but I want it done Right.) > > Comments, criticisms, suggestions, pull requests would be very welcome! > > Tore I see these conceptually as partner documents to 464xlat (on the server side, rather than the eyeballs side). I therefore think it would be useful to bring these documents into v6ops as I-D's, especially if real-world operational deployment experience could be included. -- Regards, RayH From nobody Sat Aug 16 12:17: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 8B8851A016A for ; Sat, 16 Aug 2014 12:17:31 -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 KIfs5WVmNgZJ for ; Sat, 16 Aug 2014 12:17:29 -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 F149B1A0169 for ; Sat, 16 Aug 2014 12:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2584; q=dns/txt; s=iport; t=1408216649; x=1409426249; h=from:to:subject:date:message-id:references:mime-version; bh=W0bR0vkVjeslvnb6ftWXkcNJYyHRvF/r33Cx0EQDW60=; b=BA3pkpOhortzVdFnIotFGkklKyOR75E1D4S3TrasMMbfZ1HLnNq0hpgd neBVkP1xdI54ZXTcAvM12lWr6f/TmH/S6aq2dwdhWiVgYRTlfbN9jqhQW O78vqgm+3XJNA54UvfEd+tqIhDGtnN5AvfnRUc0qLdD+EZ6y8LSSqZvBQ M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFAE6t71OtJV2a/2dsb2JhbABZgw1TUwQEzEcKh1iBDhZ3hAMBAQEDAQEBAWsQCwIBGQMBAi8nCxQHAggCBBMJBYgsCAgFwnYXjzsTgj1TJIEdBZElggCBSlyGd4FXjHyGMINdbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.01,876,1400025600"; d="asc'?scan'208";a="69824100" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 16 Aug 2014 19:17:28 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7GJHSrk018109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 16 Aug 2014 19:17:28 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; Sat, 16 Aug 2014 14:17:28 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: I-D Action: draft-smith-enhance-vne-with-ipv6-04.txt Thread-Index: AQHPuTpkc+gNtfsj3EuzHHA6kz7xsg== Date: Sat, 16 Aug 2014 19:17:27 +0000 Message-ID: <5AE88B79-FB7F-4C47-BEEC-4290A48477E3@cisco.com> References: <20140816101041.6913.45904.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.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_9D66BAFE-9481-4BEA-8E7D-C57C77ED011D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bH6S9ptJjcP6j9oNAls9TkUD_TQ Subject: [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 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 19:17:31 -0000 --Apple-Mail=_9D66BAFE-9481-4BEA-8E7D-C57C77ED011D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark would like our comments, please > From: > Subject: I-D Action: draft-smith-enhance-vne-with-ipv6-04.txt > Date: August 16, 2014 at 3:10:41 AM PDT > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Enhancing Virtual Network Encapsulation with = IPv6 > Author : Mark Smith > Filename : draft-smith-enhance-vne-with-ipv6-04.txt > Pages : 17 > Date : 2014-08-16 >=20 > Abstract: > A variety of network virtualization over layer 3 methods are > currently being developed and deployed. These methods treat IPv4 and > IPv6 as equivalent underlay network technologies. This memo suggests > how IPv6's additional capabilities may be used to enhance Virtual > Network encapsulation over an IPv6 Underlay Network. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-smith-enhance-vne-with-ipv6/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-enhance-vne-with-ipv6-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_9D66BAFE-9481-4BEA-8E7D-C57C77ED011D 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 iD8DBQFT765DbjEdbHIsm0MRAtLQAJ0QeBtSd/K5lRLhl33+BvVt1a3swgCbBqq2 R5+olpuuPlfWz8fP6/dBVHQ= =FC0D -----END PGP SIGNATURE----- --Apple-Mail=_9D66BAFE-9481-4BEA-8E7D-C57C77ED011D-- From nobody Mon Aug 18 06:53: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 780321A0351 for ; Mon, 18 Aug 2014 06:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jQNoZ6HVI5y for ; Mon, 18 Aug 2014 06:53:13 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81C51A0380 for ; Mon, 18 Aug 2014 06:53:10 -0700 (PDT) X-Env-Sender: jloiacon@csc.com X-Msg-Ref: server-7.tower-171.messagelabs.com!1408369988!20209905!1 X-Originating-IP: [20.137.2.180] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14458 invoked from network); 18 Aug 2014 13:53:09 -0000 Received: from amer-mta103.csc.com (HELO amer-mta113.csc.com) (20.137.2.180) by server-7.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Aug 2014 13:53:09 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta113.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s7IDr7vv027890 for ; Mon, 18 Aug 2014 09:53:07 -0400 In-Reply-To: <5AE88B79-FB7F-4C47-BEEC-4290A48477E3@cisco.com> References: <20140816101041.6913.45904.idtracker@ietfa.amsl.com> <5AE88B79-FB7F-4C47-BEEC-4290A48477E3@cisco.com> To: IPv6 Ops WG MIME-Version: 1.0 X-KeepSent: D1D40919:16189100-85257D38:004BDF3C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Joe Loiacono Message-ID: Date: Mon, 18 Aug 2014 09:53:06 -0400 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 08/18/2014 09:53:08 AM, Serialize complete at 08/18/2014 09:53:08 AM Content-Type: multipart/alternative; boundary="=_alternative 004C462285257D38_=" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KuScPNlQk0a1Q1RXdX5wPW0K21A Subject: [v6ops] Announcement: FlowViewer v4.4 - IPv6 netflow analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 13:53:16 -0000 This is a multipart message in MIME format. --=_alternative 004C462285257D38_= Content-Type: text/plain; charset="US-ASCII" Better understand IPv6 traffic across your network ... FlowViewer version 4.4 was released to SourceForge Friday. FlowViewer provides a dynamic web front-end to two powerful open-source netflow data collector and analyzers, flow-tools and SiLK. FlowViewer provides the user with the ability to report, graph and track (MRTG-like) user specified subsets of network traffic (IPv4 and IPv6.) Version 4.4 is a significant upgrade with several new key features: * A visual Analysis feature that simplifies the identification of major contributors to traffic events (e.g., peak flows.) * The ability to create multiple Dashboards for different user classes (individuals, groups, networks, data centers, etc.) * More flexibility for interfacing with a wide variety of SiLK configurations. The new features extend FlowViewer's security analysis capabilities and enhance the user's general traffic situational awareness. https://sourceforge.net/projects/flowviewer Regards, Joe --=_alternative 004C462285257D38_= Content-Type: text/html; charset="US-ASCII" Better understand IPv6 traffic across your network ...



FlowViewer version 4.4 was released to SourceForge Friday.

FlowViewer provides a dynamic web front-end to two powerful open-source netflow data collector and analyzers, flow-tools and SiLK. FlowViewer provides the user with the ability to report, graph and track (MRTG-like) user specified subsets of network traffic (IPv4 and IPv6.)

Version 4.4 is a significant upgrade with several new key features:

* A visual Analysis feature that simplifies the identification of major contributors to traffic events (e.g., peak flows.)
* The ability to create multiple Dashboards for different user classes (individuals, groups, networks, data centers, etc.)
* More flexibility for interfacing with a wide variety of SiLK configurations.

The new features extend FlowViewer's security analysis capabilities and enhance the user's general traffic situational awareness.

https://sourceforge.net/projects/flowviewer

Regards,

Joe --=_alternative 004C462285257D38_=-- From nobody Tue Aug 19 05:00: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 E71261A03E1; Tue, 19 Aug 2014 05:00:33 -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 w2-m8TlU2dJO; Tue, 19 Aug 2014 05:00:30 -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 10EF51A03D7; Tue, 19 Aug 2014 05:00:29 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJi5T-0003v9-1p; Tue, 19 Aug 2014 14:00:27 +0200 Message-ID: <53F33C4F.2070807@si6networks.com> Date: Tue, 19 Aug 2014 09:00: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: IPv6 Operations Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/E-GzEvaqrCNdPZsRGlFUiVtlmdU Cc: "'opsec@ietf.org'" Subject: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:00:34 -0000 Folks, Ten days ago or so we published this I-D: Section 5.2 of the I-D discusses a possible attack vector based on a combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by operators, along with proposed countermeasures -- on which we'd like to hear your comments. Since Section 5.2 is in the draft, let me offer a more informal and practical explanation: 1) It is known that filtering of packets containing IPv6 Extension Headers (including the Fragment Header) is widespread (see our I-D above) 2) Let us assume that Host A is communicating with Server B, and that some node filters fragments between Host A and Server B. 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop MTU<1280), in the hopes of eliciting "atomic fragments" (see ) from now on. 4) Now server B starts sending IPv6 atomic fragments... And since they include a frag header (and in '2)' above we noted that frags are dropped on that path), these packets get dropped (i.e., DoS). "Demo" with the icmp6 tool () -- (some addresses have been changed (anonimized), but it is trivial to pick a victim server...) "2001:db8:1:10:0:1991:8:25" is the server, and "2001:5c0:1000:a::e7d" is my own address): ---- cut here ---- ***** First of all, I telnet to port 80 of the server, and everything works as expected **** fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 Trying 2001:db8:1:10:0:1991:8:25... Connected to 2001:db8:1:10:0:1991:8:25. Escape character is '^]'. ^CConnection closed by foreign host. **** Now I send the forget ICMPv6 PTB **** fgont@satellite:~$ sudo icmp6 --icmp6-packet-too-big -d 2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o 80 -v icmp6: Security assessment tool for attack vectors based on ICMPv6 error messages IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected) IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25 IPv6 Hop Limit: 227 (randomized) ICMPv6 Packet Too Big (Type 2), Code 0 Next-Hop MTU: 1000 Payload Type: IPv6/TCP (default) Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected) Destination Address: 2001:5c0:1000:a::e7d Hop Limit: 237 (randomized) Source Port: 80 Destination Port: 38189 (randomized) SEQ Number: 734463213 (randomized) ACK Number: 866605720 (randomized) Flags: A (default) Window: 18944 (randomized) URG Pointer: 0 (default) Initial attack packet(s) sent successfully. ***** And now I try the same telnet command as above... but it fails, because the frags from the server to me are getting dropped somewhere **** fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 Trying 2001:db8:1:10:0:1991:8:25... [timeout] ---- cut here ---- Of course, in this particular case I just "shot myself". But one could do this to DoS connections between mailservers, etc. A nice question is: what if e.g.... 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and react (as expected) by generating atomic fragments, *and*, 2) These same BGP servers deem fragmentation as "harmful", and hence drop such fragments you could essentially DoS traffic between them As noted in the I-D, the mitigations seem to be: 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 PTB, or, 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU smaller than 1280. Thoughts? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 05:10: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 426CA1A88CC for ; Tue, 19 Aug 2014 05:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 JrPLFA27oMik for ; Tue, 19 Aug 2014 05:09: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 5DB6B1A03D7 for ; Tue, 19 Aug 2014 05:09:55 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s7JC9SUX011356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2014 13:09:48 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <53F33E78.4070402@foobar.org> Date: Tue, 19 Aug 2014 13:09:28 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Fernando Gont , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> In-Reply-To: <53F33C4F.2070807@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wnSGkCUXrh6JkhJz7B0HEG7r5Ho Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:09:58 -0000 On 19/08/2014 13:00, Fernando Gont wrote: > 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 > PTB, or, > > 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU > smaller than 1280. > > Thoughts? /me buries head in hands, dies a little more inside. This makes an stronger case for urpf and customer edge filtering, but there are lots of organisations who don't bother with bcp38. Also, sup720/rsp720. Sigh. Nick From nobody Tue Aug 19 05:14: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 7DF1E1A88D0 for ; Tue, 19 Aug 2014 05:14:31 -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 s1leYTgWvmfH for ; Tue, 19 Aug 2014 05:14:30 -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 EA87A1A03EC for ; Tue, 19 Aug 2014 05:14:29 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJiJ0-0003xf-8j; Tue, 19 Aug 2014 14:14:26 +0200 Message-ID: <53F33F9F.3050705@si6networks.com> Date: Tue, 19 Aug 2014 09:14:23 -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: Nick Hilliard , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F33E78.4070402@foobar.org> In-Reply-To: <53F33E78.4070402@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/88yAaPt7kB4TqB-3d0aNf1_bsFo Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:14:31 -0000 On 08/19/2014 09:09 AM, Nick Hilliard wrote: > On 19/08/2014 13:00, Fernando Gont wrote: >> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 >> PTB, or, >> >> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU >> smaller than 1280. >> >> Thoughts? > > /me buries head in hands, dies a little more inside. > > This makes an stronger case for urpf and customer edge filtering, but > there are lots of organisations who don't bother with bcp38. It is actually worse than that: The attacker does not even need to forge the source address of the ICMPv6 PTB: after all, he can pretend to be a router (i.e., the source address for the ICMPv6 PTB can be any). The only addresses that the attacker needs to forge are those of the IPv6 packet *embedded in the ICMPv6 payload*. But BCP38 does not help you there.... 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 Aug 19 05:31: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 B65641A040E; Tue, 19 Aug 2014 05:31: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK2d7kjB1gkQ; Tue, 19 Aug 2014 05:31:49 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00D01A0416; Tue, 19 Aug 2014 05:31:49 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id C6A9B10034AC6; Tue, 19 Aug 2014 12:31:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408451506; bh=/wHsniLtZHm+RYSYa6XIbbJQ50oxkzApF+gYyHsNtAI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=CTm0FGPulxxUT0eem+H2gqaafb3HR7Bimvj/DvMj9M+A33P1lFxip39x4kmgN8X1v WkQzUiDE0QswbstWA4hWLwiD9USV7eceOkVn5S9CEyRcQBSRQ6tugz72yR6bOF4MoE iXIbV9m8LpOQVZT4iWrBI3mItCMQqKuOIfdx0ij+ccdVpvCLkYxmn2ei9KCJGkEyT0 qry98QHJZRjN4Tr1Noi4NCPk7Zb86AuxyFhuwLhyvmx3BTLwUSM0eREO/TVBYhs7vM Gvvpjc0foJmSlCivqcqqUYnCyexCJbnKFfeGS03rEwXL4me8KA0xdT8K58KEzkDwWh 6yV5Tlf9Uai3g== Message-ID: <53F343A3.1070505@massar.ch> Date: Tue, 19 Aug 2014 14:31:31 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Fernando Gont , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> In-Reply-To: <53F33C4F.2070807@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VA1n8oT-oadzsV-l5so-Nk3Kplw Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:31:51 -0000 On 2014-08-19 14:00, Fernando Gont wrote: [..] > 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and > react (as expected) by generating atomic fragments, *and*, Anything accepting an MTU < 1280 does not belong on the Interwebs. Hence, it would be good that kind of broken code can't send anything. [..] > As noted in the I-D, the mitigations seem to be: > > 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 > PTB, or, > > 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU > smaller than 1280. Don't forget: 0) BCP38. Though, one would have to inspect the ICMPv6 packet too then.... Hmm, maybe time to test that out in sixxsd... Greets, Jeroen From nobody Tue Aug 19 05: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 E01191A0416; Tue, 19 Aug 2014 05:35:32 -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 WFB4mi00OZ8t; Tue, 19 Aug 2014 05:35:31 -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 D85E31A040A; Tue, 19 Aug 2014 05:35:30 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJidM-00041q-5J; Tue, 19 Aug 2014 14:35:28 +0200 Message-ID: <53F34486.7010903@si6networks.com> Date: Tue, 19 Aug 2014 09:35:18 -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: Jeroen Massar , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> In-Reply-To: <53F343A3.1070505@massar.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YmxWXfpiP7rifrNnBpg7_z0T14M Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:35:33 -0000 On 08/19/2014 09:31 AM, Jeroen Massar wrote: > On 2014-08-19 14:00, Fernando Gont wrote: > [..] >> 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and >> react (as expected) by generating atomic fragments, *and*, > > Anything accepting an MTU < 1280 does not belong on the Interwebs. > > Hence, it would be good that kind of broken code can't send anything. Well, RFC2460 requires so.... > [..] >> As noted in the I-D, the mitigations seem to be: >> >> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 >> PTB, or, >> >> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU >> smaller than 1280. > > Don't forget: > 0) BCP38. > > Though, one would have to inspect the ICMPv6 packet too then.... Agreed. You need to apply ICMPv6 to the embedded payload... > Hmm, maybe time to test that out in sixxsd... Just taking my chance to thank you for sixxsd! ;-) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 05:41: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 003401A0414 for ; Tue, 19 Aug 2014 05:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF28CknOOMOc for ; Tue, 19 Aug 2014 05:41:53 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66D71A0367 for ; Tue, 19 Aug 2014 05:41:52 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so6438056wes.37 for ; Tue, 19 Aug 2014 05:41:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mvc1rVM+hJzQv4xMsQ36p4wK91q1JeglP3+QYviRk+s=; b=eBwmmYEYydKSFf/VBMOPqqXeWEcgEmboCdICqxPUa7EqmFCwjRMiyVr0Imf6HmupeH C7iy0RJ0+C4JwV3XdAbLto3Ydv19W2Q0SbtyIkE8z+NZBYT7gp21KNgrC6X7f/b0Hqm6 /ZewXlwm5DRDUhZ9rqzyVy7aQwpMvRouVSMqOwqwgrHZhJ7K/C3X5EC5vgNqDvT3XO8X wsu9LxLVD3KsFB2dsPR6+fr/39Xjemjg7F5tH7roOPb0gT0hHB4F/0UaUinNvuQ+Dy0Q e5t2W63WkViS++g+q6pk7Rv+Cd4Cb+u4hA3ze/hR4MnxnrwLD3xnCpjyBFcjh7hLgUWa ZVHA== X-Gm-Message-State: ALoCoQmPLiz/BIGYeSDPSIClx9vwkYtdi7ezRzGD2nH7DNoHDGj2khB8hN3YZk88KW8W1aobNMD4 MIME-Version: 1.0 X-Received: by 10.180.75.203 with SMTP id e11mr6736226wiw.28.1408452110812; Tue, 19 Aug 2014 05:41:50 -0700 (PDT) Received: by 10.180.80.131 with HTTP; Tue, 19 Aug 2014 05:41:50 -0700 (PDT) In-Reply-To: <53F33F9F.3050705@si6networks.com> References: <53F33C4F.2070807@si6networks.com> <53F33E78.4070402@foobar.org> <53F33F9F.3050705@si6networks.com> Date: Tue, 19 Aug 2014 08:41:50 -0400 Message-ID: From: Simon Perreault To: Fernando Gont Content-Type: multipart/alternative; boundary=f46d0438958fbfa3260500facf82 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gwIAnQs-JBUo92CyEt9lU7asUC0 Cc: IPv6 Operations Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:41:55 -0000 --f46d0438958fbfa3260500facf82 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 19, 2014 at 8:14 AM, Fernando Gont wrote: > The attacker does not even need to forge the source address of the > ICMPv6 PTB: after all, he can pretend to be a router (i.e., the source > address for the ICMPv6 PTB can be any). > > The only addresses that the attacker needs to forge are those of the > IPv6 packet *embedded in the ICMPv6 payload*. > > But BCP38 does not help you there.... > Nice. Without relying on fragments being blocked, would it be possible to practically DoS someone by setting the MTU to a crazy low value (e.g., 1)? Would this be mitigated by standards and/or implementations? Should we start requiring that MTU < 1280 be rejected? Simon --f46d0438958fbfa3260500facf82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Aug 19, 2014 at 8:14 AM, Fernando Gont <fgont@si6networks.com<= /a>> wrote:
The attacker does not even need to forge the source address of = the
ICMPv6 PTB: after all, he can pretend to be a router (i.e., the source
address for the ICMPv6 PTB can be any).

The only addresses that the attacker needs to forge are those of the
IPv6 packet *embedded in the ICMPv6 payload*.

But BCP38 does not help you there....


Nice.

Without relying on fragments being= blocked, would it be possible to practically DoS someone by setting the MT= U to a crazy low value (e.g., 1)? Would this be mitigated by standards and/= or implementations?

Should we start requiring that MTU <= ; 1280 be rejected?

Simon
--f46d0438958fbfa3260500facf82-- From nobody Tue Aug 19 06:19: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 A2C4A1A88E7; Tue, 19 Aug 2014 06:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VD6ncwIMCwX; Tue, 19 Aug 2014 06:19:14 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C581A88C9; Tue, 19 Aug 2014 06:19:13 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 97F3A10034B7C; Tue, 19 Aug 2014 13:19:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408454350; bh=dgWWg6GkoIrtrhD8/H3YFd6mKsCCWtvTW8nxbYT0DGA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jzj/m5CoHnmxHbfvQlm8olDmqtrXtbNC+0PLDM5NJRcmluiveLwDY1fPwQtgo2SHA TsZgrofZ4AB116lg0bi2VmAxAgwQg7FQEPCVzcSkcbzlKiKyRS/97r+jjFReg4dNOz Bq/nynGSA2WRbR026wfXmOqzGi4PFZUMs/4mPXCHkzJyywhRyOGteWiM81tq8v3ej9 QfUhb9dk1OHtDAmyE3p7n6gn25qXkVeDMR5rlyj1+YLQlUYt0n8SSle2Vr9S5Ckuhk x3O+QlKmlbEVEAnQjD4iNyTXG2y0Q+8NQ/79ntmeuyVHEevPyqO4e+9ZveXn1jH7sE 5fGwDTfZDStgg== Message-ID: <53F34EC0.30400@massar.ch> Date: Tue, 19 Aug 2014 15:18:56 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Fernando Gont , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> In-Reply-To: <53F34486.7010903@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lXJuqTviPhi_59U0yKHuUIH6ErY Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:19:15 -0000 On 2014-08-19 14:35, Fernando Gont wrote: [..] >> Though, one would have to inspect the ICMPv6 packet too then.... > > Agreed. You need to apply ICMPv6 to the embedded payload... But also for ICMPv4, which has similar attacks. Hence we should formulate text a bit like: 8<------------------------ When forwarding or receiving an ICMP error packet: - The IP destination of the packet MUST match the source address represented in the ICMP error packet. - The ICMP error packet's destination address must qualify uRPF rules for the same interface as the source address.[1] As the verified packets are ICMP errors, when the verification fails the packet MUST be dropped, logging is recommended. Due to the checking inside the ICMP portion of a packet: Access-routers, firewalls and hosts MUST perform these checks. Core-routers SHOULD perform these checks [1] When ICMP-dst address matches IP-src the check should already have been performed by the standard uRPF check. ------------------------>8 But then in better wording to avoid dis-ambiguity of which src/dst is which (the one in IP or ICMP) >> Hmm, maybe time to test that out in sixxsd... > > Just taking my chance to thank you for sixxsd! ;-) Unfortunately that is only usable for a very small base of connectivity and hopefully one day will stop to be needed. The big brands needs to implement it. And it much more difficult to push out updates to devices which are not under one's control and where one has a very large deployed base. Greets, Jeroen From nobody Tue Aug 19 06:24: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 8EC151A88D0 for ; Tue, 19 Aug 2014 06:24: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 ebhACf2bjxOE for ; Tue, 19 Aug 2014 06:24:33 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C571A88C9 for ; Tue, 19 Aug 2014 06:24:33 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so1050695iec.16 for ; Tue, 19 Aug 2014 06:24: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:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BDZrqShWjWHRB5brkxDIHXf6xhS0rY8fWlIzLCWkxts=; b=ebceEGtxqYXe8GFd1IjSmGmOspVnjIO0M83p7ytHuStiXLkGobLpSGrhY1EKTj3+Ow BiIbNROWV2FREgwbZAT3aBrRqG3cIYvQzGTot/1n1pX4Q/W5pm29nPcF00FYTZFTdnKw rxNn8naGJQ4mdKre6bAGXdZmY4qkveLYGBvAYZyO90bdTHNyPWbOv5v49LNhRdoyfXVw 20J5C8TYh7mlFKa5w3oyeSXry9Ml4LrzTN5DNiI6Y0JrBQp7eFVviMNZf3FDjZ/mC1sS FdYS9rIXK5hsXWaFez+aP9fZvb1Ka3B4j1sSmKO1CJO9PozTUaM5NZWdqOuOiU1dSa5Q HnFg== X-Gm-Message-State: ALoCoQk3TxKl7tXND+7U+cSDAcZJNF54uMGm5AmEnGXSgEb20tOgliFKLRWL7eB3OXRTExLjNNef X-Received: by 10.50.124.102 with SMTP id mh6mr5698625igb.27.1408454672856; Tue, 19 Aug 2014 06:24:32 -0700 (PDT) Received: from [172.19.254.114] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by mx.google.com with ESMTPSA id l4sm56582049igt.20.2014.08.19.06.24.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 06:24:32 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Roland Dobbins In-Reply-To: <53F34EC0.30400@massar.ch> Date: Tue, 19 Aug 2014 20:23:54 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> To: "opsec@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sd5B2OSaCm-1XuzyYNfNHPUIi2k Cc: IPv6 Operations Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:24:35 -0000 On Aug 19, 2014, at 8:18 PM, Jeroen Massar wrote: > - The ICMP error packet's destination address must qualify uRPF rules = for the same interface as the source address.[1] Should this language be limited to uRPF, or should it include other = anti-spoofing mechanisms, as well? ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco=F6n From nobody Tue Aug 19 06:29: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 3A78C1A041D; Tue, 19 Aug 2014 06:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bauy2YLctQz8; Tue, 19 Aug 2014 06:29:52 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3471A02C1; Tue, 19 Aug 2014 06:29:52 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id B90A310034A9D; Tue, 19 Aug 2014 13:29:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408454990; bh=Iwji1cC8RoZoIlx+LfwnxAsQ+wQnU5V3V2GV4CbwMPY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=VshfIMmAcsVwVGC6sDM4GtLMdt8iZBmSdrCrz3uoAVmJyUO9YSvtu0yjCnIzvXgPU 5qvgg4Gn0o9IkxbT6NZd3r3E2ECEnNp56vlCGSbx3YmN6TmrbD96V1vrjHon5YY1Im ke8LXNTwj8JUj1Lf4eAfq0QxFqA+PKWPOBDMzWZg3OGeB65C6G2xZ1OzmLiaOTbaYa BfaSPo4oJP8XFXhPGsVocPd+eVkpZE9+Td2hdsSy4KymlFRm0W77NjiJ6z8isO0z/i SksRM5fm2AKA1ruBrH/5UjoWHAklaJuylzMR3SaTYM2FeEKdwquts6A/BHYauIiTx/ 8sai51E1WVB+g== Message-ID: <53F35140.7040007@massar.ch> Date: Tue, 19 Aug 2014 15:29:36 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Roland Dobbins , "opsec@ietf.org" References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> In-Reply-To: <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZrNG6fRfhKsm5nbyZfFNzm8iK94 Cc: IPv6 Operations Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:29:54 -0000 On 2014-08-19 15:23, Roland Dobbins wrote: > > On Aug 19, 2014, at 8:18 PM, Jeroen Massar wrote: > >> - The ICMP error packet's destination address must qualify uRPF rules for the same interface as the source address.[1] > > Should this language be limited to uRPF, or should it include other anti-spoofing mechanisms, as well? Any kind of mechanism that can check: "is this source address supposed to come from that interface" would qualify IMHO (as long as it does a proper job ;). Greets, Jeroen From nobody Tue Aug 19 07:11: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 7015F1A0376; Tue, 19 Aug 2014 07:11:25 -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 TwMWjYS4QQbX; Tue, 19 Aug 2014 07:11:23 -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 591AB1A8906; Tue, 19 Aug 2014 07:11:13 -0700 (PDT) X-Envelope-To: opsec@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 s7JEAeHV012392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2014 15:11:04 +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: <53F35AE0.2040304@foobar.org> Date: Tue, 19 Aug 2014 15:10: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: Jeroen Massar , Fernando Gont , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> In-Reply-To: <53F34EC0.30400@massar.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3mEnHWJPNwuvjMapeJVjPIlMjJU Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:11:25 -0000 On 19/08/2014 14:18, Jeroen Massar wrote: > But also for ICMPv4, which has similar attacks. no, it doesn't because in general ipv4 fragments are not dropped. Also, ipv4 handles this by fragmenting en-route rather than sending PTB packets to the source. Nick From nobody Tue Aug 19 07: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 9AB6C1A037E for ; Tue, 19 Aug 2014 07:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 zjlcVzooahH5 for ; Tue, 19 Aug 2014 07:33:15 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id 03E3A1A033C for ; Tue, 19 Aug 2014 07:33:14 -0700 (PDT) Received: from [85.158.137.35:22984] by server-3.bemta-3.messagelabs.com id 5A/A3-22751-A2063F35; Tue, 19 Aug 2014 14:33:14 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-7.tower-134.messagelabs.com!1408458793!33681363!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 529 invoked from network); 19 Aug 2014 14:33:13 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-7.tower-134.messagelabs.com with SMTP; 19 Aug 2014 14:33:13 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Tue, 19 Aug 2014 15:42:19 +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; Tue, 19 Aug 2014 15:32:57 +0100 From: "Heatley, Nick" To: Lorenzo Colitti , Ca By , "Fred Baker (fred) (fred@cisco.com)" Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvAuWkAgAAE0QCAABWsAIAAcMQAgAAl34CAAJ+zAIAADBCAgAAFpYCAAA64AIAAG/gAgAAekRv///gCAIAAJVUSgAHRDICAALyKgIAAAbUAgAFImdA= Date: Tue, 19 Aug 2014 14:32:56 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303B7DB43UK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ST2xtk1zyemFhCajsTt0lbNL2fk Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:33:17 -0000 --_000_6536E263028723489CCD5B6821D4B21303B7DB43UK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgSSBtYXkgc3RpY2sgbXkgbmVjayBvdXQuDQoNCknigJlkIGxpa2UgdjZvcHMgdG8gY29uc2lk ZXIgYXQgbGVhc3QgdHdvIGl0ZW1zOg0KDQoxLiAgICAgICAoQ2FycmllciBHcmFkZSkgTkFUNjQg dnMgTkFUNDQg4oCTIGEgZGVhdGhtYXRjaC4NCklNSE8gTkFUNjQgc2hvdWxkIGJlIGdyZWF0ZXIg b3IgZXF1YWwgdG8gTkFUNDQgd2hlbiBpbXBsZW1lbnRlZCBjb3JyZWN0bHkuDQpPbmx5IE5BVDY0 IGNhbiBoZWxwIHdpdGggYm90aCBwcml2YXRlIGFuZCBwdWJsaWMgSVB2NCBleGhhdXN0aW9uLiAo Tm90ZTogSW4gY2VsbHVsYXIgbmV0d29ya3MsIHdoZXJlIE5BVCBpcyBwcmV2YWxlbnQsIHByaXZh dGUgZXhoYXVzdGlvbiBpcyBhIGJpZyBpc3N1ZSB0b2RheSwgZHJpdmluZyBJTVMgdG93YXJkIElQ djYtb25seSwgYW5kIGRhdGEgc2VydmljZXMgdG8gNDY0eGxhdCkuDQpBbmQgYXMgaGlnaGxpZ2h0 ZWQgYmVsb3csIGEgbWFqb3IgcHJvcG9ydGlvbiBvZiB0cmFmZmljIGdvZXMgcHVyZSBJUHY2LCBy ZWR1Y2luZyB0aGUgbG9hZCBvbiB0aGUgTkFULg0KV2h5IGRvIHNvbWUgcGVvcGxlIHN0aWxsIGZl YXIgTkFUNjQgb3IgdGhpbmsgdGhhdCBOQVQ0NCBpcyBnb2luZyB0byBtb3ZlIHRoZW0gZm9yd2Fy ZD8gTVRVIGlzc3VlcyBjYW4gYmUgZml4ZWQuIDY0IEFMR3MgY2FuIG1hdGNoZWQgNDQuIEnigJl2 ZSBldmVuIGZpeGVkIEZUUCBpc3N1ZXMuIExpdGVyYWxzIGNhbiBiZSBmaXhlZCBhdCB0aGUgaG9z dC4NCkhvbGRpbmcgb24gdG8gdGhlIE5BVDQ0IGFyY2hpdGVjdHVyZSB3aGV0aGVyIGluIER1YWwg U3RhY2srTkFUNDQgb3Igb3RoZXJ3aXNlIHdpbGwga2VlcCB1cyBhbGwgaW4gdGhlIG9sZCB3b3Js ZC4gSWYgeW91IGFyZSBhIGxhcmdlIElTUCB0aGlua2luZyBhYm91dCBwdWJsaWMgZXhoYXVzdGlv biwgYW5kIHlvdXIgcGxhbiBpcyB0byBpbnRyb2R1Y2UgcHJpdmF0ZXMgKyBOQVQ0NCwgdGhlbiB0 aGluayBvbiwgcGVyaGFwcyB5b3UgYXJlIGp1c3QgZXhjaGFuZ2luZyBvbmUgZXhoYXVzdGlvbiBk YXRlIGZvciBhbm90aGVyLg0KQXMgaXQgc3RhbmRzIHdlIGRvbuKAmXQgaGF2ZSBhIGNvbnNlbnN1 cyBoZXJlLg0KDQoNCjIuICAgICAgIEEgcGFwZXIgdG8gdXBkYXRlIFJGQzY1ODYgYWJvdXQgdGhl IGV4cGVyaWVuY2VzIG9mIFBDcyBhbmQgTW9iaWxlIGRldmljZXMgb24gNDY0eGxhdCBuZXR3b3Jr cw0KDQpJdCBzZWVtcyBhYm91dCB0aGUgcmlnaHQgdGltZSBmb3IgdGhpcy4gUkZDNjU4NiBsZWZ0 IHVzIHdpdGggc29tZSBjbGlmZiBoYW5nZXJzLiBEb2VzIDQ2NHhsYXQgZmluaXNoIHRoZSBqb2Ig b2ZmPyBZZXMgb3Igbm8/IFdoZXJlIGFyZSB0aGUgZ2Fwcz8gKOKAnExvc3N5IGFuZCBicml0dGxl 4oCdIGZvciBJUCBsaXRlcmFsIGRlc3RpbmF0aW9ucywgd2hhdCBkb2VzIHRoaXMgbWVhbj8pDQoN CldoYXQgaXMgdGhlIGNvbW1vbiB0aGVtZSBvZiB0aGUgYWJvdmU/DQpJIGhhdmUgc2VlbiB0aGlz IHdyaXR0ZW4gaW4gdGhlIGFic3RyYWN0IGZvciBzdW5zZXQ0Lg0KDQogICBTdW5zZXR0aW5nIElQ djQgcmVmZXJzIHRvIHRoZSBwcm9jZXNzIG9mIHR1cm5pbmcgb2ZmIElQdjQNCiAgIGRlZmluaXRp dmVseS4gIEl0IGNhbiBiZSBzZWVuIGFzIHRoZSBmaW5hbCBwaGFzZSBvZiB0aGUgbWlncmF0aW9u IHRvDQogICBJUHY2DQpJIGRvbuKAmXQgdGhpbmsgdGhlIHdvcmxkIGlzIHJlYWR5IGZvciBzdW5z ZXR0aW5nIElQdjQsIGl0IGFwcGVhcnMgYW4gYWNhZGVtaWMgdG9waWMgdG8gbWFueS4gSSBkb27i gJl0IHRoaW5rIGluIHY2b3BzIHdlIGFyZSBxdWl0ZSByZWFkeSBmb3IgdGhpcyBmaW5hbCBwaGFz ZSBvZmYgdHVybmluZyBvZmYgSVB2NCDigJxhcyBhIHNlcnZpY2XigJ0uDQpIb3dldmVyIEkgZG8g dGhpbmsgdGhlcmUgaXMgc29tZSBnYXAgdG8gYnJpZGdlIGluIHY2b3BzLCBzb21lIGludGVybWVk aWFyeSBwaGFzZSBiZXR3ZWVuIHdoZXJlIHdlIGFyZSBub3cgKHN0dWNrIGluIGVxdWlsaWJyaXVt IHdpdGggSVB2NCBkb21pbmFudCksIGFuZCBhIHBvaW50IHdoZXJlIHY2IGlzIHRoZSBkb21pbmFu dCBhZGRyZXNzIGZhbWlseSBvbiBob3N0cy4NCg0KU28gdGhlIHRoZW1lIHdvdWxkIGJlIOKAnHY2 IGRvbWluYW504oCdLCBhbmQgaW4gaXQgd291bGQgYmUgdGhlIGV4aGF1c3Rpb24gYmVhdGluZyB0 ZWNobm9sb2dpZXMsIHRoZSB0ZWNobm9sb2dpZXMgdGhhdCB0aGUgSUVURiBzaG91bGQgY2hhbXBp b24gYmVjYXVzZSBiZWZvcmUgd2UgY2FuIGV2ZW4gY29uc2lkZXIgdHVybmluZyBvZmYgdjQgd2Ug bmVlZCB0byBnZXQgdG8gc3RhdGUgd2hlcmUgdGhlIElQdjYgYWRkcmVzcyBhdCB0aGUgY2xpZW50 L2hvc3QgaXMgdGhlIGRvbWluYW50IGFkZHJlc3MgZmFtaWx5IGZvciBjb25uZWN0aXZpdHkuDQpM ZXTigJlzIGZhY2UgaXQsIGlmIHlvdSBoYXZlIGEgbmljZSBzdG9ja3BpbGUgb2YgcHVibGljIElQ djQsIHlvdSBtYXkgbm90IG5lZWQgdG8gY2FyZSBhYm91dCBJUHY2LCBhbmQgZHVhbHN0YWNrIG1p Z2h0IGV2ZW4gbG9vayBsaWtlIHNvbWUgcmFkaWNhbCBhcHByb2FjaC4NCkV2ZXJ5b25lIGVsc2Ug bmVlZHMgdG8gY29sbGVjdGl2ZWx5IGRlYWwgd2l0aCBleGhhdXN0aW9uLg0KSSBkbyB0aGluayB3 ZSBoYXZlIGEgbG90IHRvIGRvIHRvIGdldCBvdXIgY29sbGVjdGl2ZSBzdG9yeSBzdHJhaWdodCBv biB0aGlzLg0KSSB0aGluayBwYXBlcnMgYWJvdmUgd291bGQgaGVscC4gVGhlcmUgbWlnaHQgYmUg bW9yZSBhZGRyZXNzIHNhdmluZyB0ZWNobmlxdWVzIHRvIGFkZCB0byB0aGUgbGlzdCBmb3Ig4oCc ZXhwZXJpZW5jZeKAnSBkb2N1bWVudHMsIHBlcmhhcHM/DQpOZXcgaWRlYXMgaGVyZT8gSWYgZXZl cnkgQ2xpZW50IE9TIGhhZCBzb21lIGluYnVpbHQgZnVuY3Rpb24gdG8gYWxsb3cgaXQgdG8gZnVu Y3Rpb24gd2hlbiB0aGUgbmV0d29yayBjYW4gb25seSBwcm92aWRlIGl0IGFuIElQdjYgcHJlZml4 IHRoZW4gd2hhdCB3b3VsZCB0aGF0IGJlPyBDb3VsZCBpdCByZW1haW4gZG9ybWFudCB1bnRpbCBy ZXF1aXJlZOKApg0KVGhvdWdodHM/DQpSZWdhcmRzLA0KTmljaw0KDQoNCkZyb206IHY2b3BzIFtt YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0 aQ0KU2VudDogMDcgQXVndXN0IDIwMTQgMTQ6MTMNClRvOiBDYSBCeQ0KQ2M6IFRvcmUgQW5kZXJz b247IElQdjYgT3BzIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBPcGVyYXRpb25hbCBDb25zZW5z dXMgb24gZGVwbG95bWVudA0KDQpPbiBUaHUsIEF1ZyA3LCAyMDE0IGF0IDEwOjA2IFBNLCBDYSBC eSA8Y2IubGlzdDZAZ21haWwuY29tPG1haWx0bzpjYi5saXN0NkBnbWFpbC5jb20+PiB3cm90ZToN Cg0KPiA+SSB0aGluayBpdCBpcyBzYWZlIHRvIHNheSB0aGF0IHByb3ZpZGluZyBnb29kIElQdjQg c2VydmljZSBpcyB0aGUgbW9zdA0KPiA+aW1wb3J0YW50IHJlcXVpcmVtZW50LiBJbiBtYW55IGNh c2VzLCBpdCBpcyBwZXJmZWN0bHkgZmluZSB0byBub3QgcHJvdmlkZQ0KPiA+YW55IElQdjYgaWYg aXQgY2Fubm90IGJlIHByb3ZpZGVkIGF0IHJlYXNvbmFibGUgY29zdCAvIHBlcmZvcm1hbmNlLg0K Pg0KPiBJcyB0aGF0IHNhZmUgdG8gc2F5Pw0KDQpOby4NCg0KMjAlIG9mIG15IHN1YnNjcmliZXJz IGFyZSBpcHY2LW9ubHkgYW5kIGZvciB0aGVtIHRoZSBtYWpvcml0eSBvZiB0aGUgdHJhZmZpYyBp cyBpcHY2LiBGb3IgdGhlc2Ugc3Vic2NyaWJlcnMsIGl0IGlzIHF1YW50aXRhdGl2ZWx5IG1vc3Qg aW1wb3J0YW50IHRoYXQgaXB2NiB3b3Jrcy4gUXVhbGl0YXRpdmVseSwgaXQgaXMgbW9zdCBpbXBv cnRhbnQgdGhlIG1vc3QgaW1wYWN0ZnVsIHNlcnZpY2VzIGxpa2UgZmFjZWJvb2ssIGdvb2dsZSwg YW5kIG5ldGZsaXggd29yayBvbiBpcHY2Lg0KUmlnaHQuIEFuIG9wZXJhdG9yIGNhbm5vdCBhZmZv cmQgbm90IHRvIHByb3ZpZGUgSVB2NCwgYmVjYXVzZSAidGhhdCdzIG5vdCBJbnRlcm5ldCIuIEJ1 dCBpZiB0aGUgbWFqb3JpdHkgb2YgdHJhZmZpYyBpcyBJUHY2LCB0aGVuIHRoZSBvcGVyYXRvciBj YW4gcHJvdmlkZSBwcm9wb3J0aW9uYWxseSBsb3dlciBxdWFsaXR5IG9mIHNlcnZpY2UgdG8gSVB2 NCB3aXRob3V0IGRpc3J1cHRpbmcgdXNlciBleHBlcmllbmNlLg0KDQpBIDRHIGhhbmRzZXQgd2l0 aCA0NjR4bGF0IHdpbGwgaGF2ZSB+NTAlIG9mIHRyYWZmaWMgbmF0aXZlIElQdjYsIH40NSUgTkFU NjQsIGFuZCB+NSUgNDY0eGxhdC4gNDY0IGNvbnZlcnNpb24gaXMgbG9zc3kgYW5kIGJyaXR0bGUs IGJ1dCBpZiBpdCdzIG9ubHkgdXNlZCBmb3IgNSUgb2YgdHJhZmZpYywgdGhlbiB0aGUgb3BlcmF0 b3IgbWlnaHQganVzdCBzYXksICJXaG8gY2FyZXM/IEkgZG9uJ3Q7IGFuZCBpZiBzb21lYm9keSBl bHNlIGRvZXMsIHRoZXkncmUgZnJlZSB0byB1c2UgSVB2Ni4iDQoNCk5PVElDRSBBTkQgRElTQ0xB SU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVk IGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlz IGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFu eSBwdXJwb3NlLiAgDQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5n IGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBz dGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBm cm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1 cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0 ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBO dW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNl LCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVw0K --_000_6536E263028723489CCD5B6821D4B21303B7DB43UK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0K c3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjE3MTY4MDY3Nzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyNzgwODY4ODIgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4 MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAx MzQ4MDc1Nzk7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTc1OTIxMjI0MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTE4NTg3MTczNTQgLTE2Mjc5ODgzOTIgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMg MTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlz dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTk2ODEyMTk2MTsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk4NjY4MzAxOCAxMzQ4MDc1 NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4 MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIEkgbWF5IHN0aWNrIG15IG5lY2sgb3V0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SeKAmWQgbGlrZSB2Nm9wcyB0byBjb25zaWRlciBhdCBsZWFzdCB0d28gaXRlbXM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm80Ij48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oQ2FycmllciBHcmFkZSkgTkFUNjQgdnMgTkFUNDQg4oCT IGEgZGVhdGhtYXRjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SU1ITyBOQVQ2NCBzaG91bGQgYmUgZ3JlYXRlciBvciBlcXVhbCB0byBO QVQ0NCB3aGVuIGltcGxlbWVudGVkIGNvcnJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25seSBOQVQ2NCBjYW4gaGVscCB3aXRo IGJvdGggcHJpdmF0ZSBhbmQgcHVibGljIElQdjQgZXhoYXVzdGlvbi4gKE5vdGU6IEluIGNlbGx1 bGFyIG5ldHdvcmtzLCB3aGVyZSBOQVQgaXMgcHJldmFsZW50LCBwcml2YXRlIGV4aGF1c3Rpb24N CiBpcyBhIGJpZyBpc3N1ZSB0b2RheSwgZHJpdmluZyBJTVMgdG93YXJkIElQdjYtb25seSwgYW5k IGRhdGEgc2VydmljZXMgdG8gNDY0eGxhdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBhcyBoaWdobGlnaHRlZCBiZWxvdywgYSBt YWpvciBwcm9wb3J0aW9uIG9mIHRyYWZmaWMgZ29lcyBwdXJlIElQdjYsIHJlZHVjaW5nIHRoZSBs b2FkIG9uIHRoZSBOQVQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPldoeSBkbyBzb21lIHBlb3BsZSBzdGlsbCBmZWFyIE5BVDY0IG9yIHRo aW5rIHRoYXQgTkFUNDQgaXMgZ29pbmcgdG8gbW92ZSB0aGVtIGZvcndhcmQ/IE1UVSBpc3N1ZXMg Y2FuIGJlIGZpeGVkLiA2NCBBTEdzIGNhbiBtYXRjaGVkDQogNDQuIEnigJl2ZSBldmVuIGZpeGVk IEZUUCBpc3N1ZXMuIExpdGVyYWxzIGNhbiBiZSBmaXhlZCBhdCB0aGUgaG9zdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9sZGluZyBv biB0byB0aGUgTkFUNDQgYXJjaGl0ZWN0dXJlIHdoZXRoZXIgaW4gRHVhbCBTdGFjayYjNDM7TkFU NDQgb3Igb3RoZXJ3aXNlIHdpbGwga2VlcCB1cyBhbGwgaW4gdGhlIG9sZCB3b3JsZC4gSWYgeW91 IGFyZSBhIGxhcmdlDQogSVNQIHRoaW5raW5nIGFib3V0IHB1YmxpYyBleGhhdXN0aW9uLCBhbmQg eW91ciBwbGFuIGlzIHRvIGludHJvZHVjZSBwcml2YXRlcyAmIzQzOyBOQVQ0NCwgdGhlbiB0aGlu ayBvbiwgcGVyaGFwcyB5b3UgYXJlIGp1c3QgZXhjaGFuZ2luZyBvbmUgZXhoYXVzdGlvbiBkYXRl IGZvciBhbm90aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5BcyBpdCBzdGFuZHMgd2UgZG9u4oCZdCBoYXZlIGEgY29uc2Vuc3VzIGhl cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QSBwYXBlciB0byB1cGRhdGUgUkZDNjU4NiBhYm91dCB0aGUgZXhwZXJpZW5jZXMgb2Yg UENzIGFuZCBNb2JpbGUgZGV2aWNlcyBvbiA0NjR4bGF0IG5ldHdvcmtzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBzZWVtcyBhYm91dCB0aGUgcmlnaHQgdGltZSBmb3Ig dGhpcy4gUkZDNjU4NiBsZWZ0IHVzIHdpdGggc29tZSBjbGlmZiBoYW5nZXJzLiBEb2VzIDQ2NHhs YXQgZmluaXNoIHRoZSBqb2Igb2ZmPyBZZXMgb3Igbm8/IFdoZXJlIGFyZSB0aGUgZ2Fwcz8gKOKA nExvc3N5DQogYW5kIGJyaXR0bGXigJ0gZm9yIElQIGxpdGVyYWwgZGVzdGluYXRpb25zLCB3aGF0 IGRvZXMgdGhpcyBtZWFuPykgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGlzIHRoZSBjb21tb24gdGhlbWUgb2Yg dGhlIGFib3ZlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgc2VlbiB0aGlz IHdyaXR0ZW4gaW4gdGhlIGFic3RyYWN0IGZvciBzdW5zZXQ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IDxiPg0K U3Vuc2V0dGluZyBJUHY0IHJlZmVycyB0byB0aGUgcHJvY2VzcyBvZiB0dXJuaW5nIG9mZiBJUHY0 PG86cD48L286cD48L2I+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgZGVmaW5pdGl2ZWx5LiZuYnNwOyBJdCBjYW4gYmUgc2VlbiBhcyB0 aGUgZmluYWwgcGhhc2Ugb2YgdGhlIG1pZ3JhdGlvbiB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IElQdjYm bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5r IHRoZSB3b3JsZCBpcyByZWFkeSBmb3Igc3Vuc2V0dGluZyBJUHY0LCBpdCBhcHBlYXJzIGFuIGFj YWRlbWljIHRvcGljIHRvIG1hbnkuIEkgZG9u4oCZdCB0aGluayBpbiB2Nm9wcyB3ZSBhcmUgcXVp dGUgcmVhZHkgZm9yIHRoaXMgZmluYWwgcGhhc2Ugb2ZmDQogdHVybmluZyBvZmYgSVB2NCDigJxh cyBhIHNlcnZpY2XigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIgSSBk byB0aGluayB0aGVyZSBpcyBzb21lIGdhcCB0byBicmlkZ2UgaW4gdjZvcHMsIHNvbWUgaW50ZXJt ZWRpYXJ5IHBoYXNlIGJldHdlZW4gd2hlcmUgd2UgYXJlIG5vdyAoc3R1Y2sgaW4gZXF1aWxpYnJp dW0gd2l0aCBJUHY0IGRvbWluYW50KSwgYW5kIGEgcG9pbnQNCiB3aGVyZSB2NiBpcyB0aGUgZG9t aW5hbnQgYWRkcmVzcyBmYW1pbHkgb24gaG9zdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB0aGUgdGhlbWUgd291 bGQgYmUg4oCcdjYgZG9taW5hbnTigJ0sIGFuZCBpbiBpdCB3b3VsZCBiZSB0aGUgZXhoYXVzdGlv biBiZWF0aW5nIHRlY2hub2xvZ2llcywgdGhlIHRlY2hub2xvZ2llcyB0aGF0IHRoZSBJRVRGIHNo b3VsZCBjaGFtcGlvbiBiZWNhdXNlIGJlZm9yZSB3ZQ0KIGNhbiBldmVuIGNvbnNpZGVyIHR1cm5p bmcgb2ZmIHY0IHdlIG5lZWQgdG8gZ2V0IHRvIHN0YXRlIHdoZXJlIHRoZSBJUHY2IGFkZHJlc3Mg YXQgdGhlIGNsaWVudC9ob3N0IGlzIHRoZSBkb21pbmFudCBhZGRyZXNzIGZhbWlseSBmb3IgY29u bmVjdGl2aXR5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxldOKAmXMgZmFjZSBp dCwgaWYgeW91IGhhdmUgYSBuaWNlIHN0b2NrcGlsZSBvZiBwdWJsaWMgSVB2NCwgeW91IG1heSBu b3QgbmVlZCB0byBjYXJlIGFib3V0IElQdjYsIGFuZCBkdWFsc3RhY2sgbWlnaHQgZXZlbiBsb29r IGxpa2Ugc29tZSByYWRpY2FsIGFwcHJvYWNoLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkV2ZXJ5b25lIGVsc2UgbmVlZHMgdG8gY29sbGVjdGl2ZWx5IGRlYWwgd2l0aCBleGhhdXN0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvIHRoaW5rIHdlIGhhdmUgYSBs b3QgdG8gZG8gdG8gZ2V0IG91ciBjb2xsZWN0aXZlIHN0b3J5IHN0cmFpZ2h0IG9uIHRoaXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgcGFwZXJzIGFib3ZlIHdvdWxkIGhl bHAuIFRoZXJlIG1pZ2h0IGJlIG1vcmUgYWRkcmVzcyBzYXZpbmcgdGVjaG5pcXVlcyB0byBhZGQg dG8gdGhlIGxpc3QgZm9yIOKAnGV4cGVyaWVuY2XigJ0gZG9jdW1lbnRzLCBwZXJoYXBzPw0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5ldyBpZGVhcyBoZXJlPyBJZiBldmVyeSBDbGll bnQgT1MgaGFkIHNvbWUgaW5idWlsdCBmdW5jdGlvbiB0byBhbGxvdyBpdCB0byBmdW5jdGlvbiB3 aGVuIHRoZSBuZXR3b3JrIGNhbiBvbmx5IHByb3ZpZGUgaXQgYW4gSVB2NiBwcmVmaXggdGhlbiB3 aGF0IHdvdWxkIHRoYXQNCiBiZT8gQ291bGQgaXQgcmVtYWluIGRvcm1hbnQgdW50aWwgcmVxdWly ZWTigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhvdWdodHM/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk5pY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IDA3IEF1Z3VzdCAyMDE0IDE0OjEzPGJy Pg0KPGI+VG86PC9iPiBDYSBCeTxicj4NCjxiPkNjOjwvYj4gVG9yZSBBbmRlcnNvbjsgSVB2NiBP cHMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gT3BlcmF0aW9uYWwgQ29uc2Vu c3VzIG9uIGRlcGxveW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFRodSwgQXVnIDcsIDIwMTQgYXQgMTA6MDYgUE0sIENhIEJ5ICZsdDs8 YSBocmVmPSJtYWlsdG86Y2IubGlzdDZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2IubGlz dDZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHA+Jmd0 OyAmZ3Q7SSB0aGluayBpdCBpcyBzYWZlIHRvIHNheSB0aGF0IHByb3ZpZGluZyBnb29kIElQdjQg c2VydmljZSBpcyB0aGUgbW9zdDxicj4NCiZndDsgJmd0O2ltcG9ydGFudCByZXF1aXJlbWVudC4g SW4gbWFueSBjYXNlcywgaXQgaXMgcGVyZmVjdGx5IGZpbmUgdG8gbm90IHByb3ZpZGU8YnI+DQom Z3Q7ICZndDthbnkgSVB2NiBpZiBpdCBjYW5ub3QgYmUgcHJvdmlkZWQgYXQgcmVhc29uYWJsZSBj b3N0IC8gcGVyZm9ybWFuY2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgSXMgdGhhdCBzYWZlIHRvIHNh eT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+Tm8uIDxvOnA+PC9vOnA+PC9wPg0KPHA+MjAl IG9mIG15IHN1YnNjcmliZXJzIGFyZSBpcHY2LW9ubHkgYW5kIGZvciB0aGVtIHRoZSBtYWpvcml0 eSBvZiB0aGUgdHJhZmZpYyBpcyBpcHY2LiBGb3IgdGhlc2Ugc3Vic2NyaWJlcnMsIGl0IGlzIHF1 YW50aXRhdGl2ZWx5IG1vc3QgaW1wb3J0YW50IHRoYXQgaXB2NiB3b3Jrcy4gUXVhbGl0YXRpdmVs eSwgaXQgaXMgbW9zdCBpbXBvcnRhbnQgdGhlIG1vc3QgaW1wYWN0ZnVsIHNlcnZpY2VzIGxpa2Ug ZmFjZWJvb2ssIGdvb2dsZSwgYW5kIG5ldGZsaXgNCiB3b3JrIG9uIGlwdjYuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQuIEFuIG9wZXJhdG9yIGNhbm5v dCBhZmZvcmQgbm90IHRvIHByb3ZpZGUgSVB2NCwgYmVjYXVzZSAmcXVvdDt0aGF0J3Mgbm90IElu dGVybmV0JnF1b3Q7LiBCdXQgaWYgdGhlIG1ham9yaXR5IG9mIHRyYWZmaWMgaXMgSVB2NiwgdGhl biB0aGUgb3BlcmF0b3IgY2FuIHByb3ZpZGUgcHJvcG9ydGlvbmFsbHkgbG93ZXIgcXVhbGl0eSBv ZiBzZXJ2aWNlIHRvIElQdjQgd2l0aG91dCBkaXNydXB0aW5nIHVzZXIgZXhwZXJpZW5jZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSA0RyBo YW5kc2V0IHdpdGggNDY0eGxhdCB3aWxsIGhhdmUgfjUwJSBvZiB0cmFmZmljIG5hdGl2ZSBJUHY2 LCB+NDUlIE5BVDY0LCBhbmQgfjUlIDQ2NHhsYXQuIDQ2NCBjb252ZXJzaW9uIGlzIGxvc3N5IGFu ZCBicml0dGxlLCBidXQgaWYgaXQncyBvbmx5IHVzZWQgZm9yIDUlIG9mIHRyYWZmaWMsIHRoZW4g dGhlIG9wZXJhdG9yIG1pZ2h0IGp1c3Qgc2F5LCAmcXVvdDtXaG8gY2FyZXM/IEkgZG9uJ3Q7IGFu ZCBpZiBzb21lYm9keQ0KIGVsc2UgZG9lcywgdGhleSdyZSBmcmVlIHRvIHVzZSBJUHY2LiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cg0KPFA+Tk9USUNFIEFORCBESVNDTEFJTUVSPEJSPlRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55 IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCANCmZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMp LiZuYnNwOyBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCANCm5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVt IGFuZCBkbyBub3QgDQpkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiZuYnNwOyA8QlI+ Jm5ic3A7PEJSPldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyANCmFuZCBvdXRnb2luZyBlbWFp bHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMg dG8gDQplbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9t IGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgDQp5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3Vy ZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91LiA8L1A+DQo8UD5FRSBM aW1pdGVkPEJSPlJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXM8QlI+Q29tcGFueSBSZWdp c3RlcmVkIE51bWJlcjogDQowMjM4MjE2MTxCUj5SZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBU cmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCANCkhlcnRmb3Jkc2hpcmUsIEFM MTAgOUJXPC9QPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6536E263028723489CCD5B6821D4B21303B7DB43UK30S005EXS06EE_-- From nobody Tue Aug 19 07:37: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 E02A51A890C; Tue, 19 Aug 2014 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv0d5NRxN_4w; Tue, 19 Aug 2014 07:37:15 -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 E3ACE1A0382; Tue, 19 Aug 2014 07:37:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XJkXA-0000SGC; Tue, 19 Aug 2014 16:37:12 +0200 Message-Id: To: Roland Dobbins From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> In-reply-to: Your message of "Tue, 19 Aug 2014 20:23:54 +0700 ." <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> Date: Tue, 19 Aug 2014 16:37:11 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i7uPDU6WznGF5fktXlKwEDqHpxY Cc: "opsec@ietf.org" , IPv6 Operations Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:37:17 -0000 In your letter dated Tue, 19 Aug 2014 20:23:54 +0700 you wrote: >On Aug 19, 2014, at 8:18 PM, Jeroen Massar wrote: > >> - The ICMP error packet's destination address must qualify uRPF rules for= > the same interface as the source address.[1] > >Should this language be limited to uRPF, or should it include other anti-spoofing >mechanisms, as well? At least for TCP it is relatively easy for the host to check whether the sequence numbers make sense. If they don't, discard the error ICMP. From nobody Tue Aug 19 07:51:48 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 4EDB51A891F; Tue, 19 Aug 2014 07:51:45 -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 g900IMSb-OL1; Tue, 19 Aug 2014 07:51:43 -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 1F3971A03AC; Tue, 19 Aug 2014 07:51:43 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJkkq-0004e3-Kw; Tue, 19 Aug 2014 16:51:41 +0200 Message-ID: <53F36432.8090108@si6networks.com> Date: Tue, 19 Aug 2014 11:50: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: "6man@ietf.org" <6man@ietf.org> References: <20140819144703.13248.62145.idtracker@ietfa.amsl.com> In-Reply-To: <20140819144703.13248.62145.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140819144703.13248.62145.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/okcIJ5K9f0bjlSWjovk3iOa1wR4 Cc: IPv6 Operations Subject: [v6ops] Deprecating the Generation of IPv6 Atomic Fragments (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:51:45 -0000 Folks, FYI, this is our Std-track "patch" to fix this: Comments welcome ;-) Thanks! Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt Date: Tue, 19 Aug 2014 07:47:03 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Will(Shucheng) Liu , Fernando Gont , Shucheng LIU (Will) A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-deprecate-atomfrag-generation Revision: 00 Title: Deprecating the Generation of IPv6 Atomic Fragments Document date: 2014-08-19 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/ Htmlized: http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00 Abstract: The core IPv6 specification requires that when a host receives an ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller than 1280, the host includes a Fragment Header in all subsequent packets sent to that destination, without reducing the assumed Path- MTU. The simplicity with which ICMPv6 "Packet Too Big" messages can be forged, coupled with the widespread filtering of IPv6 fragments, results in an attack vector that can be leveraged for Denial of Service purposes. This document briefly discusses the aforementioned attack vector, and formally deprecates the generation of IPv6 atomic fragments, such that the aforementioned attack vector is eliminated. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Aug 19 07:53: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 538F51A03AC for ; Tue, 19 Aug 2014 07:53: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 zWBK64qiDDW2 for ; Tue, 19 Aug 2014 07:53:39 -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 A9A6D1A8906 for ; Tue, 19 Aug 2014 07:53:38 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJkn2-0004f8-KD; Tue, 19 Aug 2014 16:53:36 +0200 Message-ID: <53F364E9.4050507@si6networks.com> Date: Tue, 19 Aug 2014 11:53:29 -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: Simon Perreault References: <53F33C4F.2070807@si6networks.com> <53F33E78.4070402@foobar.org> <53F33F9F.3050705@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0YaQT9xPKN8vUGkQu7mvCmekABY Cc: IPv6 Operations Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:53:41 -0000 On 08/19/2014 09:41 AM, Simon Perreault wrote: > Nice. > > Without relying on fragments being blocked, would it be possible to > practically DoS someone by setting the MTU to a crazy low value (e.g., > 1)? Would this be mitigated by standards and/or implementations? Yes, this is supposed to be mitigated, since Sect 5 of RFC2460 says that you don't need to reduce the Path-MTU when the reported Next-Hop MTU is smaller than 1280 bytes. > Should we start requiring that MTU < 1280 be rejected? Yes: (but also in filters) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 07:59: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 8FE421A03DF; Tue, 19 Aug 2014 07:59: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 8jxV3cYY6Uxw; Tue, 19 Aug 2014 07:59:04 -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 149391A03C8; Tue, 19 Aug 2014 07:59:04 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJks8-0004jE-JT; Tue, 19 Aug 2014 16:58:54 +0200 Message-ID: <53F36622.1000503@si6networks.com> Date: Tue, 19 Aug 2014 11:58:42 -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: Philip Homburg , Roland Dobbins References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UUBJmjcmcj5-T5RxDyIcp9Rg7bA Cc: "opsec@ietf.org" , IPv6 Operations Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:59:09 -0000 On 08/19/2014 11:37 AM, Philip Homburg wrote: >> >>> - The ICMP error packet's destination address must qualify uRPF rules for= >> the same interface as the source address.[1] >> >> Should this language be limited to uRPF, or should it include other anti-spoofing >> mechanisms, as well? > > At least for TCP it is relatively easy for the host to check whether the sequence > numbers make sense. If they don't, discard the error ICMP. mmm.. not really... check this (from ): 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. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 09: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 56E6E1A0645; Tue, 19 Aug 2014 09:17:31 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 561sFjRQGxB9; Tue, 19 Aug 2014 09:17:29 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F231A063E; Tue, 19 Aug 2014 09:17:28 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id D213310038DA0; Tue, 19 Aug 2014 16:17:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408465046; bh=YpedaDIl0LGDhDO4gIXOej0pxTSbA4PM4WBmMZYj9gI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=RVcwhEqiM+tDx+oc7tVEIFkxI4SM+CABoKGMRJc0r4W9pUxz21pSuL7UzDf5CuCmw DFd8RlLMi/RVmhD1AlAOmj7FdMmEa6mR+WD5hFLsq84CBwm/aG/G25YgNwyARC0Gzo n/2x78f05hl7QfqBaPlRb+g/ToCABO2vXcGgHrxZNOeA6FwiDZTiavH5OSwjZZ/Zrg QTlHMoz1GwbTogaAe33MXsakAQCg9ZYZQDGDDZtRXyZ848q58Gzp+4fZsj9IEjcHVF jqN1Ft3/SdYk4tdrO9Rc5WBWYz2Zw3abmPbsJmPBMI163Bi8/3YI3zkd7PlyLaGbuj MToTDqB0FXPKA== Message-ID: <53F37885.9040903@massar.ch> Date: Tue, 19 Aug 2014 18:17:09 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Nick Hilliard , Fernando Gont , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F35AE0.2040304@foobar.org> In-Reply-To: <53F35AE0.2040304@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_EzMK6KaPlDrFgISSgLJPi4CgRg Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:17:31 -0000 On 2014-08-19 16:10, Nick Hilliard wrote: > On 19/08/2014 14:18, Jeroen Massar wrote: >> But also for ICMPv4, which has similar attacks. > > no, it doesn't because in general ipv4 fragments are not dropped. Also, > ipv4 handles this by fragmenting en-route rather than sending PTB packets > to the source. Note the word 'similar' in that sentence. While that specific fragmented attack won't work, one can still spoof return ICMPs and give wrong answers. Anyone remember Rotorouter[1] ? :) Hence, why it is a good idea to do the same checks for IPv4 too and why I avoid mentioning what kind of attack it was solving. It is just good hygiene to check validity of things. Greets, Jeroen [1] http://www.shmoo.com/mail/bugtraq/aug98/msg00110.html From nobody Tue Aug 19 09:18: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 E69221A7014; Tue, 19 Aug 2014 09:18:11 -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 MF5jckA-S5in; Tue, 19 Aug 2014 09:18:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 269F81A6FCF; Tue, 19 Aug 2014 09:18:02 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819161802.22471.669.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 09:18:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8I30jO3GTd-5CUh61hGpUtv6JVA Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Enterprise IPv6 Deployment Guidelines' to Informational RFC (draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:18:12 -0000 The IESG has approved the following document: - 'Enterprise IPv6 Deployment Guidelines' (draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ipv6/ Technical Summary This document summarizes a proposed framework for enterprise network architects and administrators as they plan the introduction of IPv6 support in their environments, specifically dual stack and eventually IPv6 only. Working Group Summary This draft was first submitted as draft-ietf-v6ops-enterprise-incremental-ipv6-00.txt in August 2012. The document has been revised several times since introduced. The document outlines considerations, both technical and logistical, that enterprise adopters of IPv6 should consider as they advance or even begin introducing support for IPv6 across their respective enterprises. The draft has been discussed at length and in detail. Document Quality As specified in the abstract, the document is not a protocol or procedure; the document outlines topics that enterprise adopters should consider when planning for the adoption of IPv6. The document touches on areas that would be typically be present when planning an IPv6 adoption project so several are the items focus on non-technical aspects of an enterprise IPv6 deployment. Personnel The document shepherd is John Jason Brzozowski. The responsible AD is Joel Jaegli. From nobody Tue Aug 19 09:30: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 6D3321A066A; Tue, 19 Aug 2014 09:30:15 -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 jx6fIQSTu5WE; Tue, 19 Aug 2014 09:30:12 -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 3C9901A0640; Tue, 19 Aug 2014 09:30:12 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJmIT-00054V-30; Tue, 19 Aug 2014 18:30:09 +0200 Message-ID: <53F37A7F.8020708@si6networks.com> Date: Tue, 19 Aug 2014 13:25:35 -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: Jeroen Massar , Nick Hilliard , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F35AE0.2040304@foobar.org> <53F37885.9040903@massar.ch> In-Reply-To: <53F37885.9040903@massar.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NC84CIbBgME6f4wY0fK-oBe0MOs Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:30:15 -0000 On 08/19/2014 01:17 PM, Jeroen Massar wrote: > > While that specific fragmented attack won't work, one can still spoof > return ICMPs and give wrong answers. > > Anyone remember Rotorouter[1] ? :) > > Hence, why it is a good idea to do the same checks for IPv4 too and why > I avoid mentioning what kind of attack it was solving. It is just good > hygiene to check validity of things. FWIW, I had posted this thingy a while ago: -- essentially BCP38 on the ICMPv4 payload.. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 09:34: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 8CA111A05F5; Tue, 19 Aug 2014 09:34: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 JHNF5InF8zhE; Tue, 19 Aug 2014 09:34: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 A37F51A6FCF; Tue, 19 Aug 2014 09:34:20 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJmMV-00056N-1j; Tue, 19 Aug 2014 18:34:19 +0200 Message-ID: <53F37C72.6040406@si6networks.com> Date: Tue, 19 Aug 2014 13:33:54 -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: Jeroen Massar , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> In-Reply-To: <53F34EC0.30400@massar.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/791q26D6pPdbPknaMRS9Hs-LCK4 Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:34:21 -0000 Hello, Jeroen, On 08/19/2014 10:18 AM, Jeroen Massar wrote: > Hence we should formulate text a bit like: > > 8<------------------------ > When forwarding or receiving an ICMP error packet: > - The IP destination of the packet MUST match the source address > represented in the ICMP error packet. > > - The ICMP error packet's destination address must qualify uRPF rules > for the same interface as the source address.[1] > > As the verified packets are ICMP errors, when the verification fails the > packet MUST be dropped, logging is recommended. > > Due to the checking inside the ICMP portion of a packet: > Access-routers, firewalls and hosts MUST perform these checks. > Core-routers SHOULD perform these checks > > [1] When ICMP-dst address matches IP-src the check should already have > been performed by the standard uRPF check. > ------------------------>8 Should we include something alng this lines to the countermeasures listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking about something else? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 09:49: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 6FC221A04F1; Tue, 19 Aug 2014 09:48: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAnihqUR5A0D; Tue, 19 Aug 2014 09:48:57 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5C01A0650; Tue, 19 Aug 2014 09:48:56 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 09FC810034BE7; Tue, 19 Aug 2014 16:48:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408466933; bh=2Y7S/GVTibKjrrPfWqWxatouUSki6OGtN8+4knEk414=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=fsZY1T0DG1StynpMHM0iO9Ti/2tcWD1Jl9wabtyX9eoJUKk3duAdqno9iL/CsemOS Z3NLEBvWQumPJKNWEPydTmj4mWMGIWbT4/u1dfIH9cEC5jbj9v16NSNi4H5216QsqZ FCOyEF5ffYV+0pG3eMvyCTAEOv7uD0kcumC6PmtI6ebcR3ctJtQxtkp4/q6GFdhdjS Po7IXzI34GcPnipGWYv/LnQ9opUzz8LtOWHiHc96p3djBhcA96hme6TZLp6qsLdk2u GRdAIgeHsOxgmxurgXXOkNWLhFd3LLQLzCwYWRpMjluGZtB2d83FTCf5PaXydY6fKi 8qvC/uKr5SQGQ== Message-ID: <53F37FE6.6080306@massar.ch> Date: Tue, 19 Aug 2014 18:48:38 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Fernando Gont , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F37C72.6040406@si6networks.com> In-Reply-To: <53F37C72.6040406@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yP_WppkUAgGvAA-OmvpC_tuYYfs Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:48:58 -0000 [merging two different replies back into one] On 2014-08-19 18:33, Fernando Gont wrote: > Hello, Jeroen, > > On 08/19/2014 10:18 AM, Jeroen Massar wrote: >> Hence we should formulate text a bit like: >> >> 8<------------------------ >> When forwarding or receiving an ICMP error packet: >> - The IP destination of the packet MUST match the source address >> represented in the ICMP error packet. >> >> - The ICMP error packet's destination address must qualify uRPF rules >> for the same interface as the source address.[1] >> >> As the verified packets are ICMP errors, when the verification fails the >> packet MUST be dropped, logging is recommended. >> >> Due to the checking inside the ICMP portion of a packet: >> Access-routers, firewalls and hosts MUST perform these checks. >> Core-routers SHOULD perform these checks >> >> [1] When ICMP-dst address matches IP-src the check should already have >> been performed by the standard uRPF check. >> ------------------------>8 > > Should we include something alng this lines to the countermeasures > listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking > about something else? While it kind-of has a place there, (ipv6-ehs-in-real-world) is a "current state of the Internet" regarding this problem, it thus introduces the problem. Hence, a short, separate document which updates ICMPv4 + ICMPv6 referencing that draft would be more appropriate IMHO. Especially as then it is quicker for implementers to see what they need to get done to solve the issue. Hence, a short intro with "this is the problem: ....; for more detail see draft-X + RFC5927" + "do this in your ICMPv4/v6 stacks" would be a good start. Then we might be able to get it quickly into at least Linux and BSD kernels which is what most access-router/firewalls are being built upon. On 2014-08-19 18:25, Fernando Gont wrote: > On 08/19/2014 01:17 PM, Jeroen Massar wrote: >> >> While that specific fragmented attack won't work, one can still spoof >> return ICMPs and give wrong answers. >> >> Anyone remember Rotorouter[1] ? :) >> >> Hence, why it is a good idea to do the same checks for IPv4 too >> and why I avoid mentioning what kind of attack it was solving. >> It is just good hygiene to check validity of things. > > FWIW, I had posted this thingy a while ago: > > -- essentially BCP38 on the ICMPv4 payload.. aka RFC 5927, though only informational even though it went through WG review it seems. That indeed touches upon the subject quite a bit too, and would be a good thing to reference from a draft dubbed: "ICMPv4 + ICMPv6 Address Verification" Greets, Jeroen From nobody Tue Aug 19 10:19: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 C49E31A04E9; Tue, 19 Aug 2014 10:19:45 -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 BJX9yc70ZEZf; Tue, 19 Aug 2014 10:19:43 -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 8C57D1A048D; Tue, 19 Aug 2014 10:19:43 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJn4N-0005F5-QH; Tue, 19 Aug 2014 19:19:40 +0200 Message-ID: <53F386F2.2060900@si6networks.com> Date: Tue, 19 Aug 2014 14:18:42 -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: Jeroen Massar , IPv6 Operations References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F37C72.6040406@si6networks.com> <53F37FE6.6080306@massar.ch> In-Reply-To: <53F37FE6.6080306@massar.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OA48prqO6ydrP0XnQKo7FERPAAI Cc: "'opsec@ietf.org'" Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:19:45 -0000 On 08/19/2014 01:48 PM, Jeroen Massar wrote: >> Should we include something alng this lines to the countermeasures >> listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking >> about something else? > > While it kind-of has a place there, (ipv6-ehs-in-real-world) is a > "current state of the Internet" regarding this problem, it thus > introduces the problem. > > Hence, a short, separate document which updates ICMPv4 + ICMPv6 > referencing that draft would be more appropriate IMHO. Ok, makes sense. >>> Hence, why it is a good idea to do the same checks for IPv4 too >>> and why I avoid mentioning what kind of attack it was solving. >>> It is just good hygiene to check validity of things. >> >> FWIW, I had posted this thingy a while ago: >> >> -- essentially BCP38 on the ICMPv4 payload.. > > aka RFC 5927, though only informational even though it went through WG > review it seems. It took 7 years to publish... and not because of slacking. It was insane. :-) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 10:58: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 617721A0665; Tue, 19 Aug 2014 10:58:04 -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 MmarFEBdiCZ3; Tue, 19 Aug 2014 10:58:03 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c: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 DD99F1A065F; Tue, 19 Aug 2014 10:58:02 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so6819062wev.13 for ; Tue, 19 Aug 2014 10:58:01 -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=OEJe297rAinQyx6hjtS3gYSrxW5i18ysPS+q8oxDjww=; b=dBTiE8W2XaG0rZV24Akw4F0k+KsUQMydUM25nVd24OzezMcbnzYPCTuFEgq92dG43O PUj89DyBRvUQucDBguW93Z5XHIHcYOUedB/UUmera8bqazjpngwHjLH1xO/yGAiWJEPO GNTOaRjpLMngp1Qaxsm09VTnuvHZSnW8ADKhL7G81QXt5xk3pFoLOslJWFXV3Lsutaoc MhXofD3Neq4HoQ9QOPV5SAA0FPhcTPUnnXZnpNvsRJkoFhlFBaGhiebdoFOP32N4kuzr v+WNt5E9wDMgu1UC+yoE7t0Cv6uDu4C6wLiIKlGs41uehD/U6RhPzyJT/twb4+y+yqb8 9KOw== MIME-Version: 1.0 X-Received: by 10.180.80.133 with SMTP id r5mr8548105wix.62.1408471081403; Tue, 19 Aug 2014 10:58:01 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Tue, 19 Aug 2014 10:58:01 -0700 (PDT) In-Reply-To: <53F33C4F.2070807@si6networks.com> References: <53F33C4F.2070807@si6networks.com> Date: Tue, 19 Aug 2014 10:58:01 -0700 X-Google-Sender-Auth: QFtG_KIiw0MDqLS6Z27ZyGjwiXM Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A9XltD9_8XywseXFpTeHRZLEtBg Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:58:04 -0000 At Tue, 19 Aug 2014 09:00:15 -0300, Fernando Gont wrote: > you could essentially DoS traffic between them > > As noted in the I-D, the mitigations seem to be: > > 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 > PTB, or, > > 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU > smaller than 1280. > > Thoughts? In my general understanding, ICMPv6 PTB with the MTU < 1280 could be only (at least in practice) used for the "stateless" type of IPv4/v6 translators so that the IPv6-only host can give the translator a hint for the 16-bit IPv4 header ID value. Am I correct? If so, one possible alternative would be to drop such ICMPv6 PTB unless the source IPv6 address is one of those reserved for such use (as defined in RFC 6052). Then we can at least reduce the problem to source address spoofing. And, unless/until we heavily rely on such types of translators, this may be actually sufficient in practice, since in the vast majority of legitimate cases we should use different addresses than those special ones. -- JINMEI, Tatuya From nobody Tue Aug 19 11:11: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 A4D3F1A0684; Tue, 19 Aug 2014 11:11:18 -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 9KfcaTPn4Ysh; Tue, 19 Aug 2014 11:11: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 F34AB1A066D; Tue, 19 Aug 2014 11:11:13 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJnsE-0005PR-EB; Tue, 19 Aug 2014 20:11:10 +0200 Message-ID: <53F3931F.9050601@si6networks.com> Date: Tue, 19 Aug 2014 15:10: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: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <53F33C4F.2070807@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yzeyAc660ghlNQXRwvn6rrmRLqI Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 18:11:18 -0000 Hi, Jinmei, On 08/19/2014 02:58 PM, 神ćŽé”哉 wrote: >> As noted in the I-D, the mitigations seem to be: >> >> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 >> PTB, or, >> >> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU >> smaller than 1280. >> >> Thoughts? > > In my general understanding, ICMPv6 PTB with the MTU < 1280 could be > only (at least in practice) used for the "stateless" type of IPv4/v6 > translators so that the IPv6-only host can give the translator a hint > for the 16-bit IPv4 header ID value. Am I correct? Yes. (That's the theory, at least. Me, I'd say that the host is really in no better position than the translator to pick a Frag ID... actually, it's in a much worse position). > If so, one possible alternative would be to drop such ICMPv6 PTB > unless the source IPv6 address is one of those reserved for such use > (as defined in RFC 6052). Source of the ICMPv6 message? If so, I'd say that while that's certainly better than the current situation, unless there's widespread deployment of BCP38, an attacker could still forge an ICMPv6 with one of such addresses and still perform the attack.. > Then we can at least reduce the problem to > source address spoofing. And, unless/until we heavily rely on such > types of translators, this may be actually sufficient in practice, > since in the vast majority of legitimate cases we should use different > addresses than those special ones. I must say that I fail to see the need for generating IPv6 atomic fragments 8packets with a frag header, which are not really fragmented). See e.g. what we wrote in . Thoughts? 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 Tue Aug 19 15:30: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 3316A1A6F6B for ; Tue, 19 Aug 2014 15:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 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.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 Z2k-3WDdA6K6 for ; Tue, 19 Aug 2014 15:30:01 -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 91DAD1A6F2A for ; Tue, 19 Aug 2014 15:30:01 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so1894326ieb.7 for ; Tue, 19 Aug 2014 15:30:01 -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=z+p06hkbOpbL8qP3g0YBEKxiGqu8dq3ibLtFfF3EVvM=; b=gYRKZNrINFpwPaK3Oks17p6DUjO4lq201dJx608GrtsaqkffztW8HUxRBpPY8vtRqj FK4DBugMs025Nz/uTGxfCpWJy0GXCTRM4C41tkHV3OCiMLJuxNJtPov5dpIr3ug8alBz Vxsv4vw1Cex8aOhuKk0KlayZL3abQNXcAgjGv/F4LgY0hpSsZC0LCLB9IOe6DWYne0ZG dtpG379XWYEg6FDylOIPL3XveBfY5Izj3A+eGjFwBEwIQAfO+hSE4lf/aTcJE2ptsD9S nVlx9EiSxbGGlgI4rVxLsLSQzslibkcP0mQZUtqGijkSr0RmWSaPTvyhMShP7Gg0ftlS nPsA== 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=z+p06hkbOpbL8qP3g0YBEKxiGqu8dq3ibLtFfF3EVvM=; b=akLbrGlTNeC0PnPUSObwzutl0MOwYWDxvQK+4iYS0mbsHuYMX2JiEZ6P89YlmpvQH3 bOOVCpDllWK/Ym5qDPxUu6S+Zq0+kNvlZHVH3tbp/PLj6Hpqv8acX6iOue93T+W+kgEJ pFFXmCQCzNmTWV5wRLHd76DkIc/IV0j4fv98VpfgySkuTjhYZBJknKm6T1jzo/HxjTyt oxy8LrYPMHfDXAA34d8uDoD/EiuALkF//9cqzUZ+AgCSifv4YJlMt7MqO/mvXt0cyfF1 JG+1kQ/Q0APNhdlIhKT7mb+rvul+i+ZIWh6T4CBQEoUDtTha0gLNUVoNJcz1zWH+Hh7V 49iQ== X-Gm-Message-State: ALoCoQkS559SG2M1n/WAiu7HtqaVTcWYHZJvcLkDgYB4dgbFKCE8exCCcnlS15t8dqRIUgZXGVZ6 X-Received: by 10.50.143.101 with SMTP id sd5mr9169419igb.18.1408487400902; Tue, 19 Aug 2014 15:30:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.103 with HTTP; Tue, 19 Aug 2014 15:29:40 -0700 (PDT) In-Reply-To: <53F3931F.9050601@si6networks.com> References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> From: Lorenzo Colitti Date: Tue, 19 Aug 2014 15:29:40 -0700 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a1134bad033b15e05010307f1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OU6t6Uy5MuT8uQTW-NwwQ3sXN18 Cc: IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:30:03 -0000 --001a1134bad033b15e05010307f1 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont wrote: > I must say that I fail to see the need for generating IPv6 atomic > fragments 8packets with a frag header, which are not really fragmented). > See e.g. what we wrote in > < > http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00 > >. > It does seem kind of silly that we say "you must support MTU >= 1280 to run IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't simply say that PTB packets < 1280 are invalid? --001a1134bad033b15e05010307f1 Content-Type: text/html; charset=UTF-8
On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont <fgont@si6networks.com> wrote:
I must say that I fail to see the need for generating IPv6 atomic
fragments 8packets with a frag header, which are not really fragmented).
See e.g. what we wrote in
<http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00>.

It does seem kind of silly that we say "you must support MTU >= 1280 to run IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't simply say that PTB packets < 1280 are invalid?
--001a1134bad033b15e05010307f1-- From nobody Tue Aug 19 15:39: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 12E3A1A03DF; Tue, 19 Aug 2014 08:14:46 -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 D0Z3AjqAXyEd; Tue, 19 Aug 2014 08:14:44 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147391A03BD; Tue, 19 Aug 2014 08:14:44 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id i138so4663130oig.5 for ; Tue, 19 Aug 2014 08:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BqeXDf8B8BqNYbKcYmPhdZbXvTtjL7dxbNCJIHF1+VE=; b=Hye3VOmDA03BH3mbAX3NMbuhDANc4aZvCJrDl9ENOO6C2UTM6CH5clTbVK8Z8QrWTR Fu1mXOmlU07Dcdh++okQ9etXms6KYdk8cBs5tMjnXHUTOZL++Lekull90OLQOupHZxor rYT1A8aqA0ChtTQqCj/U74NNDdWfc4QJA6zcfmhdd0U2PUiw5GmLfcZg5VuiX1cxWP2i KRlDb7fm3HlWMyLFMyFLr5OfZdKvjqxUo6GPhRejFGRqcT89qp3vCidstuI3RgQjR87I is9dol5H+YiikQ7QrNHq6yd9FwXF97uRsy/E65sqCgNP2GZeX97qZeGvnnYOif3BOE8J 7c6w== MIME-Version: 1.0 X-Received: by 10.182.112.134 with SMTP id iq6mr42751248obb.34.1408461283451; Tue, 19 Aug 2014 08:14:43 -0700 (PDT) Received: by 10.202.206.212 with HTTP; Tue, 19 Aug 2014 08:14:43 -0700 (PDT) In-Reply-To: <53F36432.8090108@si6networks.com> References: <20140819144703.13248.62145.idtracker@ietfa.amsl.com> <53F36432.8090108@si6networks.com> Date: Tue, 19 Aug 2014 18:14:43 +0300 Message-ID: From: Antonios Atlasis To: Fernando Gont , 6man@ietf.org Content-Type: multipart/alternative; boundary=089e0149cf607aec600500fcf270 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dJTxJCUou-HfV_ZfPB6FO7p3log X-Mailman-Approved-At: Tue, 19 Aug 2014 15:39:48 -0700 Cc: v6ops@ietf.org Subject: Re: [v6ops] Deprecating the Generation of IPv6 Atomic Fragments (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:14:46 -0000 --089e0149cf607aec600500fcf270 Content-Type: text/plain; charset=UTF-8 Hi, regarding the second paragraph of section 5, I thought that the fragment ID, included both in the IPv6 atomic fragments (the half of the ID actually) and in the IPv4 header was necessary to track the end-to-end connection. If a fragment ID is used only in the IPv4 part of the end-to-end path, how does IPv6-to-IPv4 translation node is going to track the end-to-end connection? Unless I miss sthg here. Best Antonios 2014-08-19 17:50 GMT+03:00 Fernando Gont : > Folks, > > FYI, this is > < > http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt > > > our Std-track "patch" to fix this: > > > Comments welcome ;-) > > Thanks! > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-6man-deprecate-atomfrag-generation-00.txt > Date: Tue, 19 Aug 2014 07:47:03 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , Will(Shucheng) Liu > , Fernando Gont , > Shucheng LIU (Will) > > > A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-6man-deprecate-atomfrag-generation > Revision: 00 > Title: Deprecating the Generation of IPv6 Atomic Fragments > Document date: 2014-08-19 > Group: Individual Submission > Pages: 7 > URL: > > http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt > Status: > > https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/ > Htmlized: > http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00 > > > Abstract: > The core IPv6 specification requires that when a host receives an > ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller > than 1280, the host includes a Fragment Header in all subsequent > packets sent to that destination, without reducing the assumed Path- > MTU. The simplicity with which ICMPv6 "Packet Too Big" messages can > be forged, coupled with the widespread filtering of IPv6 fragments, > results in an attack vector that can be leveraged for Denial of > Service purposes. This document briefly discusses the aforementioned > attack vector, and formally deprecates the generation of IPv6 atomic > fragments, such that the aforementioned attack vector is eliminated. > > > > > > 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 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ===================== Antonios Atlasis, PhD, MPhil GXPN, GREM, GPEN, GWAPT, CCIH, GCIA --089e0149cf607aec600500fcf270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

regarding the second para= graph of section 5, I thought that the fragment ID, included both in the IP= v6 atomic fragments (the half of the ID actually) and in the IPv4 header wa= s necessary to track the end-to-end connection. If a fragment ID is used on= ly in the IPv4 part of the end-to-end path, how does IPv6-to-IPv4 translati= on node is going to track the end-to-end connection? Unless I miss sthg her= e.

Best

Antonios

2014-08-19 17:50 GMT+03:00 Fernando Gont <= span dir=3D"ltr"><fgont@si6networks.com>:
Folks,

FYI, this is
<http://www.ietf.org/interne= t-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt>
our Std-track "patch" to fix this:
<http://www.ietf.org/mail-archive/web/v6ops/current/= msg19746.html>

Comments welcome ;-)

Thanks!
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-6man-deprecate-atomfrag-generation-00.txt
Date: Tue, 19 Aug 2014 07:47:03 -0700
From: internet-drafts@ietf.org<= /a>
To: Fernando Gont <fgont@si6net= works.com>, Will(Shucheng) Liu
<liushucheng@huawei.com>= ;, Fernando Gont <fgont@si6netw= orks.com>,
Shucheng LIU (Will) <liushuche= ng@huawei.com>


A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-00.txt<= br> 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-6man-deprecate-ato= mfrag-generation
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating the Generation of IPv6= Atomic Fragments
Document date:=C2=A0 2014-08-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:
http://www.ietf.org/internet-dr= afts/draft-gont-6man-deprecate-atomfrag-generation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-g= ont-6man-deprecate-atomfrag-generation/
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-d= eprecate-atomfrag-generation-00


Abstract:
=C2=A0 =C2=A0The core IPv6 specification requires that when a host receives= an
=C2=A0 =C2=A0ICMPv6 "Packet Too Big" message reporting a "Ne= xt-Hop MTU" smaller
=C2=A0 =C2=A0than 1280, the host includes a Fragment Header in all subseque= nt
=C2=A0 =C2=A0packets sent to that destination, without reducing the assumed= Path-
=C2=A0 =C2=A0MTU.=C2=A0 The simplicity with which ICMPv6 "Packet Too B= ig" messages can
=C2=A0 =C2=A0be forged, coupled with the widespread filtering of IPv6 fragm= ents,
=C2=A0 =C2=A0results in an attack vector that can be leveraged for Denial o= f
=C2=A0 =C2=A0Service purposes.=C2=A0 This document briefly discusses the af= orementioned
=C2=A0 =C2=A0attack vector, and formally deprecates the generation of IPv6 = atomic
=C2=A0 =C2=A0fragments, such that the aforementioned attack vector is elimi= nated.





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




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Antonios Atlasis, PhD, MPhil<= br> GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
--089e0149cf607aec600500fcf270-- From nobody Tue Aug 19 15:47: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 8A3DB1A6F2A; Tue, 19 Aug 2014 15:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 l6sXHHRjkutD; Tue, 19 Aug 2014 15:47:39 -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 6DDC21A6F03; Tue, 19 Aug 2014 15:47:39 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 471063493A5; Tue, 19 Aug 2014 22:47:37 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F09BE160059; Tue, 19 Aug 2014 22:58:50 +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 99F89160032; Tue, 19 Aug 2014 22:58:50 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 28B0B1D0F8C9; Wed, 20 Aug 2014 08:47:34 +1000 (EST) To: Fernando Gont From: Mark Andrews References: <53F33C4F.2070807@si6networks.com> In-reply-to: Your message of "Tue, 19 Aug 2014 09:00:15 -0300." <53F33C4F.2070807@si6networks.com> Date: Wed, 20 Aug 2014 08:47:34 +1000 Message-Id: <20140819224734.28B0B1D0F8C9@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MA_h_rwTv2_U9OtG05JNNtcJWRU Cc: IPv6 Operations , "'opsec@ietf.org'" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:47:41 -0000 In message <53F33C4F.2070807@si6networks.com>, Fernando Gont writes: > Folks, > > Ten days ago or so we published this I-D: > 00.txt> > > Section 5.2 of the I-D discusses a possible attack vector based on a > combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by > operators, along with proposed countermeasures -- on which we'd like to > hear your comments. > > Since Section 5.2 is in the draft, let me offer a more informal and > practical explanation: > > 1) It is known that filtering of packets containing IPv6 Extension > Headers (including the Fragment Header) is widespread (see our I-D above) > > 2) Let us assume that Host A is communicating with Server B, and that > some node filters fragments between Host A and Server B. Some node is performing a Denial Of Service attack on the communications between Host A and Server B. The logical thing is to remove/reconfigure the node performing the denial of service attack. Note the box that is dropping the fragments is almost certainly controlled by the owners of A or the owners of B. > 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop > MTU<1280), in the hopes of eliciting "atomic fragments" (see > ) from now on. > > 4) Now server B starts sending IPv6 atomic fragments... And since they > include a frag header (and in '2)' above we noted that frags are dropped > on that path), these packets get dropped (i.e., DoS). The PTB is not the problem. The Atomic fragments are not the problem. The problem is the node that is filtering the packets. Atomic fragements are easily identifiable. There is zero reason to filter them and good reason to let them continue to exist. Write up a CERT advisary and list all the known firewalls that fail to pass atomic fragments. Write a RFC "Firewalls That Drop Atomic Fragments Considered Harmful". > "Demo" with the icmp6 tool > () -- (some addresses have > been changed (anonimized), but it is trivial to pick a victim server...) > > "2001:db8:1:10:0:1991:8:25" is the server, and > "2001:5c0:1000:a::e7d" is my own address): > > ---- cut here ---- > ***** First of all, I telnet to port 80 of the server, and > everything works as expected **** > > fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 > Trying 2001:db8:1:10:0:1991:8:25... > Connected to 2001:db8:1:10:0:1991:8:25. > Escape character is '^]'. > ^CConnection closed by foreign host. > > **** Now I send the forget ICMPv6 PTB **** > > fgont@satellite:~$ sudo icmp6 --icmp6-packet-too-big -d > 2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o > 80 -v > icmp6: Security assessment tool for attack vectors based on ICMPv6 error > messages > > IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected) > IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25 > IPv6 Hop Limit: 227 (randomized) > ICMPv6 Packet Too Big (Type 2), Code 0 > Next-Hop MTU: 1000 > Payload Type: IPv6/TCP (default) > Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected) > Destination Address: 2001:5c0:1000:a::e7d > Hop Limit: 237 (randomized) > Source Port: 80 Destination Port: 38189 (randomized) > SEQ Number: 734463213 (randomized) ACK Number: 866605720 (randomized) > Flags: A (default) Window: 18944 (randomized) URG Pointer: 0 (default > ) > Initial attack packet(s) sent successfully. > > > ***** And now I try the same telnet command as above... but it fails, > because the frags from the server to me are getting dropped somewhere **** > > fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 > Trying 2001:db8:1:10:0:1991:8:25... > [timeout] > ---- cut here ---- > > > Of course, in this particular case I just "shot myself". But one could > do this to DoS connections between mailservers, etc. > > A nice question is: what if e.g.... > > 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and > react (as expected) by generating atomic fragments, *and*, > > 2) These same BGP servers deem fragmentation as "harmful", and hence > drop such fragments > > you could essentially DoS traffic between them > > As noted in the I-D, the mitigations seem to be: > > 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 > PTB, or, > > 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU > smaller than 1280. > > Thoughts? > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Aug 19 15:58: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 1A7101A6FA1; Tue, 19 Aug 2014 15:58: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 NFJk4r2myWSu; Tue, 19 Aug 2014 15:58:50 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814101A6F9B; Tue, 19 Aug 2014 15:58:50 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id e131so5162342oig.12 for ; Tue, 19 Aug 2014 15:58: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=l9RBnPfkuZBxk7mV4kLWvR1v+NKWxA//psxP1OIJvsY=; b=04bD3LDorcKfkkCk8uICX5Kp/npzlyzMWe4Lrq/nF+KAW9b/KfVjSd7/P34BZOk6B3 y2Fzq3DTh3qqTbcjXOQOtDppx9rvjbLIQDxIFtDYvhSjuCAQLak5VKgSmKUURZtGDb42 TxZ4sCfQSid8nl43biuFHjgM9q1gLSJIzru1ZQ9x800rPyzVU+DjfPabzlGNGzjake05 HXPu2sA5khCdHcfr9EUJz28gYRsJjm6ZWgOydr2KPJ80ciwbES1hI18yRnD4z+CgBEKY BfGe2S3UqDZ+ixi5FS74KxL8TvBCL6PnwLlNymZnBXj3W7WxFi3KeMVutNVB5eRHr1M7 v2FQ== X-Received: by 10.60.103.195 with SMTP id fy3mr46704274oeb.35.1408489129979; Tue, 19 Aug 2014 15:58:49 -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 bz3sm30570557oec.10.2014.08.19.15.58.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 15:58:49 -0700 (PDT) Message-ID: <53F3D6AB.4090505@gmail.com> Date: Wed, 20 Aug 2014 10:58:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/f_sLsMST-J-Rt-cn7cI7ZaLU33o Cc: Fernando Gont , IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:58:52 -0000 On 20/08/2014 10:29, Lorenzo Colitti wrote: > On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont > wrote: > >> I must say that I fail to see the need for generating IPv6 atomic >> fragments 8packets with a frag header, which are not really fragmented). >> See e.g. what we wrote in >> < >> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00 >>> . > > It does seem kind of silly that we say "you must support MTU >= 1280 to run > IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't > simply say that PTB packets < 1280 are invalid? Because of SIIT, that is equivalent to saying that the minimum IPv4 MTU is now 1260. That might be a discussion worth having, but 576 has been around for a long time. Brian From nobody Tue Aug 19 16:02: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 728B81A6FB8 for ; Tue, 19 Aug 2014 16:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 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.668, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBQdM2FqKJG2 for ; Tue, 19 Aug 2014 16:02:12 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBBB1A6FB3 for ; Tue, 19 Aug 2014 16:02:11 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id c1so10417731igq.9 for ; Tue, 19 Aug 2014 16:02:11 -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=dFU++xRywQHGMctoRIY/RoGsaXOcBUCKzHZ63gueQKc=; b=KRhysDzev5xQ/kvvI4fAXXFqhSZVLUfkHYSWlE+GV4cOYhO/7mdTVd+GD8xcAlxJnf bILkwFxLxR8bA1MMl5qSjQzANk7K0NwspV4mlu7p4ctqXhME/xHdVoTe9po08iNku3S0 kFtH/jn/6sgukt/e6RwzKej0ZtHw8n0W+gVBKUbfXDYtVUi1VBxWDoViOTWIB90fT+LY bGy0I76zTn/VTKO37fb8HZswIXr1O7tccPSKQ0T65HxxJHsSIGTC9zO701KKQbmAICr6 kx4AMqQ6dK29vLYOPmhUIaI+QVMX5ytgLAXOZCIjdEZz9Gwb+p94CT93BjRBaRHRmhJy KQdQ== 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=dFU++xRywQHGMctoRIY/RoGsaXOcBUCKzHZ63gueQKc=; b=TUYCr2qMpopU4Mmb7OpuWTrfXPg36c67oMWccB3LBYZQDlVNUamW5gm+3bcZdUxEFs C7KHcOI9W9Qoht9YvI0vYdSp/mXPpK4u4va7Rus9B80EJBKaOafVBl2nVD6Bv2mlvL3l bpMuqoDVBb++uVBWbmzKVdipF5qm8VQIOc1vuI6jqy9yxiJ2Wf0oUEpoctIVjeFPTpz1 kjUbt6r0oGD6hcZIppl9iTfFuXeVj1qdF16gdCiKPZkrtdQV4KVoBfOuhBxZzHa/SG7s 55LghcNz6vGG+9c9OyAysxxXt+XCs10gcbu+e9RVwKOtxAqeY/9YXEiiKETI2wnYp0q2 VbIA== X-Gm-Message-State: ALoCoQmCiY2lBd4OtQmZbvcTQDSLq2oLFyPOuWyQmxpiy/AE8XVk3F9Bo3e8MtyVP2FebQiGyFe5 X-Received: by 10.50.33.16 with SMTP id n16mr8924649igi.15.1408489331270; Tue, 19 Aug 2014 16:02:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.103 with HTTP; Tue, 19 Aug 2014 16:01:51 -0700 (PDT) In-Reply-To: <53F3D6AB.4090505@gmail.com> References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> From: Lorenzo Colitti Date: Tue, 19 Aug 2014 16:01:51 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0153840c42c6ca0501037a09 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mboyFJbemirvUalAEGsKNmFBe6E Cc: Fernando Gont , IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:02:13 -0000 --089e0153840c42c6ca0501037a09 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 19, 2014 at 3:58 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Any reason we can't simply say that PTB packets < 1280 are invalid? > > Because of SIIT, that is equivalent to saying that the minimum IPv4 > MTU is now 1260. That might be a discussion worth having, but 576 has > been around for a long time. > Can we then say that PTB packets < 1280 are invalid and should be ignored by hosts? Or should be ignored unless they are running a SIIT translator? --089e0153840c42c6ca0501037a09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 19, 2014 at 3:58 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
>= Any reason we can't=C2=A0simply say that PTB packets < 1280 are inv= alid?

Because of SIIT, that is equivalent to saying that the minimum = IPv4
MTU is now 1260. That might be a discussion worth having, but 576 has
been around for a long time.

Can we the= n say that PTB packets < 1280 are invalid and should be ignored by hosts= ? Or should be ignored unless they are running a SIIT translator?
--089e0153840c42c6ca0501037a09-- From nobody Tue Aug 19 16:22: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 9B2811A6FA6; Tue, 19 Aug 2014 16:22: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 2kO7h14FD0Gz; Tue, 19 Aug 2014 16:22:48 -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 F3B711A6FC1; Tue, 19 Aug 2014 16:22:47 -0700 (PDT) Received: from [186.134.69.71] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJsjl-0007VS-Sy; Wed, 20 Aug 2014 01:22:46 +0200 Message-ID: <53F3DC3C.5080607@si6networks.com> Date: Tue, 19 Aug 2014 20:22:36 -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: <53F33C4F.2070807@si6networks.com> <20140819224734.28B0B1D0F8C9@rock.dv.isc.org> In-Reply-To: <20140819224734.28B0B1D0F8C9@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7ug9858upxDuXXfdlH3V3p0xlSE Cc: IPv6 Operations , "'opsec@ietf.org'" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:22:50 -0000 On 08/19/2014 07:47 PM, Mark Andrews wrote: >> Since Section 5.2 is in the draft, let me offer a more informal and >> practical explanation: >> >> 1) It is known that filtering of packets containing IPv6 Extension >> Headers (including the Fragment Header) is widespread (see our I-D above) >> >> 2) Let us assume that Host A is communicating with Server B, and that >> some node filters fragments between Host A and Server B. > > Some node is performing a Denial Of Service attack on the communications > between Host A and Server B. The logical thing is to remove/reconfigure > the node performing the denial of service attack. Note the box > that is dropping the fragments is almost certainly controlled by > the owners of A or the owners of B. Not necessarily. Please see our measurement results in regarding the percentage of packet drops that happen in a different AS other than the destination AS. >> 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop >> MTU<1280), in the hopes of eliciting "atomic fragments" (see >> ) from now on. >> >> 4) Now server B starts sending IPv6 atomic fragments... And since they >> include a frag header (and in '2)' above we noted that frags are dropped >> on that path), these packets get dropped (i.e., DoS). > > The PTB is not the problem. The Atomic fragments are not the > problem. The problem is the node that is filtering the packets. > Atomic fragements are easily identifiable. There is zero reason > to filter them and good reason to let them continue to exist. There's no problem with *processing* atomic fragments. The question here is what that of "including an FH in all subsequence packets in response to an ICMPv6 PTB<1280" buys us. As far as I can see, it only buys trouble. > Write up a CERT advisary and list all the known firewalls that fail > to pass atomic fragments. > > Write a RFC "Firewalls That Drop Atomic Fragments Considered Harmful". FWIW, they are dropping all fragments, not just atomic fragments. The only issue with atomic fragments is how their generation is triggered: they are (easily) triggered by a packet type (ICMPv6 PTB) that does not even require source address spoofing, and that is hard to validate. And even if you think you have everything under control in the sense of "I block all fragments, and artificially limit the MTU to 1280" you may get bitten. In the same way you will get bitten when a third party is dropping IPv6 fragments (as our measurements indicate). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 16:25: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 0723F1A6FA6; Tue, 19 Aug 2014 16:25:36 -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 gY42JUU9gr7d; Tue, 19 Aug 2014 16:25:34 -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 AE20F1A0023; Tue, 19 Aug 2014 16:25:34 -0700 (PDT) Received: from [186.134.69.71] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XJsmR-0007WO-3T; Wed, 20 Aug 2014 01:25:31 +0200 Message-ID: <53F3DCA1.2080207@si6networks.com> Date: Tue, 19 Aug 2014 20:24: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 E Carpenter , Lorenzo Colitti References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> In-Reply-To: <53F3D6AB.4090505@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vjKlHqitBg-kUaSFulJudFHBygo Cc: IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:25:36 -0000 Hi, Brian, On 08/19/2014 07:58 PM, Brian E Carpenter wrote: >> >> It does seem kind of silly that we say "you must support MTU >= 1280 to run >> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't >> simply say that PTB packets < 1280 are invalid? > > Because of SIIT, that is equivalent to saying that the minimum IPv4 > MTU is now 1260. That might be a discussion worth having, but 576 has > been around for a long time. Not sure what you meant about 576... that we can assume that to be a minmum MTU, or something else? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 19 16:56: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 E230B1A003A; Tue, 19 Aug 2014 16:56:12 -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 TdwONpkzvUu6; Tue, 19 Aug 2014 16:56:11 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003: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 56C351A0024; Tue, 19 Aug 2014 16:56:10 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id g18so5887445oah.9 for ; Tue, 19 Aug 2014 16:56: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=HyhaFpk9ScaIGk7Bt0PzJj6b2im7a96QNSyg5OV6fho=; b=J3xU+93nnoxW8wijFSGOGvThACPB/Meha/lYitmfFczxWJFzRsLrH9xTIKIC7rWxyB NawGPnSHXhuHswImwpC9hN67bK3STz1qSxhF/N9HIW2CtsphtpfZXZTfgMc+S6Rz211J kdE+fjc+eD3BRXnSRs04TXFBKlljj5d0WzzdzOLPLFbD8IBy1QGZXVAZ3W2+PWjohKpB cVucd3cFBy+Xg9USHD8t6LI/Z27+jDTE6Rp6eW6q2DGbbbulrVygl+4s10RX1OwpxJ7h T9Iqj6bsgr4h8TeKVZ0uOiLw4x3+QpPXBYxxZgaKHX3GrLA2lRJKIqN2BfmTgkfZQMr1 NPMw== X-Received: by 10.182.44.135 with SMTP id e7mr46596682obm.18.1408492569731; Tue, 19 Aug 2014 16:56:09 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id df10sm30752148oec.1.2014.08.19.16.56.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 16:56:09 -0700 (PDT) Message-ID: <53F3E41C.3060100@gmail.com> Date: Wed, 20 Aug 2014 11:56:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@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/Lg6v-P-SBZO9Z8N06DlGjDRpAkI Cc: Fernando Gont , IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:56:13 -0000 On 20/08/2014 11:01, Lorenzo Colitti wrote: > On Tue, Aug 19, 2014 at 3:58 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> Any reason we can't simply say that PTB packets < 1280 are invalid? >> Because of SIIT, that is equivalent to saying that the minimum IPv4 >> MTU is now 1260. That might be a discussion worth having, but 576 has >> been around for a long time. >> > > Can we then say that PTB packets < 1280 are invalid and should be ignored > by hosts? Or should be ignored unless they are running a SIIT translator? The host doesn't know in general if there is a translator downstream (except in a DNS64/NAT64 scenario). Brian From nobody Tue Aug 19 17:09: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 D2AF91A8971; Tue, 19 Aug 2014 17:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crA3Qu9pY2Pa; Tue, 19 Aug 2014 17:09:10 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354271A8964; Tue, 19 Aug 2014 17:09:10 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id h136so5104194oig.7 for ; Tue, 19 Aug 2014 17:09: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=MPl+yRGBdebp2ChjC13UxlENBF6Bv1LYnpKbbv1liYg=; b=HGqBsKFWKZ4mMbp550Ul/qxWTlQ830WcLCGdpRywf5wBblYscFnNnHUdET67RdZC5Y 66Z4S4v5rAdWvJgO5NOFExSKKW6EnjJrreg5AXdv2eZtu+GS+2iiP1nZnIynnI5tv4Mj GKd0gffDzRGPItdVP2FLPzM8aKsulN8IO24UPwgTKvzy2oypRqolbUh37UAkaG+7SRwr lVsmcD6lc5WC6gjunkR1U89BZY95BAZ9DfeMyDez7FQOrzD2At9V83gCjHrXuRBBK3nB O/qUfavLwGCsMSXmK8Yh5u8DCSqTr28P5MOJkm1Svyv21jQSs5gFOjWnj83nNk4zGDXO bjKw== X-Received: by 10.60.150.211 with SMTP id uk19mr12990627oeb.70.1408493349691; Tue, 19 Aug 2014 17:09:09 -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 sx14sm30795044oeb.14.2014.08.19.17.09.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 17:09:09 -0700 (PDT) Message-ID: <53F3E725.6050708@gmail.com> Date: Wed, 20 Aug 2014 12:09:09 +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: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> In-Reply-To: <53F3DCA1.2080207@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WcfSGZ7cJMwQuXO6Otx2C3rKcgg Cc: IPv6 Operations , =?UTF-8?B?56We5piO6YGU5ZOJ?= , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 00:09:12 -0000 On 20/08/2014 11:24, Fernando Gont wrote: > Hi, Brian, > > On 08/19/2014 07:58 PM, Brian E Carpenter wrote: >>> It does seem kind of silly that we say "you must support MTU >= 1280 to run >>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't >>> simply say that PTB packets < 1280 are invalid? >> Because of SIIT, that is equivalent to saying that the minimum IPv4 >> MTU is now 1260. That might be a discussion worth having, but 576 has >> been around for a long time. > > Not sure what you meant about 576... that we can assume that to be a > minmum MTU, Yes, that hasn't changed since RFC 791 (although the way fragmentation is defined for IPv4 is rather different from IPv6, of course). Maybe we consider it acceptable that SIIT will break on paths that include a shorter-than-Ethernet link MTU. But we need to make that statement explicit. Brian or something else? > > Thanks! > > Cheers, From nobody Tue Aug 19 17:33: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 C040E1A89FE for ; Tue, 19 Aug 2014 17:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.069 X-Spam-Level: X-Spam-Status: No, score=-5.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SONATA=2.5, RCVD_IN_DNSWL_HI=-5, 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 CV27bt8MnQYH for ; Tue, 19 Aug 2014 17:33:49 -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 A324E1A89F8 for ; Tue, 19 Aug 2014 17:33:49 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 78931349308 for ; Wed, 20 Aug 2014 00:33:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7C640160059 for ; Wed, 20 Aug 2014 00:45:01 +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 4DCA4160032 for ; Wed, 20 Aug 2014 00:45:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 23DE61D105DD for ; Wed, 20 Aug 2014 10:33:44 +1000 (EST) To: IPv6 Ops WG From: Mark Andrews References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> In-reply-to: Your message of "Tue, 19 Aug 2014 14:32:56 +0000." <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Wed, 20 Aug 2014 10:33:43 +1000 Message-Id: <20140820003344.23DE61D105DD@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oDRONPSzjKdxCsND0TI95SZcb7I Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 00:33:50 -0000 In message <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.C O.UK>, "Heatley, Nick" writes: > If I may stick my neck out. > > Id like v6ops to consider at least two items: > > 1. (Carrier Grade) NAT64 vs NAT44 a deathmatch. Most of the problem with NAT64 vs NAT44 is getting CPE devices upgraded. 464xlate worked for cellular networks because the devices were replaced to support 4G services and those new devices support 464xlate. Additionally cell phones are fragile devices that get stolen, lost, dropped, stepped on, driven over, and is some market need to be replaced to change carrier ... so there is a high turnover. For wired connections there is no incentive for the customer to replace the CPE device so NAT44 is a required part of the solution space just to share the limited IPv4 address space between the IPv4 only customers. Cable and DSL modems work for 10+ years. Home routers work for similar lengths of time. You can still buy IPv4 only routers and they are cheaper than anything with IPv6 in it. If you are on a limited budget a IPv4 only router with 802.11g "will do". Add to that ISP's not offering / promoting IPv6 there is no incentive for the customer to buy the IPv6 capable device over the IPv4 only one. The choice of device is made on other factors. If ISPs offered to do 2G of IPv6 data for the price of 1G of IPv4 data one might actually get customers to buy IPv6 capable routers. A 12 month rebate for installing a IPv6 capable CPE device could offset the costs of installing more CGNAT boxes. IPv6 capable 802.11n routers can be got for AUD80 today. Even on a AUD$20 plan the rebates would cover the costs if the usual +50% taffic shift to IPv6 occurs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Aug 19 17: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 7C5C31A004D for ; Tue, 19 Aug 2014 17:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_SONATA=2.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJOhoq1Fa8-8 for ; Tue, 19 Aug 2014 17:38:06 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D221A004B for ; Tue, 19 Aug 2014 17:38:05 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id rd3so11181717pab.40 for ; Tue, 19 Aug 2014 17:38:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5ihwg701qDGoc9Wg04LbeXHc1EoPMIkuvCBnPH8Fvoc=; b=eq131gbwiWKpG2cINujx/ZUPDvAZGDirwtG1XTg7iREZ12QmoqjZYIs9gCDtv1Yi0X Vb3sh87g1sOVgd6oBrqgZywqwKCI7XeFAREnDTxAN3WfLp/mCsg9daFle1Q4l7crcCw4 r/07Ab6g7/7DcRpxaUBISv9oDRnNM7e6X69aJEf+5nwncyT8oLHqJFiibLEj7+Csf7WP e/PB/5qMw01YsFrWXuCSxz2SmcmSgdXB9gDghQ7Ta98O6qvdlyZJwbl6JYkmSYx2j4Fe HDAinmS5Ckfi9I9Wp6rGDK8PJKJfZ9k0bNWXxowSfsr7G+HQqsWVTI42jkFLOXQzCHm+ fjMw== X-Gm-Message-State: ALoCoQmU+AmPfIs1LWtcn5jD6p75KAMzLQNstGdn1c+6KWGEBKgFxDBH4kugUFzKTFmtMGxvBfk+ MIME-Version: 1.0 X-Received: by 10.68.164.164 with SMTP id yr4mr48386313pbb.57.1408495084805; Tue, 19 Aug 2014 17:38:04 -0700 (PDT) Received: by 10.70.92.99 with HTTP; Tue, 19 Aug 2014 17:38:04 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:7831:c1ff:fe5c:6600] In-Reply-To: <20140820003344.23DE61D105DD@rock.dv.isc.org> References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> Date: Wed, 20 Aug 2014 10:38:04 +1000 Message-ID: From: George Michaelson To: Mark Andrews Content-Type: multipart/alternative; boundary=047d7b10c8b732b9a2050104d1e9 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4SG96GJye7fdAUZrkbrjHKbitcI Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 00:38:07 -0000 --047d7b10c8b732b9a2050104d1e9 Content-Type: text/plain; charset=UTF-8 Tax incentives for early depreciation and write off. For Australia and NZ, where a lot of the deployment is self-bought this isn't going to work as well as for other economies, but at world scale, this will enable ISPs who own the CPE to do a deployment with some financial efficiency. Regulators always have two tools: the carrot and the stick. We see a lot of noise about the stick on these lists, we never see quite enough mention of the carrot side of the equation. -G On Wed, Aug 20, 2014 at 10:33 AM, Mark Andrews wrote: > > In message > <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.C > O.UK>, "Heatley, Nick" writes: > > If I may stick my neck out. > > > > Id like v6ops to consider at least two items: > > > > 1. (Carrier Grade) NAT64 vs NAT44 a deathmatch. > > Most of the problem with NAT64 vs NAT44 is getting CPE > devices upgraded. 464xlate worked for cellular networks > because the devices were replaced to support 4G services > and those new devices support 464xlate. Additionally cell > phones are fragile devices that get stolen, lost, dropped, > stepped on, driven over, and is some market need to be > replaced to change carrier ... so there is a high turnover. > > For wired connections there is no incentive for the customer > to replace the CPE device so NAT44 is a required part of > the solution space just to share the limited IPv4 address > space between the IPv4 only customers. Cable and DSL modems > work for 10+ years. Home routers work for similar lengths > of time. You can still buy IPv4 only routers and they are > cheaper than anything with IPv6 in it. If you are on a > limited budget a IPv4 only router with 802.11g "will do". > > Add to that ISP's not offering / promoting IPv6 there is > no incentive for the customer to buy the IPv6 capable device > over the IPv4 only one. The choice of device is made on > other factors. If ISPs offered to do 2G of IPv6 data for > the price of 1G of IPv4 data one might actually get customers > to buy IPv6 capable routers. A 12 month rebate for installing > a IPv6 capable CPE device could offset the costs of installing > more CGNAT boxes. IPv6 capable 802.11n routers can be got > for AUD80 today. Even on a AUD$20 plan the rebates would > cover the costs if the usual +50% taffic shift to IPv6 > occurs. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b10c8b732b9a2050104d1e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tax incentives for early depreciation and write off. For A= ustralia and NZ, where a lot of the deployment is self-bought this isn'= t going to work as well as for other economies, but at world scale, this wi= ll enable ISPs who own the CPE to do a deployment with some financial effic= iency.

Regulators always have two tools: the carrot and the stick. = We see a lot of noise about the stick on these lists, we never see quite en= ough mention of the carrot side of the equation.

-G


On Wed, Aug 20, 2014 at 10:33 AM, Mark Andrews <marka@isc.org> = wrote:

In message <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.= EEINT.C
O.UK>, &qu= ot;Heatley, Nick" writes:
> If I may stick my neck out.
>
> Id like v6ops to consider at least two items:
>
> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0(Carrier Grade) NAT64 vs NAT44=C2=A0 a de= athmatch.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Most of the problem with NAT64 vs NAT44 i= s getting CPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 devices upgraded.=C2=A0 464xlate worked for cel= lular networks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 because the devices were replaced to support 4G= services
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and those new devices support 464xlate.=C2=A0 A= dditionally cell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 phones are fragile devices that get stolen, los= t, dropped,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stepped on, driven over, and is some market nee= d to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 replaced to change carrier ... so there is a hi= gh turnover.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For wired connections there is no incentive for= the customer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to replace the CPE device so NAT44 is a require= d part of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the solution space just to share the limited IP= v4 address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 space between the IPv4 only customers.=C2=A0 Ca= ble and DSL modems
=C2=A0 =C2=A0 =C2=A0 =C2=A0 work for 10+ years.=C2=A0 Home routers work for= similar lengths
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of time.=C2=A0 You can still buy IPv4 only rout= ers and they are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cheaper than anything with IPv6 in it.=C2=A0 If= you are on a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 limited budget a IPv4 only router with 802.11g = "will do".

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Add to that ISP's not offering / promoting = IPv6 there is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 no incentive for the customer to buy the IPv6 c= apable device
=C2=A0 =C2=A0 =C2=A0 =C2=A0 over the IPv4 only one.=C2=A0 The choice of dev= ice is made on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other factors.=C2=A0 If ISPs offered to do 2G o= f IPv6 data for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the price of 1G of IPv4 data one might actually= get customers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to buy IPv6 capable routers.=C2=A0 A 12 month r= ebate for installing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a IPv6 capable CPE device could offset the cost= s of installing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 more CGNAT boxes.=C2=A0 IPv6 capable 802.11n ro= uters can be got
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for AUD80 today.=C2=A0 Even on a AUD$20 plan th= e rebates would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cover the costs if the usual +50% taffic shift = to IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 occurs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

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

--047d7b10c8b732b9a2050104d1e9-- From nobody Tue Aug 19 18: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 056D31A6F96; Tue, 19 Aug 2014 18:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 7ZbuaEsRZb2t; Tue, 19 Aug 2014 18:55:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5417A1A6FE2; Tue, 19 Aug 2014 18:55:30 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id C9CCC1FCB4D; Wed, 20 Aug 2014 01:55:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8118F160059; Wed, 20 Aug 2014 02:06:40 +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 518EA160032; Wed, 20 Aug 2014 02:06:40 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6DB261D117FF; Wed, 20 Aug 2014 11:55:22 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com> In-reply-to: Your message of "Wed, 20 Aug 2014 12:09:09 +1200." <53F3E725.6050708@gmail.com> Date: Wed, 20 Aug 2014 11:55:22 +1000 Message-Id: <20140820015522.6DB261D117FF@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g2ebBg9GTPnK6cgsicI02oFHTOc Cc: Fernando Gont , IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:55:32 -0000 576 is the mimimum reassembly buffer size to be supported by all IPv4 hosts. It is *not* the minimum path MTU size. The miminum link MTU is 68 bytes. RFC 791. Mark In message <53F3E725.6050708@gmail.com>, Brian E Carpenter writes: > On 20/08/2014 11:24, Fernando Gont wrote: > > Hi, Brian, > > > > On 08/19/2014 07:58 PM, Brian E Carpenter wrote: > >>> It does seem kind of silly that we say "you must support MTU >= 1280 to r > un > >>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't > >>> simply say that PTB packets < 1280 are invalid? > >> Because of SIIT, that is equivalent to saying that the minimum IPv4 > >> MTU is now 1260. That might be a discussion worth having, but 576 has > >> been around for a long time. > > > > Not sure what you meant about 576... that we can assume that to be a > > minmum MTU, > > Yes, that hasn't changed since RFC 791 (although the way fragmentation > is defined for IPv4 is rather different from IPv6, of course). > > Maybe we consider it acceptable that SIIT will break on paths that > include a shorter-than-Ethernet link MTU. But we need to make that > statement explicit. > > Brian > > or something else? > > > > Thanks! > > > > Cheers, > > _______________________________________________ > 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 Aug 19 19:29: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 B5C791A8716; Tue, 19 Aug 2014 19:29: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 W-JUYHSs9RIY; Tue, 19 Aug 2014 19:29:51 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4968D1A8715; Tue, 19 Aug 2014 19:29:51 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so5250574oif.30 for ; Tue, 19 Aug 2014 19:29: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=zSK19esL+XnjXS/3JEoL0M3pfNydqNct+Cd1V3KOIiY=; b=GNiTjPLyZeSUWmdwJiYeo7afmNfMc4vuWGSV4TxtJ+XFig4IFvT7yGa7V8lsYsZXti SMjlc43ONyptSmdLk1acl13mu0lXZR5lLtbUICi8Og1cMa2AFBqwbbyZaWepsRb4Vnqv KqcMbdPsJy0CaR9CZgzlL4GPz2LaSpL7r4An5K04xpV7iCVWEceXC+bFalVGyDXtD1sS OHWEjWTp3hbG0SW0YiqxRVccwf7wsiZ2H9nOCxk9y86pmFAnEp7rssz/ExxiGXpHrvHK MfyKNzBBUG04NJKqpNVqt1aCsUF99RfmhkL9hTHwNgyX4jToSY2UcNqXshhaGX9kNflz 3V2g== X-Received: by 10.182.3.100 with SMTP id b4mr96694obb.79.1408501789636; Tue, 19 Aug 2014 19:29:49 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id my6sm23408481obb.4.2014.08.19.19.29.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 19:29:49 -0700 (PDT) Message-ID: <53F40820.1060407@gmail.com> Date: Wed, 20 Aug 2014 14:29:52 +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: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com> <20140820015522.6DB261D117FF@rock.dv.isc.org> In-Reply-To: <20140820015522.6DB261D117FF@rock.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mNT0KWiEkCj-e_xp0ZVRBBFajBg Cc: Fernando Gont , IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 02:29:52 -0000 On 20/08/2014 13:55, Mark Andrews wrote: > 576 is the mimimum reassembly buffer size to be supported > by all IPv4 hosts. It is *not* the minimum path MTU size. Indeed. In fact what I was trying to say, badly, is that the proposed change would de facto create a minimum path MTU of 1260 for IPv4, iff we want SIIT to work in the general case. Which is a choice we could make, but we'd need to be clear that we were making it. Brian > > The miminum link MTU is 68 bytes. RFC 791. > > Mark > > In message <53F3E725.6050708@gmail.com>, Brian E Carpenter writes: >> On 20/08/2014 11:24, Fernando Gont wrote: >>> Hi, Brian, >>> >>> On 08/19/2014 07:58 PM, Brian E Carpenter wrote: >>>>> It does seem kind of silly that we say "you must support MTU >= 1280 to r >> un >>>>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't >>>>> simply say that PTB packets < 1280 are invalid? >>>> Because of SIIT, that is equivalent to saying that the minimum IPv4 >>>> MTU is now 1260. That might be a discussion worth having, but 576 has >>>> been around for a long time. >>> Not sure what you meant about 576... that we can assume that to be a >>> minmum MTU, >> Yes, that hasn't changed since RFC 791 (although the way fragmentation >> is defined for IPv4 is rather different from IPv6, of course). >> >> Maybe we consider it acceptable that SIIT will break on paths that >> include a shorter-than-Ethernet link MTU. But we need to make that >> statement explicit. >> >> Brian >> >> or something else? >>> Thanks! >>> >>> Cheers, >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 19 19:42: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 350DF1A8790 for ; Tue, 19 Aug 2014 19:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 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.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 MR41HWQj6Q9g for ; Tue, 19 Aug 2014 19:42:33 -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 DF5F61A87CF for ; Tue, 19 Aug 2014 19:42:32 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so2204022ier.13 for ; Tue, 19 Aug 2014 19:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tUI9iMHJ3aHYmlTbJxS4ccUa5T6Y7JHzYo6RWqHCMAc=; b=AESMh+rFBA3IId6RHaLJWLjztMM8kKW+zIpyb6xHsvc3NgFaeopqs5LQlp5vJweWap MHtEat2Wjhq+LAgrTbN5TzcfxmChJN+9/++bQAlh6+sTF3veF7AI/oDMQmfdvZh44TFE MXTzMteZl7b8xhEXBXk9iWaKP4ZbBk2tk+6SuVhBKJzvpYmR3ZvKOTwk5eSknNKwkTTJ Q5ZilWMw+GzQLrUutC1Kacea9PI301KLNI9HvgRBqfIU2vI42ARbfDfi9fqbFNliO559 A+Gj7w+Fw5FlXS+XXDZAfal8HRWTNoOP6V1i43qIbaf81lw/2At675+uZymZ8NXpThWv rN2g== 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=tUI9iMHJ3aHYmlTbJxS4ccUa5T6Y7JHzYo6RWqHCMAc=; b=NqqynUD3DI9XY+ZPrRnDlNuVX7MoW97U+hihXSiX9X6/SlRStV944XjyJkSoZbMOFe 2pf8fDgEeIQtRvUDhgIlQRxAnF4110Mz7zmceLwppW01tgZ5a9ZVHiAzsRv5y6c2WjnF GHr+an8kVJ+AQeKVKktNppG8Ui0B6Ww9fM4JQ54iggD3/BtADZ5xmf19xfPsVx3yiBsC uehafIpOuXEBsCNiPvgb+x9fsHb2NaO/Y8KmvQtXQ/cgeZm7lvOyvFUS1w/VeX6FmXAG Hglux31QHTa+XZrSMdV/WwK18HJnvIRlJSWq6Lzp8EgKzFplzUfmDb8bAVd35HNFZ1sc u1wA== X-Gm-Message-State: ALoCoQmY0MnqcoJbKR3ZV3pYrAKLWyEQqHieFTj5p9CZ0aIDHYHB6kLt9coBhnOiFlKkp6QIVJnE X-Received: by 10.42.96.132 with SMTP id j4mr44423982icn.16.1408502552239; Tue, 19 Aug 2014 19:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.103 with HTTP; Tue, 19 Aug 2014 19:42:09 -0700 (PDT) In-Reply-To: <53F3E41C.3060100@gmail.com> References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3E41C.3060100@gmail.com> From: Lorenzo Colitti Date: Tue, 19 Aug 2014 19:42:09 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf303ea6144ac33b0501068eb0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jRwp6WUD_8rphFJaRvaAEbam5VM Cc: Fernando Gont , IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 02:42:34 -0000 --20cf303ea6144ac33b0501068eb0 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 19, 2014 at 4:56 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Can we then say that PTB packets < 1280 are invalid and should be ignored > > by hosts? Or should be ignored unless they are running a SIIT translator? > > The host doesn't know in general if there is a translator downstream > (except in a DNS64/NAT64 scenario). > What does "downstream" mean? Do you mean "the host does not know if the other host it's talking to is behind a SIIT translator"? Or something else? --20cf303ea6144ac33b0501068eb0 Content-Type: text/html; charset=UTF-8
On Tue, Aug 19, 2014 at 4:56 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> Can we then say that PTB packets < 1280 are invalid and should be ignored
> by hosts? Or should be ignored unless they are running a SIIT translator?

The host doesn't know in general if there is a translator downstream
(except in a DNS64/NAT64 scenario).

What does "downstream" mean? Do you mean "the host does not know if the other host it's talking to is behind a SIIT translator"? Or something else?
--20cf303ea6144ac33b0501068eb0-- From nobody Tue Aug 19 21:03: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 3B4011A0B82; Tue, 19 Aug 2014 21:02:54 -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 cgdsAh9trRLL; Tue, 19 Aug 2014 21:02:52 -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 21E251A06D9; Tue, 19 Aug 2014 21:02:51 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so11278486pad.41 for ; Tue, 19 Aug 2014 21:02:51 -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=zZdMNEv8deRU9EoL3V9aUV9Lom16VpwS7+CVzZR4VQw=; b=ZihYHBoQdhYZUD3Bf2pudSdykKSAO8vV8dPdchxSE40VtFbXq52R3hdSiKZp3vJrVP FA7n288e7TFL+Ex5ACOaQMUuxndpiBlHWTYxwUYikr+FJFQygPf6gpf2TKY6aXzfLf17 r9x0PsXEJwZCTQG48u5kNPNjhxd6v5KfzL9Bx2O9AYOt2c5i6UIbWYoyQIgQom6cT8AK 9vlrkM1hESVKRMRgJi9RawljSmPwgoQWJp7wVRk0gy7N1Col0b5iFHae7kilzSqfbOKA gvF70HPrnabK/hyqjpHGJSQVMLiktLKfB0lFVSZKtvo+IU0d/WujIW/3LsZGpO8L6hjX J3IA== X-Received: by 10.68.202.196 with SMTP id kk4mr8601646pbc.37.1408507371588; Tue, 19 Aug 2014 21:02:51 -0700 (PDT) Received: from [192.168.178.23] (182.199.69.111.dynamic.snap.net.nz. [111.69.199.182]) by mx.google.com with ESMTPSA id mj9sm75695845pab.20.2014.08.19.21.02.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 21:02:51 -0700 (PDT) Message-ID: <53F41DE2.6020907@gmail.com> Date: Wed, 20 Aug 2014 16:02:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3E41C.3060100@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/UE3pYxK6z7hYlnMC0rdjZnY3wcw Cc: Fernando Gont , IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 04:02:54 -0000 On 20/08/2014 14:42, Lorenzo Colitti wrote: > On Tue, Aug 19, 2014 at 4:56 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> Can we then say that PTB packets < 1280 are invalid and should be ignored >>> by hosts? Or should be ignored unless they are running a SIIT translator? >> The host doesn't know in general if there is a translator downstream >> (except in a DNS64/NAT64 scenario). >> > > What does "downstream" mean? Do you mean "the host does not know if the > other host it's talking to is behind a SIIT translator"? Or something else? No, exactly that. SIIT is defined as a stateless translation, and there's no direct way for a host to know it exists. So if you get a PTB for <1280, you simply don't know if it's from a real translator or not in the general case. That's why there's a DOS risk in the first place. It would be interesting to know if this matters. It only matters if there is a significant number of operational paths with the combination of SIIT and small IPv4 MTUs. I think we need more data before 6man considers making an incompatible change. Brian From nobody Wed Aug 20 00:52: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 2FC501A0056; Wed, 20 Aug 2014 00:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.041 X-Spam-Level: * X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DATE_IN_PAST_06_12=1.543, 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 JC16zTT1uSJH; Wed, 20 Aug 2014 00:52:34 -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 743071A0060; Wed, 20 Aug 2014 00:52:30 -0700 (PDT) Received: from [2001:5c0:1000:a::753] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XK0h0-0001na-0N; Wed, 20 Aug 2014 09:52:26 +0200 Message-ID: <53F3F371.4010402@si6networks.com> Date: Tue, 19 Aug 2014 22:01: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 References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com> In-Reply-To: <53F3E725.6050708@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ElaUilaAX4Aef_0MpWd_1ab0FTI Cc: IPv6 Operations , =?UTF-8?B?56We5piO6YGU5ZOJ?= , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 07:52:36 -0000 Hi, Brian, On 08/19/2014 09:09 PM, Brian E Carpenter wrote: >> On 08/19/2014 07:58 PM, Brian E Carpenter wrote: >>>> It does seem kind of silly that we say "you must support MTU >= 1280 to run >>>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't >>>> simply say that PTB packets < 1280 are invalid? >>> Because of SIIT, that is equivalent to saying that the minimum IPv4 >>> MTU is now 1260. That might be a discussion worth having, but 576 has >>> been around for a long time. >> >> Not sure what you meant about 576... that we can assume that to be a >> minmum MTU, > > Yes, that hasn't changed since RFC 791 Not really. For v4, 576 is the "minimum reassembly buffer size" (you're guaranteed to the remote host can reassemble a datagram of that size), not the minimum MTU. The IPv4 minimum MTU is actually 68 bytes. While working on RFC5927, I recall that at least OpenBSD enforced a lower limit as low as (around) 296 bytes, since that accommodated some radio links that were known to be in use at the time... > Maybe we consider it acceptable that SIIT will break on paths that > include a shorter-than-Ethernet link MTU. But we need to make that > statement explicit. Or just update SIIT along with deprecating the generation of atomic fragments. -- At the end of the day, not that long ago there were at least a handful of implementations that didn't react to ICMPv6 PTB<1280 as required by RFC2460. Some we might already have scenarios in which the SIIT device expects the host to generate atomic fragments, but it doesn't. 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 Aug 20 01:14: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 197E91A0008; Wed, 20 Aug 2014 01:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 9ldqi11MVQc6; Wed, 20 Aug 2014 01:14:10 -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 581111A00AB; Wed, 20 Aug 2014 01:14:10 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=50726 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 1XK11s-0004hw-ID; Wed, 20 Aug 2014 10:14:00 +0200 Message-ID: <53F45871.3040604@fud.no> Date: Wed, 20 Aug 2014 10:12:33 +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: Brian E Carpenter , Fernando Gont References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com> In-Reply-To: <53F3E725.6050708@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eGaYkB-N8WmjT5XoZ866LUDFW30 Cc: IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 08:14:12 -0000 * Brian E Carpenter > Maybe we consider it acceptable that SIIT will break on paths that > include a shorter-than-Ethernet link MTU. But we need to make that > statement explicit. Making ICMPv6 PTB with MTU < 1280 invalid would only break SIIT for IPv4 paths with an IPv4 MTU, as an ICMPv4 Fragmentation Needed indicating an MTU value of 1260 would be translated to an ICMPv6 Packet Too Big with an MTU value of 1280 by the SIIT translator. See RFC 6145 section 4.2. In other words, "shorter-than-Ethernet link MTU" is fine, IFF the paths in the IPv4 domain are >=1260 (and obviously >=1280 in the IPv6 domain, but that is guaranteed irrespective of SIIT). I discuss this briefly in my SIIT-DC draft here: http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.section.3.8.2 Finally, there is a workaround (described in section 4.5 of my draft). In a nutshell: 1) Clamp all MTU values in translated ICMPv6 PTBs up to 1280 2) When translating IPv6 packets <=1280 bytes to IPv4, always clear the DF flag and generate an Identification value. This will hide the path with the small <1260/1280 IPv4/IPv6 MTU from the IPv6 node by making the IPv4 network fragment the packets instead. How common IPv4 paths with an MTU of <1260 are on today's internet, I don't know. Maybe the RIPE Atlas team could find out for us? It could be that problem isn't worth losing too much sleep over in the first place. Tore From nobody Wed Aug 20 01:28: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 2F0791A005D; Wed, 20 Aug 2014 01:28:18 -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 W8tm4-lnA3u0; Wed, 20 Aug 2014 01:28:17 -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 0C3DE1A005C; Wed, 20 Aug 2014 01:28:17 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=51076 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 1XK1Fc-00051Q-I2; Wed, 20 Aug 2014 10:28:12 +0200 Message-ID: <53F45BC5.2030807@fud.no> Date: Wed, 20 Aug 2014 10:26:45 +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: Brian E Carpenter , Fernando Gont References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com> <53F45871.3040604@fud.no> In-Reply-To: <53F45871.3040604@fud.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_gwwed2b6zpyX_nBWs5NtpJNXdA Cc: IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 08:28:18 -0000 * Tore Anderson > Making ICMPv6 PTB with MTU < 1280 invalid would only break SIIT for IPv4 > paths with an IPv4 MTU, [..] Correction, this should have read «[...] paths with an IPv4 MTU < 1260». Tore From nobody Wed Aug 20 01:50: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 D3F9B1A0101; Wed, 20 Aug 2014 01:50: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 fOTwBdLdzH_A; Wed, 20 Aug 2014 01:50: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 8B1351A00F9; Wed, 20 Aug 2014 01:50:25 -0700 (PDT) Received: from [2001:5c0:1000:a::791] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XK1az-0001yI-DA; Wed, 20 Aug 2014 10:50:20 +0200 Message-ID: <53F460D6.4080908@si6networks.com> Date: Wed, 20 Aug 2014 05:48:22 -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 , Lorenzo Colitti References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F3D6AB.4090505@gmail.com> <53F3E41C.3060100@gmail.com> <53F41DE2.6020907@gmail.com> In-Reply-To: <53F41DE2.6020907@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NDwRIvVidXMsqGrtS88UYH6z_Pk Cc: IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 08:50:28 -0000 Hi, Brian, On 08/20/2014 01:02 AM, Brian E Carpenter wrote: >> >> What does "downstream" mean? Do you mean "the host does not know if the >> other host it's talking to is behind a SIIT translator"? Or something else? > > No, exactly that. SIIT is defined as a stateless translation, > and there's no direct way for a host to know it exists. So if > you get a PTB for <1280, you simply don't know if it's from a > real translator or not in the general case. That's why there's > a DOS risk in the first place. > > It would be interesting to know if this matters. It only matters > if there is a significant number of operational paths with the > combination of SIIT and small IPv4 MTUs. I think we need more > data before 6man considers making an incompatible change. Truth is that, at this point in time, you will not find any significant number of SIIT deployments for any kind of measurements to be to have any significance. It would also depend on the kind of SIIT deployment: * If the translator is closer to the client, I'd expect that IPv4 path has at least the 1280 bytes. * OTOH, if SIIT is being deployed closer to the server (IPv6-only datacenter sort of thing), then the IPv4 could be... anything (although, I'd still expect the vast majority to have MTUs of at least 1280 bytes). But in this case, you really want to avoid IPv6 fragmentation as much as possible, since sending IPv6 fragments greatly reduces the chances of your packets from getting there. In any case, I think that there are some factors to consider here: * At least some popular OSes were not generating IPv6 atomic fragments as expected (that includes some rather recent versions of FreeBSD and Mac OS X). Hence the most robust option is to gracefully handle the case where the IPv6 node does not generate IPv6 atomic fragments. * And we're certainly not at a stage in which SIIT deployments are "the rule". Hence, the earlier this is fixed, the cheaper it gets. 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 Aug 20 13:37: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 284951A6ED9; Wed, 20 Aug 2014 13:37:46 -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 huzH7f0qx6nc; Wed, 20 Aug 2014 13:37:44 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200561A0422; Wed, 20 Aug 2014 13:37:43 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so7515528wiw.6 for ; Wed, 20 Aug 2014 13:37:42 -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=3dFqapswngjp4KCcx+xczTKG9UE3l0TAiGYOVsLRRTw=; b=pFh5ImtlYGsy3FZjIPPOiYaW6HowPTmWsF2YkI8R8clnGVjpWmZ1HnMzfEHVkCUhlL 377TEK5mRfawhpeZi4a+4LzUe23uKZ1j3uDTVj3dYXiEdPLOeUFFbpacbZmjsq60DFAz lD4G+60tChEvDsrG0kkYJhw7L9kCzNlygquioRVjWSr+oxx0UYxeUurabNB34XaJWF7U uoBO9Gn92olV+/pGzmACWSaWs0+xLTv3Z+p2rB+cXAj6o9DDcH0K7/OQZTbBkJHJGUrm QJ8h2N6bEY5w1qM5zgQ/H4DzQk/uA0Bzzg5mFkswn5BzBHEBcw+mXr86uuDYRspUx/qE KJ5g== MIME-Version: 1.0 X-Received: by 10.194.62.104 with SMTP id x8mr63324509wjr.7.1408567062677; Wed, 20 Aug 2014 13:37:42 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Wed, 20 Aug 2014 13:37:42 -0700 (PDT) In-Reply-To: <53F3931F.9050601@si6networks.com> References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> Date: Wed, 20 Aug 2014 13:37:42 -0700 X-Google-Sender-Auth: kd8v3_kOZXB0E9EwGh2nO5a2k_0 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6yLeTWnGO3LavdV2en0Nn7A8LkQ Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 20:37:46 -0000 At Tue, 19 Aug 2014 15:10:39 -0300, Fernando Gont wrote: > > If so, one possible alternative would be to drop such ICMPv6 PTB > > unless the source IPv6 address is one of those reserved for such use > > (as defined in RFC 6052). > > Source of the ICMPv6 message? I was not really accurate - I should have said the destination address of the original IPv6 packet that triggered the ICMPv6 PTB. But in this specific case, the effect should be the same in practice, since the source of the ICMPv6 PTB is the translator box, which would use the destination of the original IPv6 packet as the source of the ICMPv6. > If so, I'd say that while that's certainly > better than the current situation, unless there's widespread deployment > of BCP38, an attacker could still forge an ICMPv6 with one of such > addresses and still perform the attack.. In your previous/other messages you emphasized that the attack cannot be prevented by BCP38, seemingly to back the conclusion that completely killing PTB<1280 is the best option. Bringing the point that BCP38 isn't widely deployed once you saw a scenario where it could be a measure makes me doubt the credibility of this discussion: if your goal was to convince people with your preferred solution (which itself is perfectly fine), I'd rather see the discussion that way from the beginning, than listing possible options and soliciting general "thoughts". But anyway, even the point with the deployability of BCP38 is not that important in this case. The key part is here: >> And, unless/until we heavily rely on such >> types of translators, this may be actually sufficient in practice, >> since in the vast majority of legitimate cases we should use different >> addresses than those special ones. If SIIT-type of translators aren't really deployed at least yet (which we all seem to agree on), dropping the offending ICMPv6 PTB except for these special addresses effectively works as dropping them unconditionally. It still works better than dropping all such ICMPv6 PTB for the unlikely case of having serious deployments of SIIT, in that we don't break existing practices (although they need to decide whether to keep using it at the cost of seeing the DoS discussed here). And, while the SIIT-kind of spec may have to be revised because of this issue, we can still allow experimental/serious deployment of it at their own risk. If and when such revision of the spec is completed and reasonably deployed, we can then consider killing ICMPv6 PTB<1280 completely. > I must say that I fail to see the need for generating IPv6 atomic > fragments 8packets with a frag header, which are not really fragmented). > See e.g. what we wrote in > . > > Thoughts? I personally have no problem with deprecating atomic fragments (which would also deprecate PTB<1280 naturally); I'm not relying on SIIT myself nor I have any incentive to defend it in general. So, if others are also happy with that I'll be too. But as this thread actually shows, a proposal of deprecating something can often be controversial since it can break some existing deployment, and it's basically impossible to prove there's no such deployment (and the acceptable deployment level to justify the deprecation is often a matter of opinion). Now that I've seen such controversy, I'd personally prefer more gradual path like the "alternative approach" I mentioned. -- JINMEI, Tatuya From nobody Wed Aug 20 14:26: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 37D881A6EF3; Wed, 20 Aug 2014 14:26: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 BBoJ1zEVRkA9; Wed, 20 Aug 2014 14:26: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 229991A2119; Wed, 20 Aug 2014 14:26:31 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XKDOn-0007mz-A8; Wed, 20 Aug 2014 23:26:29 +0200 Message-ID: <53F51269.8070506@si6networks.com> Date: Wed, 20 Aug 2014 18:26:01 -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?56We5piO6YGU5ZOJ?= References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4YLbPgkhXjCUwsJR9304UDrhDCM Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:26:34 -0000 Jinmei, On 08/20/2014 05:37 PM, 神ćŽé”哉 wrote: >> If so, I'd say that while that's certainly >> better than the current situation, unless there's widespread deployment >> of BCP38, an attacker could still forge an ICMPv6 with one of such >> addresses and still perform the attack.. > > In your previous/other messages you emphasized that the attack cannot > be prevented by BCP38, seemingly to back the conclusion that > completely killing PTB<1280 is the best option. I never said that. And that certainly wasn't my line of reasoning. I emphasized that BCP38 doesn't block the attack, because BCP38 does block many/most of this sort of attack (e.g., attacks against TCP connections, etc.). Then, we came up with one possible way to mitigate this vulnerability and asked for comments. > Bringing the point > that BCP38 isn't widely deployed once you saw a scenario where it > could be a measure makes me doubt the credibility of this discussion: > if your goal was to convince people with your preferred solution > (which itself is perfectly fine), I'd rather see the discussion that > way from the beginning, than listing possible options and soliciting > general "thoughts". I asked for "thoughts" because I might have missed or overlooked something, or someone might come up with a better idea. Given options so far, I tried to analyze pros and cons. The one you suggested addresses only one of the two kinds of translators (if I understood correctly), and may still leave the door open in some scenarios. That's why I concluded that the one we originally offered still seemed like the best way to fix this. (i.e., me thinking out loud rather that anything else) >>> And, unless/until we heavily rely on such >>> types of translators, this may be actually sufficient in practice, >>> since in the vast majority of legitimate cases we should use different >>> addresses than those special ones. > > If SIIT-type of translators aren't really deployed at least yet (which > we all seem to agree on), dropping the offending ICMPv6 PTB except for > these special addresses effectively works as dropping them > unconditionally. It still works better than dropping all such ICMPv6 > PTB for the unlikely case of having serious deployments of SIIT, in > that we don't break existing practices (although they need to decide > whether to keep using it at the cost of seeing the DoS discussed > here). FWIW, the "dropping" is by the end node... and if that really is an issue, then we're already in "trouble", because it turns out that at least some boxes (some FreeBSD versions, NetBSD, and some Mac OS versions, fail to produce atomic fragments in response to ICMPv6 PTB). > And, while the SIIT-kind of spec may have to be revised > because of this issue, we can still allow experimental/serious > deployment of it at their own risk. It's really "deployment at someone *else's* risk". Because it's the folks that generate atomic fragments the ones paying the price (and not the SIIT boxes or deployments). > I personally have no problem with deprecating atomic fragments (which > would also deprecate PTB<1280 naturally); I'm not relying on SIIT > myself nor I have any incentive to defend it in general. So, if > others are also happy with that I'll be too. But as this thread > actually shows, a proposal of deprecating something can often be > controversial since it can break some existing deployment, and it's > basically impossible to prove there's no such deployment (and the > acceptable deployment level to justify the deprecation is often a > matter of opinion). What breaks what may vary from one case to another. For instance, relying on atomic fragments implies that you rely on: 1) Both ICMPv4 and ICMPv6 messages not being filtered 2) IPv6 fragments not being filtered 3) Nodes reacting to ICMPv6 PTB<1280 Both 1 through 3 vary from one environment to another... but I'm of the idea that the lest you rely on them, the better. Thanks! 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 Aug 20 14:39: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 9E46C1A6F0C; Wed, 20 Aug 2014 14:39:52 -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 Ukja48YQ6wkV; Wed, 20 Aug 2014 14:39:49 -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 5E7321A8826; Wed, 20 Aug 2014 14:39:43 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s7KLdA4l021830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Aug 2014 14:39:11 -0700 (PDT) Message-ID: <53F51582.3010003@isi.edu> Date: Wed, 20 Aug 2014 14:39:14 -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: Lorenzo Colitti , Fernando Gont References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> In-Reply-To: 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/IQ6cwZDux4EzaqkFJHf5dDR-sFI Cc: IPv6 Operations , "opsec@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:39:52 -0000 On 8/19/2014 3:29 PM, Lorenzo Colitti wrote: > On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont > wrote: > > I must say that I fail to see the need for generating IPv6 atomic > fragments 8packets with a frag header, which are not really fragmented). > See e.g. what we wrote in > . > > > It does seem kind of silly that we say "you must support MTU >= 1280 to > run IPv6" and then allow PTB packets with an MTU < 1280. Any reason we > can't simply say that PTB packets < 1280 are invalid? I can't see a good reason that the INT area couldn't do this. I see many reasons why V6OPS shouldn't be deciding this. Joe From nobody Wed Aug 20 15:20: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 BC5AE1A894E for ; Wed, 20 Aug 2014 15:20:03 -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 cqdl4N3lBxyz for ; Wed, 20 Aug 2014 15:20:00 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E8A1A894B for ; Wed, 20 Aug 2014 15:19:59 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so12975411pad.7 for ; Wed, 20 Aug 2014 15:19:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6wcpzfMChGUd8U5tRFTTSvu8hfjqaUQJogGzblmfUV4=; b=PqMhhf6yMA7WWFzmqxPOnz3eXFhpRszTP2ugzrrVG29DFnJ4AVK53ZFIUou7vrpCR1 S/q7GEHvPp+upMfjMkn2FpMYpyviL9x0twNJ2q7SDpEOt7NEgb7N0wA+aecTiWfUEsWh jf+C7j8Jia7c2C4wYmsvCJxG66kOoyPdE2VQAZLF2w8tM+HuqHAgTpmpJi15rXjXygUL 0V3y+vscEmvE6f6/p6u5dkQEV9xMQQODm8olHCghiulz1CrdbIYGsFD0m/JClbot3sWY PSC8vKT3NdGMKkoL7Aln/2nuEo39tRn/HDAGxJGNCmAKJEe+Adq3VmfjX+1ESXbueniK 91gw== X-Gm-Message-State: ALoCoQnSPpDt1XG/vUGgRj5fTtbRJfRRtqPwWARXs2nFmEh4nUa6KRarOtxopqqpb05bNzL1RktS X-Received: by 10.68.68.234 with SMTP id z10mr55763529pbt.59.1408573199450; Wed, 20 Aug 2014 15:19:59 -0700 (PDT) Received: from [172.19.254.174] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by mx.google.com with ESMTPSA id ou2sm30754709pdb.17.2014.08.20.15.19.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 15:19:58 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Roland Dobbins In-Reply-To: <53F51582.3010003@isi.edu> Date: Thu, 21 Aug 2014 05:19:48 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F51582.3010003@isi.edu> To: "opsec@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qjMioZXqpV43KGOMNWx20XhaKVU Cc: IPv6 Operations Subject: Re: [v6ops] [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 22:20:04 -0000 On Aug 21, 2014, at 4:39 AM, Joe Touch wrote: > I can't see a good reason that the INT area couldn't do this. Personally, I don't think it's practical, given the realities of legacy = deployments, et. al. > I see many reasons why V6OPS shouldn't be deciding this. Concur 100%. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco=F6n From nobody Wed Aug 20 18:07: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 32A4A1A6F97; Wed, 20 Aug 2014 18:07:25 -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 qbp57lIkyg2C; Wed, 20 Aug 2014 18:07:24 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D0B1A0027; Wed, 20 Aug 2014 18:07:23 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so8657812wgh.32 for ; Wed, 20 Aug 2014 18:07:21 -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=6xJP+fndDEfW3sNzb8gbnwqnWmza4whyJrHhnJ/YeD0=; b=rEZmIps4A/NsowR+rH8SKH8SHYz3DGKyYSM9Q9zyr0kTRzc1xFCF5Vra1Nvh/gHII1 NX6OvGH3dMByejEQ5vVyX5Vv8I6hhtRUjzwfljl2FGZO8yx6cSC86oam8DMzyXHBXY2d dRX2SVQaG3uIAM4aeRVRjh9fUOQnv0Jvijta43lgdxL2FoEgGhz1bN6NinbvmcczCmQj eB0w8FJGCJW2UWn3iUnJORhPCSvTaM96C9xJaKcHjP+sbXFiyVr1I+i7uTdSgG8PcPo1 j6/hRTzGDtH4yREHNNSwLTdSz5D1BztZmIlJ4YtZM2YHi9Jbz7JzH0LaKVj79OmEfz38 fifg== MIME-Version: 1.0 X-Received: by 10.194.62.104 with SMTP id x8mr64782718wjr.7.1408583241922; Wed, 20 Aug 2014 18:07:21 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Wed, 20 Aug 2014 18:07:21 -0700 (PDT) In-Reply-To: <53F51269.8070506@si6networks.com> References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F51269.8070506@si6networks.com> Date: Wed, 20 Aug 2014 18:07:21 -0700 X-Google-Sender-Auth: TcTSDfnqhuDnlX0IT5Y7BVNJn10 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9k7BJ9IpHJygt5cfGXQ_Rxsw3Ik Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 01:07:25 -0000 At Wed, 20 Aug 2014 18:26:01 -0300, Fernando Gont wrote: > [...] The one you suggested addresses > only one of the two kinds of translators (if I understood correctly), > and may still leave the door open in some scenarios. Specifically? > > And, while the SIIT-kind of spec may have to be revised > > because of this issue, we can still allow experimental/serious > > deployment of it at their own risk. > > It's really "deployment at someone *else's* risk". Because it's the > folks that generate atomic fragments the ones paying the price (and not > the SIIT boxes or deployments). If the deployment/experiment of SIIT is real but we still ban PTB<1280 as a first step of revision, they (= someone *else*) will need to pay some price anyway: either they can be susceptible to the DoS in question or they can see some strange failure when IPv4 fragmentation is needed. Certainly, we should fix SIIT(-kind) of translators for a longer term. So it seems to me the question of which kind of cost we ask "them" for paying until then. I thought the gradual approach would be less controversial than an abrupt ban and allow us to use our time more efficiently, so I mentioned it (I actually didn't intend to "suggest" it, as I personally don't have a strong stake on it). I know you have a different opinion and I respect that. I just wish it would be accepted smoothly. > > I personally have no problem with deprecating atomic fragments (which > > would also deprecate PTB<1280 naturally); I'm not relying on SIIT > > myself nor I have any incentive to defend it in general. So, if > > others are also happy with that I'll be too. But as this thread > > actually shows, a proposal of deprecating something can often be > > controversial since it can break some existing deployment, and it's > > basically impossible to prove there's no such deployment (and the > > acceptable deployment level to justify the deprecation is often a > > matter of opinion). > > What breaks what may vary from one case to another. For instance, > relying on atomic fragments implies that you rely on: > > 1) Both ICMPv4 and ICMPv6 messages not being filtered > 2) IPv6 fragments not being filtered > 3) Nodes reacting to ICMPv6 PTB<1280 > > Both 1 through 3 vary from one environment to another... but I'm of the > idea that the lest you rely on them, the better. Same as above. It just seems to be that we have different expectations on the feasibility of options from different point of views. As you still seem to believe your preferred option is more feasible in terms of the standardization process, I have nothing more to say; I have no reason to push the alternative I mentioned, so please simply ignore it and try to persuade others. -- JINMEI, Tatuya From nobody Thu Aug 21 00:18: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 39C8B1A0681; Thu, 21 Aug 2014 00:18: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 uQXiUyIJh0NR; Thu, 21 Aug 2014 00:18: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 420111A0652; Thu, 21 Aug 2014 00:18:32 -0700 (PDT) Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XKMdf-0004wH-Tm; Thu, 21 Aug 2014 09:18:28 +0200 Message-ID: <53F590A2.2090101@si6networks.com> Date: Thu, 21 Aug 2014 03:24:34 -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?56We5piO6YGU5ZOJ?= References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F51269.8070506@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A98IBETt8i6dLYlkOMyPnq0kv0o Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 07:18:35 -0000 On 08/20/2014 10:07 PM, 神ćŽé”哉 wrote: > At Wed, 20 Aug 2014 18:26:01 -0300, > Fernando Gont wrote: > >> [...] The one you suggested addresses >> only one of the two kinds of translators (if I understood correctly), >> and may still leave the door open in some scenarios. > > Specifically? Well, you can only really apply the suggested check to the stateless translation scenario. But since a host does not now where it will be deployed, it cannot (out of the box) require that e.g. ICMPv6 PTB<1280 use any specific part of the address space. Put another way, the mitigation would not "just work out of the box" for any of the servers running on the public Internet. And then, for the scenarios "a" or "c" from Section 2 of RFC6144, you still need to enforce filtering to prevent attacks within the IPv6 network. >>> And, while the SIIT-kind of spec may have to be revised >>> because of this issue, we can still allow experimental/serious >>> deployment of it at their own risk. >> >> It's really "deployment at someone *else's* risk". Because it's the >> folks that generate atomic fragments the ones paying the price (and not >> the SIIT boxes or deployments). > > If the deployment/experiment of SIIT is real but we still ban > PTB<1280 as a first step of revision, they (= someone *else*) will > need to pay some price anyway: either they can be susceptible to the > DoS in question or they can see some strange failure when IPv4 > fragmentation is needed. Certainly, we should fix SIIT(-kind) > of translators for a longer term. So it seems to me the question of > which kind of cost we ask "them" for paying until then. Reading though RFC6145, I see that in quite a few places the spec considers "configuration options" and the like t be able to cope with IPv6 packet drops, and fragmentation -- but for a different than security (the ones that I've mentioned below). For instance, Section 6 of RFC6145 says: Two recent studies analyzed the behavior of IPv6-capable web servers on the Internet and found that approximately 95% responded as expected to an IPv6 Packet Too Big that indicated MTU = 1280, but only 43% responded as expected to an IPv6 Packet Too Big that indicated an MTU < 1280. Put another way, we are leaving the door open to attack due to something that is giving us a 60% failure rate already. > I thought the gradual approach would be less controversial than an > abrupt ban and allow us to use our time more efficiently, so I > mentioned it Just a request for clarification: The "gradual path" would be to enforce additional requirements on the ICMPv6 PTB messages? >> What breaks what may vary from one case to another. For instance, >> relying on atomic fragments implies that you rely on: >> >> 1) Both ICMPv4 and ICMPv6 messages not being filtered >> 2) IPv6 fragments not being filtered >> 3) Nodes reacting to ICMPv6 PTB<1280 >> >> Both 1 through 3 vary from one environment to another... but I'm of the >> idea that the lest you rely on them, the better. > > Same as above. It just seems to be that we have different > expectations on the feasibility of options from different point of > views. As you still seem to believe your preferred option is more > feasible in terms of the standardization process, I have no idea about which options is "more feasible in terms of standardization process", to be honest. For the time being, I'm just rethinking/re-evaluating options, even if just for the technical/mental exercise of figuring out what would be the best approach. And kind of hope that if the analysis is correct, that may result in "feasibility in terms of standardization process". -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Aug 21 02:41: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 0D3881A00D7 for ; Thu, 21 Aug 2014 02:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.499 X-Spam-Level: ** X-Spam-Status: No, score=2.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MANGLED_SONATA=2.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 KisrclzVTGUg for ; Thu, 21 Aug 2014 02:41:09 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id E80C71A00D1 for ; Thu, 21 Aug 2014 02:41:08 -0700 (PDT) Received: from [85.158.136.3:37899] by server-3.bemta-5.messagelabs.com id 87/39-13873-3BEB5F35; Thu, 21 Aug 2014 09:41:07 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-10.tower-123.messagelabs.com!1408610925!40253951!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10542 invoked from network); 21 Aug 2014 08:48:45 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-10.tower-123.messagelabs.com with SMTP; 21 Aug 2014 08:48:45 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Thu, 21 Aug 2014 09:57:49 +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; Thu, 21 Aug 2014 09:48:33 +0100 From: "Heatley, Nick" To: Mark Andrews , "IPv6 Ops WG (v6ops@ietf.org)" Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvAuWkAgAAE0QCAABWsAIAAcMQAgAAl34CAAJ+zAIAADBCAgAAFpYCAAA64AIAAG/gAgAAekRv///gCAIAAJVUSgAHRDICAALyKgIAAAbUAgAFImdCAEmJweIACF28ggAAE+3A= Date: Thu, 21 Aug 2014 08:48:34 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303B7E97B@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> 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/l3xVN3zbTfEtI0RsvWeKgph4pIY Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 09:41:11 -0000 Hi Mark, If you are saying even new customers / truck rolls, end up with a legacy = CPE, then I see the predicament. But you are basically saying NAT44 is inevitable when all you have is sup= port for IPv4. I don't intend to detract from NAT44 in that context. The context of my rant was the across the broad family of "dual stack typ= e technologies" in conjunction with NAT. Some appear to move us further forward than others, what is holding us ba= ck? BR, Nick -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Andrews Sent: 20 August 2014 01:34 To: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment In message <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.E= EINT.C O.UK>, "Heatley, Nick" writes: > If I may stick my neck out. >=20 > Id like v6ops to consider at least two items: >=20 > 1. (Carrier Grade) NAT64 vs NAT44 a deathmatch. =09Most of the problem with NAT64 vs NAT44 is getting CPE =09devices upgraded. 464xlate worked for cellular networks =09because the devices were replaced to support 4G services =09and those new devices support 464xlate. Additionally cell =09phones are fragile devices that get stolen, lost, dropped, =09stepped on, driven over, and is some market need to be =09replaced to change carrier ... so there is a high turnover. =09For wired connections there is no incentive for the customer =09to replace the CPE device so NAT44 is a required part of =09the solution space just to share the limited IPv4 address =09space between the IPv4 only customers. Cable and DSL modems =09work for 10+ years. Home routers work for similar lengths =09of time. You can still buy IPv4 only routers and they are =09cheaper than anything with IPv6 in it. If you are on a =09limited budget a IPv4 only router with 802.11g "will do". =09Add to that ISP's not offering / promoting IPv6 there is =09no incentive for the customer to buy the IPv6 capable device =09over the IPv4 only one. The choice of device is made on =09other factors. If ISPs offered to do 2G of IPv6 data for =09the price of 1G of IPv4 data one might actually get customers =09to buy IPv6 capable routers. A 12 month rebate for installing =09a IPv6 capable CPE device could offset the costs of installing =09more CGNAT boxes. IPv6 capable 802.11n routers can be got =09for AUD80 today. Even on a AUD$20 plan the rebates would =09cover the costs if the usual +50% taffic shift to IPv6 =09occurs. =09Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ 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 Aug 21 07:11: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 3CEDC1A0369; Thu, 21 Aug 2014 07:11:10 -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 PxJQjA4gZiQV; Thu, 21 Aug 2014 07:11:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE4E1A0337; Thu, 21 Aug 2014 07:11:08 -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: <20140821141108.29977.74861.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 07:11:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uu4p17icw9un5A4kBCzt8SzkVFE Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:11:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Roaming Behavior Analysis Authors : Gang Chen Hui Deng Dave Michaud Jouni Korhonen Mohamed Boucadair Vizdal Ales Filename : draft-ietf-v6ops-ipv6-roaming-analysis-04.txt Pages : 19 Date : 2014-08-21 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 21 19:47: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 7493F1A87D9 for ; Thu, 21 Aug 2014 19:47:43 -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 v6ZcGnBvnYN9 for ; Thu, 21 Aug 2014 19:47:41 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7E81A87D7 for ; Thu, 21 Aug 2014 19:47:40 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j7so9256231qaq.28 for ; Thu, 21 Aug 2014 19:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GJKIf4FUlTf+CKOUPay5mY/soJtnb7VunHcj5giMbHg=; b=bXq8L85zF2EuN9cHrv5bxhvqlDubmF+Dd3fyKVV0bdxZKTF9JI62QAsi5OK5vo2lSu kbqfhDEqH+XvC6hnD5KTq1aIP0QuUvD3tcprW82QKX43k8+5IQ7uiR1QkGxEr9/dIktA Htjw95TIkJfyI3wxtilkYOUpnefbszabrJ7Rh0Mt2Prc/GbwAmv+bfAIyf8FNG9qjMIq nhupQX/pqA2FX2gTFHC7Hg00c98h5Jyv+aLI5aj1lpwYOks8kAq+hrMmr46V67WXYuM7 mndf8lcaE63PeFhQyTb+UJgP+8gHVGfzBlI6g76HRqYBe+ujPeTSaKNdaPU9yAGXAaAk eiCg== X-Received: by 10.224.130.201 with SMTP id u9mr4115628qas.58.1408675660245; Thu, 21 Aug 2014 19:47:40 -0700 (PDT) Received: from [192.168.1.10] ([181.208.224.104]) by mx.google.com with ESMTPSA id l76sm32066631qga.8.2014.08.21.19.47.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 19:47:39 -0700 (PDT) Message-ID: <53F6AF4B.1070209@gmail.com> Date: Thu, 21 Aug 2014 22:17:39 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cB9OaXm23QE3_xtMTt3bWFwReK0 Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 02:47:43 -0000 El 8/19/2014 5:59 PM, Lorenzo Colitti escribió: > On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont > wrote: > > I must say that I fail to see the need for generating IPv6 atomic > fragments 8packets with a frag header, which are not really fragmented). > See e.g. what we wrote in > . > > > It does seem kind of silly that we say "you must support MTU >= 1280 to > run IPv6" and then allow PTB packets with an MTU < 1280. Any reason we > can't simply say that PTB packets < 1280 are invalid? Personally, it makes a lot of sense to me. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Aug 22 09:38: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 8BB0A1A041D; Fri, 22 Aug 2014 09:38:35 -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 iW2fYM6M3EXO; Fri, 22 Aug 2014 09:38:34 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0202E1A0413; Fri, 22 Aug 2014 09:38:33 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so10438464wiv.7 for ; Fri, 22 Aug 2014 09:38:32 -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=ce+U01500Zz23EY8CbvMR5WVG+MHnbJkYsfvi5PGtzo=; b=G3fEepgXC5xHmXd+QMGfHAUkOT+CrBmhpJ5lTsK5B8LOLM4y4WRvVvpsToLkrtcPV+ f+z5vpp/iTgvBJkGRtYVXCQyHKUqurYAg/XtzCai9nReGm27N0RsD4jQCcaU2CTRZx5q 74cgxlU+VAC9p+QS6MSFAcvYO9Hfvd5L7IVFJkCzQb0t5rvzJ9O3j+GY+P1Kz0TCOWKP rwwPPUKodW6+5uObOI4fh3sIcvKR2yilBh8IkqQP10EcSt5qUSjypUYFfTf4xh7xcRXp 6LHkS1nsIkBsO0rmqgxoVU5fwnX9hhXl3ph714xYlfYil4AgYVT7aqlOlNRCKQavy9zu mUxg== MIME-Version: 1.0 X-Received: by 10.194.20.230 with SMTP id q6mr6428201wje.43.1408725512679; Fri, 22 Aug 2014 09:38:32 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Fri, 22 Aug 2014 09:38:32 -0700 (PDT) In-Reply-To: <53F590A2.2090101@si6networks.com> References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F51269.8070506@si6networks.com> <53F590A2.2090101@si6networks.com> Date: Fri, 22 Aug 2014 09:38:32 -0700 X-Google-Sender-Auth: J7kaeZ6ImAauuyVClgZmEgumTjY Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DPZykQzOhs7Onf8vtWtNcSLw1o8 Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:38:35 -0000 At Thu, 21 Aug 2014 03:24:34 -0300, Fernando Gont wrote: > >> [...] The one you suggested addresses > >> only one of the two kinds of translators (if I understood correctly), > >> and may still leave the door open in some scenarios. > > > > Specifically? > > Well, you can only really apply the suggested check to the stateless > translation scenario. Yes, and I thought we'd be okay with that, based on the assumption/understanding that PTB<1280 is only useful for stateless translation scenarios (and that's why I first asked this in my very original message of this thread). > But since a host does not now where it will be > deployed, it cannot (out of the box) require that e.g. ICMPv6 PTB<1280 > use any specific part of the address space. > > Put another way, the mitigation would not "just work out of the box" for > any of the servers running on the public Internet. > > And then, for the scenarios "a" or "c" from Section 2 of RFC6144, you > still need to enforce filtering to prevent attacks within the IPv6 network. Do you mean this mitigation isn't effective if the well-known prefix (64:ff9b::/96) isn't used for the IPv4-Embedded IPv6 Addresses in the stateless translation scenario? If so, that's correct, and I have to confess I don't remember all details and variations of translation technologies and I assumed that stateless translation always uses the well-known prefix. Maybe I was incorrect about that? -- JINMEI, Tatuya From nobody Fri Aug 22 10: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 655901A06C4 for ; Fri, 22 Aug 2014 10:45:25 -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 0f1jt49P4t3R for ; Fri, 22 Aug 2014 10:45:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2C41A067F for ; Fri, 22 Aug 2014 10:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2764; q=dns/txt; s=iport; t=1408729523; x=1409939123; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=t5n5vWFcDkVphKlZhpbSba1Cb98hUsReaH2hP4R6juk=; b=FUr2LUkRaZdrGXWH5yuS36A1NgZGZkkccqI54m3wFYB5Xw/5voOTzZfh 4XbuITXFVefE5W/6GMlddIHMBEUEB/avZpaV7g5pODB2KahYYP/iiWOKp iqZRDDtJhk0iX/YsgY5CeH5xgDVVy2hT+fAbqjFpJbW+dKoYMVc2VhD2E U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFALuA91OtJV2R/2dsb2JhbABZgw1TUwQEzFAMh0oBgRAWd4QEAQEDAQEBAWsbAgEIRicLJQIEEwkFiCwICAXEXhePU4MvgR0FkSaCA4FKXIZ6gViTNINebIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="asc'?scan'208";a="349552280" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 22 Aug 2014 17:45:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7MHjMoF005643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Aug 2014 17:45:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 12:45:22 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-04.txt Thread-Index: AQHPvjDY5s20XJbymUCUCEDxyvex9w== Date: Fri, 22 Aug 2014 17:45:21 +0000 Message-ID: References: <20140821141108.29977.74861.idtracker@ietfa.amsl.com> In-Reply-To: <20140821141108.29977.74861.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.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_D9ADE8E4-BAEC-4D74-9E37-5FFAFBA18B58"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XJ9HGDMZwYyLuvTtFKGX9JpxP7U Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:45:25 -0000 --Apple-Mail=_D9ADE8E4-BAEC-4D74-9E37-5FFAFBA18B58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gang Chen has been following up on the list discussion, and thinks this = addresses all of the comments on the list. Are there any remaining = issues, or shall I send this in? Fred On Aug 21, 2014, at 7:11 AM, 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 : IPv6 Roaming Behavior Analysis > Authors : Gang Chen > Hui Deng > Dave Michaud > Jouni Korhonen > Mohamed Boucadair > Vizdal Ales > Filename : draft-ietf-v6ops-ipv6-roaming-analysis-04.txt > Pages : 19 > Date : 2014-08-21 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-04 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-roaming-analysis-= 04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_D9ADE8E4-BAEC-4D74-9E37-5FFAFBA18B58 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 iD8DBQFT94GvbjEdbHIsm0MRAgdKAJ9u8zTsU6rA0B5AxkWEMzL+2C7iSQCgmc4S OfLzbjKmwmcIXOIOUTWjxZE= =O9P0 -----END PGP SIGNATURE----- --Apple-Mail=_D9ADE8E4-BAEC-4D74-9E37-5FFAFBA18B58-- From nobody Sat Aug 23 00:48: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 CB0E01A8719; Sat, 23 Aug 2014 00:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 pxFci4YwJN0R; Sat, 23 Aug 2014 00:48:49 -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 83EDF1A871A; Sat, 23 Aug 2014 00:48:49 -0700 (PDT) Received: from [2a02:fe0:c411:a000::2] (port=60332 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XL643-0002OX-9d; Sat, 23 Aug 2014 09:48:43 +0200 Message-ID: <53F8475A.1090800@fud.no> Date: Sat, 23 Aug 2014 09:48:42 +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: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fernando Gont References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F51269.8070506@si6networks.com> <53F590A2.2090101@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-GHxzGHy-t6Uf_zSrAAEuFKlEe0 Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 07:48:51 -0000 Hello 神ćŽé”哉, > I assumed that stateless translation always uses the well-known > prefix. Maybe I was incorrect about that? Yes, that is incorrect. Per RFC 6052 the operator can use either the Well-Known Prefix and a Network-Specific Prefix. There are quite few reasons why one would choose the latter; for example it allows for the translating device to be reached across the public internet. Another reason is that only a single WKP exists, so if the operator wants to deploy both SIIT and NAT64, and/or multiple instances of either technology, all of his deployments (except for one), must necessarily use an NSP. Tore From nobody Mon Aug 25 04:47: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 8584F1A9043 for ; Mon, 25 Aug 2014 04:47:05 -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 vMfOAgkewFQD for ; Mon, 25 Aug 2014 04:47:04 -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 417291A9040 for ; Mon, 25 Aug 2014 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=148; q=dns/txt; s=iport; t=1408967225; x=1410176825; h=date:from:message-id:to:subject:cc; bh=1FtMEqhqXGDBuJ+losOlSpPzpgxzp+tX2ZcuGNYz+hA=; b=dxicaZ0euilYpLvtFbWUpXtsYhnWWYwY4Ow4DnUmXiL+XCZJBzAOM34b scQRklOSsHdnq9f76UYm2Al9iWPfmFrOGc/laHMX0QhVkzTUzDhPYwYis hjlyQGwQVLLtXApFqVlVExMrQBnBXsLWkkLl4pAkvOtHJ4JBi3OUpp5l0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoJAIsh+1OtJV2a/2dsb2JhbABagw1TWLJPAZoIh0IJgR8Wd4UDPDSJIgENwAoXj0wdhDYFiyKKLYhSkzSDfoMbAQEB X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208";a="72078824" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 25 Aug 2014 11:47:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7PBl2Nw004096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 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 s7PBl2X6010103; Mon, 25 Aug 2014 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s7PBl2b6010099; Mon, 25 Aug 2014 04:47:02 -0700 Date: Mon, 25 Aug 2014 04:47:02 -0700 From: fred@cisco.com Message-Id: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TQ_ugHaGhRLErL9oFj7xreNymEo Cc: draft-v6ops-pmtud-ecmp-problem.ietf.org@cisco.com Subject: [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, 25 Aug 2014 11:47:05 -0000 A new draft has been posted, at http://datatracker.ietf.org/wg/v6ops/charter/draft-v6ops-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Mon Aug 25 06:58: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 CB1521A8960 for ; Mon, 25 Aug 2014 06:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.186 X-Spam-Level: * X-Spam-Status: No, score=1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, 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 Wg6Lw8duaM-y for ; Mon, 25 Aug 2014 06:58:26 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9541A8954 for ; Mon, 25 Aug 2014 06:58:24 -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 CJS41150; Mon, 25 Aug 2014 15:58:18 +0200 (CEST) From: Kossut Tomasz - Hurt To: "Eric Vyncke (evyncke)" , Lorenzo Colitti Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPswOAKp4cYlfWs0iK+WcgE96R8pvGrYlQgBq87TA= Date: Mon, 25 Aug 2014 13:57:29 +0000 Message-ID: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE766BCOPE10MB06tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.8.25.125725: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, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, ECARD_KNOWN_DOMAINS, __STOCK_PHRASE_7, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0208.53FB40FA.0218, 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.0A0C0208.53FB40FA.0218, 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: 3b4cc769aff48891f03de6b30b037e7c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2_6Bm3-3OKjnD_Flb7RwCwxlixw Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:58:27 -0000 --_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE766BCOPE10MB06tpgkco_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable HI, Ipv6 traffic for OPL Ipv6 mobile subscribers returns to its "normal" values= . Native Ipv6=3D60%,NAT64=3D40%* *- mainly national content, If polish national top 10 Alexa content becomes= Ipv6 then 90% traffic will be Ipv6... So if you now IPv6 readiness for your national top Alexa sites you can esti= mate how much NAT64 you can expect. Regards, TK From: Kossut Tomasz - Hurt Sent: Friday, August 08, 2014 4:19 PM To: 'Eric Vyncke (evyncke)'; Lorenzo Colitti Cc: IPv6 Ops WG Subject: RE: [v6ops] Operational Consensus on deployment Hi, Internet traffic for OPL ipv6 -464xlat users (3G/4G) Traffic till mid-July: Ipv6 -60% (78% to Google) Nat64 -40% Traffic from mid-July up to now: Ipv6 - 40%* (50% to Google) Nat64- 60% *On W28 we noticed abnormal drop of AAAA queries generated by users. It loo= ks like some DS servers becomes Ipv4 only, or web browser ipv4 fallback tak= es place more often.. (we analyzing data) Regards, Tomasz From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] Sent: Friday, August 08, 2014 2:12 PM To: Lorenzo Colitti Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment Lorenzo For my education, do you have a pointer for a data point on: From: Lorenzo Colitti > A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% NAT64= , and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's only us= ed for 5% of traffic, then the operator might just say, "Who cares? I don't= ; and if somebody else does, they're free to use IPv6." --_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE766BCOPE10MB06tpgkco_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

HI,

Ipv6 traff= ic for OPL Ipv6 mobile subscribers returns to its “normal” valu= es.

Native Ipv= 6=3D60%,NAT64=3D40%*

 = ;

*- mainly = national content, If polish national top 10 Alexa content becomes Ipv6 then= 90% traffic will be Ipv6…

So if you = now IPv6 readiness for your national top Alexa sites you can estimate how m= uch NAT64 you can expect.

 = ;

Regards,

TK

 = ;

 = ;

From: Kossut T= omasz - Hurt
Sent: Friday, August 08, 2014 4:19 PM
To: 'Eric Vyncke (evyncke)'; Lorenzo Colitti
Cc: IPv6 Ops WG
Subject: RE: [v6ops] Operational Consensus on deployment<= /span>

 

Hi,

Internet t= raffic for OPL ipv6 -464xlat users (3G/4G)

Traffic ti= ll mid-July:

Ipv6 -60% = (78% to Google)

Nat64 -40%=

Traffic fr= om mid-July up to now:

Ipv6 ̵= 1; 40%* (50% to Google)

Nat64- 60%=

 = ;

*On W28 we= noticed abnormal drop of AAAA queries generated by users. It looks like so= me DS servers becomes Ipv4 only, or web browser ipv4 fallback takes place more often.. (we analyzing data)

 = ;

Regards,

Tomasz

 = ;

From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]
Sent: Friday, August 08, 2014 2:12 PM
To: Lorenzo Colitti
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Operational Consensus on deployment<= /span>

 

Lorenzo

 

For my education, do you ha= ve a pointer for a data point on:

 

From: Lorenzo Colitti <lorenzo@google.com>

A 4G handset with 464xlat w= ill have ~50% of traffic native IPv6, ~45% NAT64, and ~5% 464xlat. 464 conv= ersion is lossy and brittle, but if it's only used for 5% of traffic, then the operator might just say, "Who cares? I don't; an= d if somebody else does, they're free to use IPv6."<= /p>

--_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE766BCOPE10MB06tpgkco_-- From nobody Mon Aug 25 07:01:48 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 825281A8963 for ; Mon, 25 Aug 2014 07:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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=-0.668, 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 WqNXm7VCVAQr for ; Mon, 25 Aug 2014 07:01:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446721A8973 for ; Mon, 25 Aug 2014 07:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19048; q=dns/txt; s=iport; t=1408975302; x=1410184902; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DnvZItSIPA09hqNzRvEAlSx7TMGOGof3xaCpGTS0bPQ=; b=XcPTX8gnD9bW8ILS5s3/3dqkhI4b0l0cxM6c3tWHMvUtXt6jW6MzFZ/8 i/SMfW4e8yvyKjSwkQuE5eMxbNAd9+i4rENpC3tpv2MRt8fMR+bXQxi2l rlvs/fK5Gx/of2JXS1LhY9tBV6s5Fv0ruR3uhXEz5v8Aorg/OjIhuZeqT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAPVA+1OtJV2d/2dsb2JhbABZgkcjI1NXBIJ40SgBGYEHFneEAwEBAQQjCkwQAgEIEQMBAQEoAwICAjAUCQgCBAENBRaILAGrW5RAF48oExEGAYJ5gVMFhQQCjCCLI5UMg15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208,217";a="350072646" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 25 Aug 2014 14:01:41 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7PE1fSu025491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 14:01:41 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 09:01:41 -0500 From: "Eric Vyncke (evyncke)" To: Kossut Tomasz - Hurt , Lorenzo Colitti Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvGrYlQgBq87TCAAIUHgA== Date: Mon, 25 Aug 2014 14:01:40 +0000 Message-ID: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.70] Content-Type: multipart/alternative; boundary="_000_D0210E0C28BDEevynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lKQeCazQXpEu_TdMuYvV6yAiqck Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:01:46 -0000 --_000_D0210E0C28BDEevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXBkYXRl4oCmIGFuZCBpbmRlZWQsIGluIG5vbi1FbmdsaXNoIG5hdGl2 ZSBjb3VudHJpZXMgKGxpa2UgbWluZSksIGxvY2FsIGNvbnRlbnQgaXMgaW1wb3J0YW504oCmIGJ1 dCB2ZXJ5IGRpZmZpY3VsdCB0byBnZXQgbW92aW5nIHRvIElQdjYgKEkgbWVhbiB0aGUgYnVzaW5l c3MvcG9saXRpY2FsIHJlYXNvbiB0byBtb3ZlLCBub3QgdGhlIHRlY2huaWNhbCBtb3ZlIGl0c2Vs ZiB3aXRoIHRoZSBoZWxwIG9mIENETikNCg0KLcOpcmljDQoNCkZyb206IEtvc3N1dCBUb21hc3og LSBIdXJ0IDxUb21hc3ouS29zc3V0QG9yYW5nZS5jb208bWFpbHRvOlRvbWFzei5Lb3NzdXRAb3Jh bmdlLmNvbT4+DQpEYXRlOiBsdW5kaSAyNSBhb8O7dCAyMDE0IDE1OjU3DQpUbzogRXJpYyBWeW5j a2UgPGV2eW5ja2VAY2lzY28uY29tPG1haWx0bzpldnluY2tlQGNpc2NvLmNvbT4+LCBMb3Jlbnpv IENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPj4N CkNjOiBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4s IEN6ZXJ3b25rYSBNaWNoYcWCIDEgLSBIdXJ0IDxNaWNoYWwuQ3plcndvbmthMUBvcmFuZ2UuY29t PG1haWx0bzpNaWNoYWwuQ3plcndvbmthMUBvcmFuZ2UuY29tPj4NClN1YmplY3Q6IFJFOiBbdjZv cHNdIE9wZXJhdGlvbmFsIENvbnNlbnN1cyBvbiBkZXBsb3ltZW50DQoNCkhJLA0KSXB2NiB0cmFm ZmljIGZvciBPUEwgSXB2NiBtb2JpbGUgc3Vic2NyaWJlcnMgcmV0dXJucyB0byBpdHMg4oCcbm9y bWFs4oCdIHZhbHVlcy4NCk5hdGl2ZSBJcHY2PTYwJSxOQVQ2ND00MCUqDQoNCiotIG1haW5seSBu YXRpb25hbCBjb250ZW50LCBJZiBwb2xpc2ggbmF0aW9uYWwgdG9wIDEwIEFsZXhhIGNvbnRlbnQg YmVjb21lcyBJcHY2IHRoZW4gOTAlIHRyYWZmaWMgd2lsbCBiZSBJcHY24oCmDQpTbyBpZiB5b3Ug bm93IElQdjYgcmVhZGluZXNzIGZvciB5b3VyIG5hdGlvbmFsIHRvcCBBbGV4YSBzaXRlcyB5b3Ug Y2FuIGVzdGltYXRlIGhvdyBtdWNoIE5BVDY0IHlvdSBjYW4gZXhwZWN0Lg0KDQpSZWdhcmRzLA0K VEsNCg0KDQpGcm9tOiBLb3NzdXQgVG9tYXN6IC0gSHVydA0KU2VudDogRnJpZGF5LCBBdWd1c3Qg MDgsIDIwMTQgNDoxOSBQTQ0KVG86ICdFcmljIFZ5bmNrZSAoZXZ5bmNrZSknOyBMb3JlbnpvIENv bGl0dGkNCkNjOiBJUHY2IE9wcyBXRw0KU3ViamVjdDogUkU6IFt2Nm9wc10gT3BlcmF0aW9uYWwg Q29uc2Vuc3VzIG9uIGRlcGxveW1lbnQNCg0KSGksDQpJbnRlcm5ldCB0cmFmZmljIGZvciBPUEwg aXB2NiAtNDY0eGxhdCB1c2VycyAoM0cvNEcpDQpUcmFmZmljIHRpbGwgbWlkLUp1bHk6DQpJcHY2 IC02MCUgKDc4JSB0byBHb29nbGUpDQpOYXQ2NCAtNDAlDQpUcmFmZmljIGZyb20gbWlkLUp1bHkg dXAgdG8gbm93Og0KSXB2NiDigJMgNDAlKiAoNTAlIHRvIEdvb2dsZSkNCk5hdDY0LSA2MCUNCg0K Kk9uIFcyOCB3ZSBub3RpY2VkIGFibm9ybWFsIGRyb3Agb2YgQUFBQSBxdWVyaWVzIGdlbmVyYXRl ZCBieSB1c2Vycy4gSXQgbG9va3MgbGlrZSBzb21lIERTIHNlcnZlcnMgYmVjb21lcyBJcHY0IG9u bHksIG9yIHdlYiBicm93c2VyIGlwdjQgZmFsbGJhY2sgdGFrZXMgcGxhY2UgbW9yZSBvZnRlbi4u ICh3ZSBhbmFseXppbmcgZGF0YSkNCg0KUmVnYXJkcywNClRvbWFzeg0KDQpGcm9tOiBFcmljIFZ5 bmNrZSAoZXZ5bmNrZSkgW21haWx0bzpldnluY2tlQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwg QXVndXN0IDA4LCAyMDE0IDI6MTIgUE0NClRvOiBMb3JlbnpvIENvbGl0dGkNCkNjOiBJUHY2IE9w cyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gT3BlcmF0aW9uYWwgQ29uc2Vuc3VzIG9uIGRlcGxv eW1lbnQNCg0KTG9yZW56bw0KDQpGb3IgbXkgZWR1Y2F0aW9uLCBkbyB5b3UgaGF2ZSBhIHBvaW50 ZXIgZm9yIGEgZGF0YSBwb2ludCBvbjoNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIDxsb3Jlbnpv QGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+DQpBIDRHIGhhbmRzZXQgd2l0 aCA0NjR4bGF0IHdpbGwgaGF2ZSB+NTAlIG9mIHRyYWZmaWMgbmF0aXZlIElQdjYsIH40NSUgTkFU NjQsIGFuZCB+NSUgNDY0eGxhdC4gNDY0IGNvbnZlcnNpb24gaXMgbG9zc3kgYW5kIGJyaXR0bGUs IGJ1dCBpZiBpdCdzIG9ubHkgdXNlZCBmb3IgNSUgb2YgdHJhZmZpYywgdGhlbiB0aGUgb3BlcmF0 b3IgbWlnaHQganVzdCBzYXksICJXaG8gY2FyZXM/IEkgZG9uJ3Q7IGFuZCBpZiBzb21lYm9keSBl bHNlIGRvZXMsIHRoZXkncmUgZnJlZSB0byB1c2UgSVB2Ni4iDQo= --_000_D0210E0C28BDEevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8D910E86FFBECF47A39339FF66228F4F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+VGhhbmtzIGZv ciB0aGUgdXBkYXRl4oCmIGFuZCBpbmRlZWQsIGluIG5vbi1FbmdsaXNoIG5hdGl2ZSBjb3VudHJp ZXMgKGxpa2UgbWluZSksIGxvY2FsIGNvbnRlbnQgaXMgaW1wb3J0YW504oCmIGJ1dCB2ZXJ5IGRp ZmZpY3VsdCB0byBnZXQgbW92aW5nIHRvIElQdjYgKEkgbWVhbiB0aGUgYnVzaW5lc3MvcG9saXRp Y2FsIHJlYXNvbiB0byBtb3ZlLCBub3QgdGhlIHRlY2huaWNhbCBtb3ZlIGl0c2VsZiB3aXRoIHRo ZSBoZWxwIG9mIENETik8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi3DqXJpYzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5Lb3NzdXQgVG9tYXN6IC0gSHVydCAmbHQ7PGEg aHJlZj0ibWFpbHRvOlRvbWFzei5Lb3NzdXRAb3JhbmdlLmNvbSI+VG9tYXN6Lktvc3N1dEBvcmFu Z2UuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTog PC9zcGFuPmx1bmRpIDI1IGFvw7t0IDIwMTQgMTU6NTc8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5FcmljIFZ5bmNrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2 eW5ja2VAY2lzY28uY29tIj5ldnluY2tlQGNpc2NvLmNvbTwvYT4mZ3Q7LCBMb3JlbnpvIENvbGl0 dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xl LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3Nw YW4+SVB2NiBPcHMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNA aWV0Zi5vcmc8L2E+Jmd0OywgQ3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpNaWNoYWwuQ3plcndvbmthMUBvcmFuZ2UuY29tIj5NaWNoYWwuQ3plcndvbmthMUBv cmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi amVjdDogPC9zcGFuPlJFOiBbdjZvcHNdIE9wZXJhdGlvbmFsIENvbnNlbnN1cyBvbiBkZXBsb3lt ZW50PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRk ZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5z OnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v b2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAo ZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGVrc3QgZHlta2EgWm5hayI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRla3N0ZHlta2FabmFrDQoJ e21zby1zdHlsZS1uYW1lOiJUZWtzdCBkeW1rYSBabmFrIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRla3N0IGR5bWthIjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5TdHlsd2lhZG9tb2NpZS1tYWlsMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uU3R5bHdpYWRvbW9jaWUtbWFpbDIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFu Zz0iUEwiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7ICI+SEksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5J cHY2IHRyYWZmaWMgZm9yIE9QTCBJcHY2IG1vYmlsZSBzdWJzY3JpYmVycyByZXR1cm5zIHRvIGl0 cyDigJxub3JtYWzigJ0gdmFsdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+ TmF0aXZlIElwdjY9NjAlLE5BVDY0PTQwJSo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Ki0gbWFpbmx5IG5h dGlvbmFsIGNvbnRlbnQsIElmIHBvbGlzaCBuYXRpb25hbCB0b3AgMTAgQWxleGEgY29udGVudCBi ZWNvbWVzIElwdjYgdGhlbiA5MCUgdHJhZmZpYyB3aWxsIGJlIElwdjbigKY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyAiPlNvIGlmIHlvdSBub3cgSVB2NiByZWFkaW5lc3MgZm9yIHlv dXIgbmF0aW9uYWwgdG9wIEFsZXhhIHNpdGVzIHlvdSBjYW4gZXN0aW1hdGUgaG93IG11Y2ggTkFU NjQgeW91IGNhbiBleHBlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgIj5USzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj4gS29zc3V0 IFRvbWFzeiAtIEh1cnQNCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEF1Z3VzdCAwOCwgMjAx NCA0OjE5IFBNPGJyPg0KPGI+VG86PC9iPiAnRXJpYyBWeW5ja2UgKGV2eW5ja2UpJzsgTG9yZW56 byBDb2xpdHRpPGJyPg0KPGI+Q2M6PC9iPiBJUHY2IE9wcyBXRzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW3Y2b3BzXSBPcGVyYXRpb25hbCBDb25zZW5zdXMgb24gZGVwbG95bWVudDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsgIj5JbnRlcm5ldCB0cmFmZmljIGZvciBPUEwgaXB2NiAtNDY0eGxhdCB1c2VycyAo M0cvNEcpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5UcmFmZmljIHRpbGwgbWlk LUp1bHk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5JcHY2IC02MCUgKDc4JSB0 byBHb29nbGUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5OYXQ2NCAtNDAlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5UcmFmZmljIGZyb20gbWlkLUp1bHkgdXAg dG8gbm93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+SXB2NiDigJMgNDAlKiAo NTAlIHRvIEdvb2dsZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPk5hdDY0LSA2 MCU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7ICI+Kk9uIFcyOCB3ZSBub3RpY2VkIGFibm9ybWFsIGRyb3Agb2Yg QUFBQSBxdWVyaWVzIGdlbmVyYXRlZCBieSB1c2Vycy4gSXQgbG9va3MgbGlrZSBzb21lIERTIHNl cnZlcnMgYmVjb21lcyBJcHY0IG9ubHksIG9yIHdlYiBicm93c2VyDQogaXB2NCBmYWxsYmFjayB0 YWtlcyBwbGFjZSBtb3JlIG9mdGVuLi4gKHdlIGFuYWx5emluZyBkYXRhKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsgIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+VG9tYXN6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyAiPiBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgWzxhIGhyZWY9Im1haWx0bzpldnluY2tlQGNp c2NvLmNvbSI+bWFpbHRvOmV2eW5ja2VAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEF1Z3VzdCAwOCwgMjAxNCAyOjEyIFBNPGJyPg0KPGI+VG86PC9iPiBMb3Jlbnpv IENvbGl0dGk8YnI+DQo8Yj5DYzo8L2I+IElQdjYgT3BzIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbdjZvcHNdIE9wZXJhdGlvbmFsIENvbnNlbnN1cyBvbiBkZXBsb3ltZW50PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyAiPkxvcmVuem88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogYmxhY2s7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyAiPkZvciBt eSBlZHVjYXRpb24sIGRvIHlvdSBoYXZlIGEgcG9pbnRlciBmb3IgYSBkYXRhIHBvaW50IG9uOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiBibGFjazsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogYmxhY2s7ICI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBi bGFjazsgIj5Mb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2ds ZS5jb20iPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCIg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IGJsYWNrOyAiPkEgNEcgaGFuZHNldCB3aXRoIDQ2NHhsYXQgd2lsbCBoYXZlIH41MCUg b2YgdHJhZmZpYyBuYXRpdmUgSVB2NiwgfjQ1JSBOQVQ2NCwgYW5kIH41JSA0NjR4bGF0LiA0NjQg Y29udmVyc2lvbiBpcyBsb3NzeSBhbmQgYnJpdHRsZSwgYnV0IGlmIGl0J3Mgb25seSB1c2VkIGZv cg0KIDUlIG9mIHRyYWZmaWMsIHRoZW4gdGhlIG9wZXJhdG9yIG1pZ2h0IGp1c3Qgc2F5LCAmcXVv dDtXaG8gY2FyZXM/IEkgZG9uJ3Q7IGFuZCBpZiBzb21lYm9keSBlbHNlIGRvZXMsIHRoZXkncmUg ZnJlZSB0byB1c2UgSVB2Ni4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D0210E0C28BDEevynckeciscocom_-- From nobody Mon Aug 25 09:22: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 620FF1A024E for ; Mon, 25 Aug 2014 09:22: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 XvMU-7fDCBu5 for ; Mon, 25 Aug 2014 09:22:06 -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 C751E1A0164 for ; Mon, 25 Aug 2014 09:09:10 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s7PG8q9e085219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 17:08:52 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <53FB5F94.4020308@foobar.org> Date: Mon, 25 Aug 2014 17:08:52 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> In-Reply-To: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uaaLfv53F1N3nZyR18ySIGWOqIo Cc: draft-v6ops-pmtud-ecmp-problem.ietf.org@cisco.com 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, 25 Aug 2014 16:22:09 -0000 On 25/08/2014 12:47, fred@cisco.com wrote: > A new draft has been posted, at http://datatracker.ietf.org/wg/v6ops/charter/draft-v6ops-pmtud-ecmp-problem. Please take a look at it and comment. no sign yet of this draft on datatracker. Did it get stuck? Nick From nobody Mon Aug 25 09:35: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 CE4C31A007A for ; Mon, 25 Aug 2014 09:35:15 -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 6mR_Svm-1v00 for ; Mon, 25 Aug 2014 09:35:14 -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 B60171A010C for ; Mon, 25 Aug 2014 09:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1110; q=dns/txt; s=iport; t=1408983817; x=1410193417; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cw0Z8KjxgOrZ2pbr/fn4LnxTfWXxb7UqDzKSAN3ast4=; b=A6wDyM7r8vOfh5lgahHbbSG/AyJe2OM0b24YlXjbsWpB+BllubgBP9GO PXGOSxbBGGFa6rR5VLODNa2orEPuWJWE3F1NYAn2TEasWr4rUQuYOKL0m foMTsEfOpMalTk6pP1H5XRc1U15ZAsBVOvDeC/Y7bHsfsyMnCjpL3b1mE Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFALBi+1OtJA2B/2dsb2JhbABagw1TVwTMVYdLAYEiFneEAwEBAQMBeQULAgEIGC4yJQIEDgUOiCwIDb98F49MB4MvgR0FkSaCA4FKXIZ6gViTNINebIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="asc'?scan'208";a="350089357" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 25 Aug 2014 16:23:37 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7PGNbK9029298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 16:23:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 11:23:37 -0500 From: "Fred Baker (fred)" To: Nick Hilliard Thread-Topic: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem Thread-Index: AQHPwIDr3jpTenmH40C/SbTbm0dDFg== Date: Mon, 25 Aug 2014 16:23:36 +0000 Message-ID: <5CBD1594-2A9B-41B6-A2CD-1D42A8AE70B7@cisco.com> References: <201408251147.s7PBl2b6010099@irp-lnx1.cisco.com> <53FB5F94.4020308@foobar.org> In-Reply-To: <53FB5F94.4020308@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_7814D5EF-1FEE-4D58-BB9C-FE4215E0EE96"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fJMJp7bW0wJosLIYn6Q9Vt3NOvA Cc: "v6ops@ietf.org" , "draft-v6ops-pmtud-ecmp-problem.ietf.org@cisco.com" 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, 25 Aug 2014 16:35:15 -0000 --Apple-Mail=_7814D5EF-1FEE-4D58-BB9C-FE4215E0EE96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 25, 2014, at 9:08 AM, Nick Hilliard wrote: > On 25/08/2014 12:47, fred@cisco.com wrote: >> A new draft has been posted, at = http://datatracker.ietf.org/wg/v6ops/charter/draft-v6ops-pmtud-ecmp-proble= m. Please take a look at it and comment. >=20 > no sign yet of this draft on datatracker. Did it get stuck? Sorry, my bad: http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem --Apple-Mail=_7814D5EF-1FEE-4D58-BB9C-FE4215E0EE96 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 iD8DBQFT+2MHbjEdbHIsm0MRAkHzAKDhz4HiOoFOwaW0JUQApvsTIyYdEQCgjQfa ZD9HzfxJmxLUXL511y402lk= =kp0w -----END PGP SIGNATURE----- --Apple-Mail=_7814D5EF-1FEE-4D58-BB9C-FE4215E0EE96-- From nobody Mon Aug 25 10:20: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 503B51A0115 for ; Mon, 25 Aug 2014 10:20:34 -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 jP23jfwHoEht for ; Mon, 25 Aug 2014 10:20:32 -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 05EE31A016B for ; Mon, 25 Aug 2014 10:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=970; q=dns/txt; s=iport; t=1408987229; x=1410196829; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=E1NeKPF/7Ebe397JBHuX/LSNH+AIOBegvrdwy4v09O0=; b=AKGmhpW8t7uCMoN8qWtOzjZ/k+alqaQrte+cm8Scd4E7tTR2pIOEHlZt yeZY/i0AfFGliGCbxbOiaIxU3BN9+3bK4Jnkae0VBTD2BSxHYfbOI3teP saVZZeOtDd7mh9aEF8TTkt1XVx4LhkJA183r0/xXvNv+/qTlZSQFckxT6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMGAKxv+1OtJA2I/2dsb2JhbABagw1TWAPMVYdNgSMWd4QKOj8SAT5CJwQOiEcNv3sXj0yDNoEdBZEmhCmGeoFYkzSDXoI0gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="72173726" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 25 Aug 2014 17:20:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7PHKS72003271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 17:20:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 12:20:28 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: PMTUD issue discussion Thread-Index: AQHPwIjdFvWLDa0ZaUmp2x0TvslW9A== Date: Mon, 25 Aug 2014 17:20:27 +0000 Message-ID: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <9AC2BF42307AD84E94F2DEE2AF4C7738@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Dj1eAgnHs6430_PiMC1olYoT4QU Subject: [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, 25 Aug 2014 17:20:34 -0000 http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem http://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem "Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)", Matt Byerly, Matt Hite, Joel Jaeggli, 2014-08-24, As requested at IETF 90, Joel has edited and reposted his draft. There are = two questions before the house: - do we want to make this a working group draft? - what do we want to do next? Note that, by charter, what we are not permitted to do is change implementa= tions or protocols; we are allowed to define operational procedure. That sa= id, we *can* make recommendations to other working groups, asking them to c= hange something. So, for example, we might ask 6man to do something specific, or we might as= k tcpm to do something specific. Something specific that we might ask tcpm = to do would be to get operational experience with RFC 4821 and commit it ba= ck to open source, for example. From nobody Mon Aug 25 10:58: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 24B211A00A5; Mon, 25 Aug 2014 10:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.722 X-Spam-Level: * X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Hk7qsVTCdNcZ; Mon, 25 Aug 2014 10:58:22 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371FC1A0218; Mon, 25 Aug 2014 10:57:09 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so13372318wgg.31 for ; Mon, 25 Aug 2014 10:57:07 -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=8AEwR/qdwLRtrhs0vjkZXkdNI+3PyE6FWEdilm1Q0BQ=; b=Pzm7Dugq7SlIvhrwyj2HMqu7OR86ocvpbftyMOGogYcRpkCwPEIkUmaEokBUOOT9Qw FcIL7e5ZsQF114MijfED+xuvhqY+Pt/BBoiuHrEQdhY9KfykTV7TZuWUZh905Y//0u90 c0Hf5n1r9bGaWPh85cLr6V5KA9TND2HAj3Mibt2745z2e+jVJXCG9rAPCl4oX5HPZlsa MvmR9FMxg+18hT5HU9TC1euY5EV3gSZK4wfI5XLlIXhSB6Ng3LoWyf8GYGPRkbIPOstW rG48aH8K9lwG4JV7a87er6ve7d6YX2/gNm7C6qkwXhIy3Nkmn4cuzLBLLSjP3JkXZaYQ 4yiw== MIME-Version: 1.0 X-Received: by 10.180.75.49 with SMTP id z17mr16559665wiv.80.1408989427756; Mon, 25 Aug 2014 10:57:07 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Mon, 25 Aug 2014 10:57:07 -0700 (PDT) In-Reply-To: <53F8475A.1090800@fud.no> References: <53F33C4F.2070807@si6networks.com> <53F3931F.9050601@si6networks.com> <53F51269.8070506@si6networks.com> <53F590A2.2090101@si6networks.com> <53F8475A.1090800@fud.no> Date: Mon, 25 Aug 2014 10:57:07 -0700 X-Google-Sender-Auth: aiCdpsIpSaaasWSy74Wn2FRjzq8 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Gp_CqUD31-d_5uUqs-vpqlxqiUM Cc: IPv6 Operations , "opsec@ietf.org" Subject: Re: [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:58:23 -0000 At Sat, 23 Aug 2014 09:48:42 +0200, Tore Anderson wrote: > > I assumed that stateless translation always uses the well-known > > prefix. Maybe I was incorrect about that? > > Yes, that is incorrect. Per RFC 6052 the operator can use either the > Well-Known Prefix and a Network-Specific Prefix. There are quite few > reasons why one would choose the latter; for example it allows for the > translating device to be reached across the public internet. Another > reason is that only a single WKP exists, so if the operator wants to > deploy both SIIT and NAT64, and/or multiple instances of either > technology, all of his deployments (except for one), must necessarily > use an NSP. Okay, thanks for the correction. In that case this approach cannot be a complete alternative to dropping PTB<1280 unconditionally without affecting possible existing/coming deployments. -- JINMEI, Tatuya From nobody Mon Aug 25 13:50: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 E8ED51A034A for ; Mon, 25 Aug 2014 13:49:59 -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 HckSywr4iYex for ; Mon, 25 Aug 2014 13:49:58 -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 446D71A0332 for ; Mon, 25 Aug 2014 13:49:58 -0700 (PDT) Received: from [128.9.184.196] ([128.9.184.196]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s7PKnoHq008842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Aug 2014 13:49:51 -0700 (PDT) Message-ID: <53FBA174.2040302@isi.edu> Date: Mon, 25 Aug 2014 13:49:56 -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)" , IPv6 Ops WG References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> In-Reply-To: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JH3blgZPtovG7o_rbMQaY4iR9wU 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, 25 Aug 2014 20:50:00 -0000 Hi, all, Speaking from TCPM-land, I would observe the following: - PMTUD already has many known problems, which is why PLMTUD is recommended instead - the issue here appears to be a device that routes TCP and UDP packets based on a hash, but does not apply that hash to the ICMP messages that's clearly an oversight of those devices. ICMP feedback is a known part of the Internet architecture, and any device that demultiplexes packets based on transport info needs to similarly process ICMP messages that goes for NATs, load balancers, or anything else. I'm not sure what would be added other than to say "we found this problem here too". It's a bug that ought to be fixed, but endpoints that intend to be robust already know not to rely on ICMP. Joe On 8/25/2014 10:20 AM, Fred Baker (fred) wrote: > http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem > http://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem > "Close encounters of the ICMP type 2 kind (near misses with ICMPv6 > PTB)", Matt Byerly, Matt Hite, Joel Jaeggli, 2014-08-24, > > As requested at IETF 90, Joel has edited and reposted his draft. There are two questions before the house: > - do we want to make this a working group draft? > - what do we want to do next? > > Note that, by charter, what we are not permitted to do is change implementations or protocols; we are allowed to define operational procedure. That said, we *can* make recommendations to other working groups, asking them to change something. > > So, for example, we might ask 6man to do something specific, or we might ask tcpm to do something specific. Something specific that we might ask tcpm to do would be to get operational experience with RFC 4821 and commit it back to open source, for example. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Aug 25 13:57: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 6E7941A0352 for ; Mon, 25 Aug 2014 13:57:21 -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 oQV-kKoRxKgE for ; Mon, 25 Aug 2014 13:57:12 -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 CCCDE1A035D for ; Mon, 25 Aug 2014 13:57:06 -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 s7PKv6qF021141; Mon, 25 Aug 2014 15:57:06 -0500 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7PKutsD020548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 25 Aug 2014 15:56:56 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.81]) with mapi id 14.03.0181.006; Mon, 25 Aug 2014 13:56:55 -0700 From: "Templin, Fred L" To: Joe Touch , "Fred Baker (fred)" , "IPv6 Ops WG" Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPwKYq3jcR+fTlj0+il5BtQavN3Zvhy9HA Date: Mon, 25 Aug 2014 20:56:54 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CFBC5C@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> In-Reply-To: <53FBA174.2040302@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/9uM7APYg_a4ITsYH3WvNU7gdEa8 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, 25 Aug 2014 20:57:21 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Monday, August 25, 2014 1:50 PM > To: Fred Baker (fred); IPv6 Ops WG > Subject: Re: [v6ops] PMTUD issue discussion >=20 > Hi, all, >=20 > Speaking from TCPM-land, I would observe the following: >=20 > - PMTUD already has many known problems, which is why PLMTUD is > recommended instead >=20 > - the issue here appears to be a device that routes TCP and UDP packets > based on a hash, but does not apply that hash to the ICMP messages > that's clearly an oversight of those devices. > ICMP feedback is a known part of the Internet architecture, > and any device that demultiplexes packets based on transport > info needs to similarly process ICMP messages >=20 > that goes for NATs, load balancers, or anything else. >=20 > I'm not sure what would be added other than to say "we found this > problem here too". It's a bug that ought to be fixed, but endpoints that > intend to be robust already know not to rely on ICMP. +1, and that also reinforces Fred's point about becoming more proactive in encouraging RFC4821. Thanks - Fred fred.l.templin@boeing.com > Joe >=20 > On 8/25/2014 10:20 AM, Fred Baker (fred) wrote: > > http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem > > http://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem > > "Close encounters of the ICMP type 2 kind (near misses with ICMPv6 > > PTB)", Matt Byerly, Matt Hite, Joel Jaeggli, 2014-08-24, > > > > As requested at IETF 90, Joel has edited and reposted his draft. There = are two questions before the > house: > > - do we want to make this a working group draft? > > - what do we want to do next? > > > > Note that, by charter, what we are not permitted to do is change implem= entations or protocols; we > are allowed to define operational procedure. That said, we *can* make rec= ommendations to other working > groups, asking them to change something. > > > > So, for example, we might ask 6man to do something specific, or we migh= t ask tcpm to do something > specific. Something specific that we might ask tcpm to do would be to get= operational experience with > RFC 4821 and commit it back to open source, for example. > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Aug 25 14:13: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 55FC01A0351 for ; Mon, 25 Aug 2014 14:13:14 -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 SeAU3HNGLnzp for ; Mon, 25 Aug 2014 14:13:12 -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 1451F1A0320 for ; Mon, 25 Aug 2014 14:13:12 -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 s7PLDAxe024265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Aug 2014 21:13:11 GMT (envelope-from joelja@bogus.com) Message-ID: <53FBA6E1.90905@bogus.com> Date: Mon, 25 Aug 2014 14:13:05 -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: Joe Touch , IPv6 Ops WG References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> In-Reply-To: <53FBA174.2040302@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t86JTt1V2MNDkTQVwbF433VH2rAxdBFR4" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 25 Aug 2014 21:13:11 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/faV0yB0imptHt6k3M61jazfaL_I 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, 25 Aug 2014 21:13:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t86JTt1V2MNDkTQVwbF433VH2rAxdBFR4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/25/14 1:49 PM, Joe Touch wrote: > Hi, all, >=20 > Speaking from TCPM-land, I would observe the following: >=20 > - PMTUD already has many known problems, which is why PLMTUD is > recommended instead I agree, operationally however I'm trying not to break existing devices attempting to connect to me, is the motivation for the note. > - the issue here appears to be a device that routes TCP and UDP packets= > based on a hash, but does not apply that hash to the ICMP messages > that's clearly an oversight of those devices. > ICMP feedback is a known part of the Internet architecture, > and any device that demultiplexes packets based on transport > info needs to similarly process ICMP messages If you use source / dest / flow label or even just source / dest you have the same issue. e.g. using the transport header for hash computation is not required to induce this. > that goes for NATs, load balancers, or anything else. This requires that I not only be transport aware but be able to parse into the payload. As noted, the data I would need can probably be found at a fixed offset (modula extension headers) so in fact that is probably feasible. > I'm not sure what would be added other than to say "we found this > problem here too". It's a bug that ought to be fixed, but endpoints tha= t > intend to be robust already know not to rely on ICMP. I don't disagree with that sentiment. > Joe >=20 > On 8/25/2014 10:20 AM, Fred Baker (fred) wrote: >> http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem >> http://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem >> "Close encounters of the ICMP type 2 kind (near misses with ICMPv6 >> PTB)", Matt Byerly, Matt Hite, Joel Jaeggli, 2014-08-24, >> >> As requested at IETF 90, Joel has edited and reposted his draft. There= >> are two questions before the house: >> - do we want to make this a working group draft? >> - what do we want to do next? >> >> Note that, by charter, what we are not permitted to do is change >> implementations or protocols; we are allowed to define operational >> procedure. That said, we *can* make recommendations to other working >> groups, asking them to change something. >> >> So, for example, we might ask 6man to do something specific, or we >> might ask tcpm to do something specific. Something specific that we >> might ask tcpm to do would be to get operational experience with RFC >> 4821 and commit it back to open source, for example. >> >> _______________________________________________ >> 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 --t86JTt1V2MNDkTQVwbF433VH2rAxdBFR4 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 iEYEARECAAYFAlP7puEACgkQ8AA1q7Z/VrL01gCZAdy6O0jLO4ZZTh+Sld6Tevjt YJIAnRPPzHDGpeGSVl8EPC39bDWwWWJ8 =x5ko -----END PGP SIGNATURE----- --t86JTt1V2MNDkTQVwbF433VH2rAxdBFR4-- From nobody Tue Aug 26 02:50: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 DD74E1A6F1D for ; Tue, 26 Aug 2014 02:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 57OQT5LftGM4 for ; Tue, 26 Aug 2014 02:50:02 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F651A6F13 for ; Tue, 26 Aug 2014 02:50:02 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so4198065igc.6 for ; Tue, 26 Aug 2014 02:50:01 -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=H68/P+O/1NTO5uWuOroAsx8UCq7efC2McNVMhK/bog8=; b=f1DOx8wmc8hb1zTSCGSidp7lCZ3ZV+wRFFHG1zjzOWRPhpAz7t4Zy/ZFekRM5EK21s JJnrYCxJhkaPSURnQRVTwQMiXmq/DvvasT+9ye7dWWvilXxV41ceaG2zEUcoBg3QVi40 PMwSyUf5Is+MQS76UeXfhLjVMV1M/iOT9tp/EM+fJTNNPxO7SFsvY9tybuAMiQl9ScAe XJAHNKlhSoXPRPrZiNrjItdFileSDrKlLuVzBKWLjnTTpW0YNbazdqgX1Aq5MJllOJzo vojZajLi1CZ+BQnHk2QWklj5vwK2mAcs8dxY7LeiCBZWIvdTSX2XxUjxkgcS576b5OsA xTrg== MIME-Version: 1.0 X-Received: by 10.50.41.104 with SMTP id e8mr20847747igl.35.1409046601707; Tue, 26 Aug 2014 02:50:01 -0700 (PDT) Received: by 10.107.135.234 with HTTP; Tue, 26 Aug 2014 02:50:01 -0700 (PDT) In-Reply-To: <53FBA6E1.90905@bogus.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> Date: Tue, 26 Aug 2014 11:50:01 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XYfIozQXdLi1YezmhnQCWQthusk 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, 26 Aug 2014 09:50:04 -0000 Joel, 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 devices > attempting to connect to me, is the motivation for the note. > 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. 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" 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. I think it would be useful to see the discussion of this measure and its applicability/tradeoffs in the draft. --a From nobody Tue Aug 26 07:59: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 D704C1A86EC for ; Tue, 26 Aug 2014 07:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 70KbLADMbXcU for ; Tue, 26 Aug 2014 07:59:45 -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 B71081A86E2 for ; Tue, 26 Aug 2014 07:59:45 -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 s7QExiVO004502; Tue, 26 Aug 2014 09:59:45 -0500 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7QExIDL003987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 26 Aug 2014 09:59:38 -0500 Received: from XCH-BLV-102.nw.nos.boeing.com (2002:82f7:1975::82f7:1975) by XCH-PHX-213.sw.nos.boeing.com (2002:82f7:198e::82f7:198e) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 26 Aug 2014 07:59:35 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.84]) with mapi id 14.03.0181.006; Tue, 26 Aug 2014 07:59:33 -0700 From: "Templin, Fred L" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= , "joel jaeggli" Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPwRMa3jcR+fTlj0+il5BtQavN3Zvi+baA Date: Tue, 26 Aug 2014 14:59:32 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CFC84D@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YafyTEMfGEHWM0ajU9hxPbXmuAo 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, 26 Aug 2014 14:59:48 -0000 SGkgQW5kcmV3LA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3Bz IFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyA/PyBZ b3VydGNoZW5rbw0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjYsIDIwMTQgMjo1MCBBTQ0KPiBU bzogam9lbCBqYWVnZ2xpDQo+IENjOiBJUHY2IE9wcyBXRw0KPiBTdWJqZWN0OiBSZTogW3Y2b3Bz XSBQTVRVRCBpc3N1ZSBkaXNjdXNzaW9uDQo+IA0KPiBKb2VsLA0KPiANCj4gT24gOC8yNS8xNCwg am9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPiB3cm90ZToNCj4gPiBPbiA4LzI1LzE0IDE6 NDkgUE0sIEpvZSBUb3VjaCB3cm90ZToNCj4gPj4gSGksIGFsbCwNCj4gPj4NCj4gPj4gU3BlYWtp bmcgZnJvbSBUQ1BNLWxhbmQsIEkgd291bGQgb2JzZXJ2ZSB0aGUgZm9sbG93aW5nOg0KPiA+Pg0K PiA+PiAtIFBNVFVEIGFscmVhZHkgaGFzIG1hbnkga25vd24gcHJvYmxlbXMsIHdoaWNoIGlzIHdo eSBQTE1UVUQgaXMNCj4gPj4gcmVjb21tZW5kZWQgaW5zdGVhZA0KPiA+DQo+ID4gSSBhZ3JlZSwg b3BlcmF0aW9uYWxseSBob3dldmVyIEknbSB0cnlpbmcgbm90IHRvIGJyZWFrIGV4aXN0aW5nIGRl dmljZXMNCj4gPiBhdHRlbXB0aW5nIHRvIGNvbm5lY3QgdG8gbWUsIGlzIHRoZSBtb3RpdmF0aW9u IGZvciB0aGUgbm90ZS4NCj4gPg0KPiANCj4gRHVyaW5nIHRoZSBwcmVzZW50YXRpb24gaW4gdGhl IHY2b3BzIHNlc3Npb24gSSBtYWRlIGEgY29tbWVudCBhYm91dA0KPiBzeXNjdGwgbmV0LmlwdjQu dGNwX210dV9wcm9iaW5nLiBTaW5jZSB0aGVuIEkgaGFkIGEgY2hhbmNlIHRvIHRlc3QgaXQNCj4g LSBhbmQgaW5kZWVkLCBpdCBhZmZlY3RzIHRoZSBiZWhhdmlvciBvZiBUQ1Agb3ZlciBJUHY2IGFz IHdlbGwuDQoNClBUQiBtZXNzYWdlIGxvc3MgaXMgYWxzbyBhIGNvbmNlcm4gZm9yIElQdjYsIGFu ZCBub3QganVzdCBmb3IgSVB2NC4NCiANCj4gSG93ZXZlciwgdGhlIHZhbHVlIG9mIDEgY2F1c2Vz IGEgbGFyZ2UgdmFsdWUgb2YgTVNTIHRvIGJlIHVzZWQsDQo+IHJlc3VsdGluZyBpbiBhYm91dCAx LjUgc2Vjb25kIGhpY2N1cC4gU28sIHllYWggaXQgIndvcmtzIiBidXQgZm9yDQo+IGJhcmVseSBh Y2NlcHRhYmxlIHZhbHVlcyBvZiAid29ya3MiDQo+IA0KPiBTZXR0aW5nIHRoZSB2YWx1ZSB0byAy IGNhdXNlcyB0aGUgaW5pdGlhbCBNU1MgdG8gYmUgNTEyLCB3aGljaA0KPiAibWl0aWdhdGVzIiB0 aGUgcHJvYmxlbSBhbmQgYXZvaWRlZCB0aGUgaGljY3VwcyBvbiBhIDEwMGtiIGZpbGUgSSB3YXMN Cj4gdGVzdGluZyB3aXRoIC0gYXQgdGhlIGV4cGVuc2Ugb2YgYWxtb3N0IDN4IG1vcmUgcGFja2V0 cyBvZiBjb3Vyc2UuDQoNCkkgdGhpbmsgdGhhdCBpbXBsZW1lbnRhdGlvbiB3YXMgYWRkZWQgdG8g dGhlIGxpbnV4IGtlcm5lbCBhIGxvbmcNCnRpbWUgYWdvLCBhbmQgSSBhbSBub3Qgc3VyZSBpZiBh bnlvbmUgaXMgc3RpbGwgbWFpbnRhaW5pbmcgaXQuIElzDQp0aGlzIGEgcHJvYmxlbSB0aGF0IHNo b3VsZCBiZSByZXBvcnRlZCB0byBuZXRkZXY/DQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1w bGluQGJvZWluZy5jb20NCiANCj4gSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gc2VlIHRo ZSBkaXNjdXNzaW9uIG9mIHRoaXMgbWVhc3VyZSBhbmQNCj4gaXRzIGFwcGxpY2FiaWxpdHkvdHJh ZGVvZmZzIGluIHRoZSBkcmFmdC4NCj4gDQo+IC0tYQ0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2 b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHMNCg== From nobody Tue Aug 26 08:14: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 006871A8722 for ; Tue, 26 Aug 2014 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.869 X-Spam-Level: X-Spam-Status: No, score=-114.869 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=-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 flVBFX8qH7k1 for ; Tue, 26 Aug 2014 08:14:02 -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 950811A8731 for ; Tue, 26 Aug 2014 08:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1903; q=dns/txt; s=iport; t=1409066033; x=1410275633; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GcBJ2T+hxsUKkM6GI7sEAKXdPGsxTfJEh2UHkKMLQmc=; b=Eqf5tdX+tKYzFi/DsM7SxjoCxh9Odz0RUJhssbcupwtgVIWCzysc2pEb g1XfQpvdwQmhr94hesz1n+FHVL9Yjg6deYx2hOvGIHr1FSGQBulMBg+DH yi9QC+EgHxgEgwG2tJUNKgIjxnGGlDKtSbV7twwgg18qhsNXlX2LMQo9J U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJqj/FOtJA2E/2dsb2JhbABbgw2BKgSCeNEoAYESFneEBAEBAwEjVgULAgEGAkICAiERJQIEDgUOiCADCQiNSZw9j10NhTcXjR+CLQeCeTaBHQWRJoIDgUqDFoIwghCOV4Y1g15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,405,1406592000"; d="asc'?scan'208";a="72454747" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 26 Aug 2014 15:13:52 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7QFDpDV010561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 15:13:52 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; Tue, 26 Aug 2014 10:13:51 -0500 From: "Fred Baker (fred)" To: =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPwUBXIBTvVsIdRUGXV+6lKnALmw== Date: Tue, 26 Aug 2014 15:13:51 +0000 Message-ID: <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_43201F7D-9E15-4F2E-B81E-778670F40B95"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uS1AbXyMrXOl5bKFKVXpjdU88Kw 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, 26 Aug 2014 15:14:07 -0000 X-List-Received-Date: Tue, 26 Aug 2014 15:14:07 -0000 --Apple-Mail=_43201F7D-9E15-4F2E-B81E-778670F40B95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 26, 2014, at 2:50 AM, Andrew =F0=9F=91=BD Yourtchenko = wrote: > 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. It seems like it might have value to also test the interaction with = various initial window settings, and look at its inclusion in other = relevant OS=E2=80=99s including FreeBSD, Windows, and MacOSX. My reading = of 4821 says it=E2=80=99s grand theory, but I=E2=80=99m not precisely = sure how I would write the code. As an initial setting, for example, I = could imagine sending an initial burst containing a 9K byte packet, a = 1500 byte packet, and a 1280 byte packet in that order, and set the MSS = to the the size of the first acknowledgment I receive. How does that = relate to IW=3D10 (RFC 6928)? --Apple-Mail=_43201F7D-9E15-4F2E-B81E-778670F40B95 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 iD8DBQFT/KQtbjEdbHIsm0MRAjYIAKCvoReVdfmIV3SvY5xCkAAo8Lvi4QCdHltH E3S+lDPcoxNy1biDPA/YA0c= =higH -----END PGP SIGNATURE----- --Apple-Mail=_43201F7D-9E15-4F2E-B81E-778670F40B95-- From nobody Tue Aug 26 08:35: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 AEEA71A8749 for ; Tue, 26 Aug 2014 08:35:28 -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 QFXYdyWNPJMz for ; Tue, 26 Aug 2014 08:35: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 017561A873C for ; Tue, 26 Aug 2014 08:35:28 -0700 (PDT) Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XMImM-0006Ah-0t; Tue, 26 Aug 2014 17:35:26 +0200 Message-ID: <53FCA926.9080206@si6networks.com> Date: Tue, 26 Aug 2014 12:35:02 -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)" , =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cg==?= =?UTF-8?B?dGNoZW5rbw==?= References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> In-Reply-To: <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lanoxFbStRseO4CweB8DWqrirsk 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, 26 Aug 2014 15:35:28 -0000 Hi, Fred, On 08/26/2014 12:13 PM, Fred Baker (fred) wrote: >> I think it would be useful to see the discussion of this measure >> and its applicability/tradeoffs in the draft. > > It seems like it might have value to also test the interaction > with various initial window settings, and look at its inclusion in > other relevant OS’s including FreeBSD, Windows, and MacOSX. FWIW, while RFC4821 can work without relying on PLPMTUD at all, some OSes (such as Windows) only fall back to ICMP-less PMTUD as part of "ICMP blackhole detecion" -- and they have been doing this for years now... > My reading of 4821 says it’s grand theory, but I’m not precisely > sure how I would write the code. As an initial setting, for > example, I could imagine sending an initial burst containing a 9K > byte packet, a 1500 byte Unlikely if the underlying link-layer technology is Ethernet (PMTUD will never be assumed to be larger than your own MTU). Additionally, I doubt you'd employ different packet sizes/assumed_PMTUDs all at once. 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 Aug 26 08:43: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 5F8C41A0046 for ; Tue, 26 Aug 2014 08:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 dfov-JAF1wBo for ; Tue, 26 Aug 2014 08:43:00 -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 24D5F1A8546 for ; Tue, 26 Aug 2014 08:43:00 -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 s7QFgx9b010837; Tue, 26 Aug 2014 08:42:59 -0700 Received: from XCH-PHX-111.sw.nos.boeing.com (xch-phx-111.sw.nos.boeing.com [130.247.25.132]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7QFgqap010314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 26 Aug 2014 08:42:53 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-111.sw.nos.boeing.com ([169.254.11.229]) with mapi id 14.03.0181.006; Tue, 26 Aug 2014 08:42:52 -0700 From: "Templin, Fred L" To: Fernando Gont , "Fred Baker (fred)" , =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPwUNN3jcR+fTlj0+il5BtQavN3ZvjBboA Date: Tue, 26 Aug 2014 15:42:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CFC96E@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> <53FCA926.9080206@si6networks.com> In-Reply-To: <53FCA926.9080206@si6networks.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/fEr4fFgVI7x4YYCzk1UHG4D0o5Y 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, 26 Aug 2014 15:43:05 -0000 SGkgRmVybmFuZG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRmVybmFuZG8g R29udA0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjYsIDIwMTQgODozNSBBTQ0KPiBUbzogRnJl ZCBCYWtlciAoZnJlZCk7IEFuZHJldyDwn5G9IFlvdXJ0Y2hlbmtvDQo+IENjOiBJUHY2IE9wcyBX Rw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQTVRVRCBpc3N1ZSBkaXNjdXNzaW9uDQo+IA0KPiBI aSwgRnJlZCwNCj4gDQo+IE9uIDA4LzI2LzIwMTQgMTI6MTMgUE0sIEZyZWQgQmFrZXIgKGZyZWQp IHdyb3RlOg0KPiA+PiBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBzZWUgdGhlIGRpc2N1 c3Npb24gb2YgdGhpcyBtZWFzdXJlDQo+ID4+IGFuZCBpdHMgYXBwbGljYWJpbGl0eS90cmFkZW9m ZnMgaW4gdGhlIGRyYWZ0Lg0KPiA+DQo+ID4gSXQgc2VlbXMgbGlrZSBpdCBtaWdodCBoYXZlIHZh bHVlIHRvIGFsc28gdGVzdCB0aGUgaW50ZXJhY3Rpb24NCj4gPiB3aXRoIHZhcmlvdXMgaW5pdGlh bCB3aW5kb3cgc2V0dGluZ3MsIGFuZCBsb29rIGF0IGl0cyBpbmNsdXNpb24gaW4NCj4gPiBvdGhl ciByZWxldmFudCBPU+KAmXMgaW5jbHVkaW5nIEZyZWVCU0QsIFdpbmRvd3MsIGFuZCBNYWNPU1gu DQo+IA0KPiBGV0lXLCB3aGlsZSBSRkM0ODIxIGNhbiB3b3JrIHdpdGhvdXQgcmVseWluZyBvbiBQ TFBNVFVEIGF0IGFsbCwgc29tZQ0KPiBPU2VzIChzdWNoIGFzIFdpbmRvd3MpIG9ubHkgZmFsbCBi YWNrIHRvIElDTVAtbGVzcyBQTVRVRCBhcyBwYXJ0IG9mDQo+ICJJQ01QIGJsYWNraG9sZSBkZXRl Y2lvbiIgLS0gYW5kIHRoZXkgaGF2ZSBiZWVuIGRvaW5nIHRoaXMgZm9yIHllYXJzDQo+IG5vdy4u Lg0KDQpJIHRoaW5rIHRoZSBwb2ludCBpcyB0aGF0IFBMUE1UVUQgaXMgbm90IHdlbGwgc3VwcG9y dGVkIGluIG1vZGVybg0KT1NlcyBpbiB0aGUgc3Bpcml0IGluIHdoaWNoIGl0IHdhcyBzcGVjaWZp ZWQgaW4gUkZDNDgyMS4gVGhhdA0KbmVlZHMgdG8gY2hhbmdlLg0KDQpUaGFua3MgLSBGcmVkDQpm cmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gPiBNeSByZWFkaW5nIG9mIDQ4MjEgc2F5cyBp dOKAmXMgZ3JhbmQgdGhlb3J5LCBidXQgSeKAmW0gbm90IHByZWNpc2VseQ0KPiA+IHN1cmUgaG93 IEkgd291bGQgd3JpdGUgdGhlIGNvZGUuIEFzIGFuIGluaXRpYWwgc2V0dGluZywgZm9yDQo+ID4g ZXhhbXBsZSwgSSBjb3VsZCBpbWFnaW5lIHNlbmRpbmcgYW4gaW5pdGlhbCBidXJzdCBjb250YWlu aW5nIGEgOUsNCj4gPiBieXRlIHBhY2tldCwgYSAxNTAwIGJ5dGUNCj4gDQo+IFVubGlrZWx5IGlm IHRoZSB1bmRlcmx5aW5nIGxpbmstbGF5ZXIgdGVjaG5vbG9neSBpcyBFdGhlcm5ldCAoUE1UVUQN Cj4gd2lsbCBuZXZlciBiZSBhc3N1bWVkIHRvIGJlIGxhcmdlciB0aGFuIHlvdXIgb3duIE1UVSku DQo+IA0KPiBBZGRpdGlvbmFsbHksIEkgZG91YnQgeW91J2QgZW1wbG95IGRpZmZlcmVudCBwYWNr ZXQNCj4gc2l6ZXMvYXNzdW1lZF9QTVRVRHMgYWxsIGF0IG9uY2UuDQo+IA0KPiBUaGFua3MsDQo+ IC0tDQo+IEZlcm5hbmRvIEdvbnQNCj4gU0k2IE5ldHdvcmtzDQo+IGUtbWFpbDogZmdvbnRAc2k2 bmV0d29ya3MuY29tDQo+IFBHUCBGaW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIx IEUzQzQgQUUyNSAwRDU1IDFENEUgNzQ5Mg0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0 DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMNCg== From nobody Tue Aug 26 09:19: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 8F8271A003A for ; Tue, 26 Aug 2014 09:19:26 -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 T3ACx75wuPni for ; Tue, 26 Aug 2014 09:19: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 ABDF51A0401 for ; Tue, 26 Aug 2014 09:19:24 -0700 (PDT) Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XMJSp-0006Kr-1Z; Tue, 26 Aug 2014 18:19:19 +0200 Message-ID: <53FCB378.6060209@si6networks.com> Date: Tue, 26 Aug 2014 13:19:04 -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: "Templin, Fred L" , "Fred Baker (fred)" , =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <53FCA926.9080206@si6networks.com> <2134F8430051B64F815C691A62D9831832CFC96E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CFC96E@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Cd4xyTswl0H2C9mc9lTLvxSXqO8 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, 26 Aug 2014 16:19:27 -0000 On 08/26/2014 12:42 PM, Templin, Fred L wrote: >> On 08/26/2014 12:13 PM, Fred Baker (fred) wrote: >>>> I think it would be useful to see the discussion of this measure >>>> and its applicability/tradeoffs in the draft. >>> >>> It seems like it might have value to also test the interaction >>> with various initial window settings, and look at its inclusion in >>> other relevant OS’s including FreeBSD, Windows, and MacOSX. >> >> FWIW, while RFC4821 can work without relying on PLPMTUD at all, some >> OSes (such as Windows) only fall back to ICMP-less PMTUD as part of >> "ICMP blackhole detecion" -- and they have been doing this for years >> now... > > I think the point is that PLPMTUD is not well supported in modern > OSes in the spirit in which it was specified in RFC4821. That > needs to change. FWIW, I'm all in favor of RFC4821, since it improves robustness of PMTUD. That said, as far as I can recall, using RFC4821 for blackhole detection (when traditional PMTUD fails) is well within the spirit of RFC4821 (RFC4821 doesn't push ICMP-less as the only implementation strategy). What I recall from discussing this with Linux developers circa 2005 is that a complete ICMP-less PMTUD is rather undesirable, since it tends to have longer convergence time when compared with "traditional PMTUD" || "Traditional PMTUD + RFC4821 for blachole detection". 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 Aug 26 09:34: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 BA6361A0066 for ; Tue, 26 Aug 2014 09:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 YDpOeeGIEsZp for ; Tue, 26 Aug 2014 09:34:02 -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 EB1C91A0024 for ; Tue, 26 Aug 2014 09:34:01 -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 s7QGY1FC012719; Tue, 26 Aug 2014 11:34:01 -0500 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7QGXsYW012635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 26 Aug 2014 11:33:55 -0500 Received: from XCH-BLV-404.nw.nos.boeing.com (2002:82f7:199d::82f7:199d) by XCH-PHX-309.sw.nos.boeing.com (2002:82f7:19a3::82f7:19a3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 26 Aug 2014 09:33:54 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.121]) with mapi id 14.03.0181.006; Tue, 26 Aug 2014 09:33:54 -0700 From: "Templin, Fred L" To: Fernando Gont , "Fred Baker (fred)" , =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPwUNN3jcR+fTlj0+il5BtQavN3ZvjBboAgACAAAD//432MA== Date: Tue, 26 Aug 2014 16:33:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CFCACA@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> <53FCA926.9080206@si6networks.com> <2134F8430051B64F815C691A62D9831832CFC96E@XCH-BLV-504.nw.nos.boeing.com> <53FCB378.6060209@si6networks.com> In-Reply-To: <53FCB378.6060209@si6networks.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/F8oVxj7rPOEW1RhR8buQlNvuQbI 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, 26 Aug 2014 16:34:04 -0000 SGkgRmVybmFuZG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmVy bmFuZG8gR29udCBbbWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbV0NCj4gU2VudDogVHVlc2Rh eSwgQXVndXN0IDI2LCAyMDE0IDk6MTkgQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgRnJlZCBC YWtlciAoZnJlZCk7IEFuZHJldyDwn5G9IFlvdXJ0Y2hlbmtvDQo+IENjOiBJUHY2IE9wcyBXRw0K PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQTVRVRCBpc3N1ZSBkaXNjdXNzaW9uDQo+IA0KPiBPbiAw OC8yNi8yMDE0IDEyOjQyIFBNLCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4+IE9uIDA4LzI2 LzIwMTQgMTI6MTMgUE0sIEZyZWQgQmFrZXIgKGZyZWQpIHdyb3RlOg0KPiA+Pj4+IEkgdGhpbmsg aXQgd291bGQgYmUgdXNlZnVsIHRvIHNlZSB0aGUgZGlzY3Vzc2lvbiBvZiB0aGlzIG1lYXN1cmUN Cj4gPj4+PiBhbmQgaXRzIGFwcGxpY2FiaWxpdHkvdHJhZGVvZmZzIGluIHRoZSBkcmFmdC4NCj4g Pj4+DQo+ID4+PiBJdCBzZWVtcyBsaWtlIGl0IG1pZ2h0IGhhdmUgdmFsdWUgdG8gYWxzbyB0ZXN0 IHRoZSBpbnRlcmFjdGlvbg0KPiA+Pj4gd2l0aCB2YXJpb3VzIGluaXRpYWwgd2luZG93IHNldHRp bmdzLCBhbmQgbG9vayBhdCBpdHMgaW5jbHVzaW9uIGluDQo+ID4+PiBvdGhlciByZWxldmFudCBP U+KAmXMgaW5jbHVkaW5nIEZyZWVCU0QsIFdpbmRvd3MsIGFuZCBNYWNPU1guDQo+ID4+DQo+ID4+ IEZXSVcsIHdoaWxlIFJGQzQ4MjEgY2FuIHdvcmsgd2l0aG91dCByZWx5aW5nIG9uIFBMUE1UVUQg YXQgYWxsLCBzb21lDQo+ID4+IE9TZXMgKHN1Y2ggYXMgV2luZG93cykgb25seSBmYWxsIGJhY2sg dG8gSUNNUC1sZXNzIFBNVFVEIGFzIHBhcnQgb2YNCj4gPj4gIklDTVAgYmxhY2tob2xlIGRldGVj aW9uIiAtLSBhbmQgdGhleSBoYXZlIGJlZW4gZG9pbmcgdGhpcyBmb3IgeWVhcnMNCj4gPj4gbm93 Li4uDQo+ID4NCj4gPiBJIHRoaW5rIHRoZSBwb2ludCBpcyB0aGF0IFBMUE1UVUQgaXMgbm90IHdl bGwgc3VwcG9ydGVkIGluIG1vZGVybg0KPiA+IE9TZXMgaW4gdGhlIHNwaXJpdCBpbiB3aGljaCBp dCB3YXMgc3BlY2lmaWVkIGluIFJGQzQ4MjEuIFRoYXQNCj4gPiBuZWVkcyB0byBjaGFuZ2UuDQo+ IA0KPiBGV0lXLCBJJ20gYWxsIGluIGZhdm9yIG9mIFJGQzQ4MjEsIHNpbmNlIGl0IGltcHJvdmVz IHJvYnVzdG5lc3Mgb2YgUE1UVUQuDQo+IA0KPiBUaGF0IHNhaWQsIGFzIGZhciBhcyBJIGNhbiBy ZWNhbGwsIHVzaW5nIFJGQzQ4MjEgZm9yIGJsYWNraG9sZSBkZXRlY3Rpb24NCj4gKHdoZW4gdHJh ZGl0aW9uYWwgUE1UVUQgZmFpbHMpIGlzIHdlbGwgd2l0aGluIHRoZSBzcGlyaXQgb2YgUkZDNDgy MQ0KPiAoUkZDNDgyMSBkb2Vzbid0IHB1c2ggSUNNUC1sZXNzIGFzIHRoZSBvbmx5IGltcGxlbWVu dGF0aW9uIHN0cmF0ZWd5KS4NCj4gDQo+IFdoYXQgSSByZWNhbGwgZnJvbSBkaXNjdXNzaW5nIHRo aXMgd2l0aCBMaW51eCBkZXZlbG9wZXJzIGNpcmNhIDIwMDUgaXMNCj4gdGhhdCBhIGNvbXBsZXRl IElDTVAtbGVzcyBQTVRVRCBpcyByYXRoZXIgdW5kZXNpcmFibGUsIHNpbmNlIGl0IHRlbmRzIHRv DQo+IGhhdmUgbG9uZ2VyIGNvbnZlcmdlbmNlIHRpbWUgd2hlbiBjb21wYXJlZCB3aXRoICJ0cmFk aXRpb25hbCBQTVRVRCIgfHwNCj4gIlRyYWRpdGlvbmFsIFBNVFVEICsgUkZDNDgyMSBmb3IgYmxh Y2hvbGUgZGV0ZWN0aW9uIi4NCg0KQWNjZXB0aW5nIGFuZCBwcm9jZXNzaW5nIFBUQnMgYXMgcGFy dCBvZiB0aGUgUExQTVRVRCBwcm9jZWR1cmUgaXMNCmRlc2lyYWJsZSBhbmQgc3BlZWRzIGNvbnZl cmdlbmNlLiBCdXQsIHRoZSBtZWNoYW5pc20gc3RpbGwgbmVlZHMgdG8NCndvcmsgd2hlbiB0aGVy ZSBhcmUgbm8gUFRCcy4NCg0KU28sIHRoZSBuZXR3b3JrIHNob3VsZCBzdGlsbCBkbyBpdHMgYmVz dCB0byByZXR1cm4gUFRCcywgYW5kIGhvc3RzDQpzaG91bGQgc3RpbGwgZG8gdGhlaXIgYmVzdCB0 byBvYnNlcnZlIHRoZW0uDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5j b20NCg0KPiBUaGFua3MsDQo+IC0tDQo+IEZlcm5hbmRvIEdvbnQNCj4gU0k2IE5ldHdvcmtzDQo+ IGUtbWFpbDogZmdvbnRAc2k2bmV0d29ya3MuY29tDQo+IFBHUCBGaW5nZXJwcmludDogNjY2NiAz MUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUgNzQ5Mg0KPiANCj4gDQo+IA0K DQo= From nobody Tue Aug 26 09:48: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 8B2E51A00A7 for ; Tue, 26 Aug 2014 09:48:10 -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 dKeOEBbDebcC for ; Tue, 26 Aug 2014 09:48:09 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886321A87A9 for ; Tue, 26 Aug 2014 09:41:54 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so4798020igd.11 for ; Tue, 26 Aug 2014 09:41:53 -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=yads/D+WsbFZH0qjSL9+SzXqjgopcubbYeaerP8kErg=; b=ZaNGAUiSs8iNG3JeQRWbfkcwvQ8GVkC5IsmYm9U/flACQ6OzkQZlPckioomhFsQobv r/B6ZVLvg8o4C0S3JNdihIEcDQxb9oBzmZxPFPUkmscaoPpgpMIaDDIsDnH+hSyTG3+3 dRKkN/L0bCxhx9rt/2UHKxX96pHLkqY5q0OI+5P9Uu52IbjhKb8OlVxra0jX0qZNjpIh s/wRUIKu0MPZ6oRXID8m2bLDysMs2ShUmLFfdUjqKiCukdAJ5PTHoWoDl6msLqC/171e /edkJWz/eorSB5olCjKNN6JuUwHTqglUgXscaZ9m9PjSxOrOE52PPC3R80mk5KjsB2oh oqDA== MIME-Version: 1.0 X-Received: by 10.42.83.131 with SMTP id h3mr2121287icl.77.1409071313856; Tue, 26 Aug 2014 09:41:53 -0700 (PDT) Received: by 10.107.135.234 with HTTP; Tue, 26 Aug 2014 09:41:53 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832CFC84D@XCH-BLV-504.nw.nos.boeing.com> References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <2134F8430051B64F815C691A62D9831832CFC84D@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 26 Aug 2014 18:41:53 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/unoLeytrzK3BJTCCDiaMuyIFkEk 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, 26 Aug 2014 16:48:11 -0000 Hi Fred, On 8/26/14, Templin, Fred L wrote: > Hi Andrew, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Andrew ?? >> Yourtchenko >> Sent: Tuesday, August 26, 2014 2:50 AM >> To: joel jaeggli >> Cc: IPv6 Ops WG >> Subject: Re: [v6ops] PMTUD issue discussion >> >> Joel, >> >> 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 devices >> > attempting to connect to me, is the motivation for the note. >> > >> >> 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. > > PTB message loss is also a concern for IPv6, and not just for IPv4. Absolutely agree. Just that at a first look one would see a bunch of sysctls that are labeled with ".ipv4." and a bunch of sysctls that are labeled with ".ipv6." and possibly make a conclusion they affect just that protocol. > >> 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" >> >> 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. > > I think that implementation was added to the linux kernel a long > time ago, and I am not sure if anyone is still maintaining it. Is > this a problem that should be reported to netdev? I think it works the same way it would work in IPv4 - if the ICMP PTB is lost, and the too large MSS was used, then there is a delay which is less tolerable today for the interactive traffic (IMHO) than when this code was introduced, hence my remark that "works" value is relatively small by today's high standards. But the 512-byte MSS, while preventing the delay, effectively triples the PPS, so might cause problems in some of the setups if their gear is "only" capable of 2x of the pre-change PPS value. That was the reason to suggest that if this setting can be used to solve the problem, there probably should be a discussion of the tradeoffs in the draft. I did not notice any wrong behavior - but, my testing was rather cursory. --a > > Thanks - Fred > fred.l.templin@boeing.com > >> I think it would be useful to see the discussion of this measure and >> its applicability/tradeoffs in the draft. >> >> --a >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Aug 26 09:59: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 42DEE1A00A7 for ; Tue, 26 Aug 2014 09:59:19 -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 zzPo5lbzyxqV for ; Tue, 26 Aug 2014 09:59:17 -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 52CE41A004E for ; Tue, 26 Aug 2014 09:59:17 -0700 (PDT) Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XMK5R-0006Sc-MJ; Tue, 26 Aug 2014 18:59:13 +0200 Message-ID: <53FCB8D4.30107@si6networks.com> Date: Tue, 26 Aug 2014 13:41: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: "Templin, Fred L" , "Fred Baker (fred)" , =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> <53FCA926.9080206@si6networks.com> <2134F8430051B64F815C691A62D9831832CFC96E@XCH-BLV-504.nw.nos.boeing.com> <53FCB378.6060209@si6networks.com> <2134F8430051B64F815C691A62D9831832CFCACA@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CFCACA@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gjru0DibtMfZCYDREWPS-dZjQvw 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, 26 Aug 2014 16:59:19 -0000 On 08/26/2014 01:33 PM, Templin, Fred L wrote: >> FWIW, I'm all in favor of RFC4821, since it improves robustness of PMTUD. >> >> That said, as far as I can recall, using RFC4821 for blackhole detection >> (when traditional PMTUD fails) is well within the spirit of RFC4821 >> (RFC4821 doesn't push ICMP-less as the only implementation strategy). >> >> What I recall from discussing this with Linux developers circa 2005 is >> that a complete ICMP-less PMTUD is rather undesirable, since it tends to >> have longer convergence time when compared with "traditional PMTUD" || >> "Traditional PMTUD + RFC4821 for blachole detection". > > Accepting and processing PTBs as part of the PLPMTUD procedure is > desirable and speeds convergence. But, the mechanism still needs to > work when there are no PTBs. > > So, the network should still do its best to return PTBs, and hosts > should still do their best to observe them. Agreed. IIRC, this behavios has been implemented in Windows and OpenBSD for 5+ years, though. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 26 10:06: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 684A31A0401 for ; Tue, 26 Aug 2014 10:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 3lg92UvW8Z2d for ; Tue, 26 Aug 2014 10:06:25 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6231A6F64 for ; Tue, 26 Aug 2014 10:06:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7QH6O21010040; Tue, 26 Aug 2014 12:06:24 -0500 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7QH6LU3010018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 26 Aug 2014 12:06:22 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.37]) with mapi id 14.03.0181.006; Tue, 26 Aug 2014 10:06:21 -0700 From: "Templin, Fred L" To: Fernando Gont , "Fred Baker (fred)" , =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= Thread-Topic: [v6ops] PMTUD issue discussion Thread-Index: AQHPwUNN3jcR+fTlj0+il5BtQavN3ZvjBboAgACAAAD//432MIAAeG0A//+QihA= Date: Tue, 26 Aug 2014 17:06:20 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CFCB83@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> <53FCA926.9080206@si6networks.com> <2134F8430051B64F815C691A62D9831832CFC96E@XCH-BLV-504.nw.nos.boeing.com> <53FCB378.6060209@si6networks.com> <2134F8430051B64F815C691A62D9831832CFCACA@XCH-BLV-504.nw.nos.boeing.com> <53FCB8D4.30107@si6networks.com> In-Reply-To: <53FCB8D4.30107@si6networks.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/9Sk7XSAc82o0XwVYUKEjh_4UB8w 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, 26 Aug 2014 17:06:26 -0000 SGkgRmVybmFuZG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmVy bmFuZG8gR29udCBbbWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbV0NCj4gU2VudDogVHVlc2Rh eSwgQXVndXN0IDI2LCAyMDE0IDk6NDIgQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgRnJlZCBC YWtlciAoZnJlZCk7IEFuZHJldyDwn5G9IFlvdXJ0Y2hlbmtvDQo+IENjOiBJUHY2IE9wcyBXRw0K PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQTVRVRCBpc3N1ZSBkaXNjdXNzaW9uDQo+IA0KPiBPbiAw OC8yNi8yMDE0IDAxOjMzIFBNLCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4+IEZXSVcsIEkn bSBhbGwgaW4gZmF2b3Igb2YgUkZDNDgyMSwgc2luY2UgaXQgaW1wcm92ZXMgcm9idXN0bmVzcyBv ZiBQTVRVRC4NCj4gPj4NCj4gPj4gVGhhdCBzYWlkLCBhcyBmYXIgYXMgSSBjYW4gcmVjYWxsLCB1 c2luZyBSRkM0ODIxIGZvciBibGFja2hvbGUgZGV0ZWN0aW9uDQo+ID4+ICh3aGVuIHRyYWRpdGlv bmFsIFBNVFVEIGZhaWxzKSBpcyB3ZWxsIHdpdGhpbiB0aGUgc3Bpcml0IG9mIFJGQzQ4MjENCj4g Pj4gKFJGQzQ4MjEgZG9lc24ndCBwdXNoIElDTVAtbGVzcyBhcyB0aGUgb25seSBpbXBsZW1lbnRh dGlvbiBzdHJhdGVneSkuDQo+ID4+DQo+ID4+IFdoYXQgSSByZWNhbGwgZnJvbSBkaXNjdXNzaW5n IHRoaXMgd2l0aCBMaW51eCBkZXZlbG9wZXJzIGNpcmNhIDIwMDUgaXMNCj4gPj4gdGhhdCBhIGNv bXBsZXRlIElDTVAtbGVzcyBQTVRVRCBpcyByYXRoZXIgdW5kZXNpcmFibGUsIHNpbmNlIGl0IHRl bmRzIHRvDQo+ID4+IGhhdmUgbG9uZ2VyIGNvbnZlcmdlbmNlIHRpbWUgd2hlbiBjb21wYXJlZCB3 aXRoICJ0cmFkaXRpb25hbCBQTVRVRCIgfHwNCj4gPj4gIlRyYWRpdGlvbmFsIFBNVFVEICsgUkZD NDgyMSBmb3IgYmxhY2hvbGUgZGV0ZWN0aW9uIi4NCj4gPg0KPiA+IEFjY2VwdGluZyBhbmQgcHJv Y2Vzc2luZyBQVEJzIGFzIHBhcnQgb2YgdGhlIFBMUE1UVUQgcHJvY2VkdXJlIGlzDQo+ID4gZGVz aXJhYmxlIGFuZCBzcGVlZHMgY29udmVyZ2VuY2UuIEJ1dCwgdGhlIG1lY2hhbmlzbSBzdGlsbCBu ZWVkcyB0bw0KPiA+IHdvcmsgd2hlbiB0aGVyZSBhcmUgbm8gUFRCcy4NCj4gPg0KPiA+IFNvLCB0 aGUgbmV0d29yayBzaG91bGQgc3RpbGwgZG8gaXRzIGJlc3QgdG8gcmV0dXJuIFBUQnMsIGFuZCBo b3N0cw0KPiA+IHNob3VsZCBzdGlsbCBkbyB0aGVpciBiZXN0IHRvIG9ic2VydmUgdGhlbS4NCj4g DQo+IEFncmVlZC4gSUlSQywgdGhpcyBiZWhhdmlvcyBoYXMgYmVlbiBpbXBsZW1lbnRlZCBpbiBX aW5kb3dzIGFuZCBPcGVuQlNEDQo+IGZvciA1KyB5ZWFycywgdGhvdWdoLg0KDQo9PT4gQnV0LCB0 aGUgbWVjaGFuaXNtIHN0aWxsIG5lZWRzIHRvIHdvcmsgd2hlbiB0aGVyZSBhcmUgbm8gUFRCcy4N Cg0KSWYgdGhlIGltcGxlbWVudGF0aW9ucyBhcmUgaW4gZmFjdCBhbHJlYWR5IGRvaW5nIHRoaXMg d2VsbCBhbmQNCnNlZWtpbmcgdG8gbWF4aW1pemUgdGhlIHBhdGggTVRVIGJ5IHByb2dyZXNzaXZl bHkgcHJvYmluZyBmb3INCmxhcmdlciBwYWNrZXQgc2l6ZXMgd2l0aG91dCBjYXVzaW5nIGV4Y2Vz c2l2ZSBwYWNrZXQgZHVwbGljYXRpb24NCnRoZW4gZ29vZC4gT3RoZXJ3aXNlLCBtb3JlIHdvcmsg aXMgbmVlZGVkLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQog DQo+IC0tDQo+IEZlcm5hbmRvIEdvbnQNCj4gU0k2IE5ldHdvcmtzDQo+IGUtbWFpbDogZmdvbnRA c2k2bmV0d29ya3MuY29tDQo+IFBHUCBGaW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4 RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUgNzQ5Mg0KPiANCj4gDQo+IA0KDQo= From nobody Tue Aug 26 17:13: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 A3FFB1A0250 for ; Tue, 26 Aug 2014 17:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.531 X-Spam-Level: ** X-Spam-Status: No, score=2.531 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_SONATA=2.5, RP_MATCHES_RCVD=-0.668, 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 rewnBx1jbShH for ; Tue, 26 Aug 2014 17:13:16 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 827101A00FF for ; Tue, 26 Aug 2014 17:13:15 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s7R07Xr3028429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Aug 2014 17:07:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s7R07Xr3028429 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1409098055; bh=RxAocpfUEGRbz/eApjGkOwNV10I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=E7ox758r+GCx+9UAtGrrYQBa0kD4OnTuJryeT+AAfyCGOJUr5ehCCm3FEbF6g3jx4 brQVFe0rmGuhrBKpA+KgYts4BNKc3WLX4HQwJE1QzTM8LvCOF+pEwsPBXuXwZXdbTX Le5R90EUX9Z1rgXrebxkWuP/G+xdWtQtN+9WZGGY= 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: <20140820003344.23DE61D105DD@rock.dv.isc.org> Date: Tue, 26 Aug 2014 17:07:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YEXpEQArP6eeb9WVTBnkFY3wivg Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 00:13:18 -0000 The incentive for customers to upgrade will start to happen when ISPs = start sending out notices to the following effect: =97=97=97=97=97=97=97=97 Due to the aging nature of the IPv4 protocol and the increased costs of = continuing to support customers on this protocol, we will have to start adding an IPv4 surcharge to your bill if you wish = to continue IPv4 service. We recognize that today, many customers will consider IPv4 still an = essential service. Unfortunately, several content providers, such as Amazon, Twitter, Bing, Wordpress, etc. still haven=92t joined = the modern internet by upgrading to IPv6. However, we do not feel that it is fair to penalize customers who no = longer need IPv4 by asking them to share the costs of continuing to support this aging protocol, so, for those customers that = do, we will begin adding $5/month to your bill effective =97=97=97=97=97=97=97=97 (Or something like it) I believe this will happen sooner than many people think. Owen On Aug 19, 2014, at 5:33 PM, Mark Andrews wrote: >=20 > In message = <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.C > O.UK>, "Heatley, Nick" writes: >> If I may stick my neck out. >>=20 >> Id like v6ops to consider at least two items: >>=20 >> 1. (Carrier Grade) NAT64 vs NAT44 a deathmatch. >=20 > Most of the problem with NAT64 vs NAT44 is getting CPE > devices upgraded. 464xlate worked for cellular networks > because the devices were replaced to support 4G services > and those new devices support 464xlate. Additionally cell > phones are fragile devices that get stolen, lost, dropped, > stepped on, driven over, and is some market need to be > replaced to change carrier ... so there is a high turnover. >=20 > For wired connections there is no incentive for the customer > to replace the CPE device so NAT44 is a required part of > the solution space just to share the limited IPv4 address > space between the IPv4 only customers. Cable and DSL modems > work for 10+ years. Home routers work for similar lengths > of time. You can still buy IPv4 only routers and they are > cheaper than anything with IPv6 in it. If you are on a > limited budget a IPv4 only router with 802.11g "will do". >=20 > Add to that ISP's not offering / promoting IPv6 there is > no incentive for the customer to buy the IPv6 capable device > over the IPv4 only one. The choice of device is made on > other factors. If ISPs offered to do 2G of IPv6 data for > the price of 1G of IPv4 data one might actually get customers > to buy IPv6 capable routers. A 12 month rebate for installing > a IPv6 capable CPE device could offset the costs of installing > more CGNAT boxes. IPv6 capable 802.11n routers can be got > for AUD80 today. Even on a AUD$20 plan the rebates would > cover the costs if the usual +50% taffic shift to IPv6 > occurs. >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Aug 27 09:19: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 477E91A0ADA for ; Wed, 27 Aug 2014 09:19:16 -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 S7tm_01FJQMk for ; Wed, 27 Aug 2014 09:19:13 -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 AA4E01A0233 for ; Wed, 27 Aug 2014 09:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4273; q=dns/txt; s=iport; t=1409156353; x=1410365953; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/ujZpP6Iaa5lg0dcBLuq+s2p1ioF02dmaPTUo77br8A=; b=kMjG38yB185gArcYP+yKkO6KDhIjAddi1bPPT9EgI7esxEQPegPYY4iJ vilmMKnU1HvnK0qINsQbdaviXmh9sllK4lwg4Xl8RlSp0uGe3phaZWUvu 4txOvR0wr4cE3NKTwZz3gQ7kwT+jXdUr2oB0ESOX6OChwfoAYY5gE1vlb 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAEkE/lOtJA2I/2dsb2JhbABbgw1TVwTTcwGBEhZ3hAQBAQMBeQULAgEGAkYyJQIEDgUOiCwIji2wfheOahEBDkIHgy+BHQWRL4IGgUqHWZUagWwWgVxsgQgHFyKBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,412,1406592000"; d="asc'?scan'208";a="72816179" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 27 Aug 2014 16:19:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7RGJC34005888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 16:19:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 11:19:12 -0500 From: "Fred Baker (fred)" To: Owen DeLong Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPwhKjN7kM6kJ150+pJ1FY+ZX9uw== Date: Wed, 27 Aug 2014 16:19:12 +0000 Message-ID: <373BB597-44BE-4555-9E8F-326C1DD157FD@cisco.com> References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_2EA3B40B-CA5C-4F76-8215-4C6E18A4E857"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K1bRs9DnHV0G9AVVYVK27HMWiE8 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:19:16 -0000 --Apple-Mail=_2EA3B40B-CA5C-4F76-8215-4C6E18A4E857 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 26, 2014, at 5:07 PM, Owen DeLong wrote: > The incentive for customers to upgrade will start to happen when ISPs = start sending out notices to the following effect: >=20 > =97=97=97=97=97=97=97=97 >=20 > Due to the aging nature of the IPv4 protocol and the increased costs = of continuing to support customers on this protocol, > we will have to start adding an IPv4 surcharge to your bill if you = wish to continue IPv4 service. >=20 > We recognize that today, many customers will consider IPv4 still an = essential service. Unfortunately, several content providers, > such as Amazon, Twitter, Bing, Wordpress, etc. still haven=92t joined = the modern internet by upgrading to IPv6. >=20 > However, we do not feel that it is fair to penalize customers who no = longer need IPv4 by asking them to share the costs of > continuing to support this aging protocol, so, for those customers = that do, we will begin adding $5/month to your bill effective > >=20 > =97=97=97=97=97=97=97=97 >=20 > (Or something like it) >=20 > I believe this will happen sooner than many people think. Speaking for myself, I would agree. Note that in this email I am wearing = neither a corporate nor an IETF hat (always at least theoretically true = on IETF lists, but I want to emphasize it). I am a random fly on the = wall. That said, there are a couple of steps companies need to take before = they do this. If consumers don=92t have a way to avoid the $5 charge, = it=92s simply a price increase, and will be reported and commented on as = such. Part of this is content, and therefore enterprise. I would expect that = ISPs will find themselves needing to apply price differential based on = IPv4-only vs dual stack access to their enterprise customers=92 public = sites. In essence, consumer-accessible sites need to be IPv6-capable for = https/http2 and SMTP, and possibly a few other protocols. Proof of = connectivity is probably that an IPv6-only endpoint can access the name = of the company using the included protocols, and not just on the day the = contract is signed but periodically through its lifetime. The means to = achieve that could be as simple as signing up with a CDN or cloud = provider, but I would expect the ISP to want it to use either dual stack = connectivity on the access link to the enterprise, or CDN/cloud that is = embedded with the ISP. It has to solve a problem for the ISP. Both that and residential broadband will need an IPv6-capable upstream. = Speaking for myself, AFAIK my residential provider doesn=92t offer IPv6 = to me. Last time I asked them, they quoted me $1000/month. I have IPv6 = service via VPN to my employer. We have a few companies that are = starting down that road. We need more. And as the biggest single issue in residential IPv6 deployment is the = CPE router, I suspect the ISP will need to facilitate some program in = which a known-working IPv6 CPE gets into the home. That could be a = managed service, a coupon at a department store, or whatever. But you = will have a real headache if you tell people that they will be charged = more if they don=92t have IPv6 capabilities, they agree to let you put = an IPv6 address on their modem, but then their CPE doesn=92t actually = use it. Explaining to them =93but I don=92t see IPv6 packets coming out = of your house=94 will be a real sink. The ISP will need to make it = Really Easy for them to have IPv6 packets coming out of their house = without them having to grok the implications. --Apple-Mail=_2EA3B40B-CA5C-4F76-8215-4C6E18A4E857 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 iD8DBQFT/gT+bjEdbHIsm0MRAtbeAJ4qpCeAdwoeyRtyVZoNqt4vuVzU4gCgqdPt jIKUdbezyas5hAIYMLMYHWs= =w24h -----END PGP SIGNATURE----- --Apple-Mail=_2EA3B40B-CA5C-4F76-8215-4C6E18A4E857-- From nobody Wed Aug 27 09: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 8B91E1A0B01 for ; Wed, 27 Aug 2014 09:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_SONATA=2.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi4UxwkjvSgH for ; Wed, 27 Aug 2014 09:29:34 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C2F1A06ED for ; Wed, 27 Aug 2014 09:29:33 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so327026oif.16 for ; Wed, 27 Aug 2014 09:29:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/9voVhMHtLkvl0RhDtQClEBzWRZP5NyO6RB0HlAbmY4=; b=j9j74asiM2LW+/KcQLYs0K3zBwUjrVdOxkxXiM573WdwlaYsB8Csby+f7k6jXC9+wR QmBs1B8qDInpGsG/90WN+vWiNd183pATVdEgDNf86DttGNHXZw382e3Jl+3uTQx/1UKz SovPuzFS2PJcCz3yE5U0PM2vJd2/xbnuaUeKvmUq0qWpGE5ABM3laNDPCqN5SreMvDSt 1qgRf9vmV3O8IQd0cT7/6COb9iUuZ6W8GjmITFcP1fU0DF+f+GsyWWtr6dLqQZIpfugj GpvlEgcFA7vrwa6jsF1TTa3WzziYU+nDrENASD4boYOYQPGkrxB/3sMfyQrxnEPcZXjt WWsQ== X-Gm-Message-State: ALoCoQkbZggmwJ3Njln40fMkB8Ak1Tq/qHrBvjtePtzV+uhA8XrctmvWm0n3s9qt0SeZXLctP7WE MIME-Version: 1.0 X-Received: by 10.182.219.116 with SMTP id pn20mr2507651obc.86.1409156973151; Wed, 27 Aug 2014 09:29:33 -0700 (PDT) Received: by 10.76.96.180 with HTTP; Wed, 27 Aug 2014 09:29:32 -0700 (PDT) In-Reply-To: References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> Date: Wed, 27 Aug 2014 09:29:32 -0700 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=e89a8ff248b5d163f905019eec61 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4j83nhDKlypr0kBesdn7ELOVgtg Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:29:35 -0000 --e89a8ff248b5d163f905019eec61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think about this a little differently. I contend the incentive for customers to upgrade will happen when "have you tried disabling IPv4?" and "do you have IPv6?" are the responses you start seeing in troubleshooting forums in response to questions in the category "Why is $APPLICATION not working / too slow / so unstable?" On Tue, Aug 26, 2014 at 5:07 PM, Owen DeLong wrote: > The incentive for customers to upgrade will start to happen when ISPs > start sending out notices to the following effect: > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > Due to the aging nature of the IPv4 protocol and the increased costs of > continuing to support customers on this protocol, > we will have to start adding an IPv4 surcharge to your bill if you wish t= o > continue IPv4 service. > > We recognize that today, many customers will consider IPv4 still an > essential service. Unfortunately, several content providers, > such as Amazon, Twitter, Bing, Wordpress, etc. still haven=E2=80=99t join= ed the > modern internet by upgrading to IPv6. > > However, we do not feel that it is fair to penalize customers who no > longer need IPv4 by asking them to share the costs of > continuing to support this aging protocol, so, for those customers that > do, we will begin adding $5/month to your bill effective > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > (Or something like it) > > I believe this will happen sooner than many people think. > > Owen > > On Aug 19, 2014, at 5:33 PM, Mark Andrews wrote: > > > > > In message > <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.C > > O.UK>, "Heatley, Nick" writes: > >> If I may stick my neck out. > >> > >> Id like v6ops to consider at least two items: > >> > >> 1. (Carrier Grade) NAT64 vs NAT44 a deathmatch. > > > > Most of the problem with NAT64 vs NAT44 is getting CPE > > devices upgraded. 464xlate worked for cellular networks > > because the devices were replaced to support 4G services > > and those new devices support 464xlate. Additionally cell > > phones are fragile devices that get stolen, lost, dropped, > > stepped on, driven over, and is some market need to be > > replaced to change carrier ... so there is a high turnover. > > > > For wired connections there is no incentive for the customer > > to replace the CPE device so NAT44 is a required part of > > the solution space just to share the limited IPv4 address > > space between the IPv4 only customers. Cable and DSL modems > > work for 10+ years. Home routers work for similar lengths > > of time. You can still buy IPv4 only routers and they are > > cheaper than anything with IPv6 in it. If you are on a > > limited budget a IPv4 only router with 802.11g "will do". > > > > Add to that ISP's not offering / promoting IPv6 there is > > no incentive for the customer to buy the IPv6 capable device > > over the IPv4 only one. The choice of device is made on > > other factors. If ISPs offered to do 2G of IPv6 data for > > the price of 1G of IPv4 data one might actually get customers > > to buy IPv6 capable routers. A 12 month rebate for installing > > a IPv6 capable CPE device could offset the costs of installing > > more CGNAT boxes. IPv6 capable 802.11n routers can be got > > for AUD80 today. Even on a AUD$20 plan the rebates would > > cover the costs if the usual +50% taffic shift to IPv6 > > occurs. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > _______________________________________________ > > 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 > --e89a8ff248b5d163f905019eec61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think about this a little differently.

I contend the incentive for customers to upgrade will happen when "h= ave you tried disabling IPv4?" and "do you have IPv6?" are t= he responses you start seeing in troubleshooting forums in response to ques= tions in the category "Why is $APPLICATION not working / too slow / so= unstable?"


On Tue,= Aug 26, 2014 at 5:07 PM, Owen DeLong <owen@delong.com> wrote:=
The incentive for customers to upgrade will start to happen when ISPs start= sending out notices to the following effect:

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
Due to the aging nature of the IPv4 protocol and the increased costs of con= tinuing to support customers on this protocol,
we will have to start adding an IPv4 surcharge to your bill if you wish to = continue IPv4 service.

We recognize that today, many customers will consider IPv4 still an essenti= al service. Unfortunately, several content providers,
such as Amazon, Twitter, Bing, Wordpress, etc. still haven=E2=80=99t joined= the modern internet by upgrading to IPv6.

However, we do not feel that it is fair to penalize customers who no longer= need IPv4 by asking them to share the costs of
continuing to support this aging protocol, so, for those customers that do,= we will begin adding $5/month to your bill effective
<date>

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
(Or something like it)

I believe this will happen sooner than many people think.

Owen

On Aug 19, 2014, at 5:33 PM, Mark Andrews <marka@isc.org> wrote:

>
> In message <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.= EEAD.EEINT.C
> O.UK>, "Heatley,= Nick" writes:
>> If I may stick my neck out.
>>
>> Id like v6ops to consider at least two items:
>>
>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0(Carrier Grade) NAT64 vs NAT44=C2=A0 = a deathmatch.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Most of the problem with NAT64 vs NAT44 is g= etting CPE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0devices upgraded.=C2=A0 464xlate worked for = cellular networks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0because the devices were replaced to support= 4G services
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and those new devices support 464xlate.=C2= =A0 Additionally cell
>=C2=A0 =C2=A0 =C2=A0 =C2=A0phones are fragile devices that get stolen, = lost, dropped,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0stepped on, driven over, and is some market = need to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0replaced to change carrier ... so there is a= high turnover.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For wired connections there is no incentive = for the customer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to replace the CPE device so NAT44 is a requ= ired part of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the solution space just to share the limited= IPv4 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0space between the IPv4 only customers.=C2=A0= Cable and DSL modems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0work for 10+ years.=C2=A0 Home routers work = for similar lengths
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of time.=C2=A0 You can still buy IPv4 only r= outers and they are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cheaper than anything with IPv6 in it.=C2=A0= If you are on a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0limited budget a IPv4 only router with 802.1= 1g "will do".
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Add to that ISP's not offering / promoti= ng IPv6 there is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0no incentive for the customer to buy the IPv= 6 capable device
>=C2=A0 =C2=A0 =C2=A0 =C2=A0over the IPv4 only one.=C2=A0 The choice of = device is made on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0other factors.=C2=A0 If ISPs offered to do 2= G of IPv6 data for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the price of 1G of IPv4 data one might actua= lly get customers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to buy IPv6 capable routers.=C2=A0 A 12 mont= h rebate for installing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a IPv6 capable CPE device could offset the c= osts of installing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more CGNAT boxes.=C2=A0 IPv6 capable 802.11n= routers can be got
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for AUD80 today.=C2=A0 Even on a AUD$20 plan= the rebates would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cover the costs if the usual +50% taffic shi= ft to IPv6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0occurs.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0INTERNET: marka@isc.org<= br> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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

--e89a8ff248b5d163f905019eec61-- From nobody Wed Aug 27 09:54: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 BFD5E1A0B09 for ; Wed, 27 Aug 2014 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.168 X-Spam-Level: X-Spam-Status: No, score=-115.168 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=-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 b6OFCOgNtJVI for ; Wed, 27 Aug 2014 09:54:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172B71A0346 for ; Wed, 27 Aug 2014 09:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2793; q=dns/txt; s=iport; t=1409158478; x=1410368078; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gT11gjLMjUE6mwN6na0CN5BaLMJk2IO3eu8djkSUZHU=; b=iWuGIh2fGWnXI8X8ARVY03YkSIk8eVQd8plJNGewZ7MNuYCRAuLr4BPw SeSfJlAQjPXfiXS+uV+/Lsb+XToyU/OcsTRknwXfYXSAWER6FP1t5WZkT k1MPtiq95jZFf6qgh8eTbZOrKCjh6DCvKgs/jYCohcx3oZ1aef1mUCsx5 s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FALsM/lOtJV2c/2dsb2JhbABbgkdGgSoE03MBgRIWd4QEAQEDAXkFCwIBCAQBCTgyJQIEDgUOiCwIv0YXj0wHgy+BHQEEkS+CBoFKh1mVGoNebIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,412,1406592000"; d="asc'?scan'208,217";a="350746066" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 27 Aug 2014 16:54:37 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7RGsb8S019775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 16:54:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 11:54:37 -0500 From: "Fred Baker (fred)" To: James Woodyatt Thread-Topic: [v6ops] Operational Consensus on deployment Thread-Index: AQHPwheVjjU+IWEWD0aqPTX77t6YGg== Date: Wed, 27 Aug 2014 16:54:36 +0000 Message-ID: <35E70324-B972-4411-8CD3-BC07EA553859@cisco.com> References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_85F99468-6F5E-4821-AFEC-48803C6D5BD0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cTfm5QWg7nL4PsExhA5dXW-ffCI Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:54:39 -0000 --Apple-Mail=_85F99468-6F5E-4821-AFEC-48803C6D5BD0 Content-Type: multipart/alternative; boundary="Apple-Mail=_9C633084-69E6-473C-8173-A7AE7D90608D" --Apple-Mail=_9C633084-69E6-473C-8173-A7AE7D90608D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 27, 2014, at 9:29 AM, James Woodyatt wrote: > I contend the incentive for customers to upgrade will happen when = "have you tried disabling IPv4?" and "do you have IPv6?" are the = responses you start seeing in troubleshooting forums in response to = questions in the category "Why is $APPLICATION not working / too slow / = so unstable?" True enough, but they=92ll need the access problem solved first. It must = be feasible to turn off IPv4. --Apple-Mail=_9C633084-69E6-473C-8173-A7AE7D90608D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 27, 2014, at 9:29 AM, James = Woodyatt <jhw@nestlabs.com> = wrote:

I contend the incentive for customers = to upgrade will happen when "have you tried disabling IPv4?" and "do you = have IPv6?" are the responses you start seeing in troubleshooting forums = in response to questions in the category "Why is $APPLICATION not = working / too slow / so = unstable?"

True enough, but they=92ll = need the access problem solved first. It must be feasible to turn off = IPv4.
= --Apple-Mail=_9C633084-69E6-473C-8173-A7AE7D90608D-- --Apple-Mail=_85F99468-6F5E-4821-AFEC-48803C6D5BD0 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 iD8DBQFT/g1KbjEdbHIsm0MRAnTaAKCE2E9y9Ay9ONNFzNd7L7f0Mb6YkACgzrQr hgB6eczADkkhXqy+xKUuZK4= =evoE -----END PGP SIGNATURE----- --Apple-Mail=_85F99468-6F5E-4821-AFEC-48803C6D5BD0-- From nobody Wed Aug 27 11:12: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 9F0F11A00A8 for ; Wed, 27 Aug 2014 11:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEZecky1Ehx6 for ; Wed, 27 Aug 2014 11:12:42 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CA91A00FE for ; Wed, 27 Aug 2014 11:12:42 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m19so104418oag.12 for ; Wed, 27 Aug 2014 11:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dLzTyK4NIlC9w3ak9wkqC7hSVQFy+ZvKnATst1V4Fqs=; b=cJVS257fA8X6yhfILip01+Fo9xuW8N8mLJuoFyaO5OyzavZTh9XZmNwpLO2x8iatLJ TL5aYQC4wJqvhhzlRIV6ykMCfK7vYxyzOQ35bDksTIcuLfItdWZIKtgxq2UqeGR9B/kW Q1IBTYCGVyK0Rb37adK/k0ReDjaQ0twskU05Dcqid1wRgNvOQcF0cuHtJQlzW9rbplh7 ZuEvdOwoZaJflOYmL9YdgIIRtsEeq+dG224OEB9J5zL5esiVjYUh8hAuTkNSb5mk8IhR VbWLk1iNITT8SkFVHbfVfXqKkaeZWrXG3UyOWiRKr25Qr6MmB4xHMUeHvUdeTKdfCqyY 7fmw== X-Gm-Message-State: ALoCoQnSvHMmcp8kJ1IMmATmrRIWblWX/I3a270lZbOnceQ8i2OlAn+Su89PmQvzdyRRXs1f7IF3 MIME-Version: 1.0 X-Received: by 10.182.219.116 with SMTP id pn20mr3214687obc.86.1409163161353; Wed, 27 Aug 2014 11:12:41 -0700 (PDT) Received: by 10.76.96.180 with HTTP; Wed, 27 Aug 2014 11:12:41 -0700 (PDT) In-Reply-To: <35E70324-B972-4411-8CD3-BC07EA553859@cisco.com> References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> <35E70324-B972-4411-8CD3-BC07EA553859@cisco.com> Date: Wed, 27 Aug 2014 11:12:41 -0700 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=e89a8ff248b5a9ffec0501a05d8a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/T1x3QLVATwcNDZ-mQE9Ln0fFhr4 Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:12:43 -0000 --e89a8ff248b5a9ffec0501a05d8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, actually=E2=80=94 it never needs to be feasible to turn off IPv4. Ordi= nary people, the users of Internet applications, don't really see any need to augment IPv4 with IPv6. And they never will until the utility of the IPv4 Internet begins to degrade noticeably in comparison to the IPv6 Internet. If people are never exposed to the idea that "using $APPLICATION is full of lose because IPv4, use IPv6 instead," then people will never have any incentive to stop using IPv4 and start using IPv6. So long as IPv4 continues to be 1) an essential service and 2) functionally equivalent to IPv6 at the level of application visibility, there is no actual need to solve the IPv6 access problem, because application users don't actually need it. If operators want ordinary people to migrate from IPv4 to IPv6, they might try offering IPv6-only service at discount prices=E2=80=94 which would posi= tion IPv6 as the protocol for second-class citizens who can't pay premium prices for the first-class Internet that rich celebrities enjoy between bites of caviar. Or they can offer dual-stack service and provision their networks so that CGN44 boxes are the peak-load IPv4 bottlenecks, which would position IPv4 as the protocol for second-class citizens who can't afford to upgrade to the latest gear. Which of those strategies do we think provides more incentive to upgrade to IPv6? --e89a8ff248b5a9ffec0501a05d8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, actually=E2=80=94 it never needs to be feasible to tur= n off IPv4. =C2=A0Ordinary people, the users of Internet applications, don&= #39;t really see any need to augment IPv4 with IPv6. =C2=A0And they never w= ill until the utility of the IPv4 Internet begins to degrade noticeably in = comparison to the IPv6 Internet.

If people are never exposed to the idea that "using $AP= PLICATION is full of lose because IPv4, use IPv6 instead," then people= will never have any incentive to stop using IPv4 and start using IPv6. =C2= =A0So long as IPv4 continues to be 1) an essential service and 2) functiona= lly equivalent to IPv6 at the level of application visibility, there is no = actual need to solve the IPv6 access problem, because application users don= 't actually need it.

If operators want ordinary people to migrate from IPv4 = to IPv6, they might try offering IPv6-only service at discount prices=E2=80= =94 which would position IPv6 as the protocol for second-class citizens who= can't pay premium prices for the first-class Internet that rich celebr= ities enjoy between bites of caviar. =C2=A0Or they can offer dual-stack ser= vice and provision their networks so that CGN44 boxes are the peak-load IPv= 4 bottlenecks, which would position IPv4 as the protocol for second-class c= itizens who can't afford to upgrade to the latest gear. =C2=A0Which of = those strategies do we think provides more incentive to upgrade to IPv6?
--e89a8ff248b5a9ffec0501a05d8a-- From nobody Wed Aug 27 19:00: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 2CFCF1A0089 for ; Wed, 27 Aug 2014 19:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 gcycEHFyI5Pf for ; Wed, 27 Aug 2014 19:00:25 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2471A00A6 for ; Wed, 27 Aug 2014 19:00:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 09E491FCB5C; Thu, 28 Aug 2014 02:00:22 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BD02016006A; Thu, 28 Aug 2014 02:02:59 +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 5A48916005D; Thu, 28 Aug 2014 02:02:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7B7761DA70F7; Thu, 28 Aug 2014 12:00:19 +1000 (EST) To: James Woodyatt From: Mark Andrews References: <53DFEC6C.3010707@gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <53E1236A.605@fud.no> <20140805195402.GO51793@Space.Net> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> <35E70324-B972-4411-8CD3-BC07EA553859@cisco.com> In-reply-to: Your message of "Wed, 27 Aug 2014 11:12:41 -0700." Date: Thu, 28 Aug 2014 12:00:19 +1000 Message-Id: <20140828020019.7B7761DA70F7@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eiL92VEpqQgXJddasTdKHEWazkY Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational Consensus on deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 02:00:32 -0000 In message , James Woodyatt writes: > > No, actually— it never needs to be feasible to turn off IPv4. Ordinary > people, the users of Internet applications, don't really see any need to > augment IPv4 with IPv6. And they never will until the utility of the IPv4 > Internet begins to degrade noticeably in comparison to the IPv6 Internet. CGN significantly degrades IPv4 for some as you no longer have working port forwarding, a semi static public IPv4 address, and access to protocols other that TCP, UDP and ICMP. PCP still needs the CPE to be upgraded which hopefully will include IPv6 support. > If people are never exposed to the idea that "using $APPLICATION is full > of lose because IPv4, use IPv6 instead," then people will never have any > incentive to stop using IPv4 and start using IPv6. So long as IPv4 > continues to be 1) an essential service and 2) functionally equivalent to > IPv6 at the level of application visibility, there is no actual need to > solve the IPv6 access problem, because application users don't actually > need it. > > If operators want ordinary people to migrate from IPv4 to IPv6, they might > try offering IPv6-only service at discount prices— which would position > IPv6 as the protocol for second-class citizens who can't pay premium > prices > for the first-class Internet that rich celebrities enjoy between bites of > caviar. Or they can offer dual-stack service and provision their networks > so that CGN44 boxes are the peak-load IPv4 bottlenecks, which would > position IPv4 as the protocol for second-class citizens who can't afford > to> upgrade to the latest gear. Which of those strategies do we think > provides more incentive to upgrade to IPv6? * Just fail 10% of connection attempts through the CGN44. * Only allow X table entries per customer, where X decreases every month. I think the first thing they want is to get IPv6 capable CPE devices installed and IPv6 enabled on them. When +50% of traffic will switch to IPv6 immediately you get significant saving through not having to provision the CGN44 to support all the sessions that are going over IPv6. Less IPv4 address are needed. Less boxes are needed. With CGN44 its simultaneous sessions per IPv4 address which is a limiting factor. You get a bigger pool of IPv4 which can be handed out to those customers (domestic and commercial) that really still need a public IPv4 address possibly for a addition cost. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 28 10:44: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 757ED1A886F; Thu, 28 Aug 2014 10:44:32 -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 HAiQFhJJSwOZ; Thu, 28 Aug 2014 10:44:29 -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 BD42C1A0B82; Thu, 28 Aug 2014 10:44:29 -0700 (PDT) Received: from [2001:5c0:1000:a::503] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XN3kI-0002gy-MV; Thu, 28 Aug 2014 19:44:27 +0200 Message-ID: <53FF6A6F.5010508@si6networks.com> Date: Thu, 28 Aug 2014 14:44: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: "'opsec@ietf.org'" , IPv6 Operations References: <20140828173747.6623.76624.idtracker@ietfa.amsl.com> In-Reply-To: <20140828173747.6623.76624.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140828173747.6623.76624.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NiwDzE9YXZz8HkHaf49y4UiC0EU Subject: [v6ops] ICMP/ICMPv6 network ingress filtering (Fwd: New Version Notification for draft-gont-opsec-icmp-ingress-filtering-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 17:44:32 -0000 Folks, Based on the recent discussion we have had about ICMP-based DoS attacks, we have posted an I-D which describes and suggests that network ingress filtering be applied on ICMPv4 and ICMPv6 error messages (based on the addresses of the embedded payload). The I-D is available at: Any feedback will be very appreciated. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsec-icmp-ingress-filtering-00.txt Date: Thu, 28 Aug 2014 10:37:47 -0700 From: internet-drafts@ietf.org To: Will(Shucheng) Liu , Jeroen Massar , Ray Hunter , Fernando Gont , Ray Hunter , Jeroen Massar , Fernando Gont , Shucheng LIU (Will) A new version of I-D, draft-gont-opsec-icmp-ingress-filtering-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsec-icmp-ingress-filtering Revision: 00 Title: Network Ingress Filtering: Defeating Attacks which employ Forged ICMP/ ICMPv6 Error Messages Document date: 2014-08-28 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-gont-opsec-icmp-ingress-filtering-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsec-icmp-ingress-filtering/ Htmlized: http://tools.ietf.org/html/draft-gont-opsec-icmp-ingress-filtering-00 Abstract: Over the years, a number of attack vectors that employ forged ICMP/ ICMPv6 error messages have been disclosed and exploited in the wild. The aforementioned attack vectors do not require that the source address of the packets be forged, but do require that the addresses of the IP/IPv6 packet embedded in the ICMP/ICMPv6 payload be forged. This document discusses a simple, effective, and straightforward method for using ingress traffic filtering to mitigate attacks that use forged addresses in the IP/IPv6 packet embedded in an ICMP/ICMPv6 payload. This advice is in line with the recommendations in BCP38. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Aug 29 08:01: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 D753C1A052E; Fri, 29 Aug 2014 08:01: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7USAVo9mLSLU; Fri, 29 Aug 2014 08:01:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5E11A04BC; Fri, 29 Aug 2014 08:01:34 -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: <20140829150134.28129.23191.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 08:01:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fCW0KfaTh9C75q_2tCdgor_eAwA Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-10.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, 29 Aug 2014 15:01:36 -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 Filename : draft-ietf-v6ops-mobile-device-profile-10.txt Pages : 19 Date : 2014-08-29 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-10 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 Sat Aug 30 10:50: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 E66BB1A8ABE for ; Sat, 30 Aug 2014 10:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 08tI6kI7-gzK for ; Sat, 30 Aug 2014 10:50:33 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83A811A8AA4 for ; Sat, 30 Aug 2014 10:50:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D3A6987151A; Sat, 30 Aug 2014 19:50:31 +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 Jde4D299JS3T; Sat, 30 Aug 2014 19:50:31 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:f4ce:58cf:a593:2470]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 92DB4871519; Sat, 30 Aug 2014 19:50:31 +0200 (CEST) Message-ID: <54020ECC.4000000@globis.net> Date: Sat, 30 Aug 2014 19:50:04 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) 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> In-Reply-To: <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LpHKE91QpPtFiW447jmFsO316nE 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: Sat, 30 Aug 2014 17:50:35 -0000 Fred Baker (fred) wrote: > On Aug 26, 2014, at 2:50 AM, Andrew 👽 Yourtchenko wrote: > >> 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" >> >> 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. >> >> I think it would be useful to see the discussion of this measure and >> its applicability/tradeoffs in the draft. > > It seems like it might have value to also test the interaction with various initial window settings, and look at its inclusion in other relevant OS’s including FreeBSD, Windows, and MacOSX. My reading of 4821 says it’s grand theory, but I’m not precisely sure how I would write the code. As an initial setting, for example, I could imagine sending an initial burst containing a 9K byte packet, a 1500 byte packet, and a 1280 byte packet in that order, and set the MSS to the the size of the first acknowledgment I receive. How does that relate to IW=10 (RFC 6928)? Whilst reading your discussion, I had a "what if" brainwave. Paths are learned via routing. What if Path MTU was also learned via routing, rather than being probed for by individual end hosts? Then I checked: EIGRP discovers the set of 6 metrics (bandwidth, load, delay, reliability, minimum MTU, hop count) MTU is never used in the routing decision AFAICS, but couldn't the local router be programmed to generate ICMP PTB messages (as a proxy for downstream routers) with a link-local source address to each host if a path MTU is going to be exceeded, plus a hint of the actual PMTU discovered by routing? Thus avoiding ICMP PTB message black holes?And avoiding the PLMTUD discovery process and extensive probing/ ramp up for every session? And also avoiding trust issues (as hosts presumably trust their local on-link default router)? Obviously for this to work internet wide, BGP would also need to carry an AS-PMTU attribute per AS path. -- Regards, RayH From nobody Sat Aug 30 22:00: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 B98191A6F99 for ; Sat, 30 Aug 2014 22:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARKqB8cmnFIf for ; Sat, 30 Aug 2014 22:00:40 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0: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 EFEC21A6F9B for ; Sat, 30 Aug 2014 22:00:39 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id im17so4194265vcb.32 for ; Sat, 30 Aug 2014 22:00:39 -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=NnPW1cNqKtx/QdqfmwplCjj61JCurUTTUuZ4opV4gq0=; b=gbCurYCgmWtz7ZmoGH++JwLQcHumhGjDwKzhG0DQuXAVpGZPoXe9qwtROtZ0GBB2eL JFiwgXZe4nj9ayeRj5A9c1RoNSo1VfWGO9ZJe0r1gXYN7vYSVQKwzGXVx+s5xPU5sfaD 2dyS1Kz+eDGTH8n/E7c0nqo+4V+wBfStITLCZcpW4eDUc0ClBAgFfdU1tahSbSNW/OVM FumgIkaBVrane7KFdhrSc8hnwYok9DOf9+aP3CdtD1FQlwRtc8qFg0HimyIqvJeYbAC6 7QaKfWbdyG5QPcVFxEAMWkzNDiNw07KQHOZVdJPCurvn4ONFzvsPAaNpmXI/HwW2mcQh XOzw== MIME-Version: 1.0 X-Received: by 10.220.172.8 with SMTP id j8mr17214311vcz.32.1409461239084; Sat, 30 Aug 2014 22:00:39 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.220.86.197 with HTTP; Sat, 30 Aug 2014 22:00:39 -0700 (PDT) In-Reply-To: <54020ECC.4000000@globis.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> Date: Sat, 30 Aug 2014 22:00:39 -0700 X-Google-Sender-Auth: qK8nG47-WXd4JthO7v0oxXzaCfM Message-ID: From: Matthew Petach To: Ray Hunter Content-Type: multipart/alternative; boundary=001a11c3678c7afdd00501e5c4bb Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PVtcS9SGFw3jruugYAad1v3Hwko 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: Sun, 31 Aug 2014 05:00:41 -0000 --001a11c3678c7afdd00501e5c4bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 30, 2014 at 10:50 AM, Ray Hunter wrote: > Fred Baker (fred) wrote: > >> On Aug 26, 2014, at 2:50 AM, Andrew =F0=9F=91=BD Yourtchenko >> wrote: >> >> 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" >>> >>> 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. >>> >>> I think it would be useful to see the discussion of this measure and >>> its applicability/tradeoffs in the draft. >>> >> >> It seems like it might have value to also test the interaction with >> various initial window settings, and look at its inclusion in other >> relevant OS=E2=80=99s including FreeBSD, Windows, and MacOSX. My reading= of 4821 >> says it=E2=80=99s grand theory, but I=E2=80=99m not precisely sure how I= would write the >> code. As an initial setting, for example, I could imagine sending an >> initial burst containing a 9K byte packet, a 1500 byte packet, and a 128= 0 >> byte packet in that order, and set the MSS to the the size of the first >> acknowledgment I receive. How does that relate to IW=3D10 (RFC 6928)? >> > > Whilst reading your discussion, I had a "what if" brainwave. > > Paths are learned via routing. What if Path MTU was also learned via > routing, rather than being probed for by individual end hosts? > > Then I checked: EIGRP discovers the set of 6 metrics (bandwidth, load, > delay, reliability, minimum MTU, hop count) > > MTU is never used in the routing decision AFAICS, but couldn't the local > router be programmed to generate ICMP PTB messages (as a proxy for > downstream routers) with a link-local source address to each host if a pa= th > MTU is going to be exceeded, plus a hint of the actual PMTU discovered by > routing? > > Thus avoiding ICMP PTB message black holes?And avoiding the PLMTUD > discovery process and extensive probing/ ramp up for every session? > And also avoiding trust issues (as hosts presumably trust their local > on-link default router)? > > Obviously for this to work internet wide, BGP would also need to carry an > AS-PMTU attribute per AS path. > This seems to imply you think there's a single MTU for an entire prefix? Or would this entail deaggregating prefixes down to the point where an accurate MTU could be associated with each more specific? It's a interesting idea, but highly, highly impractical without potentially blowing up the routing table size. Matt > > -- > Regards, > RayH > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c3678c7afdd00501e5c4bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Aug 30, 2014 at 10:50 AM, Ray Hunter <= v6ops@globis.net&= gt; wrote:
Fred= Baker (fred) wrote:
On Aug 26, 2014, at 2:50 AM, Andrew =F0=9F=91=BD Yourtchenko<ayourtch@gmail.com&= gt;=C2=A0 wrote:

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"

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.

I think it would be useful to see the discussion of this measure and
its applicability/tradeoffs in the draft.

It seems like it might have value to also test the interaction with various= initial window settings, and look at its inclusion in other relevant OS=E2= =80=99s including FreeBSD, Windows, and MacOSX. My reading of 4821 says it= =E2=80=99s grand theory, but I=E2=80=99m not precisely sure how I would wri= te the code. As an initial setting, for example, I could imagine sending an= initial burst containing a 9K byte packet, a 1500 byte packet, and a 1280 = byte packet in that order, and set the MSS to the the size of the first ack= nowledgment I receive. How does that relate to IW=3D10 (RFC 6928)?

Whilst reading your discussion, I had a "what if" brainwave.

Paths are learned via routing. What if Path MTU was also learned via routin= g, rather than being probed for by individual end hosts?

Then I checked: EIGRP discovers the set of 6 metrics (bandwidth, load, dela= y, reliability, minimum MTU, hop count)

MTU is never used in the routing decision AFAICS, but couldn't the loca= l router be programmed to generate ICMP PTB messages (as a proxy for downst= ream routers) with a link-local source address to each host if a path MTU i= s going to be exceeded, plus a hint of the actual PMTU discovered by routin= g?

Thus avoiding ICMP PTB message black holes?And avoiding the PLMTUD discover= y process and extensive probing/ ramp up for every session?
And also avoiding trust issues (as hosts presumably trust their local on-li= nk default router)?

Obviously for this to work internet wide, BGP would also need to carry an A= S-PMTU attribute per AS path.

This seems to imply you= think there's a single
MTU for an entire prefix?=C2=A0 Or would this entail
deaggregating prefi= xes down to the point where
an accurate MTU could be associated with
= each more specific?

It's a interesting idea, but high= ly, highly
impractical without potentially blowing
up the routing table size.
Matt


=C2=A0

--
Regards,
RayH


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

--001a11c3678c7afdd00501e5c4bb-- From nobody Sat Aug 30 23:37: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 EE3971A876D for ; Sat, 30 Aug 2014 23:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, 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 3c5Q1aRBe8nc for ; Sat, 30 Aug 2014 23:36:54 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB7E1A8754 for ; Sat, 30 Aug 2014 23:36:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B1567871519; Sun, 31 Aug 2014 08:36:52 +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 X7MWmi0zGJ92; Sun, 31 Aug 2014 08:36:52 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:1c5d:a905:6ad4:4aee]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 4AA4687005E; Sun, 31 Aug 2014 08:36:52 +0200 (CEST) Message-ID: <5402C26A.8060304@globis.net> Date: Sun, 31 Aug 2014 08:36:26 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_qfAH0toVwE97Z_v7NWpdiEb6Fo 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: Sun, 31 Aug 2014 06:36:56 -0000 > Matthew Petach > 31 August 2014 07:00 > > > > On Sat, Aug 30, 2014 at 10:50 AM, Ray Hunter > wrote: > > Fred Baker (fred) wrote: > > On Aug 26, 2014, at 2:50 AM, Andrew 👽 > Yourtchenko> > wrote: > > 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" > > 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. > > I think it would be useful to see the discussion of this > measure and > its applicability/tradeoffs in the draft. > > > It seems like it might have value to also test the interaction > with various initial window settings, and look at its > inclusion in other relevant OS’s including FreeBSD, Windows, > and MacOSX. My reading of 4821 says it’s grand theory, but I’m > not precisely sure how I would write the code. As an initial > setting, for example, I could imagine sending an initial burst > containing a 9K byte packet, a 1500 byte packet, and a 1280 > byte packet in that order, and set the MSS to the the size of > the first acknowledgment I receive. How does that relate to > IW=10 (RFC 6928)? > > > Whilst reading your discussion, I had a "what if" brainwave. > > Paths are learned via routing. What if Path MTU was also learned > via routing, rather than being probed for by individual end hosts? > > Then I checked: EIGRP discovers the set of 6 metrics (bandwidth, > load, delay, reliability, minimum MTU, hop count) > > MTU is never used in the routing decision AFAICS, but couldn't the > local router be programmed to generate ICMP PTB messages (as a > proxy for downstream routers) with a link-local source address to > each host if a path MTU is going to be exceeded, plus a hint of > the actual PMTU discovered by routing? > > Thus avoiding ICMP PTB message black holes?And avoiding the PLMTUD > discovery process and extensive probing/ ramp up for every session? > And also avoiding trust issues (as hosts presumably trust their > local on-link default router)? > > Obviously for this to work internet wide, BGP would also need to > carry an AS-PMTU attribute per AS path. > > > This seems to imply you think there's a single > MTU for an entire prefix? Or would this entail > deaggregating prefixes down to the point where > an accurate MTU could be associated with > each more specific? > > It's a interesting idea, but highly, highly > impractical without potentially blowing > up the routing table size. > > Matt > > ------------------------------------------------------------------------ Not necessarily. What might help is a realistic and early estimate of the minimum MTU 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. MTU is configured on routers. Routers determine the path (based on routes). Routes are based on prefixes. So there is certainly a relationship between MTU and prefixes. Your concern seems to be how good that correlation is. 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). 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. In BGP4, the path is a set of AS'es to be traversed. The minimum MTU of an individual AS would be the minimum MTU of all individual paths encountered when traversing that AS. e.g. the minimum of all MTUs learned in the IGP, or a static manually configured number in the AS border router. The minimum MTU of a BGP path would be the minimum of the individual AS MTUs. I can see this being potentially problematic, but is it meaningfully better than a single global constant (based on a minimum of the whole Internet)? Or is a search for the path MTU for every host for every session already a good enough solution? -- Regards, RayH