From nobody Sun Jan 4 11:00:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4801A0113 for ; Sun, 4 Jan 2015 11:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8cuQoprIwCP for ; Sun, 4 Jan 2015 11:00:17 -0800 (PST) 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 6E8671A014D for ; Sun, 4 Jan 2015 11:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=637; q=dns/txt; s=iport; t=1420398008; x=1421607608; h=date:from:message-id:to:subject:cc; bh=nWBrdJ6k0A5bmWwysSoJR578uClFCtH7r6lhkhRTpnc=; b=EOzOsGY/U1Ihi7AjEa2Cx7/BxZulmWiool6uzV4MFtg4wl3g3rOtToLK I36GXjTMAdJv+LjB9r3PujoPEaZTWtQgUCpZ3zDsKjM0qbZ3Yr7z7jd7B v7JjfscP4ZocFnQLE9i38xY0NtA+EMibFuW84xSQVGWndjkWGoVyoXx7m k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkIAAqNqVStJV2Y/2dsb2JhbABcgwZSWbcAAY8bhXGBBhYBAQEBAX2FDDw0iQwBDbtgAQEBBwEBAQEej3cdhBMFiUuICYZBMII1gjOHcoM5IoQPgxEBAQE X-IronPort-AV: E=Sophos;i="5.07,695,1413244800"; d="scan'208";a="384256773" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jan 2015 19:00:06 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t04J03Q4009644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 19:00:05 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t04J03UG017645; Sun, 4 Jan 2015 11:00:03 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t04J02rU017636; Sun, 4 Jan 2015 11:00:02 -0800 Date: Sun, 4 Jan 2015 11:00:02 -0800 From: fred@cisco.com Message-Id: <201501041900.t04J02rU017636@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/s5eUvl-fu0nWTUaoOChBOHdou6E Subject: [v6ops] draft-boucadair-6man-prefix-routing-reco 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, 04 Jan 2015 19:00:19 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-boucadair-6man-prefix-routing-reco. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Sun Jan 4 11:02:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA921A1B9A for ; Sun, 4 Jan 2015 11:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR6Byam1HwOd for ; Sun, 4 Jan 2015 11:02:05 -0800 (PST) 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 3173A1A1BCB for ; Sun, 4 Jan 2015 11:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=161; q=dns/txt; s=iport; t=1420398123; x=1421607723; h=date:from:message-id:to:subject:cc; bh=ifRYWS9v7l4GavFXWzKu/FazduYCUuJdrNoxy75q3D0=; b=SyuEwVV/w7VxhMxwbZ1Ch5lEDuklLks7dZLtoI4DSXcZWg561EjDVBRz hR1fXgrOwwj8abaoy4YNT5qzzIXBf1ns+K41QDVSZbqGNZSj+FfMA5aT2 fLYKXC5QYgN7F87ViP4YRDTF+3bIdcX465Lu/XrPM1HrpBw3fMavbFsey 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIGAEONqVStJA2I/2dsb2JhbABcgwa4KwGVDIEGFgEBAQEBfYQwXDw0iQwBu20BAQEBAQUBAQEBAQEcj3cdhBMFiUufDSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.07,695,1413244800"; d="scan'208";a="384204434" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jan 2015 19:02:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t04J21T4005810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 19:02:01 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 t04J20Zc019998; Sun, 4 Jan 2015 11:02:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t04J208N019997; Sun, 4 Jan 2015 11:02:00 -0800 Date: Sun, 4 Jan 2015 11:02:00 -0800 From: fred@cisco.com Message-Id: <201501041902.t04J208N019997@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rc6OO_q-knd5_9BD2Fhx3jGbOrs Subject: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Jan 2015 19:02:15 -0000 Are we agreed that draft-boucadair-6man-prefix-routing-reco should be adopted as a working group document in v6ops, and renamed draft-ietf-v6ops-cidr-prefix? From nobody Sun Jan 4 11:04:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0589C1A1BAC; Sun, 4 Jan 2015 11:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyB5xUzEHIAC; Sun, 4 Jan 2015 11:04:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B83541A1BCB; Sun, 4 Jan 2015 11:04:16 -0800 (PST) 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.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> Date: Sun, 04 Jan 2015 11:04:16 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ju0ZwN3B0glPuVHn1T62Mh9QkkE Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-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: Sun, 04 Jan 2015 19:04:21 -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 : Deprecating Anycast Prefix for 6to4 Relay Routers Authors : Ole Troan Brian Carpenter Filename : draft-ietf-v6ops-6to4-to-historic-10.txt Pages : 7 Date : 2015-01-04 Abstract: Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that when used in its anycast mode, the mechanism is unsuitable for widespread deployment and use in the Internet. This document therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It also obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-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 Sun Jan 4 11:10:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556791A8A70 for ; Sun, 4 Jan 2015 11:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX8XLFoKGFtG for ; Sun, 4 Jan 2015 11:10:17 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522CB1A8A68 for ; Sun, 4 Jan 2015 11:10:17 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id fp1so26556699pdb.5 for ; Sun, 04 Jan 2015 11:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JaouYyyiWsuhcssePyLLjouiuhAA94Z+6iR/UXmi86k=; b=oR4wcE5NT3I7lvzFq7ltmy3sGrsr7VEtgwEpu+2OEj7abaWUu9sN2wKeEOwSAafBSJ fA87l786wqi5zzFdsWFptrh/O5yzB2fW/4fIeuRfzWWKVG/79577pKxOwK1d2VDfWAca EL+D9Y6qqOdw2sxfcPn7o9V6xRPDStQj/fnAptAQmgOcxIf5bDYK5+FIGZshr7MZGZIX tD+ZfWQp625YRdBdksVyIOCiioHf9K0+t8QcNKZh4sncOSlKMmTXfAjuSJdFJ4u8xrvx BCGyp6YNYMcDP6vF4WyO5OpGGCFIXqn6QiWyrS/xyhULNYYhQRDDlXEnO9piRmUrgM5A ZEJw== X-Received: by 10.70.89.129 with SMTP id bo1mr143272395pdb.23.1420398616462; Sun, 04 Jan 2015 11:10:16 -0800 (PST) Received: from ?IPv6:2406:e007:5823:1:28cc:dc4c:9703:6781? ([2406:e007:5823:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id jd1sm52145924pbd.49.2015.01.04.11.10.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 11:10:15 -0800 (PST) Message-ID: <54A99025.4040506@gmail.com> Date: Mon, 05 Jan 2015 08:10:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> In-Reply-To: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r-OyhQLyLM27F01CqjNHgfUc5Bg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:10:20 -0000 This version is intended to respond to Keith Moore's comments before the holidays, with a number of clarifications and simplifications. There is not intended to be any change to the actual recommendations. Brian On 05/01/2015 08:04, 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 : Deprecating Anycast Prefix for 6to4 Relay Routers > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-10.txt > Pages : 7 > Date : 2015-01-04 > > Abstract: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that > when used in its anycast mode, the mechanism is unsuitable for > widespread deployment and use in the Internet. This document > therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay > Routers", be made obsolete and moved to historic status. It also > obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends > that future products should not support 6to4 anycast and that > existing deployments should be reviewed. This complements the > guidelines in RFC 6343. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-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/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Jan 4 12:33:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472E01A900B for ; Sun, 4 Jan 2015 12:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt5muAdlcvkV for ; Sun, 4 Jan 2015 12:33:34 -0800 (PST) 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 8A1EB1A9009 for ; Sun, 4 Jan 2015 12:33:34 -0800 (PST) Received: (qmail 81306 messnum 12317168 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 4 Jan 2015 20:33:32 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail19.svc.cra.dublin.eircom.net (qp 81306) with SMTP; 4 Jan 2015 20:33:32 -0000 Received: from [192.168.1.3] ([86.43.35.194]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bwZU1p00Q4BK5ly01wZY7x; Sun, 04 Jan 2015 20:33:32 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ross Chandler In-Reply-To: <201501041900.t04J02rU017636@irp-lnx1.cisco.com> Date: Sun, 4 Jan 2015 20:33:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201501041900.t04J02rU017636@irp-lnx1.cisco.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7SNOvYnXW4IUgi0D6wxwn_qkxIM Subject: Re: [v6ops] draft-boucadair-6man-prefix-routing-reco 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, 04 Jan 2015 20:33:36 -0000 > On 4 Jan 2015, at 19:00, fred@cisco.com wrote: >=20 >=20 > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. For user convenience I=E2=80=99ve anycast DNS caches addressed using the = lowest order bits and advertised as /128s. Also I=E2=80=99ve a couple of NAT64 boxes that only seem capable of = announcing the Pref64::/n with n=3D96. Some my routers only announce system loopbacks as /128s. Ross From nobody Sun Jan 4 12:41:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9334E1A9009 for ; Sun, 4 Jan 2015 12:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rheKaRGowcmm for ; Sun, 4 Jan 2015 12:41:02 -0800 (PST) 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 DA41B1A0211 for ; Sun, 4 Jan 2015 12:41:01 -0800 (PST) Received: (qmail 9175 messnum 1790530 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 4 Jan 2015 20:41:00 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail12.svc.cra.dublin.eircom.net (qp 9175) with SMTP; 4 Jan 2015 20:41:00 -0000 Received: from [192.168.1.3] ([86.43.35.194]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id bwgx1p00K4BK5ly01wh03z; Sun, 04 Jan 2015 20:41:00 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ross Chandler In-Reply-To: Date: Sun, 4 Jan 2015 20:40:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <43128EBA-77E7-4AF5-A4A2-1A40D88CCCC9@eircom.net> References: <201501041900.t04J02rU017636@irp-lnx1.cisco.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cBxjmGrGC37dVzDj4afurXLIyD4 Subject: Re: [v6ops] draft-boucadair-6man-prefix-routing-reco 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, 04 Jan 2015 20:41:04 -0000 Also have some CDN caches numbered using /127s and /126 that will take a = lot of traffic in future (hopefully). Ross From nobody Sun Jan 4 13:48:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53FF1A010A for ; Sun, 4 Jan 2015 13:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVaeWOQRXGJe for ; Sun, 4 Jan 2015 13:47:56 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72F81A010E for ; Sun, 4 Jan 2015 13:47:55 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org ([IPv6:2001:4d68:2002:100::10f]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id t04Llp72071840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 21:47:53 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::10f] claimed to be crumpet.foobar.org Message-ID: <54A9B505.6010803@foobar.org> Date: Sun, 04 Jan 2015 21:47:49 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> In-Reply-To: <54A99025.4040506@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RLxjrNC2NY9wllqR6molkTZhGRY Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 21:47:58 -0000 On 04/01/2015 19:10, Brian E Carpenter wrote: > This version is intended to respond to Keith Moore's comments before > the holidays, with a number of clarifications and simplifications. > There is not intended to be any change to the actual recommendations. Brian, from a future historical point of view, it's a little disappointing to see the specific operational problems disappearing from the draft. Having said that, it's more important at this stage to get the deprecation out the door rather than having another round of tyre-kicking. You can count this as support for draft -10. Nick From nobody Sun Jan 4 14:11:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9991A011F for ; Sun, 4 Jan 2015 14:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhFL4SrvnMwr for ; Sun, 4 Jan 2015 14:11:26 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e: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 ED4B41A000E for ; Sun, 4 Jan 2015 14:11:25 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so27250368pad.24 for ; Sun, 04 Jan 2015 14:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AKug/IVeyYqHkT1UJeLQvqCoFXfZamYCoAC4R/AQFRI=; b=TmIV79aHTM2un7lsti82kJfOtdkRGQAQ0qfjd6ASArOXzi+cCiq3yWKDCyL0anZKpe ATGbne/qEX2QyrhjHMWrHxDkm1GQ0mmeki0UJq6MdhOH9LknhYGbFmab73qSDujKbKEQ bSEUN9CtIVXrle00OawkMQbCsaGgAnuujvFSdw3mo79QVesj8xG+pRTveu2HNM/mjYbk 1uSSI4kCAqr42sX+rX208PedP3VvdxbE56QpR9ItZXg/jH8VC8tAVDgmv7PrWQdLlM5g kWjzQ4l+UzAlm+WGIayLGRzus21UWWXisypLI6aqI8N2CC1zx2Rfb4/m2FkWeDjG8/+Q zBXg== X-Received: by 10.70.118.202 with SMTP id ko10mr142439118pdb.48.1420409485295; Sun, 04 Jan 2015 14:11:25 -0800 (PST) Received: from ?IPv6:2406:e007:5823:1:28cc:dc4c:9703:6781? ([2406:e007:5823:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id sx4sm52351399pbc.36.2015.01.04.14.11.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 14:11:24 -0800 (PST) Message-ID: <54A9BA9A.2060609@gmail.com> Date: Mon, 05 Jan 2015 11:11:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201501041902.t04J208N019997@irp-lnx1.cisco.com> In-Reply-To: <201501041902.t04J208N019997@irp-lnx1.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/p9pvqXYF14x8kuEDXFfFdOzQjMs Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Jan 2015 22:11:32 -0000 On 05/01/2015 08:02, fred@cisco.com wrote: > Are we agreed that draft-boucadair-6man-prefix-routing-reco should > be adopted as a working group document in v6ops, and renamed > draft-ietf-v6ops-cidr-prefix? Works for me. At least two changes to the text are needed, IMHO: 1. A brief historical reminder of what CIDR is, with a reference. 2. An explicit quote of the sentence in the IPv6 addressing architecture, which in principle is already quite clear on the topic: "IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing." [Section 2.5 of RFC4291] Brian From nobody Mon Jan 5 06:37:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2391A8875 for ; Mon, 5 Jan 2015 06:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzQi-25hvyzL for ; Mon, 5 Jan 2015 06:37:36 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B521A8829 for ; Mon, 5 Jan 2015 06:37:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t05EbYUO029204 for ; Mon, 5 Jan 2015 15:37:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 257FD204EDA for ; Mon, 5 Jan 2015 15:38:27 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 16809204B2D for ; Mon, 5 Jan 2015 15:38:27 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t05EbWAS016759 for ; Mon, 5 Jan 2015 15:37:33 +0100 Message-ID: <54AAA1AC.2020502@gmail.com> Date: Mon, 05 Jan 2015 15:37:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201501041900.t04J02rU017636@irp-lnx1.cisco.com> <43128EBA-77E7-4AF5-A4A2-1A40D88CCCC9@eircom.net> In-Reply-To: <43128EBA-77E7-4AF5-A4A2-1A40D88CCCC9@eircom.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jJob48Ajg6EaxnWcvDPKkrRbLos Subject: Re: [v6ops] draft-boucadair-6man-prefix-routing-reco WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:37:38 -0000 Hi, Thanks for the notification. Another mail points to RFC4632 about CIDR experience, which led further to CIDR reports about IPv6 usage in the Internet: http://bgp.potaroo.net/index-v6.html Digging these tables (search "/") one can find that announced prefix lengths are often between 1 and 64, and a few times /96, /125, /126, /127, /128. Alex Le 04/01/2015 21:40, Ross Chandler a écrit : > Also have some CDN caches numbered using /127s and /126 that will > take a lot of traffic in future (hopefully). > > Ross > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jan 5 09:39:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9541A8714 for ; Mon, 5 Jan 2015 09:39:58 -0800 (PST) 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 eLzEABnmb_zp for ; Mon, 5 Jan 2015 09:39:56 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c: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 4D0441A212A for ; Mon, 5 Jan 2015 09:39:56 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w61so8309912wes.35 for ; Mon, 05 Jan 2015 09:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eJg0gTtpz63silqgY9K6J83RsQ/BMh4EkUZK9KHNAFE=; b=MpexFtuzd++8jIeerwzfupYvOubWXLlpcXbN0Uu6m1zKHGMpadmpSTk+kty+ueSy+M 7pFVR/V+4ANIO6VtKziDiCIVB3CckqBLUbnlvunqlByaax/82XBELvCfxW5U10pxoJfA px1U/crse80+saafgVGDksMCpVJnXe8726FAfBeEmBOxly+VLVrRoaZ70orIcmsbjJ4c LL/NKLEVog3wBzdIGShxP89tMJkIGOzuuT5suqiK3v2HoPzXO4N27cEWJLF6nk/8WM4G uHoYEEz/v8t8FP7mV4I7fui3RIB7SoRtjbkzpOA4mRaHqIdHz+0R2F5rvLGoFRDnIefn WNJg== MIME-Version: 1.0 X-Received: by 10.194.179.166 with SMTP id dh6mr183701323wjc.87.1420479594995; Mon, 05 Jan 2015 09:39:54 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.44.66 with HTTP; Mon, 5 Jan 2015 09:39:54 -0800 (PST) In-Reply-To: <201501041900.t04J02rU017636@irp-lnx1.cisco.com> References: <201501041900.t04J02rU017636@irp-lnx1.cisco.com> Date: Mon, 5 Jan 2015 09:39:54 -0800 X-Google-Sender-Auth: 0OOvSt5oU2UApqXOasBQr-USK-k Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6VE79nzn8MoYxbuuzseQN3M_cqk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-boucadair-6man-prefix-routing-reco WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:39:58 -0000 At Sun, 4 Jan 2015 11:00:02 -0800, fred@cisco.com wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-boucadair-6man-prefix-routing-reco. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. I've read the latest version, and I think it's a useful document even if what's written may look too obvious to some people. I believe it's ready for publication. -- JINMEI, Tatuya From nobody Mon Jan 5 09:51:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E4C1A036F for ; Mon, 5 Jan 2015 09:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ8G7KW4rqgj for ; Mon, 5 Jan 2015 09:51:52 -0800 (PST) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2388C1A1BE5 for ; Mon, 5 Jan 2015 09:51:51 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) id <0NHP00F00T8TK600@smtpauth2.wiscmail.wisc.edu> for v6ops@ietf.org; Mon, 05 Jan 2015 11:51:50 -0600 (CST) X-Spam-PmxInfo: Server=avs-2, Version=6.1.1.2430161, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.5.174220, SenderIP=0.0.0.0 Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPS id <0NHP00LVKTMD4020@smtpauth2.wiscmail.wisc.edu>; Mon, 05 Jan 2015 11:51:50 -0600 (CST) Received: from BN3PR0601MB1299.namprd06.prod.outlook.com (25.161.209.25) by BN3PR0601MB1059.namprd06.prod.outlook.com (25.160.155.19) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 17:51:48 +0000 Received: from ricotta.doit.wisc.edu (2607:f388:e:100:217:f2ff:fe0a:bdf6) by BN3PR0601MB1299.namprd06.prod.outlook.com (25.161.209.25) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 17:51:45 +0000 Date: Mon, 05 Jan 2015 11:51:36 -0600 From: "Dale W. Carder" To: Nick Hilliard Message-id: <20150105175136.GD64124@ricotta.doit.wisc.edu> References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54A9B505.6010803@foobar.org> In-reply-to: <54A9B505.6010803@foobar.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [2607:f388:e:100:217:f2ff:fe0a:bdf6] X-ClientProxiedBy: BY2PR02CA0043.namprd02.prod.outlook.com (10.141.216.33) To BN3PR0601MB1299.namprd06.prod.outlook.com (25.161.209.25) Authentication-results: spf=none (sender IP is ) smtp.mailfrom=dale.carder@wisc.edu; X-DmarcAction: None X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BN3PR0601MB1299; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN3PR0601MB1299; X-Forefront-PRVS: 0447DB1C71 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(24454002)(479174004)(199003)(189002)(92566001)(97736003)(106356001)(4396001)(105586002)(97756001)(31966008)(21056001)(42186005)(110136001)(87976001)(230783001)(46102003)(99396003)(76176999)(54356999)(50986999)(19580395003)(19580405001)(88552001)(122386002)(40100003)(2950100001)(33656002)(77156002)(62966003)(64706001)(90282001)(101416001)(68736005)(20776003)(47776003)(120916001)(46406003)(75432002)(23726002)(83506001)(50466002)(89122001)(107046002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1299; H:ricotta.doit.wisc.edu; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: wisc.edu does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1299; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2015 17:51:45.5165 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1299 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1059; X-OriginatorOrg: wisc.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UxNaqTzLgNSIqvkxTh5mJ7HG4N4 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:51:54 -0000 Thus spake Nick Hilliard (nick@foobar.org) on Sun, Jan 04, 2015 at 09:47:49PM +0000: > On 04/01/2015 19:10, Brian E Carpenter wrote: > > This version is intended to respond to Keith Moore's comments before > > the holidays, with a number of clarifications and simplifications. > > There is not intended to be any change to the actual recommendations. > > Brian, > > from a future historical point of view, it's a little disappointing to see > the specific operational problems disappearing from the draft. Having said > that, it's more important at this stage to get the deprecation out the door > rather than having another round of tyre-kicking. You can count this as > support for draft -10. I think the references to rfc6343 do adequately capture some amount of the operational problems that have led to this draft, and as a whole -10 looks good. Dale From nobody Tue Jan 6 02:54:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4701A9133 for ; Tue, 6 Jan 2015 02:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjQFrQ9cIZA8 for ; Tue, 6 Jan 2015 02:54:22 -0800 (PST) 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 AC6B51A9122 for ; Tue, 6 Jan 2015 02:54:21 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 4B2672DC2FC; Tue, 6 Jan 2015 11:54:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2C05E27C058; Tue, 6 Jan 2015 11:54:20 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.56]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Tue, 6 Jan 2015 11:54:20 +0100 From: To: Brian E Carpenter , "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco Thread-Index: AQHQKGtuDu72uftBu0yYfcELasWXsJyy6r7Q Date: Tue, 6 Jan 2015 10:54:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330048DFA9B@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201501041902.t04J208N019997@irp-lnx1.cisco.com> <54A9BA9A.2060609@gmail.com> In-Reply-To: <54A9BA9A.2060609@gmail.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.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_Fv-84uCw4bUZEhi8FXaAwYoXk8 Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2015 10:54:25 -0000 Hi Brian, Thank you for the comments.=20 Please see inline. Cheers, Med -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Brian E Carpente= r Envoy=E9=A0: dimanche 4 janvier 2015 23:12 =C0=A0: fred@cisco.com; v6ops@ietf.org Objet=A0: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing= -reco On 05/01/2015 08:02, fred@cisco.com wrote: > Are we agreed that draft-boucadair-6man-prefix-routing-reco should > be adopted as a working group document in v6ops, and renamed > draft-ietf-v6ops-cidr-prefix? Works for me. At least two changes to the text are needed, IMHO: 1. A brief historical reminder of what CIDR is, with a reference. [Med] I suggest to add this sentence:=20 A historical reminder of Classless Inter-Domain Routing (CIDR, [RFC4632]) is documented in [I-D.iab-ipversion7] and [RFC1380]. Citing the IAB document is sufficient IMHO.=20 2. An explicit quote of the sentence in the IPv6 addressing architecture, which in principle is already quite clear on the topic: "IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing." [Section 2.5 of RFC4291] [Med] Done in my local copy. Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jan 6 11:38:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE61A1B40 for ; Tue, 6 Jan 2015 11:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJs6BFr9fbSs for ; Tue, 6 Jan 2015 11:38:08 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6329F1A1AA8 for ; Tue, 6 Jan 2015 11:38:08 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id p10so31106373pdj.27 for ; Tue, 06 Jan 2015 11:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Imp1r8XdtrX0vSuvl4XBZ4YMKHuB350iRSIxeCXeH+w=; b=Lb/3rY3A7X5f4SKZK6gpIJ503cp291MLkyhCOa/WTIPiNrAHEC1XF1inDi6WXxdjKr UHkuMcprQNdN+DZkGjn+6AZypHQmS1w3sUailgD2e+UuUWjF13EBJ1ewr7j4aiBurtyE GJlLH4lHac0noWaoidmPsDiYMfMiO+QZE9j+2s9TE8k5XxZnyed1jOawZt0mA9T4vOar NKsNCJMKTg164GkjJeQuDGbVx2FWmeWoKd1ts2273IaHC8uXMG4rRwmhPelxdSUhBETE M9QJEFMJQVKQbwynFw8FGFv0xtJL3y+bx937aOMpPjsqenas2gDm7tyknjs/V5t2LSR9 Jmgg== X-Received: by 10.66.55.4 with SMTP id n4mr128378944pap.79.1420573087596; Tue, 06 Jan 2015 11:38:07 -0800 (PST) Received: from ?IPv6:2406:e007:6d7b:1:28cc:dc4c:9703:6781? ([2406:e007:6d7b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id y4sm38859824pdk.75.2015.01.06.11.38.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jan 2015 11:38:06 -0800 (PST) Message-ID: <54AC39B1.8040804@gmail.com> Date: Wed, 07 Jan 2015 08:38:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "fred@cisco.com" , "v6ops@ietf.org" References: <201501041902.t04J208N019997@irp-lnx1.cisco.com> <54A9BA9A.2060609@gmail.com> <787AE7BB302AE849A7480A190F8B9330048DFA9B@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330048DFA9B@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_gxkR-3svINVMJSzWPuAvA2avbo Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jan 2015 19:38:10 -0000 Hi Med, On 06/01/2015 23:54, mohamed.boucadair@orange.com wrote: > Hi Brian, >=20 > Thank you for the comments.=20 >=20 > Please see inline. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Brian E Carpen= ter > Envoy=C3=A9 : dimanche 4 janvier 2015 23:12 > =C3=80 : fred@cisco.com; v6ops@ietf.org > Objet : Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routi= ng-reco >=20 > On 05/01/2015 08:02, fred@cisco.com wrote: >> Are we agreed that draft-boucadair-6man-prefix-routing-reco should >> be adopted as a working group document in v6ops, and renamed >> draft-ietf-v6ops-cidr-prefix? >=20 > Works for me. At least two changes to the text are needed, IMHO: >=20 > 1. A brief historical reminder of what CIDR is, with a reference. >=20 > [Med] I suggest to add this sentence:=20 >=20 > A historical reminder of Classless Inter-Domain Routing (CIDR, > [RFC4632]) is documented in [I-D.iab-ipversion7] and [RFC1380]. >=20 > Citing the IAB document is sufficient IMHO.=20 Hmm. While draft-iab-ipversion7-00 was the document that triggered my own original interest in the IETF (and quite a few other more important events), I think it might be mildly controversial even to this day. Actua= lly what it says about CIDR was important, but that's not what people remember. >=20 > 2. An explicit quote of the sentence in the IPv6 addressing architectur= e, > which in principle is already quite clear on the topic: >=20 > "IPv6 unicast addresses are aggregatable with prefixes of arbitrary > bit-length, similar to IPv4 addresses under Classless Inter-Domain > Routing." [Section 2.5 of RFC4291] >=20 > [Med] Done in my local copy. Thanks Brian From nobody Tue Jan 6 22:55:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4041A1A8974 for ; Tue, 6 Jan 2015 22:55:03 -0800 (PST) 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, 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 QXF-ZGg2J3zE for ; Tue, 6 Jan 2015 22:55:01 -0800 (PST) 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 7173B1A8978 for ; Tue, 6 Jan 2015 22:54:59 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8855718C21C; Wed, 7 Jan 2015 07:54:57 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 679E323805E; Wed, 7 Jan 2015 07:54:57 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.125]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Wed, 7 Jan 2015 07:54:57 +0100 From: To: Brian E Carpenter Thread-Topic: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco Thread-Index: AQHQKehOVePAJz8LMkyrLn1oGXXdxJy0OO2Q Date: Wed, 7 Jan 2015 06:54:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330048E72F4@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201501041902.t04J208N019997@irp-lnx1.cisco.com> <54A9BA9A.2060609@gmail.com> <787AE7BB302AE849A7480A190F8B9330048DFA9B@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54AC39B1.8040804@gmail.com> In-Reply-To: <54AC39B1.8040804@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DBs9lTM3En3bWJLkam3_2h-qSd0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Jan 2015 06:55:03 -0000 SGkgQnJpYW4sDQoNCklmIHlvdSB0aGluayBjaXRpbmcgdGhlIElBQiBkb2N1bWVudCBhcyBhIGhp c3RvcmljYWwgcmVtaW5kZXIgdGhpcyBpcyBjb250cm92ZXJzaWFsLCBJIHN1Z2dlc3QgdG8gbWFp bnRhaW4gW1JGQzEzODBdIGJ1dCByZXBsYWNlIHRoZSBJQUIgZG9jdW1lbnQgd2l0aCAiU2VjdGlv biAyIG9mIFtSRkM0NjMyXSIuDQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCkRlwqA6IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tXSANCkVudm95w6nCoDogbWFyZGkgNiBqYW52aWVyIDIwMTUgMjA6MzgNCsOA wqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IGZyZWRAY2lzY28uY29tOyB2Nm9wc0BpZXRm Lm9yZw0KT2JqZXTCoDogUmU6IFt2Nm9wc10gQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtYm91Y2Fk YWlyLTZtYW4tcHJlZml4LXJvdXRpbmctcmVjbw0KDQpIaSBNZWQsDQoNCk9uIDA2LzAxLzIwMTUg MjM6NTQsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+IEhpIEJyaWFuLA0K PiANCj4gVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIA0KPiANCj4gUGxlYXNlIHNlZSBpbmxp bmUuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlIDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw YXJ0IGRlIEJyaWFuIEUgQ2FycGVudGVyDQo+IEVudm95w6kgOiBkaW1hbmNoZSA0IGphbnZpZXIg MjAxNSAyMzoxMg0KPiDDgCA6IGZyZWRAY2lzY28uY29tOyB2Nm9wc0BpZXRmLm9yZw0KPiBPYmpl dCA6IFJlOiBbdjZvcHNdIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWJvdWNhZGFpci02bWFuLXBy ZWZpeC1yb3V0aW5nLXJlY28NCj4gDQo+IE9uIDA1LzAxLzIwMTUgMDg6MDIsIGZyZWRAY2lzY28u Y29tIHdyb3RlOg0KPj4gQXJlIHdlIGFncmVlZCB0aGF0IGRyYWZ0LWJvdWNhZGFpci02bWFuLXBy ZWZpeC1yb3V0aW5nLXJlY28gc2hvdWxkDQo+PiBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91 cCBkb2N1bWVudCBpbiB2Nm9wcywgYW5kIHJlbmFtZWQNCj4+IGRyYWZ0LWlldGYtdjZvcHMtY2lk ci1wcmVmaXg/DQo+IA0KPiBXb3JrcyBmb3IgbWUuIEF0IGxlYXN0IHR3byBjaGFuZ2VzIHRvIHRo ZSB0ZXh0IGFyZSBuZWVkZWQsIElNSE86DQo+IA0KPiAxLiBBIGJyaWVmIGhpc3RvcmljYWwgcmVt aW5kZXIgb2Ygd2hhdCBDSURSIGlzLCB3aXRoIGEgcmVmZXJlbmNlLg0KPiANCj4gW01lZF0gSSBz dWdnZXN0IHRvIGFkZCB0aGlzIHNlbnRlbmNlOiANCj4gDQo+ICAgIEEgaGlzdG9yaWNhbCByZW1p bmRlciBvZiBDbGFzc2xlc3MgSW50ZXItRG9tYWluIFJvdXRpbmcgKENJRFIsDQo+ICAgIFtSRkM0 NjMyXSkgaXMgZG9jdW1lbnRlZCBpbiBbSS1ELmlhYi1pcHZlcnNpb243XSBhbmQgW1JGQzEzODBd Lg0KPiANCj4gQ2l0aW5nIHRoZSBJQUIgZG9jdW1lbnQgaXMgc3VmZmljaWVudCBJTUhPLiANCg0K SG1tLiBXaGlsZSBkcmFmdC1pYWItaXB2ZXJzaW9uNy0wMCB3YXMgdGhlIGRvY3VtZW50IHRoYXQg dHJpZ2dlcmVkIG15DQpvd24gb3JpZ2luYWwgaW50ZXJlc3QgaW4gdGhlIElFVEYgKGFuZCBxdWl0 ZSBhIGZldyBvdGhlciBtb3JlIGltcG9ydGFudA0KZXZlbnRzKSwgSSB0aGluayBpdCBtaWdodCBi ZSBtaWxkbHkgY29udHJvdmVyc2lhbCBldmVuIHRvIHRoaXMgZGF5LiBBY3R1YWxseQ0Kd2hhdCBp dCBzYXlzIGFib3V0IENJRFIgd2FzIGltcG9ydGFudCwgYnV0IHRoYXQncyBub3Qgd2hhdCBwZW9w bGUNCnJlbWVtYmVyLg0KDQo+IA0KPiAyLiBBbiBleHBsaWNpdCBxdW90ZSBvZiB0aGUgc2VudGVu Y2UgaW4gdGhlIElQdjYgYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUsDQo+IHdoaWNoIGluIHByaW5j aXBsZSBpcyBhbHJlYWR5IHF1aXRlIGNsZWFyIG9uIHRoZSB0b3BpYzoNCj4gDQo+ICAgIklQdjYg dW5pY2FzdCBhZGRyZXNzZXMgYXJlIGFnZ3JlZ2F0YWJsZSB3aXRoIHByZWZpeGVzIG9mIGFyYml0 cmFyeQ0KPiAgICBiaXQtbGVuZ3RoLCBzaW1pbGFyIHRvIElQdjQgYWRkcmVzc2VzIHVuZGVyIENs YXNzbGVzcyBJbnRlci1Eb21haW4NCj4gICAgUm91dGluZy4iIFtTZWN0aW9uIDIuNSBvZiBSRkM0 MjkxXQ0KPiANCj4gW01lZF0gRG9uZSBpbiBteSBsb2NhbCBjb3B5Lg0KDQpUaGFua3MNCiAgIEJy aWFuDQoNCg== From nobody Fri Jan 9 09:14:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72001A87E4 for ; Fri, 9 Jan 2015 09:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36IPNdtJY8OM for ; Fri, 9 Jan 2015 09:14:13 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B601A7D82 for ; Fri, 9 Jan 2015 09:14:13 -0800 (PST) Received: from pc6 (86.171.123.186) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.53.17; Fri, 9 Jan 2015 17:10:25 +0000 Message-ID: <00a801d02c2f$087deda0$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> Date: Fri, 9 Jan 2015 17:09:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.171.123.186] X-ClientProxiedBy: DB4PR02CA0028.eurprd02.prod.outlook.com (10.242.174.156) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR07MB064; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB064; X-Forefront-PRVS: 04519BA941 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(377454003)(50226001)(107046002)(107886001)(1556002)(101416001)(106356001)(44736004)(87976001)(23756003)(105586002)(89996001)(92566001)(99396003)(120916001)(1456003)(122386002)(40100003)(77096005)(68736005)(15975445007)(84392001)(47776003)(33646002)(81686999)(76176999)(50986999)(50466002)(62236002)(44716002)(64706001)(61296003)(31966008)(116806002)(230783001)(66066001)(42186005)(81816999)(14496001)(46102003)(19580405001)(19580395003)(86362001)(97736003)(77156002)(62966003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2015 17:10:25.5732 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jan 2015 17:14:18 -0000 ----- Original Message ----- From: To: Sent: Saturday, December 20, 2014 6:38 AM Subject: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco > Are we agreed that draft-boucadair-6man-prefix-routing-reco should > be adopted as a working group document in v6ops, and renamed > draft-ietf-v6ops-cidr-prefix? Ithink that it is adreadful idea. Adoptionisfine, butchangingthename atthe sametime isjust creating apile of unnecessaryworkfor eternity. Thename is irrelevant once this is a RFC; tarting it up inthe meantime just means that the continuity of I-Ds is harderto track,wastingeveryone'stime {And whoever snuck in and stole my space key over Christmas, please could I have it back?} Tom Petch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jan 9 13:44:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132DC1A01FA for ; Fri, 9 Jan 2015 13:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbybY2YOfava for ; Fri, 9 Jan 2015 13:44:50 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id C4EB21A044D for ; Fri, 9 Jan 2015 13:44:49 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 9 Jan 2015 15:44:46 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f179.google.com [209.85.223.179] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f179.google.com with SMTP id rp18so17291596iec.10 for ; Fri, 09 Jan 2015 13:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KFdQRC0rfbF0Ulg89JBpSIN2pxvNnMZsH3aREE0o3og=; b=ZyHErSybCBNEOw1oZtK49FMcsd6yFSjM1SCTa9uCaZmAC0wcVM05N7/8Ux0ejUFvIv vjhwsXhahMKQz2uWwe894lEHamlBO/Y4niTQ/3DSRLvG4HEFOTrVxGBy+Ub67ERVibxa oYLOvOxnZn8Xx9uxiLlOy3a4Rt88IhEJyZ8Ac= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=KFdQRC0rfbF0Ulg89JBpSIN2pxvNnMZsH3aREE0o3og=; b=M1suQ8QfmPoAgIqwE4Mfb2vM+CEMMKWdicuEhb8BE0OtfYWQnP5IqaoIw2+Nz+tWAm sFFhd0iHE+E60QVytoAGWBNn2QmpqXPufnNDebNRwOXNx+f5UeFPmKgKZrBJw8rvRpxz W4Q6Tf7WDlpcJOcVp4IiosZEP3l0AdR29zh3GZAMwVWITHaN2ryOzVwLeciWqycxArNd 7qlYAok02oHdmkeGRvP/KPgBAmD23Lh5BovstH4yXRRerJClF2YwjTzy6lkdyq3aG37a /rJqkWLuTrobFhmxcGj2fWK2wxnLlRTnDRfysGqUTy9tH4E7unGe3rdaOQlvZR+XscIx nq6Q== X-Gm-Message-State: ALoCoQkfmj/KXVDVt4hTvngZV1Cp4WUa9cyOvdMT+s1ACP22e/dnNARdgK3CvCW76JeSoe6XTulma9wBcs1KNbvF6nkgwxWTdEnj28Lo544ObJWOL6HZ+FZlk6Oh0kPFvB3Kgm/aWMGH X-Received: by 10.42.25.12 with SMTP id y12mr14739182icb.74.1420839885976; Fri, 09 Jan 2015 13:44:45 -0800 (PST) X-Received: by 10.42.25.12 with SMTP id y12mr14739168icb.74.1420839885787; Fri, 09 Jan 2015 13:44:45 -0800 (PST) Received: from x-134-84-51-156.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:38be:79a0:c0b9:3c58]) by mx.google.com with ESMTPSA id hi15sm34201igb.19.2015.01.09.13.44.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jan 2015 13:44:44 -0800 (PST) Message-ID: <54B04BC8.1020902@umn.edu> Date: Fri, 09 Jan 2015 15:44:40 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> In-Reply-To: <54A99025.4040506@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:44:53 -0000 On 1/4/15, 13:10 , Brian E Carpenter wrote: > This version is intended to respond to Keith Moore's comments before > the holidays, with a number of clarifications and simplifications. > There is not intended to be any change to the actual recommendations. I think the new draft is an improvement, I did a detailed review and have a list of several items for you to consider; 1. In section 3, the second sentence of the first paragraph and the first sentence of the second paragraph seem to say virtually the same thing. I suggest leaving the first paragraph as-is, deleting the first sentence of the second paragraph, and slightly rewriting the remainder of the second paragraph, maybe as follows; In the forward direction a 6to4 node will send native IPv6 traffic to a 6to4 relay router, that is connected both to the 6to4 cloud and to native IPv6. In the reverse direction a 2002::/16 route is injected into the native IPv6 routing domain to attract traffic from native IPv6 nodes to a 6to4 relay router. It is expected that traffic will use different relays in the forward and reverse direction. 2. The last paragraph of section 3 says; Peer-to-peer usage of the 6to4 mechanism, not depending on the anycast mechanism, might exist in the Internet, largely unknown to operators. This is harmless to third parties and the current document is not intended to prevent such traffic continuing. This could be taken by some to imply that the document intends to prevent anycast 6to4 traffic from continuing, more than simply deprecating anycast 6to4, I'd suggest rewriting the paragraph, maybe as follows; Peer-to-peer usage of the 6to4 mechanism exists in the Internet, likely unknown to many operators. This usage is harmless to third parties and is not dependent on the anycast 6to4 mechanism that this document deprecates. 3. In section 4, first paragraph, I believe anycast 6to4 needs to be default disabled in any new 6to4 implementation. Maybe add the following to the paragraph; However, if included in any new implementations, the anycast 6to4 mechanism MUST NOT be enabled by default. 4. Section 4, fourth paragraph, is confusing me. It says; Implementations capable of acting as 6to4 routers MUST NOT enable 6to4 without explicit user configuration. In particular, enabling IPv6 forwarding on a device MUST NOT automatically enable 6to4. As written the first sentences seems to be repeating the last sentence of third paragraph, just above it. I think maybe it was meant to say; Implementations capable of acting as IPv6 routers MUST NOT enable... 5. In previous discussions of the text in section 4, sixth paragraph, the issue of uRPF came up. I think something about uRPF, BCP38, and BCP84 should get added to this paragraph. Maybe something like this; This includes ensuring that traffic from a local 6to4 return relay with a source address of 192.88.99.1 is allowed through Anti-spoofing filters such as those described in [BCP38] and [BCP84] or through Unicast Reverse-Path-Forwarding (uRPF) checks. 6. On the more general question of filtering and the intended affect of deprecation, I would like to see the issue more strongly addressed with something like the following added; This deprecation does not constitute a recommendation for the generalized filtering of traffic or routes for 6to4 or even anycast 6to4. Both the basic 6to4 and anycast 6to4 mechanisms remain valid traffic to be carried on the Internet. In general terms this document simply recommends against further deployment of the anycast 6to4 mechanism, calls for current 6to4 deployments to evaluate the efficacy of continued use of the anycast 6to4 mechanism, and makes recommendations intended to prevent any use of 6to4 from hampering broader deployment and use of native IPv6 on the Internet as a whole. 7. We should have recommendations applicable to operators of the hosts, something like the following; All hosts using 6to4 SHOULD support the IPv6 address selection policy described in [RFC6724] or be manually configured with an address selection policy preferring IPv4 over a 6to4 source address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts not meeting these requirements SHOULD NOT use, or continue to use, the deprecated anycast 6to4 mechanism. 9. On a higher level, section 4 seem to be a bit of a hodgepodge of issues and ideas; I'm thinking split out the recommendations into a separate section. Maybe even split the recommendations into separate operational and implementation sections or sub-sections if you prefer. Taking this into account, including the issues for section 4 from above and taking editorial license to rearrange and rewrite a few things, I suggest something like the following; --- 4. Deprecation This document formally deprecates the anycast 6to4 transition mechanism defined in [RFC3068] and the associated anycast IPv4 address 192.88.99.1. It is no longer considered to be a useful service of last resort. The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except by a future IETF standards action. The guidelines in Section 4 of [RFC6343] remain valid for those who choose to continue operating Anycast 6to4 despite its deprecation. However, 6to4 Provider Managed Tunnels [RFC6732] will no longer be necessary, so they are also deprecated by this document. The basic unicast 6to4 mechanism defined in [RFC3056] and the associated 6to4 IPv6 prefix 2002::/16 are not deprecated. The default address selection rules specified in [RFC6724] are not modified. This deprecation does not constitute a recommendation for the generalized filtering of traffic or routes for 6to4 or even anycast 6to4. Both the basic 6to4 and anycast 6to4 mechanisms remain valid traffic to be carried on the Internet. In general terms this document simply recommends against further deployment of the anycast 6to4 mechanism, calls for current 6to4 deployments to evaluate the efficacy of continued use of the anycast 6to4 mechanism, and makes recommendations intended to prevent the use of 6to4 from hampering broader deployment and use of native IPv6 on the Internet as a whole. Incidental references to 6to4 should be reviewed and possibly removed from other IETF documents if and when they are updated. These documents include RFC3162, RFC3178, RFC3790, RFC4191, RFC4213, RFC4389, RFC4779, RFC4852, RFC4891, RFC4903, RFC5157, RFC5245, RFC5375, RFC5971, RFC6071 and RFC6890. 5. Implementation Recommendations Implementations MUST NOT enable the basic unicast 6to4 mechanism defined in [RFC3056] without explicit user configuration. Further, it is NOT RECOMMENDED to include the anycast 6to4 mechanism defined in [RFC3068] in any new implementations. However, if included in any new implementations, the anycast 6to4 mechanism MUST NOT be enabled by default. All implementations that include 6to4 SHOULD also include "Happy Eyeballs" [RFC6555] and the default address selection rules specified in [RFC6724]. Implementations capable of acting as IPv6 routers MUST NOT enable 6to4 without explicit user configuration. In particular, enabling IPv6 forwarding on any device MUST NOT automatically enable 6to4. 6. Operational Recommendations All hosts using 6to4 SHOULD support the default address selection rules specified in [RFC6724] or be manually configured with an address selection rule preferring IPv4 over a 6to4 source address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts not meeting these requirements SHOULD NOT use, or continue to use, the deprecated anycast 6to4 mechanism. Current operators of an anycast 6to4 relay with the IPv4 address 192.88.99.1 SHOULD review the information in [RFC6343] and the present document, and then consider carefully whether the anycast relay can be discontinued as traffic diminishes. Internet service providers that do not operate an anycast relay but do provide their customers with a route to 192.88.99.1 SHOULD verify that it does in fact lead to an operational anycast relay, as discussed in Section 4.2.1 of [RFC6343]. Furthermore, Internet service providers and other network providers MUST NOT originate a route to 192.88.99.1, unless they actively operate and monitor an anycast 6to4 relay service as detailed in Section 4.2.1 of [RFC6343]. Operators of a 6to4 return relay responding to the IPv6 prefix 2002::/16 SHOULD review the information in [RFC6343] and the present document, and then consider carefully whether the return relay can be discontinued as traffic diminishes. To avoid confusion, note that nothing in the design of 6to4 assumes or requires that return packets are handled by the same relay as outbound packets. As discussed in Section 4.5 of RFC 6343, content providers might choose to continue operating a return relay for the benefit of their own residual 6to4 clients. Internet service providers SHOULD announce the IPv6 prefix 2002::/16 to their own customers if and only if it leads to a correctly operating return relay as described in RFC 6343. IPv6-only service providers, including those operating a NAT64 service [RFC6146], are advised that their own customers need a route to such a relay in case a residual 6to4 user served by a different service provider attempts to communicate with them. Networks SHOULD NOT filter out packets whose source address is 192.88.99.1, because this is normal 6to4 traffic from a 6to4 return relay somewhere in the Internet. This includes ensuring that traffic from a local 6to4 return relay with a source address of 192.88.99.1 is allowed through Anti-spoofing filters such as those described in [BCP38] and [BCP84] or through Unicast Reverse-Path-Forwarding (uRPF) checks. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Fri Jan 9 14:04:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB291A034F for ; Fri, 9 Jan 2015 14:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 sZjTGjSitrYP for ; Fri, 9 Jan 2015 14:04:10 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0CA1A0018 for ; Fri, 9 Jan 2015 14:04:10 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id z10so19737265pdj.0 for ; Fri, 09 Jan 2015 14:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uNArNzWXD/BkwTEvD2rwpKOtlPk7D0wavNsyGatqI6E=; b=l8OkjkYYqGIvR9z+sa0lmSPSb4gHEjY05XtS7EF5Xhcirp4hK0iS6FfJGNAODqVT/+ KxTATvrqiAwX/vczuM8flmTf7UCX3VZAUWD+3f1usg7LM+FIJmDuTsDCyv5W9ydt8zHI N/XAMX9I4mjLO500jhmlLoZeWBCU8t38Rzj/661Q3DQpc2ArERQS74VbVY/wpd8qIJMw LzYghy1h0GnmprBGHUJxWHhae1QBkg0Zu1S82W2qTZ+iaiGrO8gKnyXGLly14ZqUo5FX Szxt0DkRfD20PHMCbYEzHo9Z0MGtU3VO4hrvSfR9IGSEPHUgzcShrMPvtMQHdHjuIuLJ fAnw== X-Received: by 10.70.35.7 with SMTP id d7mr26469611pdj.41.1420841049635; Fri, 09 Jan 2015 14:04:09 -0800 (PST) Received: from ?IPv6:2406:e007:5167:1:28cc:dc4c:9703:6781? ([2406:e007:5167:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bk8sm8067719pad.28.2015.01.09.14.04.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jan 2015 14:04:08 -0800 (PST) Message-ID: <54B05072.8020805@gmail.com> Date: Sat, 10 Jan 2015 11:04:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Farmer , v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> In-Reply-To: <54B04BC8.1020902@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:04:14 -0000 Hi, Since we are already post-WG Last Call, the authors will wait for direction from the WG Chairs before making any further changes. Regards Brian On 10/01/2015 10:44, David Farmer wrote: > On 1/4/15, 13:10 , Brian E Carpenter wrote: >> This version is intended to respond to Keith Moore's comments before >> the holidays, with a number of clarifications and simplifications. >> There is not intended to be any change to the actual recommendations. > > I think the new draft is an improvement, I did a detailed review and have a list of several items for you to consider; > > 1. In section 3, the second sentence of the first paragraph and the first sentence of the second paragraph seem to say virtually > the same thing. > > I suggest leaving the first paragraph as-is, deleting the first sentence of the second paragraph, and slightly rewriting the > remainder of the second paragraph, maybe as follows; > > In the forward direction a 6to4 node will send native IPv6 traffic > to a 6to4 relay router, that is connected both to the 6to4 cloud and > to native IPv6. In the reverse direction a 2002::/16 route is > injected into the native IPv6 routing domain to attract traffic from > native IPv6 nodes to a 6to4 relay router. It is expected that > traffic will use different relays in the forward and reverse > direction. > > 2. The last paragraph of section 3 says; > > Peer-to-peer usage of the 6to4 mechanism, not depending on the > anycast mechanism, might exist in the Internet, largely unknown to > operators. This is harmless to third parties and the current > document is not intended to prevent such traffic continuing. > > This could be taken by some to imply that the document intends to prevent anycast 6to4 traffic from continuing, more than simply > deprecating anycast 6to4, I'd suggest rewriting the paragraph, maybe as follows; > > Peer-to-peer usage of the 6to4 mechanism exists in the Internet, > likely unknown to many operators. This usage is harmless to third > parties and is not dependent on the anycast 6to4 mechanism that this > document deprecates. > > 3. In section 4, first paragraph, I believe anycast 6to4 needs to be default disabled in any new 6to4 implementation. Maybe add > the following to the paragraph; > > However, if included in any new implementations, the anycast 6to4 > mechanism MUST NOT be enabled by default. > > 4. Section 4, fourth paragraph, is confusing me. It says; > > Implementations capable of acting as 6to4 routers MUST NOT enable > 6to4 without explicit user configuration. In particular, enabling > IPv6 forwarding on a device MUST NOT automatically enable 6to4. > > As written the first sentences seems to be repeating the last sentence of third paragraph, just above it. I think maybe it was > meant to say; > > Implementations capable of acting as IPv6 routers MUST NOT enable... > > 5. In previous discussions of the text in section 4, sixth paragraph, the issue of uRPF came up. I think something about uRPF, > BCP38, and BCP84 should get added to this paragraph. Maybe something like this; > > This includes ensuring that traffic from a local 6to4 return relay > with a source address of 192.88.99.1 is allowed through > Anti-spoofing filters such as those described in [BCP38] and [BCP84] > or through Unicast Reverse-Path-Forwarding (uRPF) checks. > > 6. On the more general question of filtering and the intended affect of deprecation, I would like to see the issue more strongly > addressed with something like the following added; > > This deprecation does not constitute a recommendation for the > generalized filtering of traffic or routes for 6to4 or even anycast > 6to4. Both the basic 6to4 and anycast 6to4 mechanisms remain valid > traffic to be carried on the Internet. In general terms this > document simply recommends against further deployment of the anycast > 6to4 mechanism, calls for current 6to4 deployments to evaluate the > efficacy of continued use of the anycast 6to4 mechanism, and makes > recommendations intended to prevent any use of 6to4 from hampering > broader deployment and use of native IPv6 on the Internet as a > whole. > > 7. We should have recommendations applicable to operators of the hosts, something like the following; > > All hosts using 6to4 SHOULD support the IPv6 address selection > policy described in [RFC6724] or be manually configured with an > address selection policy preferring IPv4 over a 6to4 source > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > not meeting these requirements SHOULD NOT use, or continue to use, > the deprecated anycast 6to4 mechanism. > > 9. On a higher level, section 4 seem to be a bit of a hodgepodge of issues and ideas; I'm thinking split out the > recommendations into a separate section. Maybe even split the recommendations into separate operational and implementation > sections or sub-sections if you prefer. > > Taking this into account, including the issues for section 4 from above and taking editorial license to rearrange and rewrite a > few things, I suggest something like the following; > > --- > > 4. Deprecation > > This document formally deprecates the anycast 6to4 transition > mechanism defined in [RFC3068] and the associated anycast IPv4 > address 192.88.99.1. It is no longer considered to be a useful > service of last resort. > > The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except > by a future IETF standards action. > > The guidelines in Section 4 of [RFC6343] remain valid for those who > choose to continue operating Anycast 6to4 despite its deprecation. > However, 6to4 Provider Managed Tunnels [RFC6732] will no longer be > necessary, so they are also deprecated by this document. > > The basic unicast 6to4 mechanism defined in [RFC3056] and the > associated 6to4 IPv6 prefix 2002::/16 are not deprecated. The > default address selection rules specified in [RFC6724] are not > modified. > > This deprecation does not constitute a recommendation for the > generalized filtering of traffic or routes for 6to4 or even anycast > 6to4. Both the basic 6to4 and anycast 6to4 mechanisms remain valid > traffic to be carried on the Internet. In general terms this > document simply recommends against further deployment of the anycast > 6to4 mechanism, calls for current 6to4 deployments to evaluate the > efficacy of continued use of the anycast 6to4 mechanism, and makes > recommendations intended to prevent the use of 6to4 from hampering > broader deployment and use of native IPv6 on the Internet as a > whole. > > Incidental references to 6to4 should be reviewed and possibly removed > from other IETF documents if and when they are updated. These > documents include RFC3162, RFC3178, RFC3790, RFC4191, RFC4213, > RFC4389, RFC4779, RFC4852, RFC4891, RFC4903, RFC5157, RFC5245, > RFC5375, RFC5971, RFC6071 and RFC6890. > > 5. Implementation Recommendations > > Implementations MUST NOT enable the basic unicast 6to4 mechanism > defined in [RFC3056] without explicit user configuration. Further, > it is NOT RECOMMENDED to include the anycast 6to4 mechanism defined > in [RFC3068] in any new implementations. However, if included in > any new implementations, the anycast 6to4 mechanism MUST NOT be > enabled by default. > > All implementations that include 6to4 SHOULD also include "Happy > Eyeballs" [RFC6555] and the default address selection rules > specified in [RFC6724]. > > Implementations capable of acting as IPv6 routers MUST NOT enable > 6to4 without explicit user configuration. In particular, enabling > IPv6 forwarding on any device MUST NOT automatically enable 6to4. > > 6. Operational Recommendations > > All hosts using 6to4 SHOULD support the default address selection > rules specified in [RFC6724] or be manually configured with an > address selection rule preferring IPv4 over a 6to4 source > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > not meeting these requirements SHOULD NOT use, or continue to use, > the deprecated anycast 6to4 mechanism. > > Current operators of an anycast 6to4 relay with the IPv4 address > 192.88.99.1 SHOULD review the information in [RFC6343] and the > present document, and then consider carefully whether the anycast > relay can be discontinued as traffic diminishes. Internet service > providers that do not operate an anycast relay but do provide their > customers with a route to 192.88.99.1 SHOULD verify that it does in > fact lead to an operational anycast relay, as discussed in > Section 4.2.1 of [RFC6343]. Furthermore, Internet service providers > and other network providers MUST NOT originate a route to > 192.88.99.1, unless they actively operate and monitor an anycast 6to4 > relay service as detailed in Section 4.2.1 of [RFC6343]. > > Operators of a 6to4 return relay responding to the IPv6 prefix > 2002::/16 SHOULD review the information in [RFC6343] and the present > document, and then consider carefully whether the return relay can be > discontinued as traffic diminishes. To avoid confusion, note that > nothing in the design of 6to4 assumes or requires that return packets > are handled by the same relay as outbound packets. As discussed in > Section 4.5 of RFC 6343, content providers might choose to continue > operating a return relay for the benefit of their own residual 6to4 > clients. Internet service providers SHOULD announce the IPv6 prefix > 2002::/16 to their own customers if and only if it leads to a > correctly operating return relay as described in RFC 6343. IPv6-only > service providers, including those operating a NAT64 service > [RFC6146], are advised that their own customers need a route to such > a relay in case a residual 6to4 user served by a different service > provider attempts to communicate with them. > > Networks SHOULD NOT filter out packets whose source address is > 192.88.99.1, because this is normal 6to4 traffic from a 6to4 return > relay somewhere in the Internet. This includes ensuring that traffic > from a local 6to4 return relay with a source address of 192.88.99.1 > is allowed through Anti-spoofing filters such as those described in > [BCP38] and [BCP84] or through Unicast Reverse-Path-Forwarding > (uRPF) checks. > > Thanks > From nobody Sat Jan 10 14:55:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA311A03A9 for ; Sat, 10 Jan 2015 14:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkzvOCCB9U2s for ; Sat, 10 Jan 2015 14:55:03 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711C51A0039 for ; Sat, 10 Jan 2015 14:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2596; q=dns/txt; s=iport; t=1420930503; x=1422140103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=70nH+hiTv22dr3UMPHEb8dQRZmf+PYQkAQ6sW+hqxqo=; b=DIvYDcFZd0dbu20UWkMTjCLMPNxOqxwuxxNOWzgCzx49HbRKJKk3nYOe S7SbGTbK3PUY3L3JAO//ooBYz1p5R38L4/y6uBGycjKZdCFH96PJijRDK xykXL/ZRtrxCdfMjwVYRKivIoPIXZIeyMB6AWfc5EEN1okBkF5zYaHZkI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAKKssVStJV2R/2dsb2JhbABbgwaBKgSDAch5AhxtQwEBAQEBfYQMAQEBAwEjEUUFCwIBCBgCAiYCAgIfERUQAgQOBYgYAwkIth6PGg2DWgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYwugUgRAR0zB4JoLoETAQSOOodJgUSMFoVhIoNubwGBCzl+AQEB X-IronPort-AV: E=Sophos;i="5.07,737,1413244800"; d="scan'208";a="386060012" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 10 Jan 2015 22:55:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0AMt2D9028884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Jan 2015 22:55:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sat, 10 Jan 2015 16:55:02 -0600 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt Thread-Index: AQHQLSh3RR43cD5zpUSruQT8eX2Ktw== Date: Sat, 10 Jan 2015 22:55:01 +0000 Message-ID: References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B05072.8020805@gmail.com> In-Reply-To: <54B05072.8020805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="utf-8" Content-ID: <1D5D1A6254E04A4DA8B3DEABEC299616@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 22:55:05 -0000 DQo+IE9uIEphbiA5LCAyMDE1LCBhdCAyOjA0IFBNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IFNpbmNlIHdlIGFyZSBhbHJlYWR5 IHBvc3QtV0cgTGFzdCBDYWxsLCB0aGUgYXV0aG9ycyB3aWxsIHdhaXQgZm9yDQo+IGRpcmVjdGlv biBmcm9tIHRoZSBXRyBDaGFpcnMgYmVmb3JlIG1ha2luZyBhbnkgZnVydGhlciBjaGFuZ2VzLg0K DQpXZWxsLCB0d28gd2Vla3MgZnJvbSBKYW51YXJ5IDQgaXMgYWN0dWFsbHkgSmFudWFyeSAxOCAt IG9yLCBhcyBJIHRyeSB0byBkbyB0aGVzZSBvbiBOWiB0aW1lLCBmcm9tIDg6MDAgSmFudWFyeSA1 IGF0IHRoZSBkYXRlbGluZSB0d28gd2Vla3MgZ2V0cyBtZSA4OjAwIEphbnVhcnkgMTkuIEl04oCZ cyB1bmRlciB0aGUgd2lyZS4NCg0KT24gdGhlIG90aGVyIGhhbmQsIEkgZG9u4oCZdCBrbm93IHRo YXQgdGhlIGZhY3QgdGhhdCBhIGNvbW1lbnQgd2FzIG1hZGUgbWFrZXMgaXQgb25lIHRoYXQgaGFz IHRvIGJlIGFjdGVkIG9uIGluIGFjY29yZGFuY2Ugd2l0aCBpdHMgYXV0aG9yOyBpdCBpcyBwYXJ0 IG9mIHRoZSB3b3JraW5nIGdyb3VwIGNvbnZlcnNhdGlvbiwgbm90aGluZyBtb3JlIGFuZCBub3Ro aW5nIGxlc3MuIFdpdGggdGhlIHByZXBvbmRlcmFuY2Ugb2Ygb3BpbmlvbiBpbiAyMDExIG9uZSB3 YXkgYW5kIDMtNCBvcGluaW9ucyB0aGUgb3RoZXIgaW4gMjAxMSwgYW5kIHdpdGggdGhlIHByZXBv bmRlcmFuY2Ugb2Ygb3BpbmlvbiBvbmUgd2F5IGFuZCB0d28gb3BpbmlvbnMgdGhlIG90aGVyIGlu IDIwMTQsIEkgcnVsZWQgdGhlIGRpc3NlbnQgdG8gYmUg4oCcaW4gdGhlIHJvdWdo4oCdLiBXZSAo eW91KSBoYXZlIGJlbnQgb3ZlciBiYWNrd2FyZHMgdG8gYWRkcmVzcyB0aGUgaXNzdWVzIHJhaXNl ZCwgYW5kIGEgbW9udGggYWdvIEtlaXRoIHNhaWQgdGhhdCBoZSB3b3VsZCBhY2NlcHQgLTEwIHdo ZW4gaXQgd2FzIGZpbGVkLiBGcm9tIG15IHBlcnNwZWN0aXZlLCBhcyBhIHByb2Nlc3MgbWFuYWdl ciwgSeKAmW0gaGFyZCBwcmVzc2VkIHRvIHNheSB0aGF0IHdlIGRvbuKAmXQgaGF2ZSBjb25zZW5z dXMuDQoNCkhlcmXigJlzIG15IHN1Z2dlc3Rpb24uIFdvdWxkIHlvdSBraW5kbHkgcmVzcG9uZCB0 byBEYXZl4oCZcyBlbWFpbCwgYW5zd2VyaW5nIHRoZSBxdWVzdGlvbiDigJxpcyB0aGlzIGEgZnJp ZW5kbHkgYW1lbmRtZW504oCdIHBvaW50IGJ5IHBvaW50PyBJZiB0aGV5IGFyZSBmcmllbmRseSBh bWVuZG1lbnRzLCBsZXTigJlzIGluY29ycG9yYXRlIHRoZW0sIGJ1dCBpZiB0aGV5IGFyZSByYWlz aW5nIG5ldyBpc3N1ZXMsIHRoZSBpc3N1ZXMgd2lsbCBuZWVkIHN1cHBvcnQgZnJvbSBvdGhlciB3 b3JraW5nIGdyb3VwIHBhcnRpY2lwYW50cy4NCg0KUmVhZGluZyBoaXMgc3VnZ2VzdGlvbnMsIEkg dGhpbmsgdGhleSBhcmUgaW4gZmFjdCBmcmllbmRseSBhbWVuZG1lbnRzLiBJbiBlc3NlbmNlLCB0 aGUgY2hhbmdlIGZyb20gMDggdG8gMDkgcmVtb3ZlZCB0aGUgcmVjb21tZW5kYXRpb24gdG8gZmls dGVyIDE5Mi44OC45OS4xIGFuZCBnZW5lcmFsbHkgYmxvY2sgYW55Y2FzdCBzZXJ2aWNlLiBEYXZl IGlzIHNheWluZyB0aGF0IGlmIHdlIGFyZSBubyBsb25nZXIgcmVjb21tZW5kaW5nIHRoYXQsIHRo ZXJlIGFyZSBzb21lIG90aGVyIHNlY3Rpb25zIHRoYXQgYmVjb21lIHNsaWdodGx5IGFtYmlndW91 cywgYW5kIHdvdWxkIGxpa2UgdG8gc2VlIHRoYXQgY2xlYW5lZCB1cC4gSGUgd291bGQgYWxzbyBs aWtlIHRvIHNlZSB0aGUgZ2VuZXJhbCBzZXQgb2YgcmVjb21tZW5kYXRpb25zIHNlcGFyYXRlZCBp bnRvIG9wZXJhdGlvbmFsIGFuZCBpbXBsZW1lbnRhdGlvbiByZWNvbW1lbmRhdGlvbnMsIGFuZCBz dWdnZXN0cyB0ZXh0LiA= From nobody Sat Jan 10 16:52:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A4B1A1A94 for ; Sat, 10 Jan 2015 16:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKuZWR7qo2sP for ; Sat, 10 Jan 2015 16:52:16 -0800 (PST) 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 A4AE61A1A81 for ; Sat, 10 Jan 2015 16:52:16 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id y13so24201836pdi.3 for ; Sat, 10 Jan 2015 16:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qddzSc9EDfIS9pCFrwEzc1SCwMDAlOF0v69p97zjnLs=; b=GnbnqCx+bc/TyflQPK0LYXPtnsYkMPvW85NvZwYTmeDGIM8Z99OgM3wQHCimrKvUnR 7T5YaqPrkHJpxwDDB30jMm5Pl9EFfHsHoC4+T2u+gxTquYfXBJgx43M0Yp80B3qmE8Pd PpvMFGIpanNsOJe/NGGpptK01Es2inQwnlc6/A0GR5jkFVmJiyWjgJXMfFEgeAC7BGI0 WbEr9JdilvbXJmNccSPD7jJKYXKnewVUdS3M/3md2ANJfyIBUciwf3i44qzgh1Oq/Li0 xNJBuUXB7NZ7T2CufyWsILtlj2Scy+7roD1jlmgTJZ7pIJ8Y1lWNJjlYdJIlt4AsLN4L AqnQ== X-Received: by 10.68.238.234 with SMTP id vn10mr34003285pbc.140.1420937536001; Sat, 10 Jan 2015 16:52:16 -0800 (PST) Received: from ?IPv6:2406:e007:5e1b:1:28cc:dc4c:9703:6781? ([2406:e007:5e1b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id kw10sm10769176pab.29.2015.01.10.16.52.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jan 2015 16:52:14 -0800 (PST) Message-ID: <54B1C93B.2020006@gmail.com> Date: Sun, 11 Jan 2015 13:52:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B05072.8020805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 00:52:19 -0000 Hi Fred On 11/01/2015 11:55, Fred Baker (fred) wrote: >=20 >> On Jan 9, 2015, at 2:04 PM, Brian E Carpenter wrote: >> >> Since we are already post-WG Last Call, the authors will wait for >> direction from the WG Chairs before making any further changes. >=20 > Well, two weeks from January 4 is actually January 18 - or, as I try to= do these on NZ time, from 8:00 January 5 at the dateline two weeks gets = me 8:00 January 19. It=E2=80=99s under the wire. I'm a bit confused because I thought that the WGLC started with your mess= age on November 16, and that we were now in the process of tidying up WGLC co= mments, mainly Keith's. That said, I will comment on David's points in a separate message. fyi I will be mainly off-line Jan 17-25. Brian >=20 > On the other hand, I don=E2=80=99t know that the fact that a comment wa= s made makes it one that has to be acted on in accordance with its author= ; it is part of the working group conversation, nothing more and nothing = less. With the preponderance of opinion in 2011 one way and 3-4 opinions = the other in 2011, and with the preponderance of opinion one way and two = opinions the other in 2014, I ruled the dissent to be =E2=80=9Cin the rou= gh=E2=80=9D. We (you) have bent over backwards to address the issues rais= ed, and a month ago Keith said that he would accept -10 when it was filed= =2E From my perspective, as a process manager, I=E2=80=99m hard pressed t= o say that we don=E2=80=99t have consensus. >=20 > Here=E2=80=99s my suggestion. Would you kindly respond to Dave=E2=80=99= s email, answering the question =E2=80=9Cis this a friendly amendment=E2=80= =9D point by point? If they are friendly amendments, let=E2=80=99s incorp= orate them, but if they are raising new issues, the issues will need supp= ort from other working group participants. >=20 > Reading his suggestions, I think they are in fact friendly amendments. = In essence, the change from 08 to 09 removed the recommendation to filter= 192.88.99.1 and generally block anycast service. Dave is saying that if = we are no longer recommending that, there are some other sections that be= come slightly ambiguous, and would like to see that cleaned up. He would = also like to see the general set of recommendations separated into operat= ional and implementation recommendations, and suggests text.=20 >=20 From nobody Sat Jan 10 17:10:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0097C1A01F0 for ; Sat, 10 Jan 2015 17:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 4jSSxq8N4Rag for ; Sat, 10 Jan 2015 17:09:54 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DE71A1AB1 for ; Sat, 10 Jan 2015 17:09:54 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so24248095pdb.4 for ; Sat, 10 Jan 2015 17:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YLXJpCXpZDflORpH9bzWaPkxmk6R+kof7ITOk66IaqM=; b=sQQNwn2UH+JhpUN8uNQlYmL5Lhu8qlrdbiJbky7FT+3CR0wY1e7MSWSXY04Yg8Jorj cgsfdX82mUXyeRbiswalAECQfSJQ74vWDCstDhpziWnKLaiWmKlY/JXjitEEYEaTqGW7 +jYmKVF6M7AJ+JTffabgQ9fSIEcwsMUOdh2aTXkImtNYKvksNzRPpmF1ejkx3q/udVLh qr8WUAHsJUzf7t8SSmovAPk/dmrAFtqyKS+WkHi0VKjeE02MCxz2ll8RUTob0oY5dsqE CkSKOFuhFrvMEDiDdCw5eReZp/N7VAXD5GmxFrrT4DMNZHGmLbU0YTlmdqTsCdguwQ1r uOVg== X-Received: by 10.70.133.138 with SMTP id pc10mr34214692pdb.47.1420938593382; Sat, 10 Jan 2015 17:09:53 -0800 (PST) Received: from ?IPv6:2406:e007:5e1b:1:28cc:dc4c:9703:6781? ([2406:e007:5e1b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id wj3sm10786050pab.40.2015.01.10.17.09.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jan 2015 17:09:52 -0800 (PST) Message-ID: <54B1CD5C.3090107@gmail.com> Date: Sun, 11 Jan 2015 14:09:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Farmer , v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> In-Reply-To: <54B04BC8.1020902@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 01:10:14 -0000 David, On 10/01/2015 10:44, David Farmer wrote: > On 1/4/15, 13:10 , Brian E Carpenter wrote: >> This version is intended to respond to Keith Moore's comments before >> the holidays, with a number of clarifications and simplifications. >> There is not intended to be any change to the actual recommendations. > > I think the new draft is an improvement, I did a detailed review and have a list of several items for you to consider; > > 1. In section 3, the second sentence of the first paragraph and the first sentence of the second paragraph seem to say virtually > the same thing. > > I suggest leaving the first paragraph as-is, deleting the first sentence of the second paragraph, and slightly rewriting the > remainder of the second paragraph, maybe as follows; > > In the forward direction a 6to4 node will send native IPv6 traffic > to a 6to4 relay router, that is connected both to the 6to4 cloud and > to native IPv6. In the reverse direction a 2002::/16 route is > injected into the native IPv6 routing domain to attract traffic from > native IPv6 nodes to a 6to4 relay router. It is expected that > traffic will use different relays in the forward and reverse > direction. Agreed. > > 2. The last paragraph of section 3 says; > > Peer-to-peer usage of the 6to4 mechanism, not depending on the > anycast mechanism, might exist in the Internet, largely unknown to > operators. This is harmless to third parties and the current > document is not intended to prevent such traffic continuing. > > This could be taken by some to imply that the document intends to prevent anycast 6to4 traffic from continuing, more than simply > deprecating anycast 6to4, I'd suggest rewriting the paragraph, maybe as follows; > > Peer-to-peer usage of the 6to4 mechanism exists in the Internet, > likely unknown to many operators. This usage is harmless to third > parties and is not dependent on the anycast 6to4 mechanism that this > document deprecates. Agreed. > > 3. In section 4, first paragraph, I believe anycast 6to4 needs to be default disabled in any new 6to4 implementation. Maybe add > the following to the paragraph; > > However, if included in any new implementations, the anycast 6to4 > mechanism MUST NOT be enabled by default. Yes, that is certainly intended and I'm surprised that it isn't already there. > > 4. Section 4, fourth paragraph, is confusing me. It says; > > Implementations capable of acting as 6to4 routers MUST NOT enable > 6to4 without explicit user configuration. In particular, enabling > IPv6 forwarding on a device MUST NOT automatically enable 6to4. > > As written the first sentences seems to be repeating the last sentence of third paragraph, just above it. I think maybe it was > meant to say; > > Implementations capable of acting as IPv6 routers MUST NOT enable... Yes. > > 5. In previous discussions of the text in section 4, sixth paragraph, the issue of uRPF came up. I think something about uRPF, > BCP38, and BCP84 should get added to this paragraph. Maybe something like this; > > This includes ensuring that traffic from a local 6to4 return relay > with a source address of 192.88.99.1 is allowed through > Anti-spoofing filters such as those described in [BCP38] and [BCP84] > or through Unicast Reverse-Path-Forwarding (uRPF) checks. Agreed. > > 6. On the more general question of filtering and the intended affect of deprecation, I would like to see the issue more strongly > addressed with something like the following added; > > This deprecation does not constitute a recommendation for the > generalized filtering of traffic or routes for 6to4 or even anycast > 6to4. Both the basic 6to4 and anycast 6to4 mechanisms remain valid > traffic to be carried on the Internet. In general terms this > document simply recommends against further deployment of the anycast > 6to4 mechanism, calls for current 6to4 deployments to evaluate the > efficacy of continued use of the anycast 6to4 mechanism, and makes > recommendations intended to prevent any use of 6to4 from hampering > broader deployment and use of native IPv6 on the Internet as a > whole. I suspect that would be controversial because of the "remains valid" phrase, so I would delete that sentence. > > 7. We should have recommendations applicable to operators of the hosts, something like the following; > > All hosts using 6to4 SHOULD support the IPv6 address selection > policy described in [RFC6724] or be manually configured with an > address selection policy preferring IPv4 over a 6to4 source > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > not meeting these requirements SHOULD NOT use, or continue to use, > the deprecated anycast 6to4 mechanism. I agree with the sentiments. But I'd like to hear a positive echo from the WG, because this seems like a substantive addition. > > 9. On a higher level, section 4 seem to be a bit of a hodgepodge of issues and ideas; I'm thinking split out the > recommendations into a separate section. Maybe even split the recommendations into separate operational and implementation > sections or sub-sections if you prefer. It's true that this section has grown a bit organically. I think I agree with your proposal, but I'll only find out for sure when I get my editing fingers going. That seems unlikely to happen for the next couple of weeks. Regards Brian > > Taking this into account, including the issues for section 4 from above and taking editorial license to rearrange and rewrite a > few things, I suggest something like the following; > > --- > > 4. Deprecation > > This document formally deprecates the anycast 6to4 transition > mechanism defined in [RFC3068] and the associated anycast IPv4 > address 192.88.99.1. It is no longer considered to be a useful > service of last resort. > > The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except > by a future IETF standards action. > > The guidelines in Section 4 of [RFC6343] remain valid for those who > choose to continue operating Anycast 6to4 despite its deprecation. > However, 6to4 Provider Managed Tunnels [RFC6732] will no longer be > necessary, so they are also deprecated by this document. > > The basic unicast 6to4 mechanism defined in [RFC3056] and the > associated 6to4 IPv6 prefix 2002::/16 are not deprecated. The > default address selection rules specified in [RFC6724] are not > modified. > > This deprecation does not constitute a recommendation for the > generalized filtering of traffic or routes for 6to4 or even anycast > 6to4. Both the basic 6to4 and anycast 6to4 mechanisms remain valid > traffic to be carried on the Internet. In general terms this > document simply recommends against further deployment of the anycast > 6to4 mechanism, calls for current 6to4 deployments to evaluate the > efficacy of continued use of the anycast 6to4 mechanism, and makes > recommendations intended to prevent the use of 6to4 from hampering > broader deployment and use of native IPv6 on the Internet as a > whole. > > Incidental references to 6to4 should be reviewed and possibly removed > from other IETF documents if and when they are updated. These > documents include RFC3162, RFC3178, RFC3790, RFC4191, RFC4213, > RFC4389, RFC4779, RFC4852, RFC4891, RFC4903, RFC5157, RFC5245, > RFC5375, RFC5971, RFC6071 and RFC6890. > > 5. Implementation Recommendations > > Implementations MUST NOT enable the basic unicast 6to4 mechanism > defined in [RFC3056] without explicit user configuration. Further, > it is NOT RECOMMENDED to include the anycast 6to4 mechanism defined > in [RFC3068] in any new implementations. However, if included in > any new implementations, the anycast 6to4 mechanism MUST NOT be > enabled by default. > > All implementations that include 6to4 SHOULD also include "Happy > Eyeballs" [RFC6555] and the default address selection rules > specified in [RFC6724]. > > Implementations capable of acting as IPv6 routers MUST NOT enable > 6to4 without explicit user configuration. In particular, enabling > IPv6 forwarding on any device MUST NOT automatically enable 6to4. > > 6. Operational Recommendations > > All hosts using 6to4 SHOULD support the default address selection > rules specified in [RFC6724] or be manually configured with an > address selection rule preferring IPv4 over a 6to4 source > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > not meeting these requirements SHOULD NOT use, or continue to use, > the deprecated anycast 6to4 mechanism. > > Current operators of an anycast 6to4 relay with the IPv4 address > 192.88.99.1 SHOULD review the information in [RFC6343] and the > present document, and then consider carefully whether the anycast > relay can be discontinued as traffic diminishes. Internet service > providers that do not operate an anycast relay but do provide their > customers with a route to 192.88.99.1 SHOULD verify that it does in > fact lead to an operational anycast relay, as discussed in > Section 4.2.1 of [RFC6343]. Furthermore, Internet service providers > and other network providers MUST NOT originate a route to > 192.88.99.1, unless they actively operate and monitor an anycast 6to4 > relay service as detailed in Section 4.2.1 of [RFC6343]. > > Operators of a 6to4 return relay responding to the IPv6 prefix > 2002::/16 SHOULD review the information in [RFC6343] and the present > document, and then consider carefully whether the return relay can be > discontinued as traffic diminishes. To avoid confusion, note that > nothing in the design of 6to4 assumes or requires that return packets > are handled by the same relay as outbound packets. As discussed in > Section 4.5 of RFC 6343, content providers might choose to continue > operating a return relay for the benefit of their own residual 6to4 > clients. Internet service providers SHOULD announce the IPv6 prefix > 2002::/16 to their own customers if and only if it leads to a > correctly operating return relay as described in RFC 6343. IPv6-only > service providers, including those operating a NAT64 service > [RFC6146], are advised that their own customers need a route to such > a relay in case a residual 6to4 user served by a different service > provider attempts to communicate with them. > > Networks SHOULD NOT filter out packets whose source address is > 192.88.99.1, because this is normal 6to4 traffic from a 6to4 return > relay somewhere in the Internet. This includes ensuring that traffic > from a local 6to4 return relay with a source address of 192.88.99.1 > is allowed through Anti-spoofing filters such as those described in > [BCP38] and [BCP84] or through Unicast Reverse-Path-Forwarding > (uRPF) checks. > > Thanks > From nobody Sat Jan 10 17:18:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE61A1A75 for ; Sat, 10 Jan 2015 17:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsPzWZV1OML2 for ; Sat, 10 Jan 2015 17:18:45 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6D21A0095 for ; Sat, 10 Jan 2015 17:18:45 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Sat, 10 Jan 2015 19:18:44 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f178.google.com [209.85.213.178] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f178.google.com with SMTP id b16so7110878igk.5 for ; Sat, 10 Jan 2015 17:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=3M1cES1/33SM+k2NhEvzn0KnLZwJTlWk2mmy+6y1ZUk=; b=XZi2NoEFPHkyIcB6sEVBvc6CNNsPFTSPRPLZMrDTk+z2ZlugMArGKQtAhRy41boQ9Z NkNn8bx9qor+2uTlpm5TkfX6KQBcqa3xdyfcBooOyWxl3ipudc9/0mtuWoYrOdicId8f oZ830HOIm8uQv5OGhziQNF48tCUEFN7okxU7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=3M1cES1/33SM+k2NhEvzn0KnLZwJTlWk2mmy+6y1ZUk=; b=dXTebQtbimafzTRQsz3zNDB3afxmYU3XJsPLHW+e5qHZOU4i0tghSkjoOjTRxEapBR zSoQGZjafg3mVLiQFxLc2n9HfQQgvWRl+NqP+f5t4m28s8XemjTL3C/aadq0dWxs9jab YCKXtoMbzWJcOPzCgiUH0YhyYws7Df4hr+jcyQABL0XoBHlNGhDjhiWiDf78fRPrMrgg RWMPm1RuFIqQEsLhqgbYvZX/Bggd3mqrtqr5tdaq3ihbPvNvTHuKbh4C/sM90uZKDG/A uq8uls46LArSgLzjg+IrBaok1W0CordlWjTLTz8oZRAysKfytayJRjIpcCNSFyPemvft bgXQ== X-Gm-Message-State: ALoCoQkP1hGQ4yVZdNgncpLO4wtvw3EXVndT1hSjqV9+UtNZ0wiaI/N+aAM2CsPv1aykDGetLZQQslO3IFkqA5MyczI0PxpRacBXlMV5ikKGGObUsbxnzrayqnCjaF8NJAP+kXI8wH7n X-Received: by 10.50.108.68 with SMTP id hi4mr9106498igb.38.1420939123553; Sat, 10 Jan 2015 17:18:43 -0800 (PST) X-Received: by 10.50.108.68 with SMTP id hi4mr9106490igb.38.1420939123379; Sat, 10 Jan 2015 17:18:43 -0800 (PST) Received: from [10.0.0.16] (c-75-73-121-154.hsd1.mn.comcast.net. [75.73.121.154]) by mx.google.com with ESMTPSA id p137sm6126510ioe.29.2015.01.10.17.18.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Jan 2015 17:18:41 -0800 (PST) References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B05072.8020805@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (12B440) From: David Farmer Date: Sat, 10 Jan 2015 19:18:42 -0600 To: "Fred Baker (fred)" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 01:18:47 -0000 > On Jan 10, 2015, at 16:55, Fred Baker (fred) wrote: > ... > Here=E2=80=99s my suggestion. Would you kindly respond to Dave=E2=80=99s e= mail, answering the question =E2=80=9Cis this a friendly amendment=E2=80=9D p= oint by point? If they are friendly amendments, let=E2=80=99s incorporate th= em, but if they are raising new issues, the issues will need support from ot= her working group participants. >=20 > Reading his suggestions, I think they are in fact friendly amendments. In e= ssence, the change from 08 to 09 removed the recommendation to filter 192.88= .99.1 and generally block anycast service. Dave is saying that if we are no l= onger recommending that, there are some other sections that become slightly a= mbiguous, and would like to see that cleaned up. He would also like to see t= he general set of recommendations separated into operational and implementat= ion recommendations, and suggests text. Thanks Fred, I at least intended them all as friendly amendments or friendly suggestions.= I view several of the suggestions as mostly editorial in nature. =20 The host recommendations are somewhat new, however they follow directly from= comments in the introduction regarding "happy eyeballs" and source address s= election. I feel we should be explicit and recommend their use with any hos= t continuing to use 6to4 and especially any continued use of anycast 6to4. I do support the consensus regarding not filtering, but with its removal I f= eel we shouldn't just not say anything about filtering, there needs to be a c= lear statement that filtering is not recommended and beyond that what the af= fect of deprecation is intended to be. I did make a comment saying we neede= d to say more about filtering following version 9, it probably got lost in t= he conversation with Keith, and it wasn't anywhere near as clear and specifi= c as my current comment regarding this issue. =20 I look forward to Brian's response. Thanks again --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Sat Jan 10 17:58:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE631A1A8A for ; Sat, 10 Jan 2015 17:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsXnCPmYPctP for ; Sat, 10 Jan 2015 17:58:52 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 187391A1A6D for ; Sat, 10 Jan 2015 17:58:51 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Sat, 10 Jan 2015 19:58:41 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f182.google.com [209.85.213.182] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f182.google.com with SMTP id hn15so7198780igb.3 for ; Sat, 10 Jan 2015 17:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=d4FFUvXadjVtqysZ6bNuXgnZ53qKrE/slE4+RhEd9e8=; b=LjTZfjAloAGfoGVg1hnw7pNI3/OQot5Z+xmRSmD2MR08OaZaT92IthhV8QyhJYT/df zY6MrF2j9XhPYw4f0BRIuVp96oKPebbUhrZodipvHd+ATKYlt2UnIDo2jNwTHZRxXJ/G u56/WFQk3341FjTxqeamCWSRBIVDtWlhtfbf0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=d4FFUvXadjVtqysZ6bNuXgnZ53qKrE/slE4+RhEd9e8=; b=bnlpkVXKyMgBeudRFI07M97jBj1dgTD/ldI86fC2cdN+oqABg1wMEV0WJAH8HSmuZ7 r5PAO4523TrNvbSHI0ccwNTQXB1fi4TUtkh2oy2V8t+HmwPpjHmZc5/uGuoHb0Graczs nExZRxRlnSCAiAFaBhxeCTg+m9se4FG5ptsccY2r//6AtxjfMPjLVMX3+ppm2nrY89NO pjJzRFR3ckC6+mPFwzJHE6WC4kzi+bb9GVFhmInVjr8weN8A16sfld63U+Zx80L1taGu fIM3Z84eWvhJcE9vTE0jGQ2LxlnrUTynfhIujpZ1eTX3t4X3pZgifSWQopXyJFIm7FI2 FH6g== X-Gm-Message-State: ALoCoQlMSStPqZWpWHAXd/Ng/4kSXwTld/r1pK3HZinTVmfryBHcsiPgViL/vM+wDxkW3qAWfXD5Ge62/R1NCzvMTB9SuiyMRiKQ0X8BGoqe1r9BxKOVFYP99AsTJay4yqt8rgbdYuoQ X-Received: by 10.107.153.147 with SMTP id b141mr21911894ioe.49.1420941521322; Sat, 10 Jan 2015 17:58:41 -0800 (PST) X-Received: by 10.107.153.147 with SMTP id b141mr21911885ioe.49.1420941521082; Sat, 10 Jan 2015 17:58:41 -0800 (PST) Received: from ?IPv6:2601:2:5b00:a9f:b414:9565:6a1d:4a97? ([2601:2:5b00:a9f:b414:9565:6a1d:4a97]) by mx.google.com with ESMTPSA id t1sm1864277igs.0.2015.01.10.17.58.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Jan 2015 17:58:39 -0800 (PST) References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> In-Reply-To: <54B1CD5C.3090107@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7B79550B-1B07-44D6-B7E6-6AC587A8D06C@umn.edu> X-Mailer: iPad Mail (12B440) From: David Farmer Date: Sat, 10 Jan 2015 19:58:40 -0600 To: Brian E Carpenter Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 01:58:54 -0000 > On Jan 10, 2015, at 19:09, Brian E Carpenter = wrote: >> ... >> 6. On the more general question of filtering and the intended affect of d= eprecation, I would like to see the issue more strongly >> addressed with something like the following added; >>=20 >> This deprecation does not constitute a recommendation for the >> generalized filtering of traffic or routes for 6to4 or even anycast >> 6to4. Both the basic 6to4 and anycast 6to4 mechanisms remain valid >> traffic to be carried on the Internet. In general terms this >> document simply recommends against further deployment of the anycast >> 6to4 mechanism, calls for current 6to4 deployments to evaluate the >> efficacy of continued use of the anycast 6to4 mechanism, and makes >> recommendations intended to prevent any use of 6to4 from hampering >> broader deployment and use of native IPv6 on the Internet as a >> whole. >=20 > I suspect that would be controversial because of the "remains valid" > phrase, so I would delete that sentence. I'm fine with that, you are right, the "remains valid" bit might be a half a= step to far. As long as we clarify that deprecation isn't a recommendation= to filter and we say what we intend the affect of deprecation to be, then I= 'm fine. =20 >> 7. We should have recommendations applicable to operators of the hosts, s= omething like the following; >>=20 >> All hosts using 6to4 SHOULD support the IPv6 address selection >> policy described in [RFC6724] or be manually configured with an >> address selection policy preferring IPv4 over a 6to4 source >> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >> not meeting these requirements SHOULD NOT use, or continue to use, >> the deprecated anycast 6to4 mechanism. >=20 > I agree with the sentiments. But I'd like to hear a positive echo from > the WG, because this seems like a substantive addition Yes, it would be helpful if others chime in on this. But I'll add, it is vi= rtually a direct conclusion from comments in the introduction, I just think w= e just never got around to saying it as recommendation. >> 9. On a higher level, section 4 seem to be a bit of a hodgepodge of issue= s and ideas; I'm thinking split out the >> recommendations into a separate section. Maybe even split the recommenda= tions into separate operational and implementation >> sections or sub-sections if you prefer. >=20 > It's true that this section has grown a bit organically. I think I agree > with your proposal, but I'll only find out for sure when I get my > editing fingers going. That seems unlikely to happen for the next couple > of weeks. Happy to leave it with your capable editing fingers, I'm very happy with the= m so far. Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Sun Jan 11 04:18:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90481A1BCD for ; Sun, 11 Jan 2015 04:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inhBw0CnV1Q1 for ; Sun, 11 Jan 2015 04:18:30 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AE71A1BCC for ; Sun, 11 Jan 2015 04:18:29 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id t0BCIIZn027785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2015 12:18:21 GMT (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: <54B26A07.2060307@foobar.org> Date: Sun, 11 Jan 2015 12:18:15 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian E Carpenter , David Farmer , v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> In-Reply-To: <54B1CD5C.3090107@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 12:18:33 -0000 On 11/01/2015 01:09, Brian E Carpenter wrote: >> 7. We should have recommendations applicable to operators of the >> hosts, something like the following; >> >> All hosts using 6to4 SHOULD support the IPv6 address selection >> policy described in [RFC6724] or be manually configured with an >> address selection policy preferring IPv4 over a 6to4 source >> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >> not meeting these requirements SHOULD NOT use, or continue to use, >> the deprecated anycast 6to4 mechanism. > > I agree with the sentiments. But I'd like to hear a positive echo from > the WG, because this seems like a substantive addition. This paragraph doesn't belong in this document: 1. v6ops-6to4-to-historic can't fix all the world's ills. End user common sense needs to be exercised. 2. RFC6555 is standards track and already wraps up its requirements in MUST, which will trump a BCP "SHOULD". 3. any o/s which enables 6to4 is likely to be older, so won't pay attention to this document anyway. If it's newer or the end user has explicitly enabled 6to4, then see the comment on common sense above. Nick From nobody Sun Jan 11 11:00:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDB71A87C7 for ; Sun, 11 Jan 2015 11:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUhSlkGfzZ0y for ; Sun, 11 Jan 2015 11:00:05 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FFC1A7002 for ; Sun, 11 Jan 2015 11:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1421002805; x=1422212405; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=CWV7yt4A4EAwxD9kssZbkeFeyS57Ulp8axEq7uHzq9bONG1xuLMBshXv OmYVr94xW/+nDUllcw/22GSH3d4dPyq63JMFw83/ktb8X/Q+tjVaMiT9A x2A6l0vMZLqQzz7q8280tFNXIpdvZ34y3hkQCz0NaX9tK1MZNSH/T+FQy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoGAE3HslStJV2T/2dsb2JhbABbgwa4AQGVFIEIQwEBAQEBfYQwXDw0iQwBygsBAQEBBgEBAQEBARyPeR2EEwWJZY50gnKNdyKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.07,739,1413244800"; d="scan'208";a="112281085" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 11 Jan 2015 19:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0BJ02fe003229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2015 19:00:04 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t0BJ01P1030618; Sun, 11 Jan 2015 11:00:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t0BJ01j3030613; Sun, 11 Jan 2015 11:00:01 -0800 Date: Sun, 11 Jan 2015 11:00:01 -0800 From: fred@cisco.com Message-Id: <201501111900.t0BJ01j3030613@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-boucadair-6man-prefix-routing-reco 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, 11 Jan 2015 19:00:06 -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 Mon Jan 12 02:13:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF5F1A8A57; Mon, 12 Jan 2015 02:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVRqdBgR_KEb; Mon, 12 Jan 2015 02:13:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9437D1A8A98; Mon, 12 Jan 2015 02:13:10 -0800 (PST) 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.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112101310.26166.41733.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 02:13:10 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-15.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, 12 Jan 2015 10:13:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-15.txt Pages : 18 Date : 2015-01-12 Abstract: This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document identifies features to deliver IPv4 connectivity service over an IPv6-only transport as well as the required features to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-15 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 Jan 12 06:53:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8F1AC399 for ; Mon, 12 Jan 2015 06:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnXo8agSmax6 for ; Mon, 12 Jan 2015 06:53:39 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426451A924B for ; Mon, 12 Jan 2015 06:53:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0CEraW2024389 for ; Mon, 12 Jan 2015 15:53:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 560F82030CB for ; Mon, 12 Jan 2015 15:53:44 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 452AB20391D for ; Mon, 12 Jan 2015 15:53:44 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0CErZtj007398 for ; Mon, 12 Jan 2015 15:53:36 +0100 Message-ID: <54B3DFEF.303@gmail.com> Date: Mon, 12 Jan 2015 15:53:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> <00a801d02c2f$087deda0$4001a8c0@gateway.2wire.net> In-Reply-To: <00a801d02c2f$087deda0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2015 14:53:42 -0000 Tom, Le 09/01/2015 18:09, t.petch a écrit : > ----- Original Message ----- > From: > To: > Sent: Saturday, December 20, 2014 6:38 AM > Subject: [v6ops] Adoption call for > draft-boucadair-6man-prefix-routing-reco > > >> Are we agreed that draft-boucadair-6man-prefix-routing-reco should >> be adopted as a working group document in v6ops, and renamed >> draft-ietf-v6ops-cidr-prefix? > > Ithink that it is adreadful idea. Adoptionisfine, butchangingthename > atthe sametime isjust creating apile of unnecessaryworkfor eternity. > > Thename is irrelevant once this is a RFC; tarting it up inthe meantime > just means that the continuity of I-Ds is harderto > track,wastingeveryone'stime I think the I-D filename changes are tracked ok by e.g. tools.ietf.org which threads together names from individual submission state through WG acronym changes and up to RFC; an example is RFC6550 "Versions" tracked: https://tools.ietf.org/html/draft-ietf-roll-rpl-19 Alex > > {And whoever snuck in and stole my space key over Christmas, please > could I have it back?} > > Tom Petch > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jan 12 10:19:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEDB1ACD29 for ; Mon, 12 Jan 2015 10:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_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 z6VGoNjrZnt5 for ; Mon, 12 Jan 2015 10:19:15 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097A31ACD18 for ; Mon, 12 Jan 2015 10:19:14 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 18:18:51 +0000 Message-ID: <036201d02e94$155e8d60$4001a8c0@gateway.2wire.net> From: t.petch To: Alexandru Petrescu , References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> <00a801d02c2f$087deda0$4001a8c0@gateway.2wire.net> <54B3DFEF.303@gmail.com> Date: Mon, 12 Jan 2015 18:02:39 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0017.eurprd05.prod.outlook.com (25.160.40.27) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR07MB062; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB062; X-Forefront-PRVS: 0454444834 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(377454003)(13464003)(479174004)(199003)(101416001)(44716002)(66066001)(64706001)(86362001)(77156002)(230783001)(62966003)(68736005)(77096005)(15975445007)(87976001)(1456003)(62236002)(105586002)(42186005)(47776003)(116806002)(19580405001)(19580395003)(61296003)(97736003)(50986999)(33646002)(44736004)(50226001)(40100003)(122386002)(50466002)(81816999)(23746002)(81686999)(76176999)(46102003)(107886001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2015 18:18:51.9417 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Subject: Re: [v6ops] Adoption call fordraft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2015 18:19:20 -0000 ----- Original Message ----- From: "Alexandru Petrescu" To: Sent: Monday, January 12, 2015 2:53 PM Tom, Le 09/01/2015 18:09, t.petch a écrit : > ----- Original Message ----- > From: > To: > Sent: Saturday, December 20, 2014 6:38 AM > >> Are we agreed that draft-boucadair-6man-prefix-routing-reco should >> be adopted as a working group document in v6ops, and renamed >> draft-ietf-v6ops-cidr-prefix? > > Ithink that it is adreadful idea. Adoptionisfine, butchangingthename > atthe sametime isjust creating apile of unnecessaryworkfor eternity. > > Thename is irrelevant once this is a RFC; tarting it up inthe meantime > just means that the continuity of I-Ds is harderto > track,wastingeveryone'stime I think the I-D filename changes are tracked ok by e.g. tools.ietf.org which threads together names from individual submission state through WG acronym changes and up to RFC; an example is RFC6550 "Versions" tracked: https://tools.ietf.org/html/draft-ietf-roll-rpl-19 Alex Last time this happened, the tracker did not pick up on the name change. I flagged it to the tools team and was told that the linkage had to be authorised by a WG Chair or someone similar. What a waste of a scarce resouce. And even if the tracker knows, any other archive does not generating confusion or uncertainty. Certainly, such a name change lowers the priority of the I-D for me and makes it less likely I will review or comment on it - there are just so many v6ops I-Ds to choose from:-) Tom Petch Alex > > {And whoever snuck in and stole my space key over Christmas, please > could I have it back?} > > Tom Petch > From nobody Mon Jan 12 11:23:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB67F1ACD4F for ; Mon, 12 Jan 2015 11:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3-f7PMiCv-y for ; Mon, 12 Jan 2015 11:23:24 -0800 (PST) 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 DE04D1ACD3C for ; Mon, 12 Jan 2015 11:23:23 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id eu11so33672040pac.8 for ; Mon, 12 Jan 2015 11:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zxESrPlPmvOQCthl091PMzztrabfiqRq3EwjSEQpxSA=; b=mPugBcW+XCKQI7nCWY9OODN5IJqgKFN2L6HAGoOEkus1ZVjb5ZYTPEKxsSX9XAnRj5 3vTx9eMU4QhK4uAxSmhZHZrHAyq5iBsyc4+3eEZ3itcIcq1/JTc7xRFNEFoPC+yiV06O 7iNGWNX6XTXsc3FFa18NZKCQI3mWnNmZx9pWhti5T9ceUCuL3KFjJRc0TE/YgXY7oRmb Lbd5as7NsJv30uK62nE0dq04BGYq5HWZg8YbTzCLtOYD7xwnxhclASxKo/mxiy+0Oq4i cJajLVrgCFEOXINDmE8QfYOXvdwnUaU7OjoLAWK9vkdDEVXE8Ts5lYAliKSN6cZRTKqI 9KXA== X-Received: by 10.70.130.229 with SMTP id oh5mr47098883pdb.39.1421090603203; Mon, 12 Jan 2015 11:23:23 -0800 (PST) Received: from ?IPv6:2406:e007:7927:1:28cc:dc4c:9703:6781? ([2406:e007:7927:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id jp10sm15013076pbb.2.2015.01.12.11.23.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jan 2015 11:23:22 -0800 (PST) Message-ID: <54B41F29.6040904@gmail.com> Date: Tue, 13 Jan 2015 08:23:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "t.petch" , Alexandru Petrescu , v6ops@ietf.org References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> <00a801d02c2f$087deda0$4001a8c0@gateway.2wire.net> <54B3DFEF.303@gmail.com> <036201d02e94$155e8d60$4001a8c0@gateway.2wire.net> In-Reply-To: <036201d02e94$155e8d60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Adoption call fordraft-boucadair-6man-prefix-routing-reco X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2015 19:23:26 -0000 Tom, ... > Last time this happened, Draft name changes happen almost every time a draft is adopted by a WG ("almost" because it's a convention, not a rule). > the tracker did not pick up on the name change. > I flagged it to the tools team and was told that the linkage had to be > authorised by a WG Chair or someone similar. What a waste of a scarce > resource. Not really, because adoption is a specific WG decsion that needs the WG Chair's attention anyway. And if it was simply a check box in the submission tool, I could claim that draft-carpenter-silly-draft-00 replaces draft-petch-sensible-draft-07, so it does need authorisation. (It could be supported more elegantly by the tools, but that would not eliminate the authorisation step.) >> {And whoever snuck in and stole my space key over Christmas, please >> could I have it back?} Here are a few spare spaces for you to cut and paste: ;-) Brian From nobody Mon Jan 12 11:39:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF161ACDD6 for ; Mon, 12 Jan 2015 11:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-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 apXZYUduyxRN for ; Mon, 12 Jan 2015 11:38:57 -0800 (PST) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C5B1ACDCC for ; Mon, 12 Jan 2015 11:38:57 -0800 (PST) Received: by mail-oi0-f41.google.com with SMTP id i138so22114772oig.0 for ; Mon, 12 Jan 2015 11:38:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7szR8QQ339ZtVxnb1ey3KMdMFtjaJr1xeVW3CiHpurU=; b=HXaLomWjZz8fxr1E5wpo/MeeE5UpfGMXQlhLVMZIWZZmzzjQAqU25cChH0XYeF9c1c FS7wJ1Uc+HYwg7gJ7IDQSZRBP4n+XZpS3VjJjM6KUcXM0/Hx1SVYC+MQ56X+GeUNqKQj TFexWxbA/kDzzVo/sLwCWLOTYv9U4eniogi+v9FkLa0maIm5Pa5xCJKkfCGi+Gw8HydC ZTAgVc8KnLWh28NBYT39xGJP4MAcRR11cWw7XEVA8Hde4XpFF3oTPwDlhf9q2vIlYTTD WEhjqaiyk7WKPKeE94mlpcRj70I5AUclXvWKomG/niI0Z1PdHG37XMGOENzRPVl8SCbV yANg== X-Gm-Message-State: ALoCoQkaPMyeZI8uP8cxC80lmBuCX1GII/xJDC+BcEyGQibMnyDUjbTOlhwL1Dm+eVbzuSRNDA6F MIME-Version: 1.0 X-Received: by 10.202.217.138 with SMTP id q132mr17163299oig.35.1421091536899; Mon, 12 Jan 2015 11:38:56 -0800 (PST) Received: by 10.76.150.2 with HTTP; Mon, 12 Jan 2015 11:38:56 -0800 (PST) In-Reply-To: <54B1CD5C.3090107@gmail.com> References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> Date: Mon, 12 Jan 2015 11:38:56 -0800 Message-ID: From: James Woodyatt To: Brian E Carpenter , IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a113cddda40261e050c79a8a8 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 19:39:00 -0000 --001a113cddda40261e050c79a8a8 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 10, 2015 at 5:09 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > 7. We should have recommendations applicable to operators of the hosts, > something like the following; > > > > All hosts using 6to4 SHOULD support the IPv6 address selection > > policy described in [RFC6724] or be manually configured with an > > address selection policy preferring IPv4 over a 6to4 source > > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > > not meeting these requirements SHOULD NOT use, or continue to use, > > the deprecated anycast 6to4 mechanism. > > I agree with the sentiments. But I'd like to hear a positive echo from > the WG, because this seems like a substantive addition. > Consider this another negative reaction. -- james woodyatt Nest Labs, Communications Engineering --001a113cddda40261e050c79a8a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 10, 2015 at 5:09 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
>=C2=A07. We should have recommendations applicable to operators of the = hosts, something like the following;
>
>=C2=A0 =C2=A0 All hosts using 6to4 SHOULD support the IPv6 address sele= ction
>=C2=A0 =C2=A0 policy described in [RFC6724] or be manually configured w= ith an
>=C2=A0 =C2=A0 address selection policy preferring IPv4 over a 6to4 sour= ce
>=C2=A0 =C2=A0 address.=C2=A0 Further, 6to4 hosts SHOULD support "H= appy Eyeballs"
>=C2=A0 =C2=A0 [RFC6555] or use a browser supporting "Happy Eyeball= s".=C2=A0 Any hosts
>=C2=A0 =C2=A0 not meeting these requirements SHOULD NOT use, or continu= e to use,
>=C2=A0 =C2=A0 the deprecated anycast 6to4 mechanism.

I agree with the sentiments. But I'd like to hear a positive ech= o from
the WG, because this seems like a substantive addition.

Consider this another negative reaction.
<= br>
--
james woody= att <jhw@nestlabs.= com>
Nest Labs, Communications Engineering
--001a113cddda40261e050c79a8a8-- From nobody Mon Jan 12 13:57:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488CD1A6FFC for ; Mon, 12 Jan 2015 13:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQymlowBYzGa for ; Mon, 12 Jan 2015 13:57:04 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3315D1A6F0A for ; Mon, 12 Jan 2015 13:57:04 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so26641817lab.1 for ; Mon, 12 Jan 2015 13:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wIjrbhHjp8woal8PKm4TWLYHsD+SsoIJpmN72CE1NIo=; b=esd2hoQxJ4tigkwSmPRyRd/E8LsI+LKKdRzT80FaEioK8gE4APVvHYlYTi7FewDvpr tuJuLbZ0T2OeBaj8eVEnD5M8fzoX4fQH6wYnzqEa41HDAq+DJOSoLfQ5ium1JVJ/4KMy a+oDDqLYx1AbZmGg7/6r7yBfWWkBnGRUjR1va637Ca71DvEBe/2IPidk6mDNy7dHmCx0 lyUVVgT5UpbMNiPmQqcOBLzKmkRYrq0K5OdidW8ZqN+KceCnLIG3/qjG+Mk5B4kL8Uhr bTyVAqpxnbzXHZB2eh5a8cH5uQVLr28hJy/cpUTbmmuu/WK6JRTZeGkcZ8HvipJvCUZF xFOw== MIME-Version: 1.0 X-Received: by 10.152.6.41 with SMTP id x9mr38520359lax.86.1421099822688; Mon, 12 Jan 2015 13:57:02 -0800 (PST) Received: by 10.112.35.100 with HTTP; Mon, 12 Jan 2015 13:57:02 -0800 (PST) Date: Mon, 12 Jan 2015 15:57:02 -0600 Message-ID: From: Alberto Leiva To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [v6ops] About RFC 6791 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2015 21:57:06 -0000 Hello I'm trying to make sense out of RFCs 6791 and 5837 and I have three questions. RFC 6791 says > the translator SHOULD implement the ICMP > extension defined by [RFC5837]. The ICMP message SHOULD include the > Interface IP Address Sub-Object and specify the source IPv6 addresses > of the original ICMPv6. (1st question) Does this mean the extension should be replaced, or should it be appended? As in, if the packet already has an Interface Information Object (IIO), what should the translator do with it? Replacing sounds aggressive. Appending sounds dangerous because it risks interfering with this from RFC 5837: > A single ICMP message MUST NOT contain two > Interface Information Objects that specify the same role. (2nd question) What is the interface role the translator should write in the C-Type of the IIO? (rfc5837, page 8) RFC 6791 seems silent on this. I'm kind of casually assuming value 2 sounds like the least incorrect one, and at the same time it feels like I'm completely missing the point of 2. None of them seem overly concerned with remote interfaces (ie. the translator is writing an IIO of an interface that belongs to someone else). (3rd question) "sub-IP component" doesn't seem to be defined anywhere. What am I missing? Thank you Alberto From nobody Mon Jan 12 18:54:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CC91A89FD for ; Mon, 12 Jan 2015 18:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMuB3fozdWKZ for ; Mon, 12 Jan 2015 18:54:54 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001: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 51C071A89F5 for ; Mon, 12 Jan 2015 18:54:54 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so557814ier.4 for ; Mon, 12 Jan 2015 18:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lK/MvpDyVWq1F5PtuM9GO5nxmEnh5FmVf2woS44vNc0=; b=a1m1ScCNS1j61H7tRMPZamNrdGvci4aseD7+7LYerN1/imb4Q1TxDUZyS8Cv3lCGdy f53sOkmtCVyF1mJXAsdAtawXQbq9fXxtWSeQXHPSr1QhE26lVuoMISY3k8tBKNaPA71R SM2lgZWjPWfgx49UL+kXmBKXlSe4M1e9WXJZs8haU33p/VsAEq5ETYXNww0kBm1Uu3fh 6pgbS0IVx1ED12lJ5dBzthYC4miz6y5YaZLhKRJTw1YP+ulhXgPZ+2htuhknzFrRuq2K WJB6IMlJoupcikG3cOjGb99Qyjxm/U7iLw2vyH0gBJ1AkzwshpFRYV5b6wm2c59Ng75z 4Ceg== 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=lK/MvpDyVWq1F5PtuM9GO5nxmEnh5FmVf2woS44vNc0=; b=Ry8q5jEQtgzQrcIgFe8L8angMTUxinmFtNvrX/YwHJ0INwnmQ0+ABFwbA0FiM2oZjm e2VkZEjP9sZEMYuGUD7mHP3gRixb3bejw5Dsym5e6hRqkbP50bV4FOCCg0TeJiPcTZdM Ka+GWm0XBDKo/Cn5hKtHAaFiIWYJPVIaiptsp6Mu15ABuRnZgUPrjgm4JaOj+tRCcG3d q9zGxDQKCFI6puG8GR3SkppUBewg2tEEXkP2UAkp2KDbs/D2jP+pTE7QjeYEp23h1CM+ v8K2s6ISQZZThU1Y0CeinLFZYwW665GhzCgLgd5vRxbXJC5PDorZqEUMhmJqicrL0i3M nENg== X-Gm-Message-State: ALoCoQmd+PG8PbS2dSNXb1SMX3lmmg4l4mjc/ZQbfqw/Yf0e0PaMmUc8LpWDF26vMB4Gr3qH6zcL X-Received: by 10.50.66.131 with SMTP id f3mr18712071igt.7.1421117693374; Mon, 12 Jan 2015 18:54:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.93.34 with HTTP; Mon, 12 Jan 2015 18:54:33 -0800 (PST) In-Reply-To: <54B04BC8.1020902@umn.edu> References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> From: Lorenzo Colitti Date: Tue, 13 Jan 2015 11:54:33 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=047d7bdc07a24c57e7050c7fbf6f Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 02:54:56 -0000 --047d7bdc07a24c57e7050c7fbf6f Content-Type: text/plain; charset=UTF-8 On Sat, Jan 10, 2015 at 6:44 AM, David Farmer wrote: > All hosts using 6to4 SHOULD support the IPv6 address selection > policy described in [RFC6724] or be manually configured with an > address selection policy preferring IPv4 over a 6to4 source > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > not meeting these requirements SHOULD NOT use, or continue to use, > the deprecated anycast 6to4 mechanism. > I disagree that implementations should support happy eyeballs. Happy eyeballs is a hack that came into being to avoid broken IPv6 implementations. (I know, because I was there; and before anyone argues with me - were you?) It adds application complexity and makes debugging harder in order to overcome problems that would not exist if the network were properly configured, and it encourages misconfiguration to persist because it masks the effects of misconfiguration. We should not perpetuate it; we should instead be moving beyond it. Just because Happy Eyeballs is a standards track RFC doesn't mean that hosts have to implement it. --047d7bdc07a24c57e7050c7fbf6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 10, 2015 at 6:44 AM, David Farmer <farmer@umn.edu> wrot= e:
=C2=A0 =C2=A0All hosts using 6to4 SHOU= LD support the IPv6 address selection
=C2=A0 =C2=A0policy described in [RFC6724] or be manually configured with a= n
=C2=A0 =C2=A0address selection policy preferring IPv4 over a 6to4 source =C2=A0 =C2=A0address.=C2=A0 Further, 6to4 hosts SHOULD support "Happy = Eyeballs"
=C2=A0 =C2=A0[RFC6555] or use a browser supporting "Happy Eyeballs&quo= t;.=C2=A0 Any hosts
=C2=A0 =C2=A0not meeting these requirements SHOULD NOT use, or continue to = use,
=C2=A0 =C2=A0the deprecated anycast 6to4 mechanism.
I disagree that implementations should support happy eyeballs.= Happy eyeballs is a hack that came into being to avoid broken IPv6 impleme= ntations. (I know, because I was there; and before anyone argues with me - = were you?) It adds application complexity and makes debugging harder in ord= er to overcome problems that would not exist if the network were properly c= onfigured, and it encourages misconfiguration to persist because it masks t= he effects of misconfiguration. We should not perpetuate it; we should inst= ead be moving beyond it.

Just because Happy Eyebal= ls is a standards track RFC doesn't mean that hosts have to implement i= t.
--047d7bdc07a24c57e7050c7fbf6f-- From nobody Mon Jan 12 19:06:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5D51A8A04 for ; Mon, 12 Jan 2015 19:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-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 v5xAoSQ9jBij for ; Mon, 12 Jan 2015 19:06:10 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163921A701A for ; Mon, 12 Jan 2015 19:06:10 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id et14so849047pad.3 for ; Mon, 12 Jan 2015 19:06:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BKkU2mILy6FvymoGEdZrLeaV06RncmmzMIRXSKIQdlI=; b=lYt7btzRUSUj/OYGYDaroQUoav1t7XIfmZ/7L+2ug7ibyC/3x8EraL5JT21Wnq++oj 29UpjC2/uznGrq5o7PkIrtXmC+sJUGp5hJ29jwyCeEnJiSqJ9GerTbc0yKMR/us0QMtw vcoVBsZWkpmu8BdUaMAcCwiESc8xwPxRs0mv7swbT7LKjuguYLNb+nE4zRG0PaDzkU8z +ZiYiRAOZdmzLkdO7PRr4nwxAtB0FxbYO3vQ0VkCqZbGMG0HC1PGETXDgli4oMHy2Xud MyA/tY20+ABbrTopRxa5lg4N19orEHNRcK9IE76JjWkJLm3/cH/19tfB8SC7t2NEsmDX t3Qw== X-Gm-Message-State: ALoCoQnQmVz4nKRGMRrh+A43a9OksG+UfIkBSNuachohqVeGX8RT4E5DSjKmS1wMitRxVojtzG7u MIME-Version: 1.0 X-Received: by 10.70.88.164 with SMTP id bh4mr48383254pdb.96.1421118369682; Mon, 12 Jan 2015 19:06:09 -0800 (PST) Received: by 10.70.67.226 with HTTP; Mon, 12 Jan 2015 19:06:09 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:858c:2644:ddf5:8188] In-Reply-To: References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> Date: Tue, 13 Jan 2015 13:06:09 +1000 Message-ID: From: George Michaelson To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11c321ce9beecc050c7fe73b Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:06:14 -0000 --001a11c321ce9beecc050c7fe73b Content-Type: text/plain; charset=UTF-8 I agree with Lorenzo. I believe based on the measurement stuff we do, that HE has not got a net-positive effect, and was in hindsight not a good idea. Its not consistently implemented, because its not consistently understood It interacts badly with multiply addressed resources It has a proscriptive model of the 'best' connection which doesn't suit all circumstances It has begun differentiating between client level behaviours, OS behaviours and mediating device behaviours all of which interact in the V4/V6 path I think its inevitable that at some future point, HE will be deprecated. -G On Tue, Jan 13, 2015 at 12:54 PM, Lorenzo Colitti wrote: > On Sat, Jan 10, 2015 at 6:44 AM, David Farmer wrote: > >> All hosts using 6to4 SHOULD support the IPv6 address selection >> policy described in [RFC6724] or be manually configured with an >> address selection policy preferring IPv4 over a 6to4 source >> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >> not meeting these requirements SHOULD NOT use, or continue to use, >> the deprecated anycast 6to4 mechanism. >> > > I disagree that implementations should support happy eyeballs. Happy > eyeballs is a hack that came into being to avoid broken IPv6 > implementations. (I know, because I was there; and before anyone argues > with me - were you?) It adds application complexity and makes debugging > harder in order to overcome problems that would not exist if the network > were properly configured, and it encourages misconfiguration to persist > because it masks the effects of misconfiguration. We should not perpetuate > it; we should instead be moving beyond it. > > Just because Happy Eyeballs is a standards track RFC doesn't mean that > hosts have to implement it. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c321ce9beecc050c7fe73b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Lorenzo. I believe based on the measurement s= tuff we do, that HE has not got a net-positive effect, and was in hindsight= not a good idea.=C2=A0

Its not consistently implemented= , because its not consistently understood

It inter= acts badly with multiply addressed resources=C2=A0

It has a proscriptive model of the 'best' connection which doesn&#= 39;t suit all circumstances

It has begun different= iating between client level behaviours, OS behaviours and mediating device = behaviours all of which interact in the V4/V6 path

I think its inevitable that at some future point, HE will be deprecated.

-G

On Tue, Jan 13, 2015 at 12:54 PM, Lorenzo Colitti <l= orenzo@google.com> wrote:
<= div dir=3D"ltr">
On Sat, Jan 10, 2015 at 6:44 AM, David Farmer <farmer@umn.edu= > wrote:
=C2=A0 =C2=A0All hosts= using 6to4 SHOULD support the IPv6 address selection
=C2=A0 =C2=A0policy described in [RFC6724] or be manually configured with a= n
=C2=A0 =C2=A0address selection policy preferring IPv4 over a 6to4 source =C2=A0 =C2=A0address.=C2=A0 Further, 6to4 hosts SHOULD support "Happy = Eyeballs"
=C2=A0 =C2=A0[RFC6555] or use a browser supporting "Happy Eyeballs&quo= t;.=C2=A0 Any hosts
=C2=A0 =C2=A0not meeting these requirements SHOULD NOT use, or continue to = use,
=C2=A0 =C2=A0the deprecated anycast 6to4 mechanism.
I disagree that implementations should support happy ey= eballs. Happy eyeballs is a hack that came into being to avoid broken IPv6 = implementations. (I know, because I was there; and before anyone argues wit= h me - were you?) It adds application complexity and makes debugging harder= in order to overcome problems that would not exist if the network were pro= perly configured, and it encourages misconfiguration to persist because it = masks the effects of misconfiguration. We should not perpetuate it; we shou= ld instead be moving beyond it.

Just because Happy= Eyeballs is a standards track RFC doesn't mean that hosts have to impl= ement it.

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


--001a11c321ce9beecc050c7fe73b-- From nobody Mon Jan 12 19:17:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A40B1A701A for ; Mon, 12 Jan 2015 19:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssb9JXi32uS1 for ; Mon, 12 Jan 2015 19:17:49 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA0B1A1B83 for ; Mon, 12 Jan 2015 19:17:49 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 12 Jan 2015 21:17:46 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f169.google.com [209.85.213.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f169.google.com with SMTP id z20so14526425igj.0 for ; Mon, 12 Jan 2015 19:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=YBqsRi6hQROJ0bO7d41SnOKJlpN+L2I3v3zWMt5kZWI=; b=RMGs+gjjOdcjNA5ZbGCNFo8mToYnGpnC+jpt3T7k9UuxVBH+ZWI5DyYBa04LIYrcSh S9jjnZ5Uu5i7rjLSOJ7B3nCW9lnK4x2y6X5raVoZzvgnnWid7eaNyWydgmaIianydO+4 PwEyVrCwIOnu3W5M5YrvsJ55fCGkJsuojs5t8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=YBqsRi6hQROJ0bO7d41SnOKJlpN+L2I3v3zWMt5kZWI=; b=JAY7NNRRZSdfeFnlzcZ+fX36KAjrWawfsAafV5uFQuinVdXqwkbIgoWZsnXXPo8QIG zyez7v0ZSAsnDOaWYcuwXIo3KJiwFXd0F5+QW4VgmcOD1KyFXGrDnHMV/DlDLgxY1VHK Y+yFypP2ZH23auGH6gJwmIJiih/x3AQ3sNIGs/CgQaQyqcjJuvWkNFXmZpjX/eQjWvjf er1AlYl7qOyvDXagJE3zIO2dSmR1by95m/tua2JEWYBe7aaXLRhDBsFGusCtkG/mGtXT kwP8AFlOXWND/A9KmNy2gKNPjobDdd9BYOsHyU/HS0ewcSUoW1ky7MxeqPYiEoexNWMq LxRw== X-Gm-Message-State: ALoCoQmWEr2zrB5xik38NSFrDjp2AowNruYJB8TFjNUbDLQbuDbbrbFVlW6XKJpPzKQDRxfKIhE5BX2atDVkw57uyvC66xVJMPI5f0I7kmTtQ9xOTLJcd+v1HMB2X+KEhHRC3MIcT4za X-Received: by 10.42.68.73 with SMTP id w9mr6946705ici.84.1421119066015; Mon, 12 Jan 2015 19:17:46 -0800 (PST) X-Received: by 10.42.68.73 with SMTP id w9mr6946529ici.84.1421119061867; Mon, 12 Jan 2015 19:17:41 -0800 (PST) Received: from ?IPv6:2601:2:5b00:a9f:f0e4:dfa4:96e2:1025? ([2601:2:5b00:a9f:f0e4:dfa4:96e2:1025]) by mx.google.com with ESMTPSA id n4sm5422600igr.3.2015.01.12.19.17.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 19:17:40 -0800 (PST) References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-19F4ECCE-BEA7-4D07-BFF4-86E5AAE7512B Message-Id: <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> X-Mailer: iPad Mail (12B440) From: David Farmer Date: Mon, 12 Jan 2015 21:17:40 -0600 To: Lorenzo Colitti Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:17:52 -0000 --Apple-Mail-19F4ECCE-BEA7-4D07-BFF4-86E5AAE7512B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jan 12, 2015, at 20:54, Lorenzo Colitti wrote: >=20 >> On Sat, Jan 10, 2015 at 6:44 AM, David Farmer wrote: >> All hosts using 6to4 SHOULD support the IPv6 address selection >> policy described in [RFC6724] or be manually configured with an >> address selection policy preferring IPv4 over a 6to4 source >> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >> not meeting these requirements SHOULD NOT use, or continue to use, >> the deprecated anycast 6to4 mechanism. >=20 > I disagree that implementations should support happy eyeballs. Happy eyeba= lls is a hack that came into being to avoid broken IPv6 implementations. (I k= now, because I was there; and before anyone argues with me - were you?) It a= dds application complexity and makes debugging harder in order to overcome p= roblems that would not exist if the network were properly configured, and it= encourages misconfiguration to persist because it masks the effects of misc= onfiguration. We should not perpetuate it; we should instead be moving beyon= d it. >=20 > Just because Happy Eyeballs is a standards track RFC doesn't mean that hos= ts have to implement it. Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, like I sai= d it seemed to jump out of the Introduction as a conclusion. What about the= other half? If you going to continue to use anycast 6to4 should there be a= requirement or recommendation to support RFC6724 or be manually configured w= ith an address selection policy preferring IPv4 over a 6to4 source address? --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= --Apple-Mail-19F4ECCE-BEA7-4D07-BFF4-86E5AAE7512B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jan 12, 2015, at= 20:54, Lorenzo Colitti <lorenzo@go= ogle.com> wrote:

On Sat, Jan 1= 0, 2015 at 6:44 AM, David Farmer <farmer@umn.edu> wrote:
   All hosts using 6to4 SHOULD support th= e IPv6 address selection
   policy described in [RFC6724] or be manually configured with an=
   address selection policy preferring IPv4 over a 6to4 source
=    address.  Further, 6to4 hosts SHOULD support "Happy Eyebal= ls"
   [RFC6555] or use a browser supporting "Happy Eyeballs".  A= ny hosts
   not meeting these requirements SHOULD NOT use, or continue to u= se,
   the deprecated anycast 6to4 mechanism.
I disagree that implementations should support happy eyeballs. H= appy eyeballs is a hack that came into being to avoid broken IPv6 implementa= tions. (I know, because I was there; and before anyone argues with me - were= you?) It adds application complexity and makes debugging harder in order to= overcome problems that would not exist if the network were properly configu= red, and it encourages misconfiguration to persist because it masks the effe= cts of misconfiguration. We should not perpetuate it; we should instead be m= oving beyond it.

Just because Happy Eyeballs is a s= tandards track RFC doesn't mean that hosts have to implement it.
=

Ok, I'm fine without Happy Eyeballs, i= t is most defiantly a hack, like I said it seemed to jump out of the Introdu= ction as a conclusion.  What about the other half?  If you going t= o continue to use anycast 6to4 should there be a requirement or recommendati= on to support RFC6724 or be manually configured with an address selection policy preferring IPv= 4 over a 6to4 source address?

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
David Farmer             &= nbsp;            Email: farmer@umn.edu
Office of Information Technology
<= div>University of M= innesota    
2218 University Ave SE         Pho= ne: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= --Apple-Mail-19F4ECCE-BEA7-4D07-BFF4-86E5AAE7512B-- From nobody Mon Jan 12 19:20:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C620C1A89B4 for ; Mon, 12 Jan 2015 19:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzCJhcW5zGE0 for ; Mon, 12 Jan 2015 19:20:34 -0800 (PST) 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 E93B71A899E for ; Mon, 12 Jan 2015 19:20:33 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fb1so843332pad.13 for ; Mon, 12 Jan 2015 19:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xMCiOzZycNTw4ajTxcFGTMaEp800Xyn2i8TMKudNLd4=; b=tpWyZrN4EQo+bj1b470XoAGCDtnoPcuhWr1SKTIDrnzHm6h1nhuO72RV5YXDPqEn6Y I3kMkuxbFHsRxGydkuop7LJQ2DmZueRsKqwaN/6DVnmLjl/COGVCWCci03fnxFynWfkj KpNOw3cNL/vIv3TbkgEQMaKu5pLLYNDwT6Qf8iEo/Rfnx1CJ7UFoKAdFinOfYUQEQ/wl Fynv6fEje9cMpPemxSHlmQJxqe3y+QleqyCLVHh7TUYVLnh4iNOTvEHsfCs28qrYumLS u9lXB1LiwZREz4JRQg64BgJN/pbIYF8oQiEQIf/VAvBSwmatfdNISrDZxI1aHRgnfIkz qKXg== X-Received: by 10.70.55.163 with SMTP id t3mr38004686pdp.8.1421119233174; Mon, 12 Jan 2015 19:20:33 -0800 (PST) Received: from ?IPv6:2406:e007:7927:1:28cc:dc4c:9703:6781? ([2406:e007:7927:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qc1sm15455776pbb.84.2015.01.12.19.20.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jan 2015 19:20:31 -0800 (PST) Message-ID: <54B48EFF.3040107@gmail.com> Date: Tue, 13 Jan 2015 16:20:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: George Michaelson , "v6ops@ietf.org WG" References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:20:36 -0000 In terms of the current draft, I'm hearing that we should not include the paragraph in question. If people want to debate HE as such, may I politely request that y'all change the subject line? Regards Brian On 13/01/2015 16:06, George Michaelson wrote: > I agree with Lorenzo. I believe based on the measurement stuff we do, that > HE has not got a net-positive effect, and was in hindsight not a good idea. > > Its not consistently implemented, because its not consistently understood > > It interacts badly with multiply addressed resources > > It has a proscriptive model of the 'best' connection which doesn't suit all > circumstances > > It has begun differentiating between client level behaviours, OS behaviours > and mediating device behaviours all of which interact in the V4/V6 path > > I think its inevitable that at some future point, HE will be deprecated. > > -G > > On Tue, Jan 13, 2015 at 12:54 PM, Lorenzo Colitti > wrote: > >> On Sat, Jan 10, 2015 at 6:44 AM, David Farmer wrote: >> >>> All hosts using 6to4 SHOULD support the IPv6 address selection >>> policy described in [RFC6724] or be manually configured with an >>> address selection policy preferring IPv4 over a 6to4 source >>> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >>> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >>> not meeting these requirements SHOULD NOT use, or continue to use, >>> the deprecated anycast 6to4 mechanism. >>> >> >> I disagree that implementations should support happy eyeballs. Happy >> eyeballs is a hack that came into being to avoid broken IPv6 >> implementations. (I know, because I was there; and before anyone argues >> with me - were you?) It adds application complexity and makes debugging >> harder in order to overcome problems that would not exist if the network >> were properly configured, and it encourages misconfiguration to persist >> because it masks the effects of misconfiguration. We should not perpetuate >> it; we should instead be moving beyond it. >> >> Just because Happy Eyeballs is a standards track RFC doesn't mean that >> hosts have to implement it. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jan 12 19:28:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336611A89B4 for ; Mon, 12 Jan 2015 19:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eRSbRZWd_d7 for ; Mon, 12 Jan 2015 19:27:59 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFC21A89A8 for ; Mon, 12 Jan 2015 19:27:59 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so630846iec.11 for ; Mon, 12 Jan 2015 19:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FXM9IEbg8HdTdN2irW4QjZU33Nd+gbtj1WkEwbbe13Y=; b=O4ISSWIV8mhDkDo+J4RlTJeOIwubbCQOx5uR6vusON3HfWQT8x+cxuvL2A0smtV7wn zbw56k2Up43szHDeHGIP+pplzGpe8ji78hEflZUdjS8k0NXZRlAaufRQY20oSQQrmRBd a+rbMqGVTGioheefLnqLStuX6wG5ogqD8jZ7WdgWWOh4G6Qz9CYWdRWTinv2SMQssB2G j0rTzuBkMSSuIxVRErPatzEaD3HjrExSjaDrvOlxiO7QsoSAF8ucHae+NAOMlq7SRBSJ h3kTqkez4FjghohYKSylxswtq4uSze+cvvEsyonwYztEzBfH9ojNS+w4hlThMK7ndwrA TaQQ== 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=FXM9IEbg8HdTdN2irW4QjZU33Nd+gbtj1WkEwbbe13Y=; b=f1bJZdPOOPvsOl1aA2iTizaFgeFIT97yCypWql1O2Ixo/XwHl0CfgX9Le7zMlt+p/V Df0iXJSk+opIezc1WUfPSydX20yOSxaNIvptkO7GQIgadi8UStghnbUmBAQygnxY964d BXKsIGs6MLqLpvXYJklhKyQgL5NcDqPhQlO4cLz2wjlut8188f0RLiB5OpfFOzGy/ltZ 0BGKjo2E0fxAxWbv/Jx6UdnmCvvPXZdKup8ZdU2h+1NxXo2CGz9JP67D0s0Rl+nuESFM W42Z9LPFr2Yty0ggbrG/GCzHKtiUe6b+ZKokVr5XfTmsYEXrYBjaMnZbKXAPhbu3tx4X 5/Vg== X-Gm-Message-State: ALoCoQm/1ooOkl7QcbWCI3s7rg0Atv2vl80aplsX3iuk+7taxZQBebCSBz4lAWg5G7tisCdNG0r1 X-Received: by 10.42.38.9 with SMTP id a9mr26272902ice.68.1421119678391; Mon, 12 Jan 2015 19:27:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.93.34 with HTTP; Mon, 12 Jan 2015 19:27:38 -0800 (PST) In-Reply-To: <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> From: Lorenzo Colitti Date: Tue, 13 Jan 2015 12:27:38 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=90e6ba613c069d45b5050c8035e2 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:28:01 -0000 --90e6ba613c069d45b5050c8035e2 Content-Type: text/plain; charset=UTF-8 I do not object to saying that implementations SHOULD support the rules in RFC6724. On Tue, Jan 13, 2015 at 12:17 PM, David Farmer wrote: > > > On Jan 12, 2015, at 20:54, Lorenzo Colitti wrote: > > On Sat, Jan 10, 2015 at 6:44 AM, David Farmer wrote: > >> All hosts using 6to4 SHOULD support the IPv6 address selection >> policy described in [RFC6724] or be manually configured with an >> address selection policy preferring IPv4 over a 6to4 source >> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >> not meeting these requirements SHOULD NOT use, or continue to use, >> the deprecated anycast 6to4 mechanism. >> > > I disagree that implementations should support happy eyeballs. Happy > eyeballs is a hack that came into being to avoid broken IPv6 > implementations. (I know, because I was there; and before anyone argues > with me - were you?) It adds application complexity and makes debugging > harder in order to overcome problems that would not exist if the network > were properly configured, and it encourages misconfiguration to persist > because it masks the effects of misconfiguration. We should not perpetuate > it; we should instead be moving beyond it. > > Just because Happy Eyeballs is a standards track RFC doesn't mean that > hosts have to implement it. > > > Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, like I > said it seemed to jump out of the Introduction as a conclusion. What about > the other half? If you going to continue to use anycast 6to4 should there > be a requirement or recommendation to support RFC6724 or be manually > configured with an address selection policy preferring IPv4 over a 6to4 > source address? > > -- > =============================================== > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: +1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 > =============================================== > --90e6ba613c069d45b5050c8035e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do not object to saying that implementations SHOULD supp= ort the rules in RFC6724.

On Tue, Jan 13, 2015 at 12:17 PM, David Farmer <farmer@umn.edu<= /a>> wrote:
<= div>


On= Sat, Jan 10, 2015 at 6:44 AM, David Farmer <farmer@umn.edu> = wrote:
=C2=A0 =C2=A0All hosts using 6to4 = SHOULD support the IPv6 address selection
=C2=A0 =C2=A0policy described in [RFC6724] or be manually configured with a= n
=C2=A0 =C2=A0address selection policy preferring IPv4 over a 6to4 source =C2=A0 =C2=A0address.=C2=A0 Further, 6to4 hosts SHOULD support "Happy = Eyeballs"
=C2=A0 =C2=A0[RFC6555] or use a browser supporting "Happy Eyeballs&quo= t;.=C2=A0 Any hosts
=C2=A0 =C2=A0not meeting these requirements SHOULD NOT use, or continue to = use,
=C2=A0 =C2=A0the deprecated anycast 6to4 mechanism.
I disagree that implementations should support happy eyeballs.= Happy eyeballs is a hack that came into being to avoid broken IPv6 impleme= ntations. (I know, because I was there; and before anyone argues with me - = were you?) It adds application complexity and makes debugging harder in ord= er to overcome problems that would not exist if the network were properly c= onfigured, and it encourages misconfiguration to persist because it masks t= he effects of misconfiguration. We should not perpetuate it; we should inst= ead be moving beyond it.

Just because Happy Eyebal= ls is a standards track RFC doesn't mean that hosts have to implement i= t.

Ok, I'm fine without= Happy Eyeballs, it is most defiantly a hack, like I said it seemed to jump= out of the Introduction as a conclusion.=C2=A0 What about the other half?= =C2=A0 If you going to continue to use anycast 6to4 should there be a requi= rement or recommendation to support=C2=A0RFC6724 or be manually configured with an=C2=A0address selection policy= preferring IPv4 over a 6to4 source=C2=A0address?

--=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Email: farmer@umn.edu=
Office of I= nformation Technology
University of Minnesota =C2=A0 =C2=A0
<= div>2218 University Av= e SE =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: +1-612-626-0815
Minneapolis, MN 5541= 4-3029 =C2=A0 Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

--90e6ba613c069d45b5050c8035e2-- From nobody Mon Jan 12 23:27:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C01A8955 for ; Mon, 12 Jan 2015 23:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slQDkBKP8E4s for ; Mon, 12 Jan 2015 23:27:17 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A060F1A87F1 for ; Mon, 12 Jan 2015 23:27:16 -0800 (PST) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail41.telekom.de with ESMTP; 13 Jan 2015 08:27:11 +0100 X-IronPort-AV: E=Sophos;i="5.07,748,1413237600"; d="scan'208,217";a="740285634" Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 13 Jan 2015 08:27:11 +0100 Received: from HE113605.emea1.cds.t-internal.com ([10.125.65.122]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Tue, 13 Jan 2015 08:27:11 +0100 From: To: Date: Tue, 13 Jan 2015 08:27:10 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt Thread-Index: AdAu3fdkDzpB38zFT6iQibtqD860kgAI/zrA Message-ID: References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_FFD91DE61362694C94B174BB03CFDCDD0100F8F096BAHE113605eme_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 07:27:20 -0000 --_000_FFD91DE61362694C94B174BB03CFDCDD0100F8F096BAHE113605eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBvYnNlcnZhdGlvbiByZWdhcmRpbmcgSEUsIEkgZnVsbHkgYWdyZWUuDQoNCkhvd2V2ZXIg SSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgcmVjb21tZW5kYXRpb24gcmVnYXJkaW5nIFNBUyBpbiA2 dG80ICjigJw2dG80IFNIT1VMRCBzdXBwb3J0IHRoZSBJUHY2IGFkZHJlc3Mgc2VsZWN0aW9uICBw b2xpY3kgZGVzY3JpYmVkIGluIFtSRkM2NzI0XSDigKbigJ0pDQoNCk9sYWYNCg0KDQpGcm9tOiB2 Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHZW9yZ2Ug TWljaGFlbHNvbg0KU2VudDogRGllbnN0YWcsIDEzLiBKYW51YXIgMjAxNSAwNDowNg0KVG86IHY2 b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMtMTAudHh0DQoNCkkgYWdyZWUgd2l0aCBMb3Jlbnpv LiBJIGJlbGlldmUgYmFzZWQgb24gdGhlIG1lYXN1cmVtZW50IHN0dWZmIHdlIGRvLCB0aGF0IEhF IGhhcyBub3QgZ290IGEgbmV0LXBvc2l0aXZlIGVmZmVjdCwgYW5kIHdhcyBpbiBoaW5kc2lnaHQg bm90IGEgZ29vZCBpZGVhLg0KDQpJdHMgbm90IGNvbnNpc3RlbnRseSBpbXBsZW1lbnRlZCwgYmVj YXVzZSBpdHMgbm90IGNvbnNpc3RlbnRseSB1bmRlcnN0b29kDQoNCkl0IGludGVyYWN0cyBiYWRs eSB3aXRoIG11bHRpcGx5IGFkZHJlc3NlZCByZXNvdXJjZXMNCg0KSXQgaGFzIGEgcHJvc2NyaXB0 aXZlIG1vZGVsIG9mIHRoZSAnYmVzdCcgY29ubmVjdGlvbiB3aGljaCBkb2Vzbid0IHN1aXQgYWxs IGNpcmN1bXN0YW5jZXMNCg0KSXQgaGFzIGJlZ3VuIGRpZmZlcmVudGlhdGluZyBiZXR3ZWVuIGNs aWVudCBsZXZlbCBiZWhhdmlvdXJzLCBPUyBiZWhhdmlvdXJzIGFuZCBtZWRpYXRpbmcgZGV2aWNl IGJlaGF2aW91cnMgYWxsIG9mIHdoaWNoIGludGVyYWN0IGluIHRoZSBWNC9WNiBwYXRoDQoNCkkg dGhpbmsgaXRzIGluZXZpdGFibGUgdGhhdCBhdCBzb21lIGZ1dHVyZSBwb2ludCwgSEUgd2lsbCBi ZSBkZXByZWNhdGVkLg0KDQotRw0KDQpPbiBUdWUsIEphbiAxMywgMjAxNSBhdCAxMjo1NCBQTSwg TG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xl LmNvbT4+IHdyb3RlOg0KT24gU2F0LCBKYW4gMTAsIDIwMTUgYXQgNjo0NCBBTSwgRGF2aWQgRmFy bWVyIDxmYXJtZXJAdW1uLmVkdTxtYWlsdG86ZmFybWVyQHVtbi5lZHU+PiB3cm90ZToNCiAgIEFs bCBob3N0cyB1c2luZyA2dG80IFNIT1VMRCBzdXBwb3J0IHRoZSBJUHY2IGFkZHJlc3Mgc2VsZWN0 aW9uDQogICBwb2xpY3kgZGVzY3JpYmVkIGluIFtSRkM2NzI0XSBvciBiZSBtYW51YWxseSBjb25m aWd1cmVkIHdpdGggYW4NCiAgIGFkZHJlc3Mgc2VsZWN0aW9uIHBvbGljeSBwcmVmZXJyaW5nIElQ djQgb3ZlciBhIDZ0bzQgc291cmNlDQogICBhZGRyZXNzLiAgRnVydGhlciwgNnRvNCBob3N0cyBT SE9VTEQgc3VwcG9ydCAiSGFwcHkgRXllYmFsbHMiDQogICBbUkZDNjU1NV0gb3IgdXNlIGEgYnJv d3NlciBzdXBwb3J0aW5nICJIYXBweSBFeWViYWxscyIuICBBbnkgaG9zdHMNCiAgIG5vdCBtZWV0 aW5nIHRoZXNlIHJlcXVpcmVtZW50cyBTSE9VTEQgTk9UIHVzZSwgb3IgY29udGludWUgdG8gdXNl LA0KICAgdGhlIGRlcHJlY2F0ZWQgYW55Y2FzdCA2dG80IG1lY2hhbmlzbS4NCg0KSSBkaXNhZ3Jl ZSB0aGF0IGltcGxlbWVudGF0aW9ucyBzaG91bGQgc3VwcG9ydCBoYXBweSBleWViYWxscy4gSGFw cHkgZXllYmFsbHMgaXMgYSBoYWNrIHRoYXQgY2FtZSBpbnRvIGJlaW5nIHRvIGF2b2lkIGJyb2tl biBJUHY2IGltcGxlbWVudGF0aW9ucy4gKEkga25vdywgYmVjYXVzZSBJIHdhcyB0aGVyZTsgYW5k IGJlZm9yZSBhbnlvbmUgYXJndWVzIHdpdGggbWUgLSB3ZXJlIHlvdT8pIEl0IGFkZHMgYXBwbGlj YXRpb24gY29tcGxleGl0eSBhbmQgbWFrZXMgZGVidWdnaW5nIGhhcmRlciBpbiBvcmRlciB0byBv dmVyY29tZSBwcm9ibGVtcyB0aGF0IHdvdWxkIG5vdCBleGlzdCBpZiB0aGUgbmV0d29yayB3ZXJl IHByb3Blcmx5IGNvbmZpZ3VyZWQsIGFuZCBpdCBlbmNvdXJhZ2VzIG1pc2NvbmZpZ3VyYXRpb24g dG8gcGVyc2lzdCBiZWNhdXNlIGl0IG1hc2tzIHRoZSBlZmZlY3RzIG9mIG1pc2NvbmZpZ3VyYXRp b24uIFdlIHNob3VsZCBub3QgcGVycGV0dWF0ZSBpdDsgd2Ugc2hvdWxkIGluc3RlYWQgYmUgbW92 aW5nIGJleW9uZCBpdC4NCg0KSnVzdCBiZWNhdXNlIEhhcHB5IEV5ZWJhbGxzIGlzIGEgc3RhbmRh cmRzIHRyYWNrIFJGQyBkb2Vzbid0IG1lYW4gdGhhdCBob3N0cyBoYXZlIHRvIGltcGxlbWVudCBp dC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2 b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= --_000_FFD91DE61362694C94B174BB03CFDCDD0100F8F096BAHE113605eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg Mi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xh c3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn Pkdvb2Qgb2JzZXJ2YXRpb24gcmVnYXJkaW5nIEhFLCBJIGZ1bGx5IGFncmVlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+SG93ZXZlciBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSByZWNvbW1lbmRhdGlvbiBy ZWdhcmRpbmcgU0FTIGluIDZ0bzQgKOKAnDZ0bzQgU0hPVUxEIHN1cHBvcnQgdGhlIElQdjYgYWRk cmVzcyBzZWxlY3Rpb27CoCBwb2xpY3kgZGVzY3JpYmVkIGluIFtSRkM2NzI0XSDigKbigJ0pPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5PbGFmIDwvc3Bhbj48Yj48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2s7dGV4dC10cmFuc2Zvcm06dXBwZXJjYXNlJz48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+R2VvcmdlIE1p Y2hhZWxzb248YnI+PGI+U2VudDo8L2I+IERpZW5zdGFnLCAxMy4gSmFudWFyIDIwMTUgMDQ6MDY8 YnI+PGI+VG86PC9iPiB2Nm9wc0BpZXRmLm9yZyBXRzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFt2 Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljLTEwLnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBhZ3JlZSB3aXRoIExvcmVuem8uIEkgYmVs aWV2ZSBiYXNlZCBvbiB0aGUgbWVhc3VyZW1lbnQgc3R1ZmYgd2UgZG8sIHRoYXQgSEUgaGFzIG5v dCBnb3QgYSBuZXQtcG9zaXRpdmUgZWZmZWN0LCBhbmQgd2FzIGluIGhpbmRzaWdodCBub3QgYSBn b29kIGlkZWEuJm5ic3A7PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SXRzIG5vdCBj b25zaXN0ZW50bHkgaW1wbGVtZW50ZWQsIGJlY2F1c2UgaXRzIG5vdCBjb25zaXN0ZW50bHkgdW5k ZXJzdG9vZDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkl0IGludGVyYWN0 cyBiYWRseSB3aXRoIG11bHRpcGx5IGFkZHJlc3NlZCByZXNvdXJjZXMmbmJzcDs8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JdCBoYXMgYSBwcm9zY3JpcHRpdmUgbW9kZWwg b2YgdGhlICdiZXN0JyBjb25uZWN0aW9uIHdoaWNoIGRvZXNuJ3Qgc3VpdCBhbGwgY2lyY3Vtc3Rh bmNlczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkl0IGhhcyBiZWd1biBk aWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBjbGllbnQgbGV2ZWwgYmVoYXZpb3VycywgT1MgYmVoYXZp b3VycyBhbmQgbWVkaWF0aW5nIGRldmljZSBiZWhhdmlvdXJzIGFsbCBvZiB3aGljaCBpbnRlcmFj dCBpbiB0aGUgVjQvVjYgcGF0aDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkkgdGhpbmsgaXRzIGluZXZpdGFibGUgdGhhdCBhdCBzb21lIGZ1dHVyZSBwb2ludCwgSEUgd2ls bCBiZSBkZXByZWNhdGVkLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi1H PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gVHVlLCBKYW4gMTMsIDIw MTUgYXQgMTI6NTQgUE0sIExvcmVuem8gQ29saXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvcmVu em9AZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5P biBTYXQsIEphbiAxMCwgMjAxNSBhdCA2OjQ0IEFNLCBEYXZpZCBGYXJtZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpmYXJtZXJAdW1uLmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmZhcm1lckB1bW4uZWR1PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAmbmJz cDtBbGwgaG9zdHMgdXNpbmcgNnRvNCBTSE9VTEQgc3VwcG9ydCB0aGUgSVB2NiBhZGRyZXNzIHNl bGVjdGlvbjxicj4mbmJzcDsgJm5ic3A7cG9saWN5IGRlc2NyaWJlZCBpbiBbUkZDNjcyNF0gb3Ig YmUgbWFudWFsbHkgY29uZmlndXJlZCB3aXRoIGFuPGJyPiZuYnNwOyAmbmJzcDthZGRyZXNzIHNl bGVjdGlvbiBwb2xpY3kgcHJlZmVycmluZyBJUHY0IG92ZXIgYSA2dG80IHNvdXJjZTxicj4mbmJz cDsgJm5ic3A7YWRkcmVzcy4mbmJzcDsgRnVydGhlciwgNnRvNCBob3N0cyBTSE9VTEQgc3VwcG9y dCAmcXVvdDtIYXBweSBFeWViYWxscyZxdW90Ozxicj4mbmJzcDsgJm5ic3A7W1JGQzY1NTVdIG9y IHVzZSBhIGJyb3dzZXIgc3VwcG9ydGluZyAmcXVvdDtIYXBweSBFeWViYWxscyZxdW90Oy4mbmJz cDsgQW55IGhvc3RzPGJyPiZuYnNwOyAmbmJzcDtub3QgbWVldGluZyB0aGVzZSByZXF1aXJlbWVu dHMgU0hPVUxEIE5PVCB1c2UsIG9yIGNvbnRpbnVlIHRvIHVzZSw8YnI+Jm5ic3A7ICZuYnNwO3Ro ZSBkZXByZWNhdGVkIGFueWNhc3QgNnRvNCBtZWNoYW5pc20uPG86cD48L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+SSBkaXNhZ3JlZSB0aGF0IGltcGxlbWVudGF0aW9ucyBzaG91bGQgc3VwcG9y dCBoYXBweSBleWViYWxscy4gSGFwcHkgZXllYmFsbHMgaXMgYSBoYWNrIHRoYXQgY2FtZSBpbnRv IGJlaW5nIHRvIGF2b2lkIGJyb2tlbiBJUHY2IGltcGxlbWVudGF0aW9ucy4gKEkga25vdywgYmVj YXVzZSBJIHdhcyB0aGVyZTsgYW5kIGJlZm9yZSBhbnlvbmUgYXJndWVzIHdpdGggbWUgLSB3ZXJl IHlvdT8pIEl0IGFkZHMgYXBwbGljYXRpb24gY29tcGxleGl0eSBhbmQgbWFrZXMgZGVidWdnaW5n IGhhcmRlciBpbiBvcmRlciB0byBvdmVyY29tZSBwcm9ibGVtcyB0aGF0IHdvdWxkIG5vdCBleGlz dCBpZiB0aGUgbmV0d29yayB3ZXJlIHByb3Blcmx5IGNvbmZpZ3VyZWQsIGFuZCBpdCBlbmNvdXJh Z2VzIG1pc2NvbmZpZ3VyYXRpb24gdG8gcGVyc2lzdCBiZWNhdXNlIGl0IG1hc2tzIHRoZSBlZmZl Y3RzIG9mIG1pc2NvbmZpZ3VyYXRpb24uIFdlIHNob3VsZCBub3QgcGVycGV0dWF0ZSBpdDsgd2Ug c2hvdWxkIGluc3RlYWQgYmUgbW92aW5nIGJleW9uZCBpdC48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5KdXN0IGJlY2F1c2UgSGFwcHkgRXllYmFsbHMgaXMgYSBzdGFuZGFy ZHMgdHJhY2sgUkZDIGRvZXNuJ3QgbWVhbiB0aGF0IGhvc3RzIGhhdmUgdG8gaW1wbGVtZW50IGl0 LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj52Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJl Zj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48 L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_FFD91DE61362694C94B174BB03CFDCDD0100F8F096BAHE113605eme_-- From nobody Tue Jan 13 00:20:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9766B1A8A44 for ; Tue, 13 Jan 2015 00:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv-fZ1aev-0d for ; Tue, 13 Jan 2015 00:20:39 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 33D8A1A8A43 for ; Tue, 13 Jan 2015 00:20:39 -0800 (PST) Received: from [IPv6:2620::930:0:e6ce:8fff:fe5e:af29] ([IPv6:2620:0:930:0:e6ce:8fff:fe5e:af29]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t0D8JNkV008091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jan 2015 00:19:24 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t0D8JNkV008091 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1421137164; bh=Z8i/vuoAR3rvxO6bJMZeriVEMzQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Xr9DeyO7vG5c+TOj4zrZ0xqwz/Y4lFP2kwwLMXeVXCqBJC1npbzYXvulArj4MOWgj NFYTVjhJoOXuC7NRRx5yLJXwDJ6EMaMFGBKFf5X9W4YvlPs8gCg3r38fHJzhgb2W3W ZRiwsrQLyA1+iwly+Ikqag+rBOqAQbt/AwubvHzY= Content-Type: multipart/alternative; boundary="Apple-Mail=_84D9279F-9823-4128-98BE-53CDAF230583" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Owen DeLong In-Reply-To: Date: Tue, 13 Jan 2015 00:19:23 -0800 Message-Id: <45DE3833-A354-4EF8-96BC-CFE07C472E0A@delong.com> References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> To: Olaf.Bonness@telekom.de X-Mailer: Apple Mail (2.1993) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 13 Jan 2015 00:19:24 -0800 (PST) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 08:20:42 -0000 --Apple-Mail=_84D9279F-9823-4128-98BE-53CDAF230583 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HE probably won=E2=80=99t get deprecated, it will probably simply become = obsolete as IPv4 is phased out. I agree HE wasn=E2=80=99t a good idea. I thought so at the time, but I = do understand why people pushed for it. In any case, hindsight is 20/20 = and it doesn=E2=80=99t matter why so much as how we cope with where we = are today. I support Olaf=E2=80=99s recommendation, if we=E2=80=99re updating 6to4 = language. However, I thought we were basically moving 6to4 to historic = status, in which case, I=E2=80=99m not sure suggesting a new SAS = strategy as a should is relevant/necessary/consistent with this move. Owen > On Jan 12, 2015, at 23:27 , = wrote: >=20 > Good observation regarding HE, I fully agree. > =20 > However I would like to see the recommendation regarding SAS in 6to4 = (=E2=80=9C6to4 SHOULD support the IPv6 address selection policy = described in [RFC6724] =E2=80=A6=E2=80=9D) > =20 > Olaf=20 > =20 > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org = ] On Behalf Of George Michaelson > Sent: Dienstag, 13. Januar 2015 04:06 > To: v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-6to4-to-historic-10.txt > =20 > I agree with Lorenzo. I believe based on the measurement stuff we do, = that HE has not got a net-positive effect, and was in hindsight not a = good idea.=20 > =20 > Its not consistently implemented, because its not consistently = understood > =20 > It interacts badly with multiply addressed resources=20 > =20 > It has a proscriptive model of the 'best' connection which doesn't = suit all circumstances > =20 > It has begun differentiating between client level behaviours, OS = behaviours and mediating device behaviours all of which interact in the = V4/V6 path > =20 > I think its inevitable that at some future point, HE will be = deprecated. > =20 > -G > =20 > On Tue, Jan 13, 2015 at 12:54 PM, Lorenzo Colitti > wrote: > On Sat, Jan 10, 2015 at 6:44 AM, David Farmer > wrote: > All hosts using 6to4 SHOULD support the IPv6 address selection > policy described in [RFC6724] or be manually configured with an > address selection policy preferring IPv4 over a 6to4 source > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > not meeting these requirements SHOULD NOT use, or continue to use, > the deprecated anycast 6to4 mechanism. > =20 > I disagree that implementations should support happy eyeballs. Happy = eyeballs is a hack that came into being to avoid broken IPv6 = implementations. (I know, because I was there; and before anyone argues = with me - were you?) It adds application complexity and makes debugging = harder in order to overcome problems that would not exist if the network = were properly configured, and it encourages misconfiguration to persist = because it masks the effects of misconfiguration. We should not = perpetuate it; we should instead be moving beyond it. > =20 > Just because Happy Eyeballs is a standards track RFC doesn't mean that = hosts have to implement it. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_84D9279F-9823-4128-98BE-53CDAF230583 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 HE probably won=E2=80=99t get deprecated, it will probably = simply become obsolete as IPv4 is phased out.

I agree HE wasn=E2=80=99t a good idea. = I thought so at the time, but I do understand why people pushed for it. = In any case, hindsight is 20/20 and it doesn=E2=80=99t matter why so = much as how we cope with where we are today.

I support Olaf=E2=80=99s = recommendation, if we=E2=80=99re updating 6to4 language. However, I = thought we were basically moving 6to4 to historic status, in which case, = I=E2=80=99m not sure suggesting a new SAS strategy as a should is = relevant/necessary/consistent with this move.

Owen

On = Jan 12, 2015, at 23:27 , <Olaf.Bonness@telekom.de> <Olaf.Bonness@telekom.de> wrote:

Good observation regarding HE, I fully = agree.
 
However I would like to see the recommendation regarding SAS = in 6to4 (=E2=80=9C6to4 SHOULD support the IPv6 address selection  = policy described in [RFC6724] =E2=80=A6=E2=80=9D)
 
Olaf 
 
 
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf = Of George = Michaelson
Sent: Dienstag, 13. Januar 2015 = 04:06
To: v6ops@ietf.org WG
Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-6to4-to-historic-10.txt
 
I agree with Lorenzo. I believe based on the measurement = stuff we do, that HE has not got a net-positive effect, and was in = hindsight not a good idea. 
 
Its not consistently implemented, because its not = consistently understood
 
It interacts badly with multiply addressed = resources 
 
It has a proscriptive model of the 'best' connection = which doesn't suit all circumstances
 
It has begun differentiating between client level = behaviours, OS behaviours and mediating device behaviours all of which = interact in the V4/V6 path
 
I think its inevitable that at some future point, HE = will be deprecated.
 
-G
 
On Tue, Jan 13, 2015 at 12:54 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
On Sat, Jan 10, 2015 = at 6:44 AM, David Farmer <farmer@umn.edu> wrote:
   All hosts using 6to4 SHOULD = support the IPv6 address selection
   policy = described in [RFC6724] or be manually configured with an
   address selection policy preferring IPv4 over a = 6to4 source
   address.  Further, 6to4 = hosts SHOULD support "Happy Eyeballs"
  =  [RFC6555] or use a browser supporting "Happy Eyeballs".  Any = hosts
   not meeting these requirements SHOULD = NOT use, or continue to use,
   the deprecated = anycast 6to4 mechanism.
 
I disagree that implementations should support happy = eyeballs. Happy eyeballs is a hack that came into being to avoid broken = IPv6 implementations. (I know, because I was there; and before anyone = argues with me - were you?) It adds application complexity and makes = debugging harder in order to overcome problems that would not exist if = the network were properly configured, and it encourages misconfiguration = to persist because it masks the effects of misconfiguration. We should = not perpetuate it; we should instead be moving beyond it.
 
Just because Happy Eyeballs is a = standards track RFC doesn't mean that hosts have to implement it.


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

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

= --Apple-Mail=_84D9279F-9823-4128-98BE-53CDAF230583-- From nobody Tue Jan 13 01:40:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273101ACE33 for ; Tue, 13 Jan 2015 01:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i7_-5sJu8Uq for ; Tue, 13 Jan 2015 01:40:38 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F17C1ACD55 for ; Tue, 13 Jan 2015 01:40:37 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t0D9eZ0j004962 for ; Tue, 13 Jan 2015 09:40:35 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t0D9eZ0j004962 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1421142035; bh=QroWk+5CQjUpQNyyL0Vr1tnIduo=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=fA+N/Cdse2QINeWnJ6+bwQJDbn/W+xOMbVPwL3oswmtfLpGLoCiuKhS1AoztRnBAX HGmw1V1kdeV7FU5B3T/TdlZurcC24yovxvohs4TVYEAAFVkUm4xfxBsCJuJK5qdIuJ gY2wHhvAjg3lZKNDQL6IM5NwKdsPqoCHNPB7SwZk= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r0C9eZ1382301721Ep ret-id none; Tue, 13 Jan 2015 09:40:35 +0000 Received: from [172.16.2.13] ([213.48.25.226]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t0D9dGSf001576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jan 2015 09:39:16 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_9E5CD53B-C0CF-476D-9786-19FA928A75F0" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Tue, 13 Jan 2015 09:39:21 +0000 References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> <84D59468-E7E3-48EE-A86D-5FF71AD78D45@ecs.soton.ac.uk> To: "v6ops@ietf.org WG" In-Reply-To: X-Mailer: Apple Mail (2.1993) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r0C9eZ138230172100; tid=r0C9eZ1382301721Ep; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t0D9eZ0j004962 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 09:40:41 -0000 --Apple-Mail=_9E5CD53B-C0CF-476D-9786-19FA928A75F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 13 Jan 2015, at 03:27, Lorenzo Colitti wrote: >=20 > I do not object to saying that implementations SHOULD support the = rules in RFC6724. Yes, definitely. HE was a necessary hack at the time, and it made perfect sense if Google = were doing v6 for World IPv6 Day in 2011 that they could implement = something HE-like and say their browser would be resilient to the 20+ = second delays we saw otherwise back at that time. I think I even stayed = on Chrome after that day, so the ploy worked ;) I think an interesting approach is as described in = draft-ietf-mif-mpvd-arch-08, which blends many considerations including = multiple interfaces, providers and protocols. But for this draft, = RFC6724 should be the go to reference. Tim > On Tue, Jan 13, 2015 at 12:17 PM, David Farmer > wrote: >=20 >=20 > On Jan 12, 2015, at 20:54, Lorenzo Colitti > wrote: >=20 >> On Sat, Jan 10, 2015 at 6:44 AM, David Farmer > wrote: >> All hosts using 6to4 SHOULD support the IPv6 address selection >> policy described in [RFC6724] or be manually configured with an >> address selection policy preferring IPv4 over a 6to4 source >> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >> not meeting these requirements SHOULD NOT use, or continue to use, >> the deprecated anycast 6to4 mechanism. >>=20 >> I disagree that implementations should support happy eyeballs. Happy = eyeballs is a hack that came into being to avoid broken IPv6 = implementations. (I know, because I was there; and before anyone argues = with me - were you?) It adds application complexity and makes debugging = harder in order to overcome problems that would not exist if the network = were properly configured, and it encourages misconfiguration to persist = because it masks the effects of misconfiguration. We should not = perpetuate it; we should instead be moving beyond it. >>=20 >> Just because Happy Eyeballs is a standards track RFC doesn't mean = that hosts have to implement it. >=20 > Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, like = I said it seemed to jump out of the Introduction as a conclusion. What = about the other half? If you going to continue to use anycast 6to4 = should there be a requirement or recommendation to support RFC6724 or be = manually configured with an address selection policy preferring IPv4 = over a 6to4 source address? >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu = > Office of Information Technology > University of Minnesota =20 > 2218 University Ave SE Phone: +1-612-626-0815 = > Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_9E5CD53B-C0CF-476D-9786-19FA928A75F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

On 13 Jan 2015, at 03:27, Lorenzo Colitti <lorenzo@google.com> = wrote:

I do not object to saying that implementations = SHOULD support the rules in RFC6724.

Yes, definitely.

HE = was a necessary hack at the time, and it made perfect sense if Google = were doing v6 for World IPv6 Day in 2011 that they could implement = something HE-like and say their browser would be resilient to the 20+ = second delays we saw otherwise back at that time. I think I even stayed = on Chrome after that day, so the ploy worked ;)

I think an interesting approach is as described = in draft-ietf-mif-mpvd-arch-08, which blends many considerations = including multiple interfaces, providers and protocols. But for this = draft, RFC6724 should be the go to reference.

Tim

On Tue, Jan 13, 2015 at 12:17 PM, David Farmer = <farmer@umn.edu> wrote:


On Jan 12, 2015, at = 20:54, Lorenzo Colitti <lorenzo@google.com> wrote:

On Sat, Jan 10, 2015 at 6:44 AM, David Farmer = <farmer@umn.edu> wrote:
   All hosts = using 6to4 SHOULD support the IPv6 address selection
   policy described in [RFC6724] or be manually configured = with an
   address selection policy preferring IPv4 over a 6to4 = source
   address.  Further, 6to4 hosts SHOULD support "Happy = Eyeballs"
   [RFC6555] or use a browser supporting "Happy = Eyeballs".  Any hosts
   not meeting these requirements SHOULD NOT use, or continue = to use,
   the deprecated anycast 6to4 mechanism.

I disagree that implementations should support happy = eyeballs. Happy eyeballs is a hack that came into being to avoid broken = IPv6 implementations. (I know, because I was there; and before anyone = argues with me - were you?) It adds application complexity and makes = debugging harder in order to overcome problems that would not exist if = the network were properly configured, and it encourages misconfiguration = to persist because it masks the effects of misconfiguration. We should = not perpetuate it; we should instead be moving beyond it.

Just because Happy = Eyeballs is a standards track RFC doesn't mean that hosts have to = implement it.

Ok, I'm fine without Happy Eyeballs, it is most defiantly a = hack, like I said it seemed to jump out of the Introduction as a = conclusion.  What about the other half?  If you going to = continue to use anycast 6to4 should there be a requirement or = recommendation to support RFC6724 or be = manually configured with an address = selection policy preferring IPv4 over a 6to4 source address?

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer =                     =      Email: farmer@umn.edu
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, = MN 55414-3029   Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

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

= --Apple-Mail=_9E5CD53B-C0CF-476D-9786-19FA928A75F0-- From nobody Tue Jan 13 10:19:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5A11A902D for ; Tue, 13 Jan 2015 10:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-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 lJO6Mxgj5VVR for ; Tue, 13 Jan 2015 10:19:45 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA54F1A902F for ; Tue, 13 Jan 2015 10:19:44 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so3919539obc.11 for ; Tue, 13 Jan 2015 10:19:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7YRhiETMGH2biQwUCzhswutuz31Fm6BYz87ifREPHo0=; b=InIfgMRf3Z/sksqOHYBCH0kzxt/8wmRNH24ufvBmcjbk/GpNnVF7+Ur+sRyqWEwCy9 ZzfFeAFY8G2kZNvRXlxP2Ot2o2YTOsAL4F3Apdp7ZLB6K/XJAUlz0CB7zRR7DM9s9cNW putRKaE2U8qICJZLJAanelJVisuxtMJEzhIwG0Ab8qufto+x/sSUFr4FF8MOjuLBoU5w 3JVa+Eyin0n5PbFxSnkByv0pM6bDCHHNNUo56CNFAcNZQEtMPFbN58ktS9horGgeIwae 6FXiuHlOGGq8ak452ZgPQwfLUwdVioUg1OyAuSXGmDVa7QdK4k0CZyx7DRhFCbFlsjco DLgA== X-Gm-Message-State: ALoCoQkozvsB0fX1ynV8Wx5NVpzZP5GWj/MmIUmUsCwSpYN9Mjnl0ZtpxmLJmswUbN5pALobORsA MIME-Version: 1.0 X-Received: by 10.202.217.138 with SMTP id q132mr20253121oig.35.1421173184250; Tue, 13 Jan 2015 10:19:44 -0800 (PST) Received: by 10.76.150.2 with HTTP; Tue, 13 Jan 2015 10:19:44 -0800 (PST) In-Reply-To: References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> Date: Tue, 13 Jan 2015 10:19:44 -0800 Message-ID: From: James Woodyatt To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a113cdddacfddad050c8caa9e Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 18:19:47 -0000 --001a113cdddacfddad050c8caa9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Everyone=E2=80=94 I would object to the recommendation for a manual configuration option. We are already telling host implementations that enabling and configuring 6to4 cannot be automatic. It must be manual. It's redundant and unnecessary to say that a separate manual configuration is also necessary for enabling the associated address selection policy. Why would we do that? The draft as currently written seems adequate to me, and I don't see a burning need to revise it so that RFC 6724 is expressly RECOMMENDED with a keyword. If that recommendation could be added easily and without further delay, then I would not object to that. On Mon, Jan 12, 2015 at 7:27 PM, Lorenzo Colitti wrote= : > I do not object to saying that implementations SHOULD support the rules i= n > RFC6724. > > On Tue, Jan 13, 2015 at 12:17 PM, David Farmer wrote: > >> >> >> On Jan 12, 2015, at 20:54, Lorenzo Colitti wrote: >> >> On Sat, Jan 10, 2015 at 6:44 AM, David Farmer wrote: >> >>> All hosts using 6to4 SHOULD support the IPv6 address selection >>> policy described in [RFC6724] or be manually configured with an >>> address selection policy preferring IPv4 over a 6to4 source >>> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >>> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >>> not meeting these requirements SHOULD NOT use, or continue to use, >>> the deprecated anycast 6to4 mechanism. >>> >> >> I disagree that implementations should support happy eyeballs. Happy >> eyeballs is a hack that came into being to avoid broken IPv6 >> implementations. (I know, because I was there; and before anyone argues >> with me - were you?) It adds application complexity and makes debugging >> harder in order to overcome problems that would not exist if the network >> were properly configured, and it encourages misconfiguration to persist >> because it masks the effects of misconfiguration. We should not perpetua= te >> it; we should instead be moving beyond it. >> >> Just because Happy Eyeballs is a standards track RFC doesn't mean that >> hosts have to implement it. >> >> >> Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, like I >> said it seemed to jump out of the Introduction as a conclusion. What ab= out >> the other half? If you going to continue to use anycast 6to4 should the= re >> be a requirement or recommendation to support RFC6724 or be manually >> configured with an address selection policy preferring IPv4 over a 6to4 >> source address? >> >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> David Farmer Email: farmer@umn.edu >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: +1-612-626-0815 >> Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 james woodyatt Nest Labs, Communications Engineering --001a113cdddacfddad050c8caa9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Everyone=E2=80=94

I would object to the= recommendation for a manual configuration option. We are already telling h= ost implementations that enabling and configuring 6to4 cannot be automatic.= It must be manual. It's redundant and unnecessary to say that a separa= te manual configuration is also necessary for enabling the associated addre= ss selection policy. Why would we do that?

The dra= ft as currently written seems adequate to me, and I don't see a burning= need to revise it so that RFC 6724 is expressly RECOMMENDED with a keyword= .=C2=A0 If that recommendation could be added easily and without further de= lay, then I would not object to that.

On Mon, Jan 12, 2015 at 7:27 PM, Lorenzo Co= litti <lorenzo@google.com> wrote:
I do not object to saying that implementations SH= OULD support the rules in RFC6724.

On Tue, Jan = 13, 2015 at 12:17 PM, David Farmer <farmer@umn.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


On Jan 12, 2015, at 20:54, Lorenzo Colitti <lorenzo@google.com> wrote:
On Sat, Jan 10, 2015 at 6:44 AM, David Fa= rmer <farmer@umn.edu> wrote:
= =C2=A0 =C2=A0All hosts using 6to4 SHOULD support the IPv6 address selection=
=C2=A0 =C2=A0policy described in [RFC6724] or be manually configured with a= n
=C2=A0 =C2=A0address selection policy preferring IPv4 over a 6to4 source =C2=A0 =C2=A0address.=C2=A0 Further, 6to4 hosts SHOULD support "Happy = Eyeballs"
=C2=A0 =C2=A0[RFC6555] or use a browser supporting "Happy Eyeballs&quo= t;.=C2=A0 Any hosts
=C2=A0 =C2=A0not meeting these requirements SHOULD NOT use, or continue to = use,
=C2=A0 =C2=A0the deprecated anycast 6to4 mechanism.
I disagree that implementations should support happy eyeballs.= Happy eyeballs is a hack that came into being to avoid broken IPv6 impleme= ntations. (I know, because I was there; and before anyone argues with me - = were you?) It adds application complexity and makes debugging harder in ord= er to overcome problems that would not exist if the network were properly c= onfigured, and it encourages misconfiguration to persist because it masks t= he effects of misconfiguration. We should not perpetuate it; we should inst= ead be moving beyond it.

Just because Happy Eyebal= ls is a standards track RFC doesn't mean that hosts have to implement i= t.

Ok, I'm fine without= Happy Eyeballs, it is most defiantly a hack, like I said it seemed to jump= out of the Introduction as a conclusion.=C2=A0 What about the other half?= =C2=A0 If you going to continue to use anycast 6to4 should there be a requi= rement or recommendation to support=C2=A0RFC6724 or be manually configured with an=C2=A0address selection policy= preferring IPv4 over a 6to4 source=C2=A0address?

--=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Email: farmer@umn.edu
= Office of Information = Technology
University of Minnesota =C2=A0 =C2=A0
2218 University Ave SE =C2=A0= =C2=A0 =C2=A0 =C2=A0 Phone: +1-612-626-0815
Minneapolis, MN 55414-3029 =C2= =A0 Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D


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




--
james woodyatt <jhw@nestlabs.com>
Nest Lab= s, Communications Engineering
--001a113cdddacfddad050c8caa9e-- From nobody Tue Jan 13 11:35:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D021ACCFF for ; Tue, 13 Jan 2015 11:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAj4EDxJUYNY for ; Tue, 13 Jan 2015 11:35:11 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBB51ACCFE for ; Tue, 13 Jan 2015 11:35:11 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id r10so5113104pdi.7 for ; Tue, 13 Jan 2015 11:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/WqYZM2zf4O4GhzOb2Aj0kWZ4gu57DH/qdLEhHkjjG4=; b=wtFIDVsJCB6O+BTUWr/MqzZH7LGrtKdFfJjsYmqOrbj64zrDLtHWAwpgUL/eykqHty nadW7BGjCJE4zlgZsejmsByK7+qcDGDfHC3B7OvHMHIN0zyaSYErJjSVa9gleH+vbmd5 hbQ0DjYuu3wkBSpu/eEUtGYA620a53VrMDHMAdLgJoIDvZnZJr93nQ/DWm9NdghvFNH4 ercIUtXAIfMhMBRB7LvgnS7qYPLaBm0m3qWim3AoTwa8Kl5KQ0WajgAh9arV7O2xFnEJ TM8xJsrS0nC1b2wjptdflkaBR6wn5qJsBTZJaboxnWk/ADzPPZUirQodYDCDcOQvYN2s 9J/A== X-Received: by 10.70.128.131 with SMTP id no3mr123686pdb.18.1421177710795; Tue, 13 Jan 2015 11:35:10 -0800 (PST) Received: from ?IPv6:2406:e007:492f:1:28cc:dc4c:9703:6781? ([2406:e007:492f:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bx13sm17787179pdb.19.2015.01.13.11.35.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jan 2015 11:35:09 -0800 (PST) Message-ID: <54B5736E.8090308@gmail.com> Date: Wed, 14 Jan 2015 08:35:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: James Woodyatt , "v6ops@ietf.org WG" References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 19:35:13 -0000 On 14/01/2015 07:19, James Woodyatt wrote: > Everyone=E2=80=94 >=20 > I would object to the recommendation for a manual configuration option.= We > are already telling host implementations that enabling and configuring = 6to4 > cannot be automatic. It must be manual. It's redundant and unnecessary = to > say that a separate manual configuration is also necessary for enabling= the > associated address selection policy. Why would we do that? >=20 > The draft as currently written seems adequate to me, and I don't see a > burning need to revise it so that RFC 6724 is expressly RECOMMENDED wit= h a > keyword. If that recommendation could be added easily and without furt= her > delay, then I would not object to that. The text already says "The default address selection rules specified in [= RFC6724] are not modified." Since it looks as if the draft needs to be updated one= more time, we can update that sentence with a SHOULD easily enough. (RFC 6724 = is already a standard anyway, so strictly speaking this is redundant, but it= won't waste much ink.) Brian >=20 > On Mon, Jan 12, 2015 at 7:27 PM, Lorenzo Colitti w= rote: >=20 >> I do not object to saying that implementations SHOULD support the rule= s in >> RFC6724. >> >> On Tue, Jan 13, 2015 at 12:17 PM, David Farmer wrote:= >> >>> >>> >>> On Jan 12, 2015, at 20:54, Lorenzo Colitti wrote= : >>> >>> On Sat, Jan 10, 2015 at 6:44 AM, David Farmer wrote:= >>> >>>> All hosts using 6to4 SHOULD support the IPv6 address selection >>>> policy described in [RFC6724] or be manually configured with an >>>> address selection policy preferring IPv4 over a 6to4 source >>>> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >>>> [RFC6555] or use a browser supporting "Happy Eyeballs". Any host= s >>>> not meeting these requirements SHOULD NOT use, or continue to use= , >>>> the deprecated anycast 6to4 mechanism. >>>> >>> >>> I disagree that implementations should support happy eyeballs. Happy >>> eyeballs is a hack that came into being to avoid broken IPv6 >>> implementations. (I know, because I was there; and before anyone argu= es >>> with me - were you?) It adds application complexity and makes debuggi= ng >>> harder in order to overcome problems that would not exist if the netw= ork >>> were properly configured, and it encourages misconfiguration to persi= st >>> because it masks the effects of misconfiguration. We should not perpe= tuate >>> it; we should instead be moving beyond it. >>> >>> Just because Happy Eyeballs is a standards track RFC doesn't mean tha= t >>> hosts have to implement it. >>> >>> >>> Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, lik= e I >>> said it seemed to jump out of the Introduction as a conclusion. What= about >>> the other half? If you going to continue to use anycast 6to4 should = there >>> be a requirement or recommendation to support RFC6724 or be manually >>> configured with an address selection policy preferring IPv4 over a 6t= o4 >>> source address? >>> >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> David Farmer Email: farmer@umn.edu >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: +1-612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Jan 14 07:36:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ABB1A886C for ; Wed, 14 Jan 2015 07:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nC9ZWW-kKzY for ; Wed, 14 Jan 2015 07:36:28 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D8E1A8832 for ; Wed, 14 Jan 2015 07:36:28 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 01B97206D2 for ; Wed, 14 Jan 2015 10:36:27 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 14 Jan 2015 10:36:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=lxBaaG0Rzz2C1+CkgOxqCQ cMwd4=; b=EL26o7wVnddmzjO4gdDH0yItjXO9ae+qEIDjFeuCyKHBCYVG7tqJh3 84mua0ZFGPwHBmB84UPOshocE2FvKq3lrLkbnINX/1ogE6N2Xielm2z2BK3AG+KR bAbnyBUJc2vr/fUpFPFFSVFZuxuY+71iPdNoy+MRkLJIR2R0CcnNI= X-Sasl-enc: w+P0UbnSdNHd7KXB9iP8HmDkYxSOmZ4HXSqz0vHVpGwU 1421249787 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 96637C00016; Wed, 14 Jan 2015 10:36:27 -0500 (EST) Message-ID: <54B68CEA.9090606@network-heretics.com> Date: Wed, 14 Jan 2015 10:36:10 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> In-Reply-To: <54B1CD5C.3090107@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 15:36:30 -0000 On 01/10/2015 08:09 PM, Brian E Carpenter wrote: >> > All hosts using 6to4 SHOULD support the IPv6 address selection >> > policy described in [RFC6724] or be manually configured with an >> > address selection policy preferring IPv4 over a 6to4 source >> > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >> > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >> > not meeting these requirements SHOULD NOT use, or continue to use, >> > the deprecated anycast 6to4 mechanism. > I agree with the sentiments. But I'd like to hear a positive echo from > the WG, because this seems like a substantive addition. I think this goes too far. Happy Eyeballs is of very limited applicability; and there's way too much assumption here that using a web browser is the purpose of using IPv6 or maybe even the Internet. Keith From nobody Wed Jan 14 08:02:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1C11A1ABF for ; Wed, 14 Jan 2015 08:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVPM6rHucFze for ; Wed, 14 Jan 2015 08:02:29 -0800 (PST) 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 4A61B1A6FD5 for ; Wed, 14 Jan 2015 08:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2096; q=dns/txt; s=iport; t=1421251348; x=1422460948; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2s/ylsdhLknErfwGtO2P3UsEj4tJUzMFcnkHSdpwmE4=; b=D0/3ewpNqHLNHP/T1b1QXiQ96wLddT3TiqMhKQRArhXylkoY5UaVgWvI S50Ln2YdNSQ1x4TyBVYq2QxxkiERk/e7s1P7gq7Rn4Yfxq6CQBUyjzAkh cY1909ngRtUzoXRDn3IncTwYBJdPg3pYdte8UB9tqvyfAjEjKxFRMcURc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFAKaRtlStJA2I/2dsb2JhbABbgwaBKgTLcwKBFEMBAQEBAX2EDAEBAQMBOj8FCwIBCBgeEDIXAQ0CBA4FiCQI0T4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjyElMweDFoETBY5CiQ2RfCKDbm+BA0J+AQEB X-IronPort-AV: E=Sophos;i="5.07,756,1413244800"; d="scan'208";a="113225321" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 14 Jan 2015 16:02:28 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0EG2RVD004024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Jan 2015 16:02:27 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 10:02:27 -0600 From: "Fred Baker (fred)" To: Keith Moore Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt Thread-Index: AQHQMBN9Ap2uYuT4l0a6pmPBIgFF+A== Date: Wed, 14 Jan 2015 16:02:26 +0000 Message-ID: <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> In-Reply-To: <54B68CEA.9090606@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.70.226] Content-Type: text/plain; charset="us-ascii" Content-ID: <38F206A9D3226940AE8CB6ED2F83A7E8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 16:02:31 -0000 > On Jan 14, 2015, at 7:36 AM, Keith Moore wro= te: >=20 > On 01/10/2015 08:09 PM, Brian E Carpenter wrote: >>> > All hosts using 6to4 SHOULD support the IPv6 address selection >>> > policy described in [RFC6724] or be manually configured with an >>> > address selection policy preferring IPv4 over a 6to4 source >>> > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >>> > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >>> > not meeting these requirements SHOULD NOT use, or continue to use, >>> > the deprecated anycast 6to4 mechanism. >> I agree with the sentiments. But I'd like to hear a positive echo from >> the WG, because this seems like a substantive addition. >=20 > I think this goes too far. Happy Eyeballs is of very limited applicabil= ity; and there's way too much assumption here that using a web browser is t= he purpose of using IPv6 or maybe even the Internet. IMHO, HE is stated in terms of a simple use case (a client web browser, and= the issue is selecting among a set of two addresses, IPv4 and IPv6), but e= mbodies a more general principle. The principle is that if a host is multih= omed (as in, has more than one address, dual stack being but one example of= that), the addresses each represent a path, and paths may have different c= haracteristics in terms of whether they work at all, end to end delay, loss= , yada yada yada. If both ends are multihomed, it gets more complex. The principle is "if one choice isn't giving you the results you want, try = a different one, in a timely fashion." My only problem with making a recommendation about "the host" in this conte= xt is that "the host" is properly its OS, and due to the stupidity of the s= ocket API design, this is relegated to the application. So we have to chang= e each application individually - whack-a-mole. It's not like someone can m= ake a simple fix to Linux/MacOSX/Windows and suddenly every application is = IPv6-capable, or implements Happy Eyeballs.= From nobody Wed Jan 14 11:47:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BF91AD186 for ; Wed, 14 Jan 2015 11:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_gdwC4RqMII for ; Wed, 14 Jan 2015 11:47:36 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e: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 C4C251AD160 for ; Wed, 14 Jan 2015 11:47:29 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id kx10so12522646pab.2 for ; Wed, 14 Jan 2015 11:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=22tOI1iHoEGqngvwXZp3+pYq/+ang/GG8DLaKjcWkig=; b=P2fuJK/9f35OqN5OY2qZOY0no4xqsnoPd58bVGt0uJaoTSp4csCwH1R7CB12eQA34C HrUQGW6W4Dk7b1aXRSKCfDsCDr0EHf/m0LbR5xZSfJS380k9sD3wYBCEpCfyP5a9i4WH UUpQxZGs6g86N2PsLXRE0ihA/7gvGl0afab9R55n+tWZ+UT/t3/5Blt/5zI5DQmtaN6j /ypT7cMXKfkKkRlE9m/8bZNv85Ai4Z7R6AGlsmUw2DlwhaENah3FPKc9bB+Ow+eqk0Mh yBsi/C1ewCc3WPnNK45NUOMZ3Ew5WqLQvUSbVNBlaWlaHlPFMeLvfp4Q48OhSmDxghpd PIyQ== X-Received: by 10.68.191.69 with SMTP id gw5mr8135167pbc.75.1421264849017; Wed, 14 Jan 2015 11:47:29 -0800 (PST) Received: from ?IPv6:2406:e007:583e:1:28cc:dc4c:9703:6781? ([2406:e007:583e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qy3sm20402399pbc.4.2015.01.14.11.47.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jan 2015 11:47:27 -0800 (PST) Message-ID: <54B6C7D2.1040408@gmail.com> Date: Thu, 15 Jan 2015 08:47:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Farmer , James Woodyatt , "v6ops@ietf.org WG" References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> <54B5736E.8090308@gmail.com> <54B6C41A.6010203@umn.edu> In-Reply-To: <54B6C41A.6010203@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 19:47:43 -0000 Comment at the end... On 15/01/2015 08:31, David Farmer wrote: > On 1/13/15 13:35 , Brian E Carpenter wrote: >> On 14/01/2015 07:19, James Woodyatt wrote: >>> Everyone=E2=80=94 >>> >>> I would object to the recommendation for a manual configuration optio= n. We >>> are already telling host implementations that enabling and configurin= g 6to4 >>> cannot be automatic. It must be manual. It's redundant and unnecessar= y to >>> say that a separate manual configuration is also necessary for enabli= ng the >>> associated address selection policy. Why would we do that? >>> >>> The draft as currently written seems adequate to me, and I don't see = a >>> burning need to revise it so that RFC 6724 is expressly RECOMMENDED w= ith a >>> keyword. If that recommendation could be added easily and without fu= rther >>> delay, then I would not object to that. >> >> The text already says "The default address selection rules specified i= n [RFC6724] >> are not modified." Since it looks as if the draft needs to be updated = one more >> time, we can update that sentence with a SHOULD easily enough. (RFC 67= 24 is >> already a standard anyway, so strictly speaking this is redundant, but= it won't >> waste much ink.) >> >> Brian >=20 > First, I think any recommendation regarding HE is a dead issue for this= draft. With that out of the way; I think there are > three distinct issues for this draft regarding RFC6724; >=20 > 1. The deprecation of anycast 6to4 doesn't change the IPv6 address sele= ction rules described in RFC6724. If anything it > reinforces the need for the rules as the are in RFC6724. >=20 > 2. A requirement that if any new implementations include anycast 6to4 s= upport, it MUST NOT be enabled by default and MUST > support RFC6724. I suggest the following text in a separate implementa= tion recommendations section; >=20 > Implementations MUST NOT enable the basic unicast 6to4 mechanism > defined in [RFC3056] without explicit user configuration. Further, > it is NOT RECOMMENDED to include the deprecated anycast 6to4 > mechanism defined in [RFC3068] in any new implementations. However,= > if included in any new implementations, the anycast 6to4 mechanism > MUST NOT be enabled by default and the default address selection > rules specified in [RFC6724] MUST be supported. >=20 > 3. Make an operational recommendation that hosts continuing to use the = deprecated anycast mechanism 6to4 SHOULD either support > RFC6724 or be manually configured to prefer IPv4 over a 6to4. >=20 > If we are not going to provide a operational recommendation to filterin= g the anycast 6to4 route, then I think a we should > consider telling people what it takes to use it safely. Which I think = means preferring IPv4 to 6to4 either by using a newer > implementations that support RFC6724 or manually configuring such a rul= e in older implementations if possible. >=20 > I suggest the following text in a separate operational recommendations = section; >=20 > Any host using or continuing to use the deprecated anycast 6to4 > mechanism SHOULD support the default address selection rules > specified in [RFC6724] or be manually configured with an address > selection rule preferring IPv4 over a 6to4 source address. >=20 > I think there is support for the first two points, there may not be sup= port for the third, but I wanted to clarify what I was > suggesting and why before giving up on the issue. There's a section in RFC 6343 called "Vendor Issues" which is specifically addressed to implemementers, including this statement: 4. 6to4 implementations should adopt updated IETF recommendations on address selection [RFC3484-REVISE] So, there is nothing new here. It's a WG choice whether to make this a formal recommendation. We already endorse RFC 6343 as a whole in any case. Brian From nobody Wed Jan 14 11:56:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF621AD35D for ; Wed, 14 Jan 2015 11:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsrOW-vrXOec for ; Wed, 14 Jan 2015 11:56:37 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id A598D1AD160 for ; Wed, 14 Jan 2015 11:56:37 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 14 Jan 2015 13:56:36 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f181.google.com [209.85.223.181] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f181.google.com with SMTP id rl12so10895515iec.12 for ; Wed, 14 Jan 2015 11:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=J80DL7fjpEiYIl2/wC3PyfDbMOqcw5tYMEhF8dpEruM=; b=JWh9ETOHS5HHvAGe4LWyi9KCfLKgsXfRYzVADurDYOK+cfhgsUYuqMXciOUbXUKYzI bNksDXTjiv5Ogb/MbEok9wj1xHvOs/URRuoEcdjboB6+7xd6ceQHYg5HRuUViAP/4571 WcmGNMNiQ+10Le4ZIkTuXyqw6dwYXNI/VmULs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=J80DL7fjpEiYIl2/wC3PyfDbMOqcw5tYMEhF8dpEruM=; b=av0W13DuHRxP8+wxpHHteGiQRcvx/fsiudoNYGxNurzp+tENP4oQFygH9PtPJdEryF 7+CQzDLKTI0cnweqv/ivsdgsa092qLxGsSRl25zWNXKZ60QGpT3Awd9I6+aSH5hTNeyJ 44F467aE8oBR5jdQZKKaio4G+QqiSKbW1oheDvYKprzBF16sSDveua63ANb3LkmD6wqI ySS/aGBGJYCxZWmjkZZP/uhYXq8aQy+Kgs2+DtgiJqcbz8DAsTxC2fOaG8MJtgnKgd2x 1Ej/TY1BS+0rHxKfPr0yOFQ5zYuL4zyPLaMbUGHstINLDW/aVgJIbhdNxi0LpbkdxlgD YHkA== X-Received: by 10.107.38.211 with SMTP id m202mr5041239iom.62.1421263902399; Wed, 14 Jan 2015 11:31:42 -0800 (PST) X-Gm-Message-State: ALoCoQnS5qLVft2y3cWaqNzGg6ObsgyJtq9hc0QqjwzbDUCUWl/gm5CMELVzYECEr4JlVLGsqkx81ZfzbO+IxN3UDOg+KK6jDiKYz0IPG9CNOBhfPuWXBKzRFa4MnDh2jc/2gl2+577V X-Received: by 10.107.38.211 with SMTP id m202mr5041226iom.62.1421263902269; Wed, 14 Jan 2015 11:31:42 -0800 (PST) Received: from x-134-84-88-71.nts.umn.edu ([2607:ea00:101:2001:8c90:42a0:f5ee:e9ea]) by mx.google.com with ESMTPSA id g5sm12523132iod.25.2015.01.14.11.31.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jan 2015 11:31:41 -0800 (PST) Message-ID: <54B6C41A.6010203@umn.edu> Date: Wed, 14 Jan 2015 13:31:38 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian E Carpenter , James Woodyatt , "v6ops@ietf.org WG" References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <17A9A423-F751-40A0-A766-8CAF83A3B553@umn.edu> <54B5736E.8090308@gmail.com> In-Reply-To: <54B5736E.8090308@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 19:56:42 -0000 On 1/13/15 13:35 , Brian E Carpenter wrote: > On 14/01/2015 07:19, James Woodyatt wrote: >> Everyone— >> >> I would object to the recommendation for a manual configuration option. We >> are already telling host implementations that enabling and configuring 6to4 >> cannot be automatic. It must be manual. It's redundant and unnecessary to >> say that a separate manual configuration is also necessary for enabling the >> associated address selection policy. Why would we do that? >> >> The draft as currently written seems adequate to me, and I don't see a >> burning need to revise it so that RFC 6724 is expressly RECOMMENDED with a >> keyword. If that recommendation could be added easily and without further >> delay, then I would not object to that. > > The text already says "The default address selection rules specified in [RFC6724] > are not modified." Since it looks as if the draft needs to be updated one more > time, we can update that sentence with a SHOULD easily enough. (RFC 6724 is > already a standard anyway, so strictly speaking this is redundant, but it won't > waste much ink.) > > Brian First, I think any recommendation regarding HE is a dead issue for this draft. With that out of the way; I think there are three distinct issues for this draft regarding RFC6724; 1. The deprecation of anycast 6to4 doesn't change the IPv6 address selection rules described in RFC6724. If anything it reinforces the need for the rules as the are in RFC6724. 2. A requirement that if any new implementations include anycast 6to4 support, it MUST NOT be enabled by default and MUST support RFC6724. I suggest the following text in a separate implementation recommendations section; Implementations MUST NOT enable the basic unicast 6to4 mechanism defined in [RFC3056] without explicit user configuration. Further, it is NOT RECOMMENDED to include the deprecated anycast 6to4 mechanism defined in [RFC3068] in any new implementations. However, if included in any new implementations, the anycast 6to4 mechanism MUST NOT be enabled by default and the default address selection rules specified in [RFC6724] MUST be supported. 3. Make an operational recommendation that hosts continuing to use the deprecated anycast mechanism 6to4 SHOULD either support RFC6724 or be manually configured to prefer IPv4 over a 6to4. If we are not going to provide a operational recommendation to filtering the anycast 6to4 route, then I think a we should consider telling people what it takes to use it safely. Which I think means preferring IPv4 to 6to4 either by using a newer implementations that support RFC6724 or manually configuring such a rule in older implementations if possible. I suggest the following text in a separate operational recommendations section; Any host using or continuing to use the deprecated anycast 6to4 mechanism SHOULD support the default address selection rules specified in [RFC6724] or be manually configured with an address selection rule preferring IPv4 over a 6to4 source address. I think there is support for the first two points, there may not be support for the third, but I wanted to clarify what I was suggesting and why before giving up on the issue. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Jan 14 15:49:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559A51AD0AB for ; Wed, 14 Jan 2015 15:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaIrj-zwXTEZ for ; Wed, 14 Jan 2015 15:49:32 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77AB1AD0A2 for ; Wed, 14 Jan 2015 15:49:31 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id AC6DB1FCC3E; Wed, 14 Jan 2015 23:49:27 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E94AA160064; Wed, 14 Jan 2015 23:55:59 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id A9F4A160057; Wed, 14 Jan 2015 23:55:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D994B2762EA8; Thu, 15 Jan 2015 10:49:26 +1100 (EST) To: "Fred Baker (fred)" From: Mark Andrews References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> In-reply-to: Your message of "Wed, 14 Jan 2015 16:02:26 -0000." <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> Date: Thu, 15 Jan 2015 10:49:26 +1100 Message-Id: <20150114234926.D994B2762EA8@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 23:49:34 -0000 In message <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com>, "Fred Baker (fred) " writes: > > > On Jan 14, 2015, at 7:36 AM, Keith Moore wrote > : > > > > On 01/10/2015 08:09 PM, Brian E Carpenter wrote: > >>> > All hosts using 6to4 SHOULD support the IPv6 address selection > >>> > policy described in [RFC6724] or be manually configured with an > >>> > address selection policy preferring IPv4 over a 6to4 source > >>> > address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > >>> > [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > >>> > not meeting these requirements SHOULD NOT use, or continue to use, > >>> > the deprecated anycast 6to4 mechanism. > >> I agree with the sentiments. But I'd like to hear a positive echo from > >> the WG, because this seems like a substantive addition. > > > > I think this goes too far. Happy Eyeballs is of very limited applicabilit > y; and there's way too much assumption here that using a web browser is the p > urpose of using IPv6 or maybe even the Internet. > > > > IMHO, HE is stated in terms of a simple use case (a client web browser, and t > he issue is selecting among a set of two addresses, IPv4 and IPv6), but embod > ies a more general principle. The principle is that if a host is multihomed ( > as in, has more than one address, dual stack being but one example of that), > the addresses each represent a path, and paths may have different characteris > tics in terms of whether they work at all, end to end delay, loss, yada yada > yada. If both ends are multihomed, it gets more complex. > > The principle is "if one choice isn't giving you the results you want, try a > different one, in a timely fashion." > > My only problem with making a recommendation about "the host" in this context > is that "the host" is properly its OS, and due to the stupidity of the socke > t API design, this is relegated to the application. So we have to change each > application individually - whack-a-mole. It's not like someone can make a si > mple fix to Linux/MacOSX/Windows and suddenly every application is IPv6-capab > le, or implements Happy Eyeballs. But 90+% of applications just need to follow a simple framework. Simple examples are here and just take the output of getaddrinfo: http://users.isc.org/~marka/poll-connect.c http://users.isc.org/~marka/select-connect.c http://users.isc.org/~marka/thread-connect.c These leave the source address selection to the stack which has access to the routing. It could try multiple source addresses for the given destination address in preference order. Mark > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jan 14 16:09:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0431B2A70 for ; Wed, 14 Jan 2015 16:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTj1PAIykxOH for ; Wed, 14 Jan 2015 16:09:16 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322031B2A72 for ; Wed, 14 Jan 2015 16:09:16 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so13781840pad.1 for ; Wed, 14 Jan 2015 16:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=877RI1a0BHb6BdCs620DNLOJfP+ZYZmvy9OVH9nvRJM=; b=0TO8L6lj7rt/HC0RiM9ntmRbgB5GtMpLIN5iJflznU6ud3Iz8Y0MjbNJrNKzrRLxbT +ZnjePV3cOWcvh8RPkw4pO++SVR/1lBXJSoJRmDbosoN/8UZf4w5caIQNWESgw+aJ5B0 AHgZK4wlgg3dyoWn9JwJb0d4k3irUdxiNzWg9BVBkMyT5wqTqPYQTBjT8C1qeZBjLdxn yVD0r6kS0N2uteRZ8gqyUKyKFWuuJGa1iF/Kbhg8Dg5K+nusxtm1fXRhYy9hcgsHywt0 ZaRgwurprNDg0NAjDTYXg7WMs8chPWDWxWti+eZs2BOfgsGvnPRJgcfJqMXIdBurZlse AkOQ== X-Received: by 10.68.203.195 with SMTP id ks3mr9893707pbc.104.1421280555446; Wed, 14 Jan 2015 16:09:15 -0800 (PST) Received: from ?IPv6:2406:e007:583e:1:28cc:dc4c:9703:6781? ([2406:e007:583e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ts5sm20667327pbc.88.2015.01.14.16.09.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jan 2015 16:09:14 -0800 (PST) Message-ID: <54B7052E.10602@gmail.com> Date: Thu, 15 Jan 2015 13:09:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark Andrews , "Fred Baker (fred)" References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> <20150114234926.D994B2762EA8@rock.dv.isc.org> In-Reply-To: <20150114234926.D994B2762EA8@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Keith Moore Subject: [v6ops] source address selection [was I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 00:09:21 -0000 On 15/01/2015 12:49, Mark Andrews wrote: > > In message <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com>, "Fred Baker (fred) > " writes: >> >>> On Jan 14, 2015, at 7:36 AM, Keith Moore wrote >> : >>> >>> On 01/10/2015 08:09 PM, Brian E Carpenter wrote: >>>>>> All hosts using 6to4 SHOULD support the IPv6 address selection >>>>>> policy described in [RFC6724] or be manually configured with an >>>>>> address selection policy preferring IPv4 over a 6to4 source >>>>>> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" >>>>>> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts >>>>>> not meeting these requirements SHOULD NOT use, or continue to use, >>>>>> the deprecated anycast 6to4 mechanism. >>>> I agree with the sentiments. But I'd like to hear a positive echo from >>>> the WG, because this seems like a substantive addition. >>> >>> I think this goes too far. Happy Eyeballs is of very limited applicabilit >> y; and there's way too much assumption here that using a web browser is the p >> urpose of using IPv6 or maybe even the Internet. >> >> >> >> IMHO, HE is stated in terms of a simple use case (a client web browser, and t >> he issue is selecting among a set of two addresses, IPv4 and IPv6), but embod >> ies a more general principle. The principle is that if a host is multihomed ( >> as in, has more than one address, dual stack being but one example of that), >> the addresses each represent a path, and paths may have different characteris >> tics in terms of whether they work at all, end to end delay, loss, yada yada >> yada. If both ends are multihomed, it gets more complex. >> >> The principle is "if one choice isn't giving you the results you want, try a >> different one, in a timely fashion." >> >> My only problem with making a recommendation about "the host" in this context >> is that "the host" is properly its OS, and due to the stupidity of the socke >> t API design, this is relegated to the application. So we have to change each >> application individually - whack-a-mole. It's not like someone can make a si >> mple fix to Linux/MacOSX/Windows and suddenly every application is IPv6-capab >> le, or implements Happy Eyeballs. > > But 90+% of applications just need to follow a simple framework. > > Simple examples are here and just take the output of getaddrinfo: > > http://users.isc.org/~marka/poll-connect.c > http://users.isc.org/~marka/select-connect.c > http://users.isc.org/~marka/thread-connect.c > > These leave the source address selection to the stack which has > access to the routing. It could try multiple source addresses for > the given destination address in preference order. There is no preference order in the general case. In terms of best user experience, trying everything in parallel is more desirable, even though HE is apparently not the best way of doing that. I look forward to a draft that describes experience and measurements with HE... Brian From nobody Wed Jan 14 17:10:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD8F1B2A8B for ; Wed, 14 Jan 2015 17:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qAXthCDhwl6 for ; Wed, 14 Jan 2015 17:10:34 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF031B2A88 for ; Wed, 14 Jan 2015 17:10:34 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 4FAA71FCACE; Thu, 15 Jan 2015 01:10:30 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 99B11160064; Thu, 15 Jan 2015 01:17:02 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 33C2D160057; Thu, 15 Jan 2015 01:17:02 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 326EE2764228; Thu, 15 Jan 2015 12:10:29 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> <20150114234926.D994B2762EA8@rock.dv.isc.org> <54B7052E.10602@gmail.com> In-reply-to: Your message of "Thu, 15 Jan 2015 13:09:18 +1300." <54B7052E.10602@gmail.com> Date: Thu, 15 Jan 2015 12:10:29 +1100 Message-Id: <20150115011029.326EE2764228@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] source address selection [was I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 01:10:41 -0000 In message <54B7052E.10602@gmail.com>, Brian E Carpenter writes: > On 15/01/2015 12:49, Mark Andrews wrote: > > > > In message <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com>, "Fred Baker (f > red) > > " writes: > >> > >>> On Jan 14, 2015, at 7:36 AM, Keith Moore wro > te > >> : > >>> > >>> On 01/10/2015 08:09 PM, Brian E Carpenter wrote: > >>>>>> All hosts using 6to4 SHOULD support the IPv6 address selection > >>>>>> policy described in [RFC6724] or be manually configured with an > >>>>>> address selection policy preferring IPv4 over a 6to4 source > >>>>>> address. Further, 6to4 hosts SHOULD support "Happy Eyeballs" > >>>>>> [RFC6555] or use a browser supporting "Happy Eyeballs". Any hosts > >>>>>> not meeting these requirements SHOULD NOT use, or continue to use, > >>>>>> the deprecated anycast 6to4 mechanism. > >>>> I agree with the sentiments. But I'd like to hear a positive echo from > >>>> the WG, because this seems like a substantive addition. > >>> > >>> I think this goes too far. Happy Eyeballs is of very limited applicabil > it > >> y; and there's way too much assumption here that using a web browser is th > e p > >> urpose of using IPv6 or maybe even the Internet. > >> > >> > >> > >> IMHO, HE is stated in terms of a simple use case (a client web browser, an > d t > >> he issue is selecting among a set of two addresses, IPv4 and IPv6), but em > bod > >> ies a more general principle. The principle is that if a host is multihome > d ( > >> as in, has more than one address, dual stack being but one example of that > ), > >> the addresses each represent a path, and paths may have different characte > ris > >> tics in terms of whether they work at all, end to end delay, loss, yada ya > da > >> yada. If both ends are multihomed, it gets more complex. > >> > >> The principle is "if one choice isn't giving you the results you want, try > a > >> different one, in a timely fashion." > >> > >> My only problem with making a recommendation about "the host" in this cont > ext > >> is that "the host" is properly its OS, and due to the stupidity of the so > cke > >> t API design, this is relegated to the application. So we have to change e > ach > >> application individually - whack-a-mole. It's not like someone can make a > si > >> mple fix to Linux/MacOSX/Windows and suddenly every application is IPv6-ca > pab > >> le, or implements Happy Eyeballs. > > > > But 90+% of applications just need to follow a simple framework. > > > > Simple examples are here and just take the output of getaddrinfo: > > > > http://users.isc.org/~marka/poll-connect.c > > http://users.isc.org/~marka/select-connect.c > > http://users.isc.org/~marka/thread-connect.c > > > > These leave the source address selection to the stack which has > > access to the routing. It could try multiple source addresses for > > the given destination address in preference order. > > There is no preference order in the general case. In terms of > best user experience, trying everything in parallel is more > desirable, even though HE is apparently not the best way of > doing that. I look forward to a draft that describes experience > and measurements with HE... We have address selection rules which give us the remote addresses in preference order. For each of those addresses we do have selection rules for the source address to use. i.e. if the remote has a local ULA address (one of our /48's) that sorts to the top. When we attempt to connect to that address the source address rules puts our addresses in that /48 as higher preference source addresses. We currently only use the highest preference address. Extending getaddrinfo to return both source / destination pairs would be one way to address this. Yes, getaddrinfo was designed to be extended so this should be possible. Mark > Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jan 15 10:04:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401B71B2E3A for ; Thu, 15 Jan 2015 10:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vlu0z67iXv4 for ; Thu, 15 Jan 2015 10:04:29 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470171B2E37 for ; Thu, 15 Jan 2015 10:04:06 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CC31420892 for ; Thu, 15 Jan 2015 13:04:04 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 15 Jan 2015 13:04:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Y97S3ByX+qNZ7e2jwo/NUM yxQOI=; b=GLJSYWEZycdYQUU+BMBVuuc9S6/zVw3koN8KQJnBrIBEj5IZ7IwbgT 7MTHxf+md06/u+FcxdV4lx/Z4opo+wHs1mW2KzHSY+klaQTFTqMTinXGc/Vce23n c753r3yfNRgwxQ1Pb2rU91mM97NBfaHxERGfVtOtPTZA0cJCH3iVo= X-Sasl-enc: 0A5w8S4x6bEz8MadE21UcRVDmz1ubGzxC0cZWPbBik/p 1421345044 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 5FB18C00018; Thu, 15 Jan 2015 13:04:04 -0500 (EST) Message-ID: <54B800FF.6050505@network-heretics.com> Date: Thu, 15 Jan 2015 13:03:43 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> <20150114234926.D994B2762EA8@rock.dv.isc.org> <54B7052E.10602@gmail.com> <20150115011029.326EE2764228@rock.dv.isc.org> In-Reply-To: <20150115011029.326EE2764228@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] source address selection [was I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:04:31 -0000 On 01/14/2015 08:10 PM, Mark Andrews wrote: > We have address selection rules which give us the remote addresses > in preference order. For each of those addresses we do have selection > rules for the source address to use. > > i.e. if the remote has a local ULA address (one of our /48's) that > sorts to the top. I'm not sure who you mean when you say "we", but I'll point out that any assumptions made about preference of ULAs in general is pretty dubious. > Extending getaddrinfo to return both source / destination pairs > would be one way to address this. Yes, getaddrinfo was designed > to be extended so this should be possible. getaddrinfo() is a hideous mess. I've seen so many bogus things done by getaddrinfo implementations (including doing SRV lookup, LLMNR lookup, and consulting other sources of non-DNS information), that coupled with the lack of an asych lookup capability, I'm strongly of the opinion that it should be deprecated. I didn't think it was possible to do worse than gethostname(), but I was proven wrong. Keith. From nobody Thu Jan 15 10:37:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF5F1B3025 for ; Thu, 15 Jan 2015 10:37:32 -0800 (PST) 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 17o-SN4ZzsuJ for ; Thu, 15 Jan 2015 10:37:26 -0800 (PST) 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 8509E1B3028 for ; Thu, 15 Jan 2015 10:37:24 -0800 (PST) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YBpIA-00033N-P7; Thu, 15 Jan 2015 19:37:15 +0100 Message-ID: <54B808CF.4060304@si6networks.com> Date: Thu, 15 Jan 2015 15:37:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Keith Moore References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> In-Reply-To: <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: [v6ops] Src/Dst address selection (was: Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:37:33 -0000 On 01/14/2015 01:02 PM, Fred Baker (fred) wrote: > > IMHO, HE is stated in terms of a simple use case (a client web > browser, and the issue is selecting among a set of two addresses, > IPv4 and IPv6), but embodies a more general principle. The principle > is that if a host is multihomed (as in, has more than one address, > dual stack being but one example of that), the addresses each > represent a path, and paths may have different characteristics in > terms of whether they work at all, end to end delay, loss, yada yada > yada. If both ends are multihomed, it gets more complex. > > The principle is "if one choice isn't giving you the results you > want, try a different one, in a timely fashion." Fully agreed. While HE was triggered by IPv6-related stuff, reality is that work in this area was already needed. > My only problem with making a recommendation about "the host" in this > context is that "the host" is properly its OS, and due to the > stupidity of the socket API design, this is relegated to the > application. So we have to change each application individually - > whack-a-mole. It's not like someone can make a simple fix to > Linux/MacOSX/Windows and suddenly every application is IPv6-capable, > or implements Happy Eyeballs. Maybe this is an indication that it's time to do the right thing and produce a higher level give_me_a_bloody_connection_to_this_service() sort of thing? (I personally don't buy the "we don't specify APIs". Firstly, because we've done so. Secondly, because if we don't, we pay the price). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 15 10:54:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC8B1B2FF6 for ; Thu, 15 Jan 2015 10:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa9F3r7a7cvr for ; Thu, 15 Jan 2015 10:54:54 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5622B1B2F88 for ; Thu, 15 Jan 2015 10:54:54 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B51C020396 for ; Thu, 15 Jan 2015 13:54:53 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 15 Jan 2015 13:54:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id :cc:from:subject:date:to; s=smtpout; bh=uEcDRVPud6IwKs4gFxL5v4MT D70=; b=ZHekTcaaAv1ifQDAxfGCvzTb0jsmGI4o76CDPI59V+LHjNZz9JC4dYVN sE+Pt8CennGp3ELP2Nfbpqjb70tt6hlutRpcKdt04NqhFio6mFTQ85HxgHBAm7UG T4KBwGTao1AJ9zJt+vFRqSSMRDGBhtHOhqJPGlg1I1tVr5Z0br8= X-Sasl-enc: p+6BedvFr5Tf736G0Ukk9EtZyMOjlqcoIX/KfNbktwtP 1421348093 Received: from [21.83.77.201] (unknown [66.87.109.201]) by mail.messagingengine.com (Postfix) with ESMTPA id 303FEC00012; Thu, 15 Jan 2015 13:54:53 -0500 (EST) References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> <54B808CF.4060304@si6networks.com> In-Reply-To: <54B808CF.4060304@si6networks.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (12B435) From: Keith Moore Date: Thu, 15 Jan 2015 13:54:50 -0500 To: Fernando Gont Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Src/Dst address selection (was: Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:54:56 -0000 If only the Internet architecture provided us with reliable host or service n= ames. Sadly, it doesn't. IP addresses are the best we have. Sent from my iPhone > On Jan 15, 2015, at 1:37 PM, Fernando Gont wrote: >=20 >> On 01/14/2015 01:02 PM, Fred Baker (fred) wrote: >>=20 >> IMHO, HE is stated in terms of a simple use case (a client web >> browser, and the issue is selecting among a set of two addresses, >> IPv4 and IPv6), but embodies a more general principle. The principle >> is that if a host is multihomed (as in, has more than one address, >> dual stack being but one example of that), the addresses each >> represent a path, and paths may have different characteristics in >> terms of whether they work at all, end to end delay, loss, yada yada >> yada. If both ends are multihomed, it gets more complex. >>=20 >> The principle is "if one choice isn't giving you the results you >> want, try a different one, in a timely fashion." >=20 > Fully agreed. While HE was triggered by IPv6-related stuff, reality is > that work in this area was already needed. >=20 >=20 >> My only problem with making a recommendation about "the host" in this >> context is that "the host" is properly its OS, and due to the >> stupidity of the socket API design, this is relegated to the >> application. So we have to change each application individually - >> whack-a-mole. It's not like someone can make a simple fix to >> Linux/MacOSX/Windows and suddenly every application is IPv6-capable, >> or implements Happy Eyeballs.=20 >=20 > Maybe this is an indication that it's time to do the right thing and > produce a higher level give_me_a_bloody_connection_to_this_service() > sort of thing? (I personally don't buy the "we don't specify APIs". > Firstly, because we've done so. Secondly, because if we don't, we pay > the price). >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Thu Jan 15 11:07:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF73F1B30DC for ; Thu, 15 Jan 2015 11:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spNsl_lXFELD for ; Thu, 15 Jan 2015 11:07:08 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807831B30DA for ; Thu, 15 Jan 2015 11:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3319; q=dns/txt; s=iport; t=1421348828; x=1422558428; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h9QaYHkcTIbnNQ7Mc3bwY4ohk6hFmvlSio5VpVuPI/A=; b=T4yVCYZGjGhTMgaId7xD1CjwTIrtcR8JyojW2s8+EnPM9bTbvoXVSh09 pkf4xUVlksOV6+3V1heUH7Glu/bIkeZ2A51VFUoU2ft4c9BgcNV2WyfUw 0S8+kpw5xYirV73heEeANgb7qRYErd6dQohvOh7DJSoGR5JXluLvi8cjy s=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAC4PuFStJV2Y/2dsb2JhbABagwaBKgTMBgKBFUMBAQEBAX2EDAEBBAF5BQsCAQgSBiMLMhcBDQIEAQ0FDogWCNImAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4oPhWoHgxaBEwWOTIFPgSmGF5IKIoIygTxvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,404,1418083200"; d="asc'?scan'208";a="113644791" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 15 Jan 2015 19:07:07 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0FJ77EK002140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Jan 2015 19:07:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 13:07:07 -0600 From: "Fred Baker (fred)" To: Keith Moore , Fernando Gont Thread-Topic: Src/Dst address selection (was: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt) Thread-Index: AQHQMPZ0hcB49ZN65EW2fkBjejUjvQ== Date: Thu, 15 Jan 2015 19:07:07 +0000 Message-ID: References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <54B1CD5C.3090107@gmail.com> <54B68CEA.9090606@network-heretics.com> <340E935D-AF9D-40F5-8B88-44E095ED11C1@cisco.com> <54B808CF.4060304@si6networks.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.155.28.207] Content-Type: multipart/signed; boundary="Apple-Mail=_A4904D74-D12C-47C5-AF8D-6A28E1F02885"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Src/Dst address selection (was: Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:07:11 -0000 --Apple-Mail=_A4904D74-D12C-47C5-AF8D-6A28E1F02885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, guys, for changing the subject line. I think this is getting = pretty far afield from the 6to4 question... > On Jan 15, 2015, at 10:54 AM, Keith Moore = wrote: >=20 > If only the Internet architecture provided us with reliable host or = service names. Sadly, it doesn't. IP addresses are the best we have. >=20 > Sent from my iPhone >=20 >> On Jan 15, 2015, at 1:37 PM, Fernando Gont = wrote: >>=20 >>> On 01/14/2015 01:02 PM, Fred Baker (fred) wrote: >>>=20 >>> IMHO, HE is stated in terms of a simple use case (a client web >>> browser, and the issue is selecting among a set of two addresses, >>> IPv4 and IPv6), but embodies a more general principle. The principle >>> is that if a host is multihomed (as in, has more than one address, >>> dual stack being but one example of that), the addresses each >>> represent a path, and paths may have different characteristics in >>> terms of whether they work at all, end to end delay, loss, yada yada >>> yada. If both ends are multihomed, it gets more complex. >>>=20 >>> The principle is "if one choice isn't giving you the results you >>> want, try a different one, in a timely fashion." >>=20 >> Fully agreed. While HE was triggered by IPv6-related stuff, reality = is >> that work in this area was already needed. >>=20 >>=20 >>> My only problem with making a recommendation about "the host" in = this >>> context is that "the host" is properly its OS, and due to the >>> stupidity of the socket API design, this is relegated to the >>> application. So we have to change each application individually - >>> whack-a-mole. It's not like someone can make a simple fix to >>> Linux/MacOSX/Windows and suddenly every application is IPv6-capable, >>> or implements Happy Eyeballs. >>=20 >> Maybe this is an indication that it's time to do the right thing and >> produce a higher level give_me_a_bloody_connection_to_this_service() >> sort of thing? (I personally don't buy the "we don't specify APIs". >> Firstly, because we've done so. Secondly, because if we don't, we pay >> the price). >>=20 >> Thanks, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>=20 >>=20 >>=20 >>=20 --Apple-Mail=_A4904D74-D12C-47C5-AF8D-6A28E1F02885 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 iQEVAwUBVLgP2p9ieig10VPpAQKu8Af/faTBkFf4/lYKx1YEaFQ9vK+qviCCxCkG HjmJPQP0jyQWOa0cqMXlmH/eLwMCFTmzTV3kVobbmsHJzfAcJdj6CcpmPe6MlJH6 Y0n7gjLDxOfu+8Mw66mut2fOf4mY/tuXCPWyBuo2Yk12flAMTwKcsgS0zn39F+q3 zqsVlZAhHMLIQU73DguZKxVZE9H4b9AK2BHWZ5arQkL5QGGFdkgiBJ9c7vvGPOxi oOVAbUVZu69WxUGLunk9sL+XwuXOwDgkxT7NZRBorWnw4d6Lv1ixxqNwRXLxoS5R oGVy0AoSyz2ZGpjvBU2tgyC9ttbq8/ILvxbtfZjdWdqeNoanu3Eg1w== =bkUQ -----END PGP SIGNATURE----- --Apple-Mail=_A4904D74-D12C-47C5-AF8D-6A28E1F02885-- From nobody Thu Jan 15 23:25:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977E31ABD3E for ; Thu, 15 Jan 2015 23:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjCUVLOHCeLA for ; Thu, 15 Jan 2015 23:24:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9291A8878 for ; Thu, 15 Jan 2015 23:24:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YC1H7-00082s-Rc; Fri, 16 Jan 2015 07:24:58 +0000 Date: Fri, 16 Jan 2015 16:24:56 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 07:25:00 -0000 > I agree with Lorenzo. I believe based on the measurement stuff we do, > that HE has not got a net-positive effect, and was in hindsight not a > good idea. and why are we discussing a list of hack to make 6to4 'better' when the intent is supposed to be just turning this broken dren off? randy From nobody Fri Jan 16 07:55:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10801ACE48 for ; Fri, 16 Jan 2015 07:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaEg7O3Y2yQ1 for ; Fri, 16 Jan 2015 07:55:50 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 153CF1ACE55 for ; Fri, 16 Jan 2015 07:55:36 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 16 Jan 2015 09:55:35 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f172.google.com [209.85.223.172] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f172.google.com with SMTP id tr6so21314217ieb.3 for ; Fri, 16 Jan 2015 07:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=zt1VhebWz6Rm7s6NVwFK4RgDm/I0mvdZ6PvClOlHWs0=; b=bO4Bc39oQTML0O8sLEZwxvTa8UQg05eT8J88XCYhD1bQACN8MoNArSrO1B/WO83gVh xivSQ+i6AQkm3HACQEF8ZZw57lNhw20S9ovcYlFlguPdZo/vEd7zJv4KoNaLTRhIKfn8 2oiixBBiKggmr9oDZEgBobhiJr/0SpfxUDWXI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=zt1VhebWz6Rm7s6NVwFK4RgDm/I0mvdZ6PvClOlHWs0=; b=UeuZTlHOcjVaHG64UCzto8ZvnOk4ccHDsOQ9u5/oDPUgwTGsuIIagWMYfQ8kGerBdN mwbvgNJ4pPIUgCQuaLtAvs6RMRRzSyRWYzJ/sn4rmU8+aAOLAgV4R1sP1FR9/YD592tu BXPYJpyeJuuuBxKjUz8Pab2tAulmCX35DyVcl9hSeBovbzCiJ0P+QPPwlndekh6uW8La 3bbmVrymRCnL29gzw9p77IKheeRw29bjBpUS7ApHrNbD0M5U3GI4eGT39ga6MIyw9vYP qTziS1flsRe6QRe12bta4zFyJF3p62hQ0RFpfjZRvBqmUUbRT9U0RLgqvEE8HW1QaUn4 h61A== X-Gm-Message-State: ALoCoQnSzS0igw0sufmRu7U0JBL1Pk/Oql+p5qamOcAj9ZO/wtLHRKgTE4e3jhLWRor+3XR74kcvlOPFk1nAjSfJitx7oMV4Y9h7D9pRlU1sNIPuxkQTZK5wAnjFVKAipZgNcKzPbn9A X-Received: by 10.50.254.99 with SMTP id ah3mr4307559igd.12.1421423734543; Fri, 16 Jan 2015 07:55:34 -0800 (PST) X-Received: by 10.50.254.99 with SMTP id ah3mr4307533igd.12.1421423734313; Fri, 16 Jan 2015 07:55:34 -0800 (PST) Received: from ?IPv6:2601:2:5b00:a9f:e45e:fbba:4a25:65be? ([2601:2:5b00:a9f:e45e:fbba:4a25:65be]) by mx.google.com with ESMTPSA id fr4sm1603719igd.4.2015.01.16.07.55.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 07:55:32 -0800 (PST) References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <36106BF2-8C81-4129-971F-71BB167EC62C@umn.edu> X-Mailer: iPad Mail (12B440) From: David Farmer Date: Fri, 16 Jan 2015 09:55:32 -0600 To: Randy Bush Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 15:55:51 -0000 On Jan 16, 2015, at 01:24, Randy Bush wrote: >> I agree with Lorenzo. I believe based on the measurement stuff we do, >> that HE has not got a net-positive effect, and was in hindsight not a >> good idea. >=20 > and why are we discussing a list of hack to make 6to4 'better' when the > intent is supposed to be just turning this broken dren off? >=20 > randy Because we are not turning off 6to4, we're not even turning off anycast 6to4= , we are beginning a long slow, probably painful, deprecation process and wi= ll have to live with 6to4 and even anycast 6to4 for a long time. This is th= e affect of removing the idea of any filtering of 192.88.99.1.=20 We don't seem to have consensus for anything resembling turning off anycast 6= to4, which in my opinion would at least include a "networks MAY filter 192.8= 8.99.1". From nobody Fri Jan 16 08:41:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520C01ACED4 for ; Fri, 16 Jan 2015 08:41:20 -0800 (PST) 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_20=-0.001, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf_cb1pjJkdY for ; Fri, 16 Jan 2015 08:41:19 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 73ED11ACEC4 for ; Fri, 16 Jan 2015 08:41:18 -0800 (PST) Received: from [IPv6:2620::930:0:e6ce:8fff:fe5e:af29] ([IPv6:2620:0:930:0:e6ce:8fff:fe5e:af29]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t0GGbYtM020930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jan 2015 08:37:34 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t0GGbYtM020930 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1421426254; bh=EGWLLuKzkIuDFhKMk+qWf7uiqJo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=RhykxxUa0rsKYAm5gtVVd6pfKPn4akBwQM5ZYaM1DgLRjwnxAl741/a2AZBDvrIWX sMuYEE3XLOHu3Kar8jFxCbEM863dyvBXouutgrDg2DLkUUx/Z8OTNY2gi24uQN8WuO 78LWM8TIAePF6IEIUnP9U7bR9gKgHsifLsSZTXeM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Owen DeLong In-Reply-To: <36106BF2-8C81-4129-971F-71BB167EC62C@umn.edu> Date: Fri, 16 Jan 2015 08:37:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <36106BF2-8C81-4129-971F-71BB167EC62C@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1993) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 16 Jan 2015 08:37:34 -0800 (PST) Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:41:20 -0000 > On Jan 16, 2015, at 07:55 , David Farmer wrote: >=20 >=20 > On Jan 16, 2015, at 01:24, Randy Bush wrote: >=20 >>> I agree with Lorenzo. I believe based on the measurement stuff we = do, >>> that HE has not got a net-positive effect, and was in hindsight not = a >>> good idea. >>=20 >> and why are we discussing a list of hack to make 6to4 'better' when = the >> intent is supposed to be just turning this broken dren off? >>=20 >> randy >=20 > Because we are not turning off 6to4, we're not even turning off = anycast 6to4, we are beginning a long slow, probably painful, = deprecation process and will have to live with 6to4 and even anycast = 6to4 for a long time. This is the affect of removing the idea of any = filtering of 192.88.99.1.=20 >=20 > We don't seem to have consensus for anything resembling turning off = anycast 6to4, which in my opinion would at least include a "networks MAY = filter 192.88.99.1=E2=80=9D. If the we honestly believe that a statement one way or the other from = the IETF about whether a network can filter 192.88.99.1 will have any = real world impact, then I believe we are delusional. People who want to kill anycast 6to4 will filter 192.88.99.1 regardless = of any advice from IETF. People who want to save anycast 6to4 (if there are any such people) for = whatever reason will rail against such filters. IETF advice in this regard is likely to be even less well implemented = than BCP-38. As such, I would suggest we focus on the areas where we can provide = effective and useful advice and not waste document space tilting at = windmills. Owen From nobody Fri Jan 16 11:24:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69BC1B2A9E for ; Fri, 16 Jan 2015 11:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz1nuxjCVoLq for ; Fri, 16 Jan 2015 11:24:44 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA4D1B2A97 for ; Fri, 16 Jan 2015 11:24:44 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so26009706pab.6 for ; Fri, 16 Jan 2015 11:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t49lqC6zb0RZyybkMJ2evL6ypJPe+cMuBcUMN0dw2Rc=; b=HAWKeY8Ul9wUuuwTlqhaQl9+ovoXfvI9tDIyWrQ1UKJN5Mj6rH0af5jmst9xI1iAO5 8JhZg52CctQDLvhZbOXf3aehmGFWd5GODs4UCvs5b6+Bel9q/f9F2AvYPPkm/3m1+ZKJ VQ6iKsb4eayMEGlEV8enX2iQghJK74mI0UramICRVvPLioYqZ+KBI2yDimW+pyZ7/cKq Re7GzCXRs9UkvFv6pFscoyGlsPWF2xhbEVY8MHow/1jNNhhyhDhh0hf1AsG7bBi6gv5i c0sVIC9Dr1F7ODO6gZp5muJiya4TqFHeNnuzRgEGMskW9cPgoN5x8VmsHZR/eHDJvX5Z nfzw== X-Received: by 10.68.203.195 with SMTP id ks3mr25303060pbc.104.1421436283573; Fri, 16 Jan 2015 11:24:43 -0800 (PST) Received: from ?IPv6:2406:e007:7bed:1:28cc:dc4c:9703:6781? ([2406:e007:7bed:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id gx1sm4765101pbd.57.2015.01.16.11.24.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jan 2015 11:24:42 -0800 (PST) Message-ID: <54B96582.4090802@gmail.com> Date: Sat, 17 Jan 2015 08:24:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Owen DeLong , David Farmer References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <36106BF2-8C81-4129-971F-71BB167EC62C@umn.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 19:24:45 -0000 On 17/01/2015 05:37, Owen DeLong wrote: >=20 >> On Jan 16, 2015, at 07:55 , David Farmer wrote: >> >> >> On Jan 16, 2015, at 01:24, Randy Bush wrote: >> >>>> I agree with Lorenzo. I believe based on the measurement stuff we do= , >>>> that HE has not got a net-positive effect, and was in hindsight not = a >>>> good idea. >>> >>> and why are we discussing a list of hack to make 6to4 'better' when t= he >>> intent is supposed to be just turning this broken dren off? >>> >>> randy >> >> Because we are not turning off 6to4, we're not even turning off anycas= t 6to4, we are beginning a long slow, probably painful, deprecation proce= ss and will have to live with 6to4 and even anycast 6to4 for a long time.= This is the affect of removing the idea of any filtering of 192.88.99.1= =2E=20 >> >> We don't seem to have consensus for anything resembling turning off an= ycast 6to4, which in my opinion would at least include a "networks MAY fi= lter 192.88.99.1=E2=80=9D. >=20 > If the we honestly believe that a statement one way or the other from t= he IETF about whether a network can filter 192.88.99.1 will have any real= world impact, then I believe we are delusional. >=20 > People who want to kill anycast 6to4 will filter 192.88.99.1 regardless= of any advice from IETF. >=20 > People who want to save anycast 6to4 (if there are any such people) for= whatever reason will rail against such filters. >=20 > IETF advice in this regard is likely to be even less well implemented t= han BCP-38. >=20 > As such, I would suggest we focus on the areas where we can provide eff= ective and useful advice and not waste document space tilting at windmill= s. Document editor hat off: +1 Document editor hat on: I will be out for the next week or so. After that= I will edit in the comments from David that appear to be non-controversia= l, and hopefully that will be the final draft that Fred can ship to the AD. Brian From nobody Fri Jan 16 12:24:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7597C1B2B6F for ; Fri, 16 Jan 2015 12:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoutEz-XQ0Bx for ; Fri, 16 Jan 2015 12:24:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367A31B2B1D for ; Fri, 16 Jan 2015 12:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1306; q=dns/txt; s=iport; t=1421439842; x=1422649442; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DYoi+OKg/5hKfkobxWuMlp2/Y7w0bP596NL4mlNa0YQ=; b=jf+hXNBErDp08lH5T+1iP99QwFhBggGGZsYeP5J7Nw8AQhWvSJiCm6rl gzb7hARyipZWOIN1/2aqj49ciygWxp1iSqNjLeNEYimQhQWikUQyQ+Myk tMkpHW2MCcXOC9THMQnWUrok89vKtOG7gAIvguCkt4DSkxPxT2+TBWXZv k=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABxzuVStJV2Y/2dsb2JhbABagwaBKgTMGwKBE0MBAQEBAX2EDAEBAQMBeQULAgEIGC4hESUCBA4FDogKAwkIzjsNhBEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjU+CKgeDFoETBY5MgU+BKYRTgUSMH4VrIoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,412,1418083200"; d="asc'?scan'208";a="384537596" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 16 Jan 2015 20:23:55 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0GKNr1H028534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Jan 2015 20:23:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 16 Jan 2015 14:23:53 -0600 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt Thread-Index: AQHQMcpYETifn08y/USgsIlTfqFmRg== Date: Fri, 16 Jan 2015 20:23:52 +0000 Message-ID: <417DB811-8912-4178-8E98-42E5189C5E51@cisco.com> References: <20150104190416.29186.39009.idtracker@ietfa.amsl.com> <54A99025.4040506@gmail.com> <54B04BC8.1020902@umn.edu> <36106BF2-8C81-4129-971F-71BB167EC62C@umn.edu> <54B96582.4090802@gmail.com> In-Reply-To: <54B96582.4090802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.155.144.165] Content-Type: multipart/signed; boundary="Apple-Mail=_F81A981C-D108-4544-8591-BC3E422AB04E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 20:24:02 -0000 --Apple-Mail=_F81A981C-D108-4544-8591-BC3E422AB04E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 16, 2015, at 11:24 AM, Brian E Carpenter = wrote: >=20 > I will be out for the next week or so. After that > I will edit in the comments from David that appear to be = non-controversial, > and hopefully that will be the final draft that Fred can ship to the = AD. ++ --Apple-Mail=_F81A981C-D108-4544-8591-BC3E422AB04E 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 iQEVAwUBVLlzV59ieig10VPpAQJINgf/cpbq/HhS3NvZi3q47pC16/UK/kSCxOMS 3RSwU2m7TLClBqjlmDb4rl5wjCUurh29xYKc3wPlhugQWY5yEXny6o3W9zSdZtvF efNs8yvQBGYzbIVHqCK89R1NJ55UWpjgpEbb08KjvY9LNxj9xKU0oX/zvWVd6wdZ BsTsVMnrtpr3fxrSl28qeHQPsNGw94nWzbyK+QQ5fVo1H/uCVLwbYqqZ9Y+Szivz 5mnlx4cEim2F015y/K4fvRmm9/iX+ZOp4WDCflwIUUejrB3Tm1SxQmG/jsrlJosg 0XJlpO72LfTabLpP6G9jlWb7pyn8RIuqfOLfhKVHKTQRAg09bCZjtQ== =ffyS -----END PGP SIGNATURE----- --Apple-Mail=_F81A981C-D108-4544-8591-BC3E422AB04E-- From nobody Sun Jan 18 11:00:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01FB1ACDEA for ; Sun, 18 Jan 2015 11:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQyqzv3zVefj for ; Sun, 18 Jan 2015 11:00:05 -0800 (PST) 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 2C1651ACDE0 for ; Sun, 18 Jan 2015 11:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=630; q=dns/txt; s=iport; t=1421607605; x=1422817205; h=date:from:message-id:to:subject:cc; bh=8Zk40nTnDRHRoggB3cxa/uaONi/eiMWE2bX4sP1h9KU=; b=d7BamL/BsqtKll1FqJ2arnIyGOsQ64p7X86VR6s1y9N5xKW9vkPBpcMr jR8EjCtnzZNJNeTdFBA9J7MF5Pd5Ahaqen+5Y5kylGzsvcO8eAVxHT9xT 6yCK7bkWQni07l6v+JsE/QlNN+2u6/zpwKlpNeXlCG8bbyBo4rrEVQQ+D Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogJAAUCvFStJV2U/2dsb2JhbABbgwZSWbcQAY8phXGBEEMBAQEBAX2FDDw0iQwBDc4/AQEBBwEBAQEej3kdhBMFiXWIK4ZkNoJGgkCIHYM9IoQPgxEBAQE X-IronPort-AV: E=Sophos;i="5.09,422,1418083200"; d="scan'208";a="114378839" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 18 Jan 2015 19:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t0IJ03aC003182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jan 2015 19:00:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t0IJ036k011184; Sun, 18 Jan 2015 11:00:03 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t0IJ02ps011175; Sun, 18 Jan 2015 11:00:02 -0800 Date: Sun, 18 Jan 2015 11:00:02 -0800 From: fred@cisco.com Message-Id: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 18 Jan 2015 19:00:07 -0000 This is to initiate a one week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Sun Jan 18 13:23:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C881ACE21 for ; Sun, 18 Jan 2015 13:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.794 X-Spam-Level: ** X-Spam-Status: No, score=2.794 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQnlsJg_Ctym for ; Sun, 18 Jan 2015 13:23:54 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E52B1ACE1F for ; Sun, 18 Jan 2015 13:23:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 2BB843E; Sun, 18 Jan 2015 22:23:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1421616227; bh=JDyIqD0sS7btPU2bR1UGaMvYY/NEt/3WaF+9k9ov+xc=; b=F ElWKxzpJI0CuotN3TLEJNV1Y2bIvJBnCGfz7r3oQZqIHxHabLNeDXnji+qoFEcuw XdEKAepO/aua5H0DZqz1lMy9Fw+RbB/bOTR+6ADuNUF8CHSjzf9X+i1nh2zanc/U D6iK1i5XhiQCSymahHdIE9Y1JrEQ1y41RtubT3KY8s= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Hrui4a_U2HaO; Sun, 18 Jan 2015 22:23:47 +0100 (CET) Received: from [10.60.21.59] (unknown [10.60.21.59]) by mail.sintact.nl (Postfix) with ESMTPSA id E60EA34; Sun, 18 Jan 2015 22:23:46 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Sander Steffann In-Reply-To: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> Date: Sun, 18 Jan 2015 13:23:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24BE93B7-1CFE-4F1C-B1BC-22E268E89BD7@steffann.nl> References: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> To: fred@cisco.com X-Mailer: Apple Mail (2.1993) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 18 Jan 2015 21:23:55 -0000 Hi Fred, > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. Ok: This document is of operational utility :) There are still people new to IPv6 who read the 6to4 standard documents = and think it is a good idea without knowing about the issues it has. = When trying to educate those people an often heard response is "if it = was so bad it wouldn't be a PROPOSED STANDARD". Moving the relevant RFCs = to historic will help with changing the mindset and understanding of = newcomers. Cheers, Sander From nobody Tue Jan 20 05:16:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813781B2A2E for ; Tue, 20 Jan 2015 05:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhW6X6jRlNR6 for ; Tue, 20 Jan 2015 05:16:38 -0800 (PST) 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 8BD511B2A2D for ; Tue, 20 Jan 2015 05:16:38 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=44829 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YDYfb-00034A-JD; Tue, 20 Jan 2015 14:16:35 +0100 Date: Tue, 20 Jan 2015 14:16:15 +0100 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20150120141615.472bc219@echo.ms.redpill-linpro.com> In-Reply-To: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> References: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 20 Jan 2015 13:16:40 -0000 * fred@cisco.com > This is to initiate a one week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. =20 I have read this document, and I think it is ready to move forward. Its operational need for this document is less pressing now than when the -00 version was published back in 2011. Nevertheless, I find it valuable and correct to put the final nail in 6to4's coffin at this point in time. While the operational community for the most part has already realised that 6to4 has no future, there might be some who have not been paying attention and formal deprecation of the protocol may help prevent them from making the mistake of attempting to base production systems on it. I have one minor comment though: In section 1, it says =C2=ABa substantial amount of 6to4 traffic is still observed by IPv6 content providers=C2=BB. While I do see 6to4 traffic, it is quite far from being of "substantial" levels. I would therefore recommend replacing "substantial" with something milder like "noticeable", "measurable", or something along those lines. For what it's worth, today the Google public IPv6 graph shows just a measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not just me. Tore From nobody Tue Jan 20 05:21:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8391B2A33 for ; Tue, 20 Jan 2015 05:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HK_Ux2wp1hx for ; Tue, 20 Jan 2015 05:21:14 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1FE1B2A2E for ; Tue, 20 Jan 2015 05:21:14 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so15292506igb.3 for ; Tue, 20 Jan 2015 05:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZDZY/vUtcgmPe9Hhg4ObtvK1DR9vRFUORteAT5MFfl8=; b=ohADU9lWYsJ5+lq6XbmM+iGq5y1yECKdWIVtp1pgRfw7rGIl36oSQ5FFGMP3Ozj6la Ai3n2qo9/5ZySITHABF+QU02sMB0iwIgIGHiTQl5IkOHJauyoG9agp0FRLmsLm0xtdPh onDTTi+XlBx3S6V3EbUO/tnK+q/7yG2mrbNSrFPI0br//mLwCtFucTKn60QOvxDSbWd2 8jHIY6ia2oInp/tIEbpjIJSYqcfcu9IPkLeVYhC+xEF+2lmxLF9/jGqglKa3vfbZphOs g7BxPGhxGFTYns7TjaQRROnewxQ9r2/DnpdciEwNVo99xIeN9k//tEomFulXUw6eKMHW pZzQ== 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=ZDZY/vUtcgmPe9Hhg4ObtvK1DR9vRFUORteAT5MFfl8=; b=diy2pYUgw5K0prnYP5okwBCB5J0h+FgU2kwq+FvqMWfBdKl3s4DTyZf3/+gMRTEQzm tBmYp4WSsLDmZSp/Iu8sYeaL8mH5UT5ZdxfFNG2ZR/0f0tqMlaM17tFntk1keuh9nZX4 b7MdUhE0wEi/mSgXEm5Tm1IBbdtcktEgAdQtzB03Q/9nqcFRe0WfDYk3YeUwPg51DFZi e6mz67L+5Z6dsPCBtOPrTkspLKDi/a7odVJcl3Ibz9WLhwGrE4pILEBLLgwZXW7Hd2dM YU8QAHPlOYel0gRlvBoiXTJoGV/YbvoQicRGslOlJcqby7ypF177kxalT47223bRm0L9 Goww== X-Gm-Message-State: ALoCoQnl+CjX698k63zkq8NjnWDE2esY6OowA+1mvqQsSztWGPn1k8oZNSrvHmopthQQptadkmlx X-Received: by 10.50.66.131 with SMTP id f3mr26447921igt.7.1421760073238; Tue, 20 Jan 2015 05:21:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.93.102 with HTTP; Tue, 20 Jan 2015 05:20:53 -0800 (PST) In-Reply-To: <20150120141615.472bc219@echo.ms.redpill-linpro.com> References: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> <20150120141615.472bc219@echo.ms.redpill-linpro.com> From: Lorenzo Colitti Date: Tue, 20 Jan 2015 22:20:53 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=047d7bdc07a21f2ce1050d1550d9 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 20 Jan 2015 13:21:15 -0000 --047d7bdc07a21f2ce1050d1550d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 20, 2015 at 10:16 PM, Tore Anderson wrote: > I have one minor comment though: In section 1, it says =C2=ABa substantia= l > amount of 6to4 traffic is still observed by IPv6 content providers=C2=BB. > While I do see 6to4 traffic, it is quite far from being of "substantial" > levels. I would therefore recommend replacing "substantial" with > something milder like "noticeable", "measurable", or something along > those lines. > "Substantial" is definitely incorrect. From a content provider point of view, I think the number is minimal. (If I were writing the draft I'd be tempted to say "non-zero"). There is likely much more P2P 6to4 traffic though. > For what it's worth, today the Google public IPv6 graph shows just a > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not > just me. > "Measly" would also be better than "substantial" :-) --047d7bdc07a21f2ce1050d1550d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 20, 2015 at 10:16 PM, Tore Anderson <tore@fud.no> wrote:=
I have one minor comment though: In sect= ion 1, it says =C2=ABa substantial
amount of 6to4 traffic is still observed by IPv6 content providers=C2=BB. While I do see 6to4 traffic, it is quite far from being of "substantia= l"
levels. I would therefore recommend replacing "substantial" with<= br> something milder like "noticeable", "measurable", or so= mething along
those lines.

"Substantial" is= definitely incorrect. From a content provider point of view, I think the n= umber is minimal. (If I were writing the draft I'd be tempted to say &q= uot;non-zero"). There is likely much more P2P 6to4 traffic though.
=C2=A0
For what it's worth, = today the Google public IPv6 graph shows just a
measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not=
just me.

"Measly" would also = be better than "substantial" :-)
--047d7bdc07a21f2ce1050d1550d9-- From nobody Tue Jan 20 09:21:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3201B2ADF; Tue, 20 Jan 2015 09:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGXnZOhEnxdJ; Tue, 20 Jan 2015 09:21:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 518B81B2AC4; Tue, 20 Jan 2015 09:21:22 -0800 (PST) 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.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120172122.18570.89015.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 09:21:22 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-cidr-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 17:21:24 -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 Prefix Length Recommendation for Forwarding Authors : Mohamed Boucadair Alexandre Petrescu Fred Baker Filename : draft-ietf-v6ops-cidr-prefix-00.txt Pages : 5 Date : 2015-01-18 Abstract: IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software algorithms should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 20 12:14:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385DB1B2B19 for ; Tue, 20 Jan 2015 12:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw5YTn6TgEZl for ; Tue, 20 Jan 2015 12:14:54 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8071B2B41 for ; Tue, 20 Jan 2015 12:14:54 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id fl12so12091816pdb.6 for ; Tue, 20 Jan 2015 12:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A1GlGrWB7Xql4AbydlI1glAWiOcS9cYcqlwGl5oYIIk=; b=pzPXE3vVQt34lAKpLdmYpw5JR2djwNluBT4GcNsUrSTRrkC+VT7ZfhFN5UzZauZUlv 7/4B12DmIW3QvvNwyN6U/byahHdTHSTMRHYswNJLgOdbfe/PWpmPKnaD8uWVdBxLLZC/ e9jpMSawqv89GXby4P0s4yAtoprQV+f++n9RRpIKNxIaSokA8XmCwQEPahJAp1T3H7BA EC7tT8TzwzLs8sSr6Hdz5myiVzt7/cppgQe0iClUwoFZ9OZflSvN4uyMzGmbfVYBCu16 /tq57LK+vQ2UdhZgZMHQmvlGBnZUOis1QvtOAAnopHO0mAeFkZqRv6pj2k7wRznt0MJq y+sw== X-Received: by 10.68.136.228 with SMTP id qd4mr55977826pbb.122.1421784893628; Tue, 20 Jan 2015 12:14:53 -0800 (PST) Received: from [10.177.173.148] ([119.17.32.194]) by mx.google.com with ESMTPSA id i9sm852045pdk.49.2015.01.20.12.14.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 12:14:52 -0800 (PST) Message-ID: <54BEB741.8060709@gmail.com> Date: Wed, 21 Jan 2015 09:14:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tore Anderson , v6ops@ietf.org References: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> <20150120141615.472bc219@echo.ms.redpill-linpro.com> In-Reply-To: <20150120141615.472bc219@echo.ms.redpill-linpro.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 20 Jan 2015 20:14:56 -0000 On 21/01/2015 02:16, Tore Anderson wrote: > * fred@cisco.com >=20 >> This is to initiate a one week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. =20 >=20 > I have read this document, and I think it is ready to move forward. >=20 > Its operational need for this document is less pressing now than when > the -00 version was published back in 2011. Nevertheless, I find it > valuable and correct to put the final nail in 6to4's coffin at this > point in time. While the operational community for the most part has > already realised that 6to4 has no future, there might be some who have > not been paying attention and formal deprecation of the protocol may > help prevent them from making the mistake of attempting to base > production systems on it. >=20 > I have one minor comment though: In section 1, it says =C2=ABa substant= ial > amount of 6to4 traffic is still observed by IPv6 content providers=C2=BB= =2E > While I do see 6to4 traffic, it is quite far from being of "substantial= " > levels. I would therefore recommend replacing "substantial" with > something milder like "noticeable", "measurable", or something along > those lines. >=20 > For what it's worth, today the Google public IPv6 graph shows just a > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not= > just me. Tore, However, that fraction of Google traffic multipled by Google users represents something like 100000 users. I don't think we can dismiss that number of people too easily. It's a matter of taste whether that's "substantial" or "noticeable". Brian From nobody Tue Jan 20 16:30:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E71A00BE for ; Tue, 20 Jan 2015 16:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.202 X-Spam-Level: ** X-Spam-Status: No, score=2.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPWoAPAQQGVN for ; Tue, 20 Jan 2015 16:30:50 -0800 (PST) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B661A0091 for ; Tue, 20 Jan 2015 16:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1421800248; bh=F8+BLJ3DTMfSujPLC7fcOJKOTwbtW6EKVUmEzR5L7Uw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=pBzXilFOByw6I0lhFEaDRI14PlckutjbS0q+xlK8DQwqDSufXp2RiRu9LribstqHgjeQjc9+h0kLpTC5MKQp1pjSUZoQ/ta7mZzTzmlLbQdQ3Dqlf8pgu/gbwTSZRL6GiJn5Cc+/b4ZPEEnEMcBhpThKc49z4jXOZha+9sQhoKqqPg/H+pQ3y10iO+A3tc7YhKojDEhqC2FTy52EgNCH5vaRitjkQL2NHr4RMZertlqvl7FC+w/TEYYz55UPOYTWjxdwEPJCJmOZ0mGetplrujU5O6ijxCREwpK4Vrn6WrdObvJLmrF98ADJgUKk/cmxD1TytMbZ5sZKCfJq8CrBSw== Received: from [66.196.81.174] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2015 00:30:48 -0000 Received: from [98.139.212.225] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2015 00:30:48 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 21 Jan 2015 00:30:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 695786.13306.bm@omp1034.mail.bf1.yahoo.com X-YMail-OSG: yXF4ZIgVM1mVxPwfYj3JW1RyttyDSn_xwq1lhNx.8I6xqzdHirfFADfywxgwOtB 9kvJhNRvJMpOiPvdodPDfdIbM2EaB4.OEFHHAGe7dMgqo.AugzC6twpwlVkJofDlCwtkWADY0wvS kS5c4THb3QBdX7hrMYpCqBPdjhSofYcSYiyh7eVlEqsARqC0Wb3c4r4UvJkPNHvgfzI2QAMp6U5. auKcnZHcGLX8Lg0.mHeUXMpd5WOQksZkuDyrhn2zwf4S.AElHIdk092i3g9wvf58CUQzVce_kX4c m0MazPZtSeWH7dGjCR_KTNFTl2I_Sbk4C6CIPZet67DDcw6xfToRfZv8lPMdMLfI0kWzwEEtRncv ai.1u_RB5jbGIWtrg3Bsjz0LSIxRsqvk80D1QP7TxeFIDk8DY32k6ssaHv3HxgcwdHYu.iEqJq2. qHF9z2PXqCaWx17YtcTRJZrda62BKLZAGxFf27nLY1da3o84ofBCPDi3dhzmL2RqW709.Rr_AZ_k ALMwskovDi321dQ-- Received: by 66.196.81.109; Wed, 21 Jan 2015 00:30:47 +0000 Date: Wed, 21 Jan 2015 00:30:22 +0000 (UTC) From: Mark ZZZ Smith To: Brian E Carpenter , Tore Anderson , "v6ops@ietf.org" Message-ID: <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> In-Reply-To: <54BEB741.8060709@gmail.com> References: <54BEB741.8060709@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 00:30:51 -0000 ----- Original Message ----- From: Brian E Carpenter To: Tore Anderson ; v6ops@ietf.org Cc:=20 Sent: Wednesday, 21 January 2015, 7:14 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On 21/01/2015 02:16, Tore Anderson wrote: > * fred@cisco.com >=20 >> This is to initiate a one week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. =20 >=20 > I have read this document, and I think it is ready to move forward. >=20 > Its operational need for this document is less pressing now than when > the -00 version was published back in 2011. Nevertheless, I find it > valuable and correct to put the final nail in 6to4's coffin at this > point in time. While the operational community for the most part has > already realised that 6to4 has no future, there might be some who have > not been paying attention and formal deprecation of the protocol may > help prevent them from making the mistake of attempting to base > production systems on it. >=20 > I have one minor comment though: In section 1, it says =C2=ABa substantia= l > amount of 6to4 traffic is still observed by IPv6 content providers=C2=BB. > While I do see 6to4 traffic, it is quite far from being of "substantial" > levels. I would therefore recommend replacing "substantial" with > something milder like "noticeable", "measurable", or something along > those lines. >=20 > For what it's worth, today the Google public IPv6 graph shows just a > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not > just me. "Tore, However, that fraction of Google traffic multipled by Google users represents something like 100000 users. I don't think we can dismiss that number of people too easily. It's a matter of taste whether that's "substantial" or "noticeable". Brian" Actually, to those end users, the impact might be both quite significant an= d noticeable. I think one explanation for the use of 6to4 tunnelled IPv6 is that their ho= sts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google make= their services equally available over both, which I think they do), as per= RFC3484 address selection rules. The other explanation for it could be that these users have Happy Eyeballs = enabled browsers and the browser is choosing to try to use both IPv4 and IP= v6, despite the IPv6 being tunnelled rather than native. From a Happy Eyeba= lls robustness perspective, that would be quite a reasonable thing to do I = think. If the end-hosts aren't following RFC3484's default preferences, then break= ing 6to4 might cause the sorts of timeouts that HE is designed to overcome.= RFC3484 is quite old now (2003), and as a minor data point I first encount= ered the implementation of them in around 2008/2009 if I recall correctly o= n my Linux system (as I was using 6to4 at the time and wanted to use tunnel= led IPv6 in preference to native IPv4 - gai.conf(3) is the way you change t= hat). So if some hosts are still preferring tunnelled 6to4 IPv6 over native= IPv4 then perhaps they're also not going to be running a HE enabled browse= r either. Perhaps it might be possible for somebody at Google to produce a list of th= e browser User-Agent strings for people still using 6to4 to see if the brow= sers being used are HE enabled, which might also give some insight into RFC= 3484 support in the underlying OSes. Regards, Mark. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 21 04:16:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05381A1A1C for ; Wed, 21 Jan 2015 04:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSJLbSk-RymB for ; Wed, 21 Jan 2015 04:16:23 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC3D1A1A23 for ; Wed, 21 Jan 2015 04:16:22 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so22050478igq.0 for ; Wed, 21 Jan 2015 04:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iUmBxqWE74ljTua+/57zl/EFt+HFRzlGGZ4t5InRDoc=; b=B/kZcUNF5A/Od7UI6wyYK4B4rpt/l6zc1J05HwpEHJUhSZvoLKqMpwbzE/koWB5jW5 VbOfYpq4CzGc2pHhYrpyMTyRMQxMccKWM95/K9yxAOP9cSBKE+OBWUuTrClEogKLProk ifHDun4TULTO6tYJghRWSaITyhdxd5DJ4i7scixH3e2fS1YSz5Cz/UN9v5sxqaqfgBFO JyW+ZW7uXe8nqX8P0W7UYaM5DArxt4magjAWmRiqNiOCC0MDEIgcM63M3Mt0RKP3dszk HbjhZfZL9xOkMW61fwMKQbCsX3hoQhHl8PuZZcU9r9kT9VFHATZVCUlSjp4q5UPMuXxp MHig== 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=iUmBxqWE74ljTua+/57zl/EFt+HFRzlGGZ4t5InRDoc=; b=DJF0mNuNnob/fB4UCNywt7jWF42WPbZKKGtfvAQFqJ51Nd5Xx7LvOht0H53uNNdKBO zCnHO5skX1o/vGrN/tOa1j24D+do1/WE93cs4PCS+z+jbxDUFEs+djzdTbjZU060oszt AGBgjGAbcGP4GR53qWL48Y6okaBMoxa74UQ487169g2JKQFDT8nYNQ1WLuzQF4ygRO9f MXkaHDkza38llgsjK9LAJKYHTM4qGvV1d+V7jOObNBPXcib0FAfSNaHdxxCqlyOR1lMu baO2cfE0grmbreD3nAWOR5B5mUMD/EdRDFmXShwkeWW53HA5N2Ln+d7ayrHC1l3qAcNf 5OIQ== X-Gm-Message-State: ALoCoQkpXkzDD7yFBqwgl33nOOPdsfX3Ko4BSmf0Irx7AalRvPwnaBrVro31LnLzUvGqrm3QRIGN X-Received: by 10.50.49.43 with SMTP id r11mr1606228ign.18.1421842581596; Wed, 21 Jan 2015 04:16:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.93.102 with HTTP; Wed, 21 Jan 2015 04:16:01 -0800 (PST) In-Reply-To: <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Wed, 21 Jan 2015 21:16:01 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7bdca5b600d415050d288646 Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:16:25 -0000 --047d7bdca5b600d415050d288646 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, those users will definitely be impacted. Which is why the document does not suggest dropping the packets or turning off the relays, except by saying things like "operators SHOULD [...] consider carefully whether the [...] relay can be discontinued as traffic diminishes". That's quite reasonable guidance, I think. Remember: 0.01% is really a very small number. Multiplying it by 1 billion (like Brian did) makes it seem large, but that's just a trick of the light. Look at it this way: if all the relays in the world were turned off overnight and all the 6to4 users were unable to reach a given website, that website's reliability would still be 99.99% of what it was before. I support this document in its current form. I only have three comments beyond seconding Tore's objection to the draft calling 6to4 "substantial": 1. Is it necessary to formally deprecate RFC 6732? It's an individual submission. (Not that I support RFC 6732 in any way, to be sure.) 2. I don't think the sentence "some content providers have been reluctant to make content available over IPv6" is true, or at least any true for any non-trivial value of "some". 6to4 was a problem for content providers a few years ago, but we've moved past it. 3. It might be useful to cite that another reason 6to4 is being deprecated is that IPv6 is actually being deployed these days (finally). On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith wrote: > > > > > ----- Original Message ----- > From: Brian E Carpenter > To: Tore Anderson ; v6ops@ietf.org > Cc: > Sent: Wednesday, 21 January 2015, 7:14 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > On 21/01/2015 02:16, Tore Anderson wrote: > > * fred@cisco.com > > > >> This is to initiate a one week working group last call of > >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > > > > I have read this document, and I think it is ready to move forward. > > > > Its operational need for this document is less pressing now than when > > the -00 version was published back in 2011. Nevertheless, I find it > > valuable and correct to put the final nail in 6to4's coffin at this > > point in time. While the operational community for the most part has > > already realised that 6to4 has no future, there might be some who have > > not been paying attention and formal deprecation of the protocol may > > help prevent them from making the mistake of attempting to base > > production systems on it. > > > > I have one minor comment though: In section 1, it says =C2=ABa substant= ial > > amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB. > > While I do see 6to4 traffic, it is quite far from being of "substantial= " > > levels. I would therefore recommend replacing "substantial" with > > something milder like "noticeable", "measurable", or something along > > those lines. > > > > For what it's worth, today the Google public IPv6 graph shows just a > > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not > > just me. > > "Tore, > > However, that fraction of Google traffic multipled by Google users > represents something like 100000 users. I don't think we can dismiss > that number of people too easily. It's a matter of taste whether > that's "substantial" or "noticeable". > > Brian" > > Actually, to those end users, the impact might be both quite significant > and noticeable. > > I think one explanation for the use of 6to4 tunnelled IPv6 is that their > hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google > make their services equally available over both, which I think they do), = as > per RFC3484 address selection rules. > > The other explanation for it could be that these users have Happy Eyeball= s > enabled browsers and the browser is choosing to try to use both IPv4 and > IPv6, despite the IPv6 being tunnelled rather than native. From a Happy > Eyeballs robustness perspective, that would be quite a reasonable thing t= o > do I think. > > If the end-hosts aren't following RFC3484's default preferences, then > breaking 6to4 might cause the sorts of timeouts that HE is designed to > overcome. RFC3484 is quite old now (2003), and as a minor data point I > first encountered the implementation of them in around 2008/2009 if I > recall correctly on my Linux system (as I was using 6to4 at the time and > wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3) i= s > the way you change that). So if some hosts are still preferring tunnelled > 6to4 IPv6 over native IPv4 then perhaps they're also not going to be > running a HE enabled browser either. > > Perhaps it might be possible for somebody at Google to produce a list of > the browser User-Agent strings for people still using 6to4 to see if the > browsers being used are HE enabled, which might also give some insight in= to > RFC3484 support in the underlying OSes. > > Regards, > Mark. > > > > > > > > > > > > > > > _______________________________________________ > 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 > --047d7bdca5b600d415050d288646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, those users will definitely be impacted. Which is why= the document does not suggest dropping the packets or turning off the rela= ys, except by saying things like "operators SHOULD [...] consider care= fully whether the [...] relay can be discontinued as traffic diminishes&quo= t;. That's quite reasonable guidance, I think.

Remem= ber: 0.01% is really a very small number. Multiplying it by 1 billion (like= Brian did) makes it seem large, but that's just a trick of the light. = Look at it this way: if all the relays in the world were turned off overnig= ht and all the 6to4 users were unable to reach a given website, that websit= e's reliability would still be 99.99% of what it was before.
=
I support this document in its current form. I only have thr= ee comments beyond seconding Tore's objection to the draft calling 6to4= "substantial":
  1. Is it necessary to formally dep= recate RFC 6732? It's an individual submission. (Not that I support RFC= 6732 in any way, to be sure.)
  2. I don't think the sentence &= quot;some content providers have been reluctant to make content available o= ver IPv6" is true, or at least any true for any non-trivial value of &= quot;some". 6to4 was a problem for content providers a few years ago, = but we've moved past it.
  3. It might be useful to cite that an= other reason 6to4 is being deprecated is that IPv6 is actually being deploy= ed these days (finally).

On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ = Smith <markzzzsmith@yahoo.com.au> wrote:




----- Original Message -----
From: Brian E Carpenter <= brian.e.carpenter@gmail.com>
To: Tore Anderson <tore@fud.no>; <= a href=3D"mailto:v6ops@ietf.org">v6ops@ietf.org
Cc:
Sent: Wednesday, 21 January 2015, 7:14
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

On 21/01/2015 02:16, Tore Anderson wrote:
> * fred@cisco.com
>
>> This is to initiate a one week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-t= o-historic.
>
> I have read this document, and I think it is ready to move forward. >
> Its operational need for this document is less pressing now than when<= br> > the -00 version was published back in 2011. Nevertheless, I find it > valuable and correct to put the final nail in 6to4's coffin at thi= s
> point in time. While the operational community for the most part has > already realised that 6to4 has no future, there might be some who have=
> not been paying attention and formal deprecation of the protocol may > help prevent them from making the mistake of attempting to base
> production systems on it.
>
> I have one minor comment though: In section 1, it says =C2=ABa substan= tial
> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB.
> While I do see 6to4 traffic, it is quite far from being of "subst= antial"
> levels. I would therefore recommend replacing "substantial" = with
> something milder like "noticeable", "measurable", = or something along
> those lines.
>
> For what it's worth, today the Google public IPv6 graph shows just= a
> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it'= s not
> just me.

"Tore,

However, that fraction of Google traffic multipled by Google users
represents something like 100000 users. I don't think we can dismiss that number of people too easily. It's a matter of taste whether
that's "substantial" or "noticeable".

=C2=A0 =C2=A0 Brian"

Actually, to those end users, the impact might be both quite si= gnificant and noticeable.

I think one explanation for the use of 6to4 tunnelled IPv6 is that their ho= sts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google = make their services equally available over both, which I think they do), as= per RFC3484 address selection rules.

The other explanation for it could be that these users have Happy Eyeballs = enabled browsers and the browser is choosing to try to use both IPv4 and IP= v6, despite the IPv6 being tunnelled rather than native. From a Happy Eyeba= lls robustness perspective, that would be quite a reasonable thing to do I = think.

If the end-hosts aren't following RFC3484's default preferences, th= en breaking 6to4 might cause the sorts of timeouts that HE is designed to o= vercome. RFC3484 is quite old now (2003), and as a minor data point I first= encountered the implementation of them in around 2008/2009 if I recall cor= rectly on my Linux system (as I was using 6to4 at the time and wanted to us= e tunnelled IPv6 in preference to native IPv4 - gai.conf(3) is the way you = change that). So if some hosts are still preferring tunnelled 6to4 IPv6 ove= r native IPv4 then perhaps they're also not going to be running a HE en= abled browser either.

Perhaps it might be possible for somebody at Google to produce a list of th= e browser User-Agent strings for people still using 6to4 to see if the brow= sers being used are HE enabled, which might also give some insight into RFC= 3484 support in the underlying OSes.

Regards,
Mark.














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

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

--047d7bdca5b600d415050d288646-- From nobody Wed Jan 21 04:47:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695531A1A3E for ; Wed, 21 Jan 2015 04:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku4vX2nK0UDu for ; Wed, 21 Jan 2015 04:47:27 -0800 (PST) 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 812731A1A25 for ; Wed, 21 Jan 2015 04:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=128; q=dns/txt; s=iport; t=1421844448; x=1423054048; h=date:from:message-id:to:subject:cc; bh=e4tJ7avB90fwfpaK6tHDNqllvikNeBs3WP8e2Uvdo4g=; b=iYvm2HgkmU1fUSmUnJ4wDtkcRqRgJPn8LG5vHAi/SjmU0zBsTUcbbxnx PiOmjnDVZ8cg3OhKu/W4tsToCilXSdIkc6SmMR/4GFdGMSU8Nop6lfMsw 8LAErm0/vkqLOQlS9zK0KRDDC1tWjaZqux1CpZxx26Q6cTNLUAy1tcSgA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHALqfv1StJV2Q/2dsb2JhbABbgwZSWbZwAY8ohWgJgSpDAQEBAQF9hQw8NIkMAQ3RMwEBAQcBAQEBHo95HYMAgRMFiXWIK4ZkNoJGjhoihA+DEQEBAQ X-IronPort-AV: E=Sophos;i="5.09,441,1418083200"; d="scan'208";a="389344390" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 21 Jan 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0LCl29L014877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 12: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 t0LCl1Hb004625; Wed, 21 Jan 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t0LCl1sF004620; Wed, 21 Jan 2015 04:47:01 -0800 Date: Wed, 21 Jan 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201501211247.t0LCl1sF004620@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-cidr-prefix@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jan 2015 12:47:30 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment. From nobody Wed Jan 21 10:12:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ECC1A1B61 for ; Wed, 21 Jan 2015 10:11:58 -0800 (PST) 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_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ2GiXWm3sqk for ; Wed, 21 Jan 2015 10:11:56 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E598D1A1B60 for ; Wed, 21 Jan 2015 10:11:55 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t0LI9vRl005557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jan 2015 10:09:57 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t0LI9vRl005557 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1421863798; bh=52lqWFYhZIZ5suoT3qTBSze/Oug=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=1cxa/tN45krWgRm3q9rBQfaXkefQfe7tIPKYaI7sglrIqTh8Q5W+ZrRrGehS53x3/ LbxmNeEkShHb1Hix4Cb6KfVUEgSzBmCMdTLKMnSAiSFfnjksI7x1u9XwVOJmOQ0BaN ccHJCnI4JkUFXc9CJv1ZQEeEqX3esVK2XMg5NT1w= Content-Type: multipart/alternative; boundary="Apple-Mail=_3DC1D9C1-9969-49B5-B281-418D75CEE323" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Owen DeLong In-Reply-To: Date: Wed, 21 Jan 2015 10:09:57 -0800 Message-Id: <2B6E8067-6B40-4B3F-BA06-CA6DD0570526@delong.com> References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1993) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 21 Jan 2015 10:09:58 -0800 (PST) Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:11:59 -0000 --Apple-Mail=_3DC1D9C1-9969-49B5-B281-418D75CEE323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 =E2=80=94 I agree with all of Lorenzo=E2=80=99s comments. Owen > On Jan 21, 2015, at 04:16 , Lorenzo Colitti = wrote: >=20 > Yes, those users will definitely be impacted. Which is why the = document does not suggest dropping the packets or turning off the = relays, except by saying things like "operators SHOULD [...] consider = carefully whether the [...] relay can be discontinued as traffic = diminishes". That's quite reasonable guidance, I think. >=20 > Remember: 0.01% is really a very small number. Multiplying it by 1 = billion (like Brian did) makes it seem large, but that's just a trick of = the light. Look at it this way: if all the relays in the world were = turned off overnight and all the 6to4 users were unable to reach a given = website, that website's reliability would still be 99.99% of what it was = before. >=20 > I support this document in its current form. I only have three = comments beyond seconding Tore's objection to the draft calling 6to4 = "substantial": > Is it necessary to formally deprecate RFC 6732? It's an individual = submission. (Not that I support RFC 6732 in any way, to be sure.) > I don't think the sentence "some content providers have been reluctant = to make content available over IPv6" is true, or at least any true for = any non-trivial value of "some". 6to4 was a problem for content = providers a few years ago, but we've moved past it. > It might be useful to cite that another reason 6to4 is being = deprecated is that IPv6 is actually being deployed these days (finally). >=20 > On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith = > wrote: >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: Brian E Carpenter > > To: Tore Anderson >; v6ops@ietf.org = > Cc: > Sent: Wednesday, 21 January 2015, 7:14 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >=20 > On 21/01/2015 02:16, Tore Anderson wrote: > > * fred@cisco.com > > > >> This is to initiate a one week working group last call of > >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic = . > > > > I have read this document, and I think it is ready to move forward. > > > > Its operational need for this document is less pressing now than = when > > the -00 version was published back in 2011. Nevertheless, I find it > > valuable and correct to put the final nail in 6to4's coffin at this > > point in time. While the operational community for the most part has > > already realised that 6to4 has no future, there might be some who = have > > not been paying attention and formal deprecation of the protocol may > > help prevent them from making the mistake of attempting to base > > production systems on it. > > > > I have one minor comment though: In section 1, it says =C2=ABa = substantial > > amount of 6to4 traffic is still observed by IPv6 content = providers=C2=BB. > > While I do see 6to4 traffic, it is quite far from being of = "substantial" > > levels. I would therefore recommend replacing "substantial" with > > something milder like "noticeable", "measurable", or something along > > those lines. > > > > For what it's worth, today the Google public IPv6 graph shows just a > > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's = not > > just me. >=20 > "Tore, >=20 > However, that fraction of Google traffic multipled by Google users > represents something like 100000 users. I don't think we can dismiss > that number of people too easily. It's a matter of taste whether > that's "substantial" or "noticeable". >=20 > Brian" >=20 > Actually, to those end users, the impact might be both quite = significant and noticeable. >=20 > I think one explanation for the use of 6to4 tunnelled IPv6 is that = their hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming = Google make their services equally available over both, which I think = they do), as per RFC3484 address selection rules. >=20 > The other explanation for it could be that these users have Happy = Eyeballs enabled browsers and the browser is choosing to try to use both = IPv4 and IPv6, despite the IPv6 being tunnelled rather than native. =46rom= a Happy Eyeballs robustness perspective, that would be quite a = reasonable thing to do I think. >=20 > If the end-hosts aren't following RFC3484's default preferences, then = breaking 6to4 might cause the sorts of timeouts that HE is designed to = overcome. RFC3484 is quite old now (2003), and as a minor data point I = first encountered the implementation of them in around 2008/2009 if I = recall correctly on my Linux system (as I was using 6to4 at the time and = wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3) = is the way you change that). So if some hosts are still preferring = tunnelled 6to4 IPv6 over native IPv4 then perhaps they're also not going = to be running a HE enabled browser either. >=20 > Perhaps it might be possible for somebody at Google to produce a list = of the browser User-Agent strings for people still using 6to4 to see if = the browsers being used are HE enabled, which might also give some = insight into RFC3484 support in the underlying OSes. >=20 > Regards, > Mark. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_3DC1D9C1-9969-49B5-B281-418D75CEE323 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 =E2=80=94 I agree with all of Lorenzo=E2=80=99s = comments.

Owen


On Jan 21, 2015, at 04:16 , Lorenzo Colitti <lorenzo@google.com> = wrote:

Yes, those users will definitely be impacted. = Which is why the document does not suggest dropping the packets or = turning off the relays, except by saying things like "operators SHOULD = [...] consider carefully whether the [...] relay can be discontinued as = traffic diminishes". That's quite reasonable guidance, I think.

Remember: 0.01% is = really a very small number. Multiplying it by 1 billion (like Brian did) = makes it seem large, but that's just a trick of the light. Look at it = this way: if all the relays in the world were turned off overnight and = all the 6to4 users were unable to reach a given website, that website's = reliability would still be 99.99% of what it was before.

I support this document = in its current form. I only have three comments beyond seconding Tore's = objection to the draft calling 6to4 "substantial":
  1. Is it necessary to formally = deprecate RFC 6732? It's an individual submission. (Not that I support = RFC 6732 in any way, to be sure.)
  2. I = don't think the sentence "some content providers have been reluctant to = make content available over IPv6" is true, or at least any true for any = non-trivial value of "some". 6to4 was a problem for content providers a = few years ago, but we've moved past it.
  3. It might be useful to cite that another reason 6to4 is being = deprecated is that IPv6 is actually being deployed these days = (finally).

On Wed, = Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> = wrote:




----- Original Message -----
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: Tore Anderson <tore@fud.no>; v6ops@ietf.org
Cc:
Sent: Wednesday, 21 January 2015, 7:14
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
=
On 21/01/2015 02:16, Tore Anderson wrote:
> * fred@cisco.com
>
>> This is to initiate a one week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic.
>
> I have read this document, and I think it is ready to move = forward.
>
> Its operational need for this document is less pressing now than = when
> the -00 version was published back in 2011. Nevertheless, I find = it
> valuable and correct to put the final nail in 6to4's coffin at = this
> point in time. While the operational community for the most part = has
> already realised that 6to4 has no future, there might be some who = have
> not been paying attention and formal deprecation of the protocol = may
> help prevent them from making the mistake of attempting to base
> production systems on it.
>
> I have one minor comment though: In section 1, it says =C2=ABa = substantial
> amount of 6to4 traffic is still observed by IPv6 content = providers=C2=BB.
> While I do see 6to4 traffic, it is quite far from being of = "substantial"
> levels. I would therefore recommend replacing "substantial" with
> something milder like "noticeable", "measurable", or something = along
> those lines.
>
> For what it's worth, today the Google public IPv6 graph shows just = a
> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's = not
> just me.

"Tore,

However, that fraction of Google traffic multipled by Google users
represents something like 100000 users. I don't think we can dismiss
that number of people too easily. It's a matter of taste whether
that's "substantial" or "noticeable".

    Brian"

Actually, to those end users, the impact might be both quite = significant and noticeable.

I think one explanation for the use of 6to4 tunnelled IPv6 is that their = hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google = make their services equally available over both, which I think they do), = as per RFC3484 address selection rules.

The other explanation for it could be that these users have Happy = Eyeballs enabled browsers and the browser is choosing to try to use both = IPv4 and IPv6, despite the IPv6 being tunnelled rather than native. =46rom= a Happy Eyeballs robustness perspective, that would be quite a = reasonable thing to do I think.

If the end-hosts aren't following RFC3484's default preferences, then = breaking 6to4 might cause the sorts of timeouts that HE is designed to = overcome. RFC3484 is quite old now (2003), and as a minor data point I = first encountered the implementation of them in around 2008/2009 if I = recall correctly on my Linux system (as I was using 6to4 at the time and = wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3) = is the way you change that). So if some hosts are still preferring = tunnelled 6to4 IPv6 over native IPv4 then perhaps they're also not going = to be running a HE enabled browser either.

Perhaps it might be possible for somebody at Google to produce a list of = the browser User-Agent strings for people still using 6to4 to see if the = browsers being used are HE enabled, which might also give some insight = into RFC3484 support in the underlying OSes.

Regards,
Mark.














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

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

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

= --Apple-Mail=_3DC1D9C1-9969-49B5-B281-418D75CEE323-- From nobody Wed Jan 21 11:47:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE121A872A for ; Wed, 21 Jan 2015 11:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-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 pxLxbySaYfHn for ; Wed, 21 Jan 2015 11:47:24 -0800 (PST) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736251A871E for ; Wed, 21 Jan 2015 11:47:24 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id i138so8647524oig.12 for ; Wed, 21 Jan 2015 11:47:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=MbsgNGh8Tl4ki4CmmU3eTQEufwP6Lb3fgAgZYW8XQA8=; b=AB6faxT7C1o1FYvDiiDnVjrJQm4JG2Gr2QgJODt1DEsHOlPELhsjwxKdcGumKypWR4 aHrPgMCdV1rglaoFOJoI2Sj2K1+GphysUQD/jErv9v4QAQsCuwdu8YymReVNE80y97f3 a3eezD9mkQa37NMv9snnnbfX+dzwMLSc9yjOYooXplaN6hat/rOVQsUCyCaNIstqzwmT YV7SoKbk3WLuKwrnXweohZ6varywJElExUfGd0NXbKztQs9FRiBzy6BwA52yFL3xSEbL +kUxYfTjGNnpOZnh6JUZihzmck3SnpWef1V8GdZ5/PkBJDsxCZYxOMtv0gH9Vc/cLc80 hJ/Q== X-Gm-Message-State: ALoCoQn/78gDH94yhmVsfwR6m2AnUgO1z+KNvn91w+lM+g9NallxHWS++w4QVVmB2m25Hlih2ds0 MIME-Version: 1.0 X-Received: by 10.182.44.132 with SMTP id e4mr26336449obm.86.1421869643769; Wed, 21 Jan 2015 11:47:23 -0800 (PST) Received: by 10.76.150.2 with HTTP; Wed, 21 Jan 2015 11:47:23 -0800 (PST) In-Reply-To: References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> Date: Wed, 21 Jan 2015 11:47:23 -0800 Message-ID: From: James Woodyatt To: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2f49a08c030050d2ed33b Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:47:25 -0000 --001a11c2f49a08c030050d2ed33b Content-Type: text/plain; charset=UTF-8 On Wed, Jan 21, 2015 at 4:16 AM, Lorenzo Colitti wrote: > > 1. Is it necessary to formally deprecate RFC 6732? It's an individual > submission. (Not that I support RFC 6732 in any way, to be sure.) > > Rather than ask if it's necessary, I'd prefer to ask if there is any sane reason to think RFC 6732 is anything more than an historical curiosity. If 6to4-PMT isn't of any more than historical interest, then let's please move its category to Historic so that its applicability will not be confused with other practical non-standard protocol specifications published by IETF in the Informational category, many of which rightly enjoy widespread deployment today, e.g. PPPoE. -- james woodyatt Nest Labs, Communications Engineering --001a11c2f49a08c030050d2ed33b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 21, 2015 at 4:16 AM, Lorenzo Colitti <lorenzo@google.com>= wrote:
    =
  1. Is it necessary to formally deprecate RFC 6732? It's an individual = submission. (Not that I support RFC 6732 in any way, to be sure.)
=
Rather than ask if it's necessary, I'= ;d prefer to ask if there is any sane reason to think RFC 6732 is anything = more than an historical curiosity.

If 6to4-PMT isn't of any more than histori= cal interest, then let's please move its category to Historic so that i= ts applicability will not be confused with other practical non-standard pro= tocol specifications published by IETF in the Informational category, many = of which rightly enjoy widespread deployment today, e.g. PPPoE.


--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering
=
--001a11c2f49a08c030050d2ed33b-- From nobody Thu Jan 22 02:24:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B931A9108 for ; Thu, 22 Jan 2015 02:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ercmbYOJkJN for ; Thu, 22 Jan 2015 02:24:29 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE68C1A907F for ; Thu, 22 Jan 2015 02:24:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0MAOQS0010975 for ; Thu, 22 Jan 2015 11:24:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 72DB6203439 for ; Thu, 22 Jan 2015 11:24:48 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6A82D2033EC for ; Thu, 22 Jan 2015 11:24:48 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0MAOOHD014629 for ; Thu, 22 Jan 2015 11:24:25 +0100 Message-ID: <54C0CFD8.6010506@gmail.com> Date: Thu, 22 Jan 2015 11:24:24 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> In-Reply-To: <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC - 6to4 on Routers for IPv6-only Hosts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2015 10:24:32 -0000 Le 21/01/2015 01:30, Mark ZZZ Smith a écrit : > > > > > ----- Original Message ----- From: Brian E Carpenter > To: Tore Anderson ; > v6ops@ietf.org Cc: Sent: Wednesday, 21 January 2015, 7:14 Subject: > Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > On 21/01/2015 02:16, Tore Anderson wrote: >> * fred@cisco.com >> >>> This is to initiate a one week working group last call of >>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. >> >> I have read this document, and I think it is ready to move >> forward. >> >> Its operational need for this document is less pressing now than >> when the -00 version was published back in 2011. Nevertheless, I >> find it valuable and correct to put the final nail in 6to4's coffin >> at this point in time. While the operational community for the most >> part has already realised that 6to4 has no future, there might be >> some who have not been paying attention and formal deprecation of >> the protocol may help prevent them from making the mistake of >> attempting to base production systems on it. >> >> I have one minor comment though: In section 1, it says «a >> substantial amount of 6to4 traffic is still observed by IPv6 >> content providers». While I do see 6to4 traffic, it is quite far >> from being of "substantial" levels. I would therefore recommend >> replacing "substantial" with something milder like "noticeable", >> "measurable", or something along those lines. >> >> For what it's worth, today the Google public IPv6 graph shows just >> a measly 0.01% of their total IPv6 traffic being Teredo/6to4, so >> it's not just me. > > "Tore, > > However, that fraction of Google traffic multipled by Google users > represents something like 100000 users. I don't think we can dismiss > that number of people too easily. It's a matter of taste whether > that's "substantial" or "noticeable". > > Brian" > > Actually, to those end users, the impact might be both quite > significant and noticeable. > > I think one explanation for the use of 6to4 tunnelled IPv6 is that > their hosts aren't preferring native IPv4 over tunnelled IPv6 I agree. Just to note that this explanation covers a number of 6to4 users, but not all. There are 6to4 users who have no v4 on their hosts - it is an intermediary router which does 6to4. Alex > (assuming Google make their services equally available over both, > which I think they do), as per RFC3484 address selection rules. > > The other explanation for it could be that these users have Happy > Eyeballs enabled browsers and the browser is choosing to try to use > both IPv4 and IPv6, despite the IPv6 being tunnelled rather than > native. From a Happy Eyeballs robustness perspective, that would be > quite a reasonable thing to do I think. > > If the end-hosts aren't following RFC3484's default preferences, then > breaking 6to4 might cause the sorts of timeouts that HE is designed > to overcome. RFC3484 is quite old now (2003), and as a minor data > point I first encountered the implementation of them in around > 2008/2009 if I recall correctly on my Linux system (as I was using > 6to4 at the time and wanted to use tunnelled IPv6 in preference to > native IPv4 - gai.conf(3) is the way you change that). So if some > hosts are still preferring tunnelled 6to4 IPv6 over native IPv4 then > perhaps they're also not going to be running a HE enabled browser > either. > > Perhaps it might be possible for somebody at Google to produce a list > of the browser User-Agent strings for people still using 6to4 to see > if the browsers being used are HE enabled, which might also give some > insight into RFC3484 support in the underlying OSes. > > Regards, Mark. > > > > > > > > > > > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sat Jan 24 05:44:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79D61A0100 for ; Sat, 24 Jan 2015 05:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmK6JWMWW5-8 for ; Sat, 24 Jan 2015 05:44:12 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266681A0040 for ; Sat, 24 Jan 2015 05:44:11 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7680520A72 for ; Sat, 24 Jan 2015 08:44:10 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 24 Jan 2015 08:44:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=lN8Dlp/ZAM9u/BmtFzMNwm Kd0Ko=; b=Kl9up30o/fzkQ0bpXqHtAkoOYA1fPCs0wHcYoI/CGjdHdcjW1sijpN IT9doZK1ywAB+uEKgbjYyMGPirE8XBId74TPFaBi8YXWG7lV5E0z51HtkQ/LYp8O npXn4snrbvmkBBCbfzMl4i8DqdEFD92gHc7sx+56DtZ3Jvv5pqQw8= X-Sasl-enc: n9XI5mn7OmnY3ipWC+Z842Zq2w6el2k/rHVJEG5Z2Gte 1422107050 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id EFF4BC00022; Sat, 24 Jan 2015 08:44:09 -0500 (EST) Message-ID: <54C3A192.6060108@network-heretics.com> Date: Sat, 24 Jan 2015 08:43:46 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> In-Reply-To: <201501181900.t0IJ02ps011175@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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: Sat, 24 Jan 2015 13:44:13 -0000 I have no objection to this version of the document. I think the principal value in approving it is to allow the WG to move past it. Keith On 01/18/2015 02:00 PM, fred@cisco.com wrote: > This is to initiate a one week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Jan 24 06:06:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0231A1A02 for ; Sat, 24 Jan 2015 06:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHeaPMZqChFF for ; Sat, 24 Jan 2015 06:06:21 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 080081A1AA5 for ; Sat, 24 Jan 2015 06:06:16 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id t0OE6GH9012357 for ; Sat, 24 Jan 2015 09:06:16 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU t0OE6GH9012357 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1422108376; bh=Q9+m6mv89c4+LkdYMPa0MZDF2Jhn6kJUQG/qezuEbVo=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=BFsflACh5JoFE87d+HhQRTmnMVXRB8l6Z91E2oe/JQCg2SaWHly+y1CLz0CYdhalv 7yN4qE0KHWnguvMDieRiziygb45GrRYg6PNHp/FfwRy63U8bdk7QiAyDc8ErmbSHGP r2TIVRKk/cJupyU8oGgA96cBNlQx2ZefzM5w9LtE= Received: from MX3.WPI.EDU (mx3.wpi.edu [130.215.36.147]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id t0OE6GZ0012354 for ; Sat, 24 Jan 2015 09:06:16 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by MX3.WPI.EDU (8.14.4/8.14.4) with ESMTP id t0OE6Fvv013416 for ; Sat, 24 Jan 2015 09:06:15 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id t0OE6En0030120 for ; Sat, 24 Jan 2015 09:06:14 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id t0OE6EO2030119 for v6ops@ietf.org; Sat, 24 Jan 2015 09:06:14 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Sat, 24 Jan 2015 09:06:14 -0500 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20150124140613.GQ18618@angus.ind.WPI.EDU> References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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: Sat, 24 Jan 2015 14:06:24 -0000 On Wed, Jan 21, 2015 at 11:47:23AM -0800, James Woodyatt wrote: > On Wed, Jan 21, 2015 at 4:16 AM, Lorenzo Colitti wrote: > > > > > 1. Is it necessary to formally deprecate RFC 6732? It's an individual > > submission. (Not that I support RFC 6732 in any way, to be sure.) > > > > Rather than ask if it's necessary, I'd prefer to ask if there is any sane > reason to think RFC 6732 is anything more than an historical curiosity. > > If 6to4-PMT isn't of any more than historical interest, then let's please > move its category to Historic so that its applicability will not be > confused with other practical non-standard protocol specifications > published by IETF in the Informational category, many of which rightly > enjoy widespread deployment today, e.g. PPPoE. +1 — I agree with Lorenzo’s comments 2. and 3. and James' comment here. From nobody Sun Jan 25 21:03:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0DF1A1BF2 for ; Sun, 25 Jan 2015 21:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE1q8KEhwhCl for ; Sun, 25 Jan 2015 21:03:31 -0800 (PST) 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 B8A831A1BF1 for ; Sun, 25 Jan 2015 21:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1373; q=dns/txt; s=iport; t=1422248612; x=1423458212; h=from:to:subject:date:message-id:mime-version; bh=b5a+DDNbqqzv3uZYquA88wM+nkMY/+tqxF1rhKBjsnM=; b=KjwLEZFPo/H/3jghVKRv+xRF8w2I0vioNZisUnl8l3AQsABJtg1mnxw0 ZTXoopN9X8VnXnsjJVmuKqhTX0BKqsKNWwL4xJSDY06BeImkubmL+CSkv gRbkkoYxZrjHsQCbrteEqgpj7HTG4OAFDniOcf+wfYD6b7FhRT7UgDSEf s=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFAMTJxVStJA2L/2dsb2JhbABagwaBL4J8yj9DAQEBAQF9hBMjaAFKAjQnBCGIHq4+j0iUFgEBAQEBBQEBAQEBAQEBGpJnLoETBY5ugVOBKYYlkjwig26CM34BAQE X-IronPort-AV: E=Sophos;i="5.09,466,1418083200"; d="asc'?scan'208";a="117482403" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 26 Jan 2015 05:03:31 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0Q53TvT024317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Jan 2015 05:03:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sun, 25 Jan 2015 23:03:29 -0600 From: "Fred Baker (fred)" To: V6 Ops List Thread-Topic: draft-ietf-v6ops-siit-dc-2xlat Thread-Index: AQHQOSVstdgEFfvlQUi6KZXbkDo3Eg== Date: Mon, 26 Jan 2015 05:03:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_62DF3C92-F8D4-4FAE-87B4-676380E52565"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] draft-ietf-v6ops-siit-dc-2xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 05:03:33 -0000 --Apple-Mail=_62DF3C92-F8D4-4FAE-87B4-676380E52565 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We agreed to take draft-anderson-v6ops-siit-dc as a working group draft; = it is now posted as draft-ietf-v6ops-siit-dc. I=E2=80=99m not clear on = draft-anderson-v6ops-siit-dc-2xlat; Tore has done the work to post it as = draft-ietf-v6ops-siit-dc-2xlat, but I don=E2=80=99t know the collected = opinion. Do we want it (and do we want draft-anderson-v6ops-siit-dc-eam) = as working group drafts? --Apple-Mail=_62DF3C92-F8D4-4FAE-87B4-676380E52565 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 iQEVAwUBVMXKn59ieig10VPpAQJoQQgAm3fknQ5h4+Wrbv7wzIgbG/eqr6p9lUNJ b1p8i2exTKI16Db5sRR93FrkEPbLvjIivanI0fW+Rt+u48BePjXkxrkHBB3ExIX0 s1UfYOeeWjSu4leSV6sbIr9uc0MaWgYTtRStD+RNpDZDoSCMaXITlvnlq5FgituK Ucl1erBhMwa5LmDdv5YBZKzPjqWnwqD+Q0YdIfSEqtNPFHonygjiTdPNJdFGdv6C cMeuEhvmePP1H1iK2ZnENT/PZvcv4USFKmkXz3YG8uct3uHGAdNdR2Ce7O5/pqDd Q87k0z+nIOmPlgbVFEqTJJIlocXLOZxzfG/RuM+gHSnZ6gPFLLRO5g== =E3tw -----END PGP SIGNATURE----- --Apple-Mail=_62DF3C92-F8D4-4FAE-87B4-676380E52565-- From nobody Mon Jan 26 15:32:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5521A0067 for ; Mon, 26 Jan 2015 15:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.203 X-Spam-Level: ** X-Spam-Status: No, score=2.203 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIUJJF9Qdks3 for ; Mon, 26 Jan 2015 15:31:59 -0800 (PST) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369371A006B for ; Mon, 26 Jan 2015 15:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1422315118; bh=iD87iq/9RXneDtyDsyNWB0dEWapyz/Fky0bKGeprl3c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=P5nY7M5CrVp/gOpAzVvwdG2UqGpGGDgiNtWkW43nsTqIHe6cZYNr/AQUSH457XXldBTAruSYgdzEPzqSywzx6c38pYyY2MfBl2aRkHXXwqUj4/JfqQDzrfWYaT1YmVHacOa180i1XuPBMX8W2u1QxLpT2UyRrDsHlQFiIdXMXHodAXUbmzjOs/BM82e7EoGkqTbhqGawE/juTkr0UjZfQLUkSL0anq2BpF03LCse67Ws39uCwJugpNp2Dva5vVKxXPr+zPaGjgTIr6y7nCHtqeJty2mZ8LdAnmiQB1QOdY5uGwLL+HSbHIB8+deJCvlxIo//yp2ThtKsBET2kFjqPA== Received: from [66.196.81.171] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jan 2015 23:31:58 -0000 Received: from [98.139.212.243] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jan 2015 23:31:58 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 26 Jan 2015 23:31:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 436598.34456.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: AJaukYYVM1llD0HbmLl3_xp8M2XP71nKIfUtyUmCtimP8REvq5JU11bUN5h0qW_ JRkDQLnROaSkRsSUMOehxpTGKOXRolI3qrjeqF24UYsxVBHiBZgQWxtA1mcH9WvpjizK3W7.ryOb uRfh86GJA948FKsK2kbA6jJy7kO7R84w._92c5cEeT3MptjmWD_JIK.HvZMdqs3hdgoLfdyNAx1M 65ItD69QqqS.07w93WUSJrQfGwY5vFqbvu92TosR42r5JVwryoNSCOuQNLy_QZhowjOM9MKTl1Ev H14pHLX6WEU54jnjAqMKdwzdAOvHHIaDv6UM2eKhlD_yEflYo.kNwxoQW7x.t47Ifk_H_M777yko 5QpqR2HsnzLs.Cl537PfdbvhWdM52dbxoJMPcf6gDcd7x0Vc6b0apLsnk3m.B22wTXQB.2VvZFo7 frH9GlmgHUVO9GkgEiQzhqIkwQMcN1Dew1FrSrZuef04yc_eZ_PAyBEqPZ9yuw.3kP1vXahIaFdm D7FrJLdGb.oKkevzrwVCXfdHjqB2jfGEdac6bsxxgsoPG2g-- Received: by 76.13.26.79; Mon, 26 Jan 2015 23:31:57 +0000 Date: Mon, 26 Jan 2015 23:31:57 +0000 (UTC) From: Mark ZZZ Smith To: Lorenzo Colitti Message-ID: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_862322_365031483.1422315117205" Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 23:32:02 -0000 ------=_Part_862322_365031483.1422315117205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm fine with that. If it is easy enough, I think it would be interesting to get a bit more of = an insight into who/what is still using 6to4 either in preference to or in = (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 users. From: Lorenzo Colitti To: Mark ZZZ Smith =20 Cc: Brian E Carpenter ; Tore Anderson ; "v6ops@ietf.org" =20 Sent: Wednesday, 21 January 2015, 23:16 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC =20 Yes, those users will definitely be impacted. Which is why the document doe= s not suggest dropping the packets or turning off the relays, except by say= ing things like "operators SHOULD [...] consider carefully whether the [...= ] relay can be discontinued as traffic diminishes". That's quite reasonable= guidance, I think. Remember: 0.01% is really a very small number. Multiplying it by 1 billion = (like Brian did) makes it seem large, but that's just a trick of the light.= Look at it this way: if all the relays in the world were turned off overni= ght and all the 6to4 users were unable to reach a given website, that websi= te's reliability would still be 99.99% of what it was before. I support this document in its current form. I only have three comments bey= ond seconding Tore's objection to the draft calling 6to4 "substantial": = =20 - Is it necessary to formally deprecate RFC 6732? It's an individual sub= mission. (Not that I support RFC 6732 in any way, to be sure.) =20 - I don't think the sentence "some content providers have been reluctant= to make content available over IPv6" is true, or at least any true for any= non-trivial value of "some". 6to4 was a problem for content providers a fe= w years ago, but we've moved past it. =20 - It might be useful to cite that another reason 6to4 is being deprecate= d is that IPv6 is actually being deployed these days (finally). =20 On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith = wrote: ----- Original Message ----- From: Brian E Carpenter To: Tore Anderson ; v6ops@ietf.org Cc: Sent: Wednesday, 21 January 2015, 7:14 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On 21/01/2015 02:16, Tore Anderson wrote: > * fred@cisco.com > >> This is to initiate a one week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > > I have read this document, and I think it is ready to move forward. > > Its operational need for this document is less pressing now than when > the -00 version was published back in 2011. Nevertheless, I find it > valuable and correct to put the final nail in 6to4's coffin at this > point in time. While the operational community for the most part has > already realised that 6to4 has no future, there might be some who have > not been paying attention and formal deprecation of the protocol may > help prevent them from making the mistake of attempting to base > production systems on it. > > I have one minor comment though: In section 1, it says =C2=ABa substantia= l > amount of 6to4 traffic is still observed by IPv6 content providers=C2=BB. > While I do see 6to4 traffic, it is quite far from being of "substantial" > levels. I would therefore recommend replacing "substantial" with > something milder like "noticeable", "measurable", or something along > those lines. > > For what it's worth, today the Google public IPv6 graph shows just a > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not > just me. "Tore, However, that fraction of Google traffic multipled by Google users represents something like 100000 users. I don't think we can dismiss that number of people too easily. It's a matter of taste whether that's "substantial" or "noticeable". =C2=A0 =C2=A0 Brian" Actually, to those end users, the impact might be both quite significant an= d noticeable. I think one explanation for the use of 6to4 tunnelled IPv6 is that their ho= sts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google make= their services equally available over both, which I think they do), as per= RFC3484 address selection rules. The other explanation for it could be that these users have Happy Eyeballs = enabled browsers and the browser is choosing to try to use both IPv4 and IP= v6, despite the IPv6 being tunnelled rather than native. From a Happy Eyeba= lls robustness perspective, that would be quite a reasonable thing to do I = think. If the end-hosts aren't following RFC3484's default preferences, then break= ing 6to4 might cause the sorts of timeouts that HE is designed to overcome.= RFC3484 is quite old now (2003), and as a minor data point I first encount= ered the implementation of them in around 2008/2009 if I recall correctly o= n my Linux system (as I was using 6to4 at the time and wanted to use tunnel= led IPv6 in preference to native IPv4 - gai.conf(3) is the way you change t= hat). So if some hosts are still preferring tunnelled 6to4 IPv6 over native= IPv4 then perhaps they're also not going to be running a HE enabled browse= r either. Perhaps it might be possible for somebody at Google to produce a list of th= e browser User-Agent strings for people still using 6to4 to see if the brow= sers being used are HE enabled, which might also give some insight into RFC= 3484 support in the underlying OSes. Regards, Mark. _______________________________________________ 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 ------=_Part_862322_365031483.1422315117205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm fine with that.

If it is easy enough, I think it would be interesting to = get a bit more of an insight into who/what is still using 6to4 either in pr= eference to or in (HE) parallel to native IPv4 by e.g., collecting User-Age= nt for 6to4 users.

From: Lorenzo Coli= tti <lorenzo@google.com>
To= : Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Cc: Brian E Carpenter <brian.e.c= arpenter@gmail.com>; Tore Anderson <tore@fud.no>; "v6ops@ietf.org"= <v6ops@ietf.org>
Sent: Wednesday, 21 January 2015, 23:16
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic= WGLC

Yes, those users will definitely be imp= acted. Which is why the document does not suggest dropping the packets or t= urning off the relays, except by saying things like "operators SHOULD [...]= consider carefully whether the [...] relay can be discontinued as traffic = diminishes". That's quite reasonable guidance, I think.

Remember: 0.01% is really a very small number. Multiplying i= t by 1 billion (like Brian did) makes it seem large, but that's just a tric= k of the light. Look at it this way: if all the relays in the world were tu= rned off overnight and all the 6to4 users were unable to reach a given webs= ite, that website's reliability would still be 99.99% of what it was before= .

I support this document in its cu= rrent form. I only have three comments beyond seconding Tore's objection to= the draft calling 6to4 "substantial":
  1. Is it necessary to= formally deprecate RFC 6732? It's an individual submission. (Not that I su= pport RFC 6732 in any way, to be sure.)
  2. I don't = think the sentence "some content providers have been reluctant to make cont= ent available over IPv6" is true, or at least any true for any non-trivial = value of "some". 6to4 was a problem for content providers a few years ago, = but we've moved past it.
  3. It might be useful to c= ite that another reason 6to4 is being deprecated is that IPv6 is actually b= eing deployed these days (finally).



On Wed= , Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.co= m.au> wrote:




----- Original Message -----
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: Tore Anderson <tore@fud.no&= gt;; v6ops@ietf.org
Cc:
Sent: Wednesday, 21 January 2015, 7:14
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

On 21/01/2015 02:16, Tore Anderson wrote:
> * fred@cisco.com
>
>> This is to initiate a one week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-hi= storic.
>
> I have read this document, and I think it is ready to move forward. >
> Its operational need for this document is less pressing now than when<= br clear=3D"none"> > the -00 version was published back in 2011. Nevertheless, I find it > valuable and correct to put the final nail in 6to4's coffin at this > point in time. While the operational community for the most part has > already realised that 6to4 has no future, there might be some who have=
> not been paying attention and formal deprecation of the protocol may > help prevent them from making the mistake of attempting to base
> production systems on it.
>
> I have one minor comment though: In section 1, it says =C2=ABa substan= tial
> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB.
> While I do see 6to4 traffic, it is quite far from being of "substantia= l"
> levels. I would therefore recommend replacing "substantial" with
> something milder like "noticeable", "measurable", or something along > those lines.
>
> For what it's worth, today the Google public IPv6 graph shows just a > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's no= t
> just me.

"Tore,

However, that fraction of Google traffic multipled by Google users
represents something like 100000 users. I don't think we can dismiss
that number of people too easily. It's a matter of taste whether
that's "substantial" or "noticeable".

    Brian"

Actually, to those end users, the impact might be both quite si= gnificant and noticeable.

I think one explanation for the use of 6to4 tunnelled IPv6 is that their ho= sts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google make= their services equally available over both, which I think they do), as per= RFC3484 address selection rules.

The other explanation for it could be that these users have Happy Eyeballs = enabled browsers and the browser is choosing to try to use both IPv4 and IP= v6, despite the IPv6 being tunnelled rather than native. From a Happy Eyeba= lls robustness perspective, that would be quite a reasonable thing to do I = think.

If the end-hosts aren't following RFC3484's default preferences, then break= ing 6to4 might cause the sorts of timeouts that HE is designed to overcome.= RFC3484 is quite old now (2003), and as a minor data point I first encount= ered the implementation of them in around 2008/2009 if I recall correctly o= n my Linux system (as I was using 6to4 at the time and wanted to use tunnel= led IPv6 in preference to native IPv4 - gai.conf(3) is the way you change t= hat). So if some hosts are still preferring tunnelled 6to4 IPv6 over native= IPv4 then perhaps they're also not going to be running a HE enabled browse= r either.

Perhaps it might be possible for somebody at Google to produce a list of th= e browser User-Agent strings for people still using 6to4 to see if the brow= sers being used are HE enabled, which might also give some insight into RFC= 3484 support in the underlying OSes.

Regards,
Mark.














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

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

<= br>
------=_Part_862322_365031483.1422315117205-- From nobody Mon Jan 26 16:34:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3E21B2B30 for ; Mon, 26 Jan 2015 16:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlbZREvXmFWe for ; Mon, 26 Jan 2015 16:34:47 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377231B2B4C for ; Mon, 26 Jan 2015 16:34:40 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id fp1so15329679pdb.2 for ; Mon, 26 Jan 2015 16:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9lGGeZ7rh9lj8l8q3ZHbifunABNo6kH0XQcw67TFUVE=; b=ZQkTyKEJCC6voBODwsLZ3ylVLqV9M4l+M7dEeGg8TI8Ce2loztuoSe8JxExA7dwDAC 11E8raVXtuShgOy6B4R7tgzmpm6/pv+yn52Kpr5VnikTXo/vdrXxbUadd7jHgPmSXSj3 r7VDQ4h1oFzModNqzzcTz5cdgAGlhleJqJ38wF2qBXwdKCjldGBUI0beiic59r/geBf0 6qT0rj9UdjjPphlVPEeMpKcoVLXN/1mLq+0XtMgT1EgZ0uzDt68AdvFheKzJuEX1+bCc 5JxGMaQ2gRKEaHTe9w02ylswlUluzXaoU80X0nVefTOVndTF1+w5tN5MxGdvf+50hnlq 0BqQ== X-Received: by 10.70.137.66 with SMTP id qg2mr38455222pdb.73.1422318879523; Mon, 26 Jan 2015 16:34:39 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id nw2sm7113556pdb.43.2015.01.26.16.34.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 16:34:38 -0800 (PST) Message-ID: <54C6DD1D.2030000@gmail.com> Date: Tue, 27 Jan 2015 13:34:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Colitti , Mark ZZZ Smith References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 00:34:49 -0000 Hi Lorenzo, First a general comment - I have a bunch of proposed text improvements from David Farmer and I will try to get a version out with all those that are non-controversial during this week, and whatever consensual changes I find in the recent threads. More in line... On 22/01/2015 01:16, Lorenzo Colitti wrote: > Yes, those users will definitely be impacted. Which is why the document= > does not suggest dropping the packets or turning off the relays, except= by > saying things like "operators SHOULD [...] consider carefully whether t= he > [...] relay can be discontinued as traffic diminishes". That's quite > reasonable guidance, I think. >=20 > Remember: 0.01% is really a very small number. Multiplying it by 1 bill= ion > (like Brian did) makes it seem large, but that's just a trick of the li= ght. > Look at it this way: if all the relays in the world were turned off > overnight and all the 6to4 users were unable to reach a given website, = that > website's reliability would still be 99.99% of what it was before. Sure. But if I was one of the ~100k users concerned, I wouldn't want to be told that I wasn't important. I think s/substantial/measurable/ should fix this. > I support this document in its current form. I only have three comments= > beyond seconding Tore's objection to the draft calling 6to4 "substantia= l": >=20 > 1. Is it necessary to formally deprecate RFC 6732? It's an individua= l > submission. (Not that I support RFC 6732 in any way, to be sure.) Well, reviewing the emails I've archived, I see mild support for formally obsoleting it and no strong opposition. > 2. I don't think the sentence "some content providers have been > reluctant to make content available over IPv6" is true, or at least = any > true for any non-trivial value of "some". 6to4 was a problem for con= tent > providers a few years ago, but we've moved past it. Probably true as a specific reason. I hear "lack of demand" as the usual excuse today. Will rephrase. > 3. It might be useful to cite that another reason 6to4 is being > deprecated is that IPv6 is actually being deployed these days (final= ly). But there are still many IPv6 deserts in the world, so I'm a bit wary of trying to find an objective way of saying that. Brian >=20 >=20 > On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith > wrote: >=20 >> >> >> >> >> ----- Original Message ----- >> From: Brian E Carpenter >> To: Tore Anderson ; v6ops@ietf.org >> Cc: >> Sent: Wednesday, 21 January 2015, 7:14 >> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> >> On 21/01/2015 02:16, Tore Anderson wrote: >>> * fred@cisco.com >>> >>>> This is to initiate a one week working group last call of >>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. >>> >>> I have read this document, and I think it is ready to move forward. >>> >>> Its operational need for this document is less pressing now than when= >>> the -00 version was published back in 2011. Nevertheless, I find it >>> valuable and correct to put the final nail in 6to4's coffin at this >>> point in time. While the operational community for the most part has >>> already realised that 6to4 has no future, there might be some who hav= e >>> not been paying attention and formal deprecation of the protocol may >>> help prevent them from making the mistake of attempting to base >>> production systems on it. >>> >>> I have one minor comment though: In section 1, it says =C2=ABa substa= ntial >>> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB. >>> While I do see 6to4 traffic, it is quite far from being of "substanti= al" >>> levels. I would therefore recommend replacing "substantial" with >>> something milder like "noticeable", "measurable", or something along >>> those lines. >>> >>> For what it's worth, today the Google public IPv6 graph shows just a >>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's n= ot >>> just me. >> >> "Tore, >> >> However, that fraction of Google traffic multipled by Google users >> represents something like 100000 users. I don't think we can dismiss >> that number of people too easily. It's a matter of taste whether >> that's "substantial" or "noticeable". >> >> Brian" >> >> Actually, to those end users, the impact might be both quite significa= nt >> and noticeable. >> >> I think one explanation for the use of 6to4 tunnelled IPv6 is that the= ir >> hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Goog= le >> make their services equally available over both, which I think they do= ), as >> per RFC3484 address selection rules. >> >> The other explanation for it could be that these users have Happy Eyeb= alls >> enabled browsers and the browser is choosing to try to use both IPv4 a= nd >> IPv6, despite the IPv6 being tunnelled rather than native. From a Happ= y >> Eyeballs robustness perspective, that would be quite a reasonable thin= g to >> do I think. >> >> If the end-hosts aren't following RFC3484's default preferences, then >> breaking 6to4 might cause the sorts of timeouts that HE is designed to= >> overcome. RFC3484 is quite old now (2003), and as a minor data point I= >> first encountered the implementation of them in around 2008/2009 if I >> recall correctly on my Linux system (as I was using 6to4 at the time a= nd >> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3= ) is >> the way you change that). So if some hosts are still preferring tunnel= led >> 6to4 IPv6 over native IPv4 then perhaps they're also not going to be >> running a HE enabled browser either. >> >> Perhaps it might be possible for somebody at Google to produce a list = of >> the browser User-Agent strings for people still using 6to4 to see if t= he >> browsers being used are HE enabled, which might also give some insight= into >> RFC3484 support in the underlying OSes. >> >> Regards, >> Mark. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 From nobody Mon Jan 26 16:43:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E681A037B for ; Mon, 26 Jan 2015 16:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGKqSn0vMZjy for ; Mon, 26 Jan 2015 16:43:35 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFF51A0062 for ; Mon, 26 Jan 2015 16:43:34 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so1869689igb.2 for ; Mon, 26 Jan 2015 16:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rw5Ey2PavVuC8YhsPobKf9kw2JSE6xu9in+nm3DiaPY=; b=TPcq2h5vvPb6zt93rTKYPkgv0xp4QGgi5Z+79ApMEsKxC7a+4Fh1z8TWDaDEV4pj0I nRXyLk7b7j12rNanNrE8DD2nR61CxT7YxRXLheCfmE5GO+fQNCpVp91DTyQib9K8/cri 3YkXk2FxmXMQgzVjj73w+pJ/8UH0mzWOsEKXu2AkzfnNMdjR3VbWRXqj7+HJxRlbQxBC ZxlQ1wcyyD6ySs46RjNFHQd8bRPZ6Tinre63bIf7sqQVHqbAKEaCPLnuaS1ZNrZBJypZ XrMlJgAPhB8IL3wdO5I0XGEI3fCso+bnGGQiJyjI8Gs5/WUNRyM4BZ8CEHJwKmoDB9Cx ebwA== 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=rw5Ey2PavVuC8YhsPobKf9kw2JSE6xu9in+nm3DiaPY=; b=H7W8BgetERuLJ1mQiYiZr1E/3W7ZEJ4t4EluNGxDekc8SUPzJtpj4H/s2VwOqr4RHc 6aoIwLpsiqHS8u+i3/08b9G6MFsUjwMZJw3jORZwbC4PIDUfypQk2LFa0uc78Tm1Zr0G qeeghU5azfYfwa2nBysvhwZfq2S11B8EySpsBTMHuHDBWHXxLww3hqhZhT4Vsnq5gqBg vSu/AEzoIRLaWU1lKyvWOhTE4p05YM5ucuc6lcZ/0PU1KOSzOnjnvgOsYH2fAHqIY89m HxbVvzIEVDQYMzPk6xZ2U6t5n3+vV6+08NV1UBGQlEtwwbHOzalW1p2+CcLKuqNpY3d6 61eA== X-Gm-Message-State: ALoCoQlF+bUCE+toiXWD1nzmf8HxmfvBIS7g6TMOXhhsOArVvthOmpUosTlJfD+2JynGbe0K9g3t X-Received: by 10.50.222.70 with SMTP id qk6mr19233665igc.47.1422319414083; Mon, 26 Jan 2015 16:43:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Mon, 26 Jan 2015 16:43:13 -0800 (PST) In-Reply-To: <54C6DD1D.2030000@gmail.com> References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> <54C6DD1D.2030000@gmail.com> From: Lorenzo Colitti Date: Tue, 27 Jan 2015 09:43:13 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11344d8a6f34e9050d978b75 Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 00:43:36 -0000 --001a11344d8a6f34e9050d978b75 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 27, 2015 at 9:34 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Sure. But if I was one of the ~100k users concerned, I wouldn't want to > be told that I wasn't important. I think s/substantial/measurable/ > should fix this. > I see. Ok then Brian you're a unique, precious snowflake, one in ten thousand. :-P But seriously - no opposition to s/substantial/measurable/ - because it is, in fact, measurable. > Well, reviewing the emails I've archived, I see mild support for > formally obsoleting it and no strong opposition. > I suppose my question was really only procedural: *can* we even obsolete an individual submission? It's not a document based on IETF consensus, so if IETF consensus was not necessary to publish it, then how can IETF consensus be sufficient to obsolete it? --001a11344d8a6f34e9050d978b75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 27, 2015 at 9:34 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
Sure. B= ut if I was one of the ~100k users concerned, I wouldn't want to
be told that I wasn't important. I think s/substantial/measurable/
should fix this.

I see. Ok then Brian = =C2=A0you're a unique, precious snowflake, one in ten thousand. :-P

But seriously - no opposition to s/substantial/measur= able/ - because it is, in fact, measurable.
=C2=A0
Well, reviewing the emails I've archived, I s= ee mild support for
formally obsoleting it and no strong opposition.

<= /div>
I suppose my question was really only procedural: *can* we even o= bsolete an individual submission? It's not a document based on IETF con= sensus, so if IETF consensus was not necessary to publish it, then how can = IETF consensus be sufficient to obsolete it?
--001a11344d8a6f34e9050d978b75-- From nobody Mon Jan 26 17:13:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E241C1A0264 for ; Mon, 26 Jan 2015 17:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF-AyZVHfWsg for ; Mon, 26 Jan 2015 17:13:36 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974F91A1AB1 for ; Mon, 26 Jan 2015 17:13:35 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id fl12so15499848pdb.6 for ; Mon, 26 Jan 2015 17:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lWkr4AxNAVUFrav3DElMNGwsMnreKTcpWaDdlOdo4jo=; b=MzxwJX0FOCWw6b58BzHjCy3ZhEDbW7gC4dGBhcPNDY/xDQZtAkoQ2rbFRJf+nGuKZe dBT6IsW81JxaRfXV3O17DvmAEAx8fJl+2ypgLrmQ1ybY6MdTG65NDmeXZejIGPq59OgW WGerkJ0aiNfg/oBUZFp3T43KAic65WDjLTY+GmsDVhdDu1IJQ9jCt/lJSfpKAwl0znIi ACsyT5ief3Gv8PVuh/NIxAprbFoDnI57DeN8deJvpMbyHf+x03TGJb1ELCkKEkZ6cUPJ obupuCpZt+0L6Uav8L0zfokUsantHSjmgvHIkk+xzn9qk8QCsJg9AdXCZSDGyGZ3noxv Mscg== X-Received: by 10.70.123.10 with SMTP id lw10mr38463731pdb.161.1422321214866; Mon, 26 Jan 2015 17:13:34 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id om9sm2793292pbb.34.2015.01.26.17.13.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 17:13:33 -0800 (PST) Message-ID: <54C6E63D.3090805@gmail.com> Date: Tue, 27 Jan 2015 14:13:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> <54C6DD1D.2030000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 01:13:38 -0000 On 27/01/2015 13:43, Lorenzo Colitti wrote: > On Tue, Jan 27, 2015 at 9:34 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Sure. But if I was one of the ~100k users concerned, I wouldn't want to >> be told that I wasn't important. I think s/substantial/measurable/ >> should fix this. >> > > I see. Ok then Brian you're a unique, precious snowflake, one in ten > thousand. :-P > > But seriously - no opposition to s/substantial/measurable/ - because it is, > in fact, measurable. > > >> Well, reviewing the emails I've archived, I see mild support for >> formally obsoleting it and no strong opposition. >> > > I suppose my question was really only procedural: *can* we even obsolete an > individual submission? It's not a document based on IETF consensus, so if > IETF consensus was not necessary to publish it, then how can IETF consensus > be sufficient to obsolete it? Terminology alert: it's an *independent* submission, not an *individual* submission (the latter is an IETF stream draft but with no associated WG). So, your question is valid. I suggest we leave it as "obsoletes" for now and let somebody with a higher IETF pay grade decide. Next time I bump into the Independent Series Editor (which will be later this week in Rotorua NZ, as it happens) I will ask if there's a precedent. Brian From nobody Mon Jan 26 18:07:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86BE1A1B2F for ; Mon, 26 Jan 2015 18:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, 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 aALuBw41z37k for ; Mon, 26 Jan 2015 18:07:26 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D0A1A1B39 for ; Mon, 26 Jan 2015 18:07:20 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id lj1so15223142pab.6 for ; Mon, 26 Jan 2015 18:07:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3n7qUB4RtatnoMusuN/nRoH0ihIMObUNHO+m3Ii3CPk=; b=e+NUzCTXvwTXAfzpHmRBrjquINlnlZAA8F4rKRwjvuJzmv6Op4aG/cj3EV1MRmJwyy l37p7yGMraHA9MP5tyRrAYTPVNSuCL9A9ea5Gpn3qp18XDE4qrjhQ44QRUuSMc1IkK9t 8sKf+Xv1WEseQZsur7WLEe3kAjJdp2IJA3j9ZPy9I+13hDZielifkX2EeXJ4mKsp+V2O B3IGm/UAVE9eSKgi6jTg1rC2+b12ezg0uzlj41u6rGPWORPVqNqntYkYyaoRVAms6ISO qSAkcMWuKkIQGB08kGqJDFZDbaAPPjs/bToL+i/VEs4MxVSmN4TGYvdjONUl/nSV0xUw ygJw== X-Gm-Message-State: ALoCoQkId4Fx42HQcyig3+el99ekZf4fkEbXaq12wYbpxlCGrFQoI10hKbgHUMwdo8803kJi3Zg7 MIME-Version: 1.0 X-Received: by 10.68.181.69 with SMTP id du5mr1225930pbc.157.1422324438622; Mon, 26 Jan 2015 18:07:18 -0800 (PST) Received: by 10.70.67.226 with HTTP; Mon, 26 Jan 2015 18:07:18 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:149e:8b1c:d990:2562] In-Reply-To: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 27 Jan 2015 12:07:18 +1000 Message-ID: From: George Michaelson To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7b6dbaf6eb7db4050d98b60a Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 02:07:31 -0000 --047d7b6dbaf6eb7db4050d98b60a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ask and ye shall receive Here is a days summary of os, browser, os+browser as determined by the APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Python httpagentparser module to detect OS and Version info. -George os,Windows+7,22287 os,Windows+8.1,1743 os,Windows+Vista,939 os,Windows+8,894 os,Windows+XP,431 os,Macintosh+[na],124 os,iOS+[na],44 os,Linux+[na],29 os,Windows+NT 6.4,6 os,Windows Phone+8.1,2 os,ChromeOS+6310.68.0,2 browser,Chrome,18297 browser,Firefox,3774 browser,Microsoft Internet Explorer,2872 browser,Opera,1439 browser,Safari,110 browser,AndroidBrowser,5 browser,[na],2 browser,SeaMonkey,2 os+browser,Windows+7.Chrome,15539 os+browser,Windows+7.Firefox,3033 os+browser,Windows+7.Microsoft Internet Explorer,2432 os+browser,Windows+8.1.Chrome,1305 os+browser,Windows+7.Opera,1277 os+browser,Windows+8.Chrome,644 os+browser,Windows+Vista.Chrome,537 os+browser,Windows+8.1.Firefox,311 os+browser,Windows+Vista.Microsoft Internet Explorer,230 os+browser,Windows+XP.Chrome,216 os+browser,Windows+Vista.Firefox,148 os+browser,Windows+XP.Firefox,134 os+browser,Windows+8.Firefox,116 os+browser,Windows+8.Microsoft Internet Explorer,87 os+browser,Windows+8.1.Opera,64 os+browser,Windows+8.1.Microsoft Internet Explorer,63 os+browser,Macintosh+[na].Safari,60 os+browser,Windows+XP.Microsoft Internet Explorer,54 os+browser,Windows+8.Opera,45 os+browser,iOS+[na].Safari,44 os+browser,Macintosh+[na].Chrome,36 os+browser,Windows+XP.Opera,25 os+browser,Windows+Vista.Opera,24 os+browser,Macintosh+[na].Firefox,24 os+browser,Linux+[na].Chrome,16 os+browser,Linux+[na].Firefox,8 os+browser,Windows+7.Safari,6 os+browser,Linux+[na].AndroidBrowser,5 os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 os+browser,Macintosh+[na].Opera,4 os+browser,Windows+XP.SeaMonkey,2 os+browser,Windows+NT 6.4.Chrome,2 os+browser,Windows+8.[na],2 os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 os+browser,ChromeOS+6310.68.0.Chrome,2 On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith wrote: > I'm fine with that. > > If it is easy enough, I think it would be interesting to get a bit more o= f > an insight into who/what is still using 6to4 either in preference to or i= n > (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 user= s. > > ------------------------------ > *From:* Lorenzo Colitti > *To:* Mark ZZZ Smith > *Cc:* Brian E Carpenter ; Tore Anderson < > tore@fud.no>; "v6ops@ietf.org" > *Sent:* Wednesday, 21 January 2015, 23:16 > > *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > Yes, those users will definitely be impacted. Which is why the document > does not suggest dropping the packets or turning off the relays, except b= y > saying things like "operators SHOULD [...] consider carefully whether the > [...] relay can be discontinued as traffic diminishes". That's quite > reasonable guidance, I think. > > Remember: 0.01% is really a very small number. Multiplying it by 1 billio= n > (like Brian did) makes it seem large, but that's just a trick of the ligh= t. > Look at it this way: if all the relays in the world were turned off > overnight and all the 6to4 users were unable to reach a given website, th= at > website's reliability would still be 99.99% of what it was before. > > I support this document in its current form. I only have three comments > beyond seconding Tore's objection to the draft calling 6to4 "substantial"= : > > 1. Is it necessary to formally deprecate RFC 6732? It's an individual > submission. (Not that I support RFC 6732 in any way, to be sure.) > 2. I don't think the sentence "some content providers have been > reluctant to make content available over IPv6" is true, or at least an= y > true for any non-trivial value of "some". 6to4 was a problem for conte= nt > providers a few years ago, but we've moved past it. > 3. It might be useful to cite that another reason 6to4 is being > deprecated is that IPv6 is actually being deployed these days (finally= ). > > > > > On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith > wrote: > > > > > > ----- Original Message ----- > From: Brian E Carpenter > To: Tore Anderson ; v6ops@ietf.org > Cc: > Sent: Wednesday, 21 January 2015, 7:14 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > On 21/01/2015 02:16, Tore Anderson wrote: > > * fred@cisco.com > > > >> This is to initiate a one week working group last call of > >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > > > > I have read this document, and I think it is ready to move forward. > > > > Its operational need for this document is less pressing now than when > > the -00 version was published back in 2011. Nevertheless, I find it > > valuable and correct to put the final nail in 6to4's coffin at this > > point in time. While the operational community for the most part has > > already realised that 6to4 has no future, there might be some who have > > not been paying attention and formal deprecation of the protocol may > > help prevent them from making the mistake of attempting to base > > production systems on it. > > > > I have one minor comment though: In section 1, it says =C2=ABa substant= ial > > amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB. > > While I do see 6to4 traffic, it is quite far from being of "substantial= " > > levels. I would therefore recommend replacing "substantial" with > > something milder like "noticeable", "measurable", or something along > > those lines. > > > > For what it's worth, today the Google public IPv6 graph shows just a > > measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not > > just me. > > "Tore, > > However, that fraction of Google traffic multipled by Google users > represents something like 100000 users. I don't think we can dismiss > that number of people too easily. It's a matter of taste whether > that's "substantial" or "noticeable". > > Brian" > > Actually, to those end users, the impact might be both quite significant > and noticeable. > > I think one explanation for the use of 6to4 tunnelled IPv6 is that their > hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google > make their services equally available over both, which I think they do), = as > per RFC3484 address selection rules. > > The other explanation for it could be that these users have Happy Eyeball= s > enabled browsers and the browser is choosing to try to use both IPv4 and > IPv6, despite the IPv6 being tunnelled rather than native. From a Happy > Eyeballs robustness perspective, that would be quite a reasonable thing t= o > do I think. > > If the end-hosts aren't following RFC3484's default preferences, then > breaking 6to4 might cause the sorts of timeouts that HE is designed to > overcome. RFC3484 is quite old now (2003), and as a minor data point I > first encountered the implementation of them in around 2008/2009 if I > recall correctly on my Linux system (as I was using 6to4 at the time and > wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3) i= s > the way you change that). So if some hosts are still preferring tunnelled > 6to4 IPv6 over native IPv4 then perhaps they're also not going to be > running a HE enabled browser either. > > Perhaps it might be possible for somebody at Google to produce a list of > the browser User-Agent strings for people still using 6to4 to see if the > browsers being used are HE enabled, which might also give some insight in= to > RFC3484 support in the underlying OSes. > > Regards, > Mark. > > > > > > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b6dbaf6eb7db4050d98b60a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ask and ye shall receive

Here is a days= summary of os, browser, os+browser as determined by the APNIC 1x1 capture,= using 2002: as the source IPv6 address, and the Python httpagentparser mod= ule to detect OS and Version info.

-George

os,Windows+7,22287
os,Windows+8.1,1743
os,Windows+Vista,939
os,Windows+8,894
os,Windows= +XP,431
os,Macintosh+[na],124
os,iOS+[na],44
= os,Linux+[na],29
os,Windows+NT 6.4,6
os,Windows Phone+8= .1,2
os,ChromeOS+6310.68.0,2

= browser,Chrome,18297
browser,Firefox,3774
browser,Micro= soft Internet Explorer,2872
browser,Opera,1439
browser,= Safari,110
browser,AndroidBrowser,5
browser,[na],2
browser,SeaMonkey,2

os+browser,Wi= ndows+7.Chrome,15539
os+browser,Windows+7.Firefox,3033
= os+browser,Windows+7.Microsoft Internet Explorer,2432
os+browser,= Windows+8.1.Chrome,1305
os+browser,Windows+7.Opera,1277
os+browser,Windows+8.Chrome,644
os+browser,Windows+Vista.Chrome,= 537
os+browser,Windows+8.1.Firefox,311
os+browser,Windo= ws+Vista.Microsoft Internet Explorer,230
os+browser,Windows+XP.Ch= rome,216
os+browser,Windows+Vista.Firefox,148
os+browse= r,Windows+XP.Firefox,134
os+browser,Windows+8.Firefox,116
os+browser,Windows+8.Microsoft Internet Explorer,87
os+browser= ,Windows+8.1.Opera,64
os+browser,Windows+8.1.Microsoft Internet E= xplorer,63
os+browser,Macintosh+[na].Safari,60
os+brows= er,Windows+XP.Microsoft Internet Explorer,54
os+browser,Windows+8= .Opera,45
os+browser,iOS+[na].Safari,44
os+browser,Maci= ntosh+[na].Chrome,36
os+browser,Windows+XP.Opera,25
os+= browser,Windows+Vista.Opera,24
os+browser,Macintosh+[na].Firefox,= 24
os+browser,Linux+[na].Chrome,16
os+browser,Linux+[na= ].Firefox,8
os+browser,Windows+7.Safari,6
os+browser,Li= nux+[na].AndroidBrowser,5
os+browser,Windows+NT 6.4.Microsoft Int= ernet Explorer,4
os+browser,Macintosh+[na].Opera,4
os+b= rowser,Windows+XP.SeaMonkey,2
os+browser,Windows+NT 6.4.Chrome,2<= /div>
os+browser,Windows+8.[na],2
os+browser,Windows Phone+8.= 1.Microsoft Internet Explorer,2
os+browser,ChromeOS+6310.68.0.Chr= ome,2


On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:
I'm fine = with that.

If it is easy enough, I think it would be interesting to get a b= it more of an insight into who/what is still using 6to4 either in preferenc= e to or in (HE) parallel to native IPv4 by e.g., collecting User-Agent for = 6to4 users.

From: Lorenzo Colitti <lorenzo@google.com>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
<= span style=3D"font-weight:bold">Cc: Brian E Carpenter <brian.e.carpente= r@gmail.com>; Tore Anderson <tore@fud.no>; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Wednesday, 21 January 2015, 23:16

Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Yes, th= ose users will definitely be impacted. Which is why the document does not s= uggest dropping the packets or turning off the relays, except by saying thi= ngs like "operators SHOULD [...] consider carefully whether the [...] = relay can be discontinued as traffic diminishes". That's quite rea= sonable guidance, I think.

Remember: 0.01= % is really a very small number. Multiplying it by 1 billion (like Brian di= d) makes it seem large, but that's just a trick of the light. Look at i= t this way: if all the relays in the world were turned off overnight and al= l the 6to4 users were unable to reach a given website, that website's r= eliability would still be 99.99% of what it was before.

I support this document in its current form. I only ha= ve three comments beyond seconding Tore's objection to the draft callin= g 6to4 "substantial":
  1. Is it necessary to formal= ly deprecate RFC 6732? It's an individual submission. (Not that I suppo= rt RFC 6732 in any way, to be sure.)
  2. I don't= think the sentence "some content providers have been reluctant to mak= e content available over IPv6" is true, or at least any true for any n= on-trivial value of "some". 6to4 was a problem for content provid= ers a few years ago, but we've moved past it.
    3. It might be useful to cite that another reason 6to4 is being deprecated i= s that IPv6 is actually being deployed these days (finally).



<= div>On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <<= a rel=3D"nofollow" shape=3D"rect" href=3D"mailto:markzzzsmith@yahoo.com.au"= target=3D"_blank">markzzzsmith@yahoo.com.au> wrote:




----- Original Message -----
From: Brian E Carpenter <brian.e.carpenter@gmail.c= om>
To: Tore Anderson <tore@fud.no>; v6ops@ietf.org
Cc:
Sent: Wednesday, 21 January 2015, 7:14
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

On 21/01/2015 02:16, Tore Anderson wrote:
> * fred@cisco.com
>
>> This is to initiate a one week working group last call of
>> http://tools.ietf.= org/html/draft-ietf-v6ops-6to4-to-historic.
>
> I have read this document, and I think it is ready to move forward. >
> Its operational need for this document is less pressing now than when<= br clear=3D"none"> > the -00 version was published back in 2011. Nevertheless, I find it > valuable and correct to put the final nail in 6to4's coffin at thi= s
> point in time. While the operational community for the most part has > already realised that 6to4 has no future, there might be some who have=
> not been paying attention and formal deprecation of the protocol may > help prevent them from making the mistake of attempting to base
> production systems on it.
>
> I have one minor comment though: In section 1, it says =C2=ABa substan= tial
> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB.
> While I do see 6to4 traffic, it is quite far from being of "subst= antial"
> levels. I would therefore recommend replacing "substantial" = with
> something milder like "noticeable", "measurable", = or something along
> those lines.
>
> For what it's worth, today the Google public IPv6 graph shows just= a
> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it'= s not
> just me.

"Tore,

However, that fraction of Google traffic multipled by Google users
represents something like 100000 users. I don't think we can dismiss that number of people too easily. It's a matter of taste whether
that's "substantial" or "noticeable".

=C2=A0 =C2=A0 Brian"

Actually, to those end users, the impact might be both quite si= gnificant and noticeable.

I think one explanation for the use of 6to4 tunnelled IPv6 is that their ho= sts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google = make their services equally available over both, which I think they do), as= per RFC3484 address selection rules.

The other explanation for it could be that these users have Happy Eyeballs = enabled browsers and the browser is choosing to try to use both IPv4 and IP= v6, despite the IPv6 being tunnelled rather than native. From a Happy Eyeba= lls robustness perspective, that would be quite a reasonable thing to do I = think.

If the end-hosts aren't following RFC3484's default preferences, th= en breaking 6to4 might cause the sorts of timeouts that HE is designed to o= vercome. RFC3484 is quite old now (2003), and as a minor data point I first= encountered the implementation of them in around 2008/2009 if I recall cor= rectly on my Linux system (as I was using 6to4 at the time and wanted to us= e tunnelled IPv6 in preference to native IPv4 - gai.conf(3) is the way you = change that). So if some hosts are still preferring tunnelled 6to4 IPv6 ove= r native IPv4 then perhaps they're also not going to be running a HE en= abled browser either.

Perhaps it might be possible for somebody at Google to produce a list of th= e browser User-Agent strings for people still using 6to4 to see if the brow= sers being used are HE enabled, which might also give some insight into RFC= 3484 support in the underlying OSes.

Regards,
Mark.

<= br>

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


--047d7b6dbaf6eb7db4050d98b60a-- From nobody Mon Jan 26 19:35:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDD81A1BC5 for ; Mon, 26 Jan 2015 19:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=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 vQIBZTKGHqzc for ; Mon, 26 Jan 2015 19:35:22 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE2F1A1BB9 for ; Mon, 26 Jan 2015 19:35:22 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id y10so16130615pdj.9 for ; Mon, 26 Jan 2015 19:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EDb6cug72Jzs56I4eXonTeFflR++8J31IRwbL59MKLg=; b=qaVPHA8WE3QLvW6f8CsMoiIj+XrB9Gy6nLmPBRhCdxIoR/sF7NhH2c3H03AM+RQzNw k8j7bQWOgl8W6Q0wV5sVb8UFNBoN/330aY1uCbG8+jn8gGiopVcAO5lymBgV5Y5DW44z dtGFQeigLc+ryI9VAfQOmnDHlGwDW0j5gvJJN1XHSmdQQNXhe3lrXim5nsVy2qNJZ7uF GlIs7uml0LBbAcwoSqyU48ySvlORNkhITde2Q+Xjjf1JMYb5kEb5u9q2qPYplToOpxEd jpCFV24CmfXtWTLx6dINHm+8Q0WGeaPtY5WfpJ9yNeCwQqc8gipqyrpvus5SAyutMF2G b1rw== X-Received: by 10.66.222.135 with SMTP id qm7mr39890997pac.38.1422329720938; Mon, 26 Jan 2015 19:35:20 -0800 (PST) Received: from ?IPv6:2406:e007:73ff:1:28cc:dc4c:9703:6781? ([2406:e007:73ff:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ci17sm11019310pdb.70.2015.01.26.19.35.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 19:35:19 -0800 (PST) Message-ID: <54C70777.8080704@gmail.com> Date: Tue, 27 Jan 2015 16:35:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: George Michaelson , Mark ZZZ Smith References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 03:35:25 -0000 Measurable, indeed. Windows 8? Really? Regards Brian On 27/01/2015 15:07, George Michaelson wrote: > Ask and ye shall receive >=20 > Here is a days summary of os, browser, os+browser as determined by the > APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Pyth= on > httpagentparser module to detect OS and Version info. >=20 > -George >=20 > os,Windows+7,22287 > os,Windows+8.1,1743 > os,Windows+Vista,939 > os,Windows+8,894 > os,Windows+XP,431 > os,Macintosh+[na],124 > os,iOS+[na],44 > os,Linux+[na],29 > os,Windows+NT 6.4,6 > os,Windows Phone+8.1,2 > os,ChromeOS+6310.68.0,2 >=20 > browser,Chrome,18297 > browser,Firefox,3774 > browser,Microsoft Internet Explorer,2872 > browser,Opera,1439 > browser,Safari,110 > browser,AndroidBrowser,5 > browser,[na],2 > browser,SeaMonkey,2 >=20 > os+browser,Windows+7.Chrome,15539 > os+browser,Windows+7.Firefox,3033 > os+browser,Windows+7.Microsoft Internet Explorer,2432 > os+browser,Windows+8.1.Chrome,1305 > os+browser,Windows+7.Opera,1277 > os+browser,Windows+8.Chrome,644 > os+browser,Windows+Vista.Chrome,537 > os+browser,Windows+8.1.Firefox,311 > os+browser,Windows+Vista.Microsoft Internet Explorer,230 > os+browser,Windows+XP.Chrome,216 > os+browser,Windows+Vista.Firefox,148 > os+browser,Windows+XP.Firefox,134 > os+browser,Windows+8.Firefox,116 > os+browser,Windows+8.Microsoft Internet Explorer,87 > os+browser,Windows+8.1.Opera,64 > os+browser,Windows+8.1.Microsoft Internet Explorer,63 > os+browser,Macintosh+[na].Safari,60 > os+browser,Windows+XP.Microsoft Internet Explorer,54 > os+browser,Windows+8.Opera,45 > os+browser,iOS+[na].Safari,44 > os+browser,Macintosh+[na].Chrome,36 > os+browser,Windows+XP.Opera,25 > os+browser,Windows+Vista.Opera,24 > os+browser,Macintosh+[na].Firefox,24 > os+browser,Linux+[na].Chrome,16 > os+browser,Linux+[na].Firefox,8 > os+browser,Windows+7.Safari,6 > os+browser,Linux+[na].AndroidBrowser,5 > os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 > os+browser,Macintosh+[na].Opera,4 > os+browser,Windows+XP.SeaMonkey,2 > os+browser,Windows+NT 6.4.Chrome,2 > os+browser,Windows+8.[na],2 > os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 > os+browser,ChromeOS+6310.68.0.Chrome,2 >=20 >=20 > On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith > wrote: >=20 >> I'm fine with that. >> >> If it is easy enough, I think it would be interesting to get a bit mor= e of >> an insight into who/what is still using 6to4 either in preference to o= r in >> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 u= sers. >> >> ------------------------------ >> *From:* Lorenzo Colitti >> *To:* Mark ZZZ Smith >> *Cc:* Brian E Carpenter ; Tore Anderson <= >> tore@fud.no>; "v6ops@ietf.org" >> *Sent:* Wednesday, 21 January 2015, 23:16 >> >> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> >> Yes, those users will definitely be impacted. Which is why the documen= t >> does not suggest dropping the packets or turning off the relays, excep= t by >> saying things like "operators SHOULD [...] consider carefully whether = the >> [...] relay can be discontinued as traffic diminishes". That's quite >> reasonable guidance, I think. >> >> Remember: 0.01% is really a very small number. Multiplying it by 1 bil= lion >> (like Brian did) makes it seem large, but that's just a trick of the l= ight. >> Look at it this way: if all the relays in the world were turned off >> overnight and all the 6to4 users were unable to reach a given website,= that >> website's reliability would still be 99.99% of what it was before. >> >> I support this document in its current form. I only have three comment= s >> beyond seconding Tore's objection to the draft calling 6to4 "substanti= al": >> >> 1. Is it necessary to formally deprecate RFC 6732? It's an individu= al >> submission. (Not that I support RFC 6732 in any way, to be sure.) >> 2. I don't think the sentence "some content providers have been >> reluctant to make content available over IPv6" is true, or at least= any >> true for any non-trivial value of "some". 6to4 was a problem for co= ntent >> providers a few years ago, but we've moved past it. >> 3. It might be useful to cite that another reason 6to4 is being >> deprecated is that IPv6 is actually being deployed these days (fina= lly). >> >> >> >> >> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith >> wrote: >> >> >> >> >> >> ----- Original Message ----- >> From: Brian E Carpenter >> To: Tore Anderson ; v6ops@ietf.org >> Cc: >> Sent: Wednesday, 21 January 2015, 7:14 >> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> >> On 21/01/2015 02:16, Tore Anderson wrote: >>> * fred@cisco.com >>> >>>> This is to initiate a one week working group last call of >>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. >>> >>> I have read this document, and I think it is ready to move forward. >>> >>> Its operational need for this document is less pressing now than when= >>> the -00 version was published back in 2011. Nevertheless, I find it >>> valuable and correct to put the final nail in 6to4's coffin at this >>> point in time. While the operational community for the most part has >>> already realised that 6to4 has no future, there might be some who hav= e >>> not been paying attention and formal deprecation of the protocol may >>> help prevent them from making the mistake of attempting to base >>> production systems on it. >>> >>> I have one minor comment though: In section 1, it says =C2=ABa substa= ntial >>> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB. >>> While I do see 6to4 traffic, it is quite far from being of "substanti= al" >>> levels. I would therefore recommend replacing "substantial" with >>> something milder like "noticeable", "measurable", or something along >>> those lines. >>> >>> For what it's worth, today the Google public IPv6 graph shows just a >>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's n= ot >>> just me. >> >> "Tore, >> >> However, that fraction of Google traffic multipled by Google users >> represents something like 100000 users. I don't think we can dismiss >> that number of people too easily. It's a matter of taste whether >> that's "substantial" or "noticeable". >> >> Brian" >> >> Actually, to those end users, the impact might be both quite significa= nt >> and noticeable. >> >> I think one explanation for the use of 6to4 tunnelled IPv6 is that the= ir >> hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Goog= le >> make their services equally available over both, which I think they do= ), as >> per RFC3484 address selection rules. >> >> The other explanation for it could be that these users have Happy Eyeb= alls >> enabled browsers and the browser is choosing to try to use both IPv4 a= nd >> IPv6, despite the IPv6 being tunnelled rather than native. From a Happ= y >> Eyeballs robustness perspective, that would be quite a reasonable thin= g to >> do I think. >> >> If the end-hosts aren't following RFC3484's default preferences, then >> breaking 6to4 might cause the sorts of timeouts that HE is designed to= >> overcome. RFC3484 is quite old now (2003), and as a minor data point I= >> first encountered the implementation of them in around 2008/2009 if I >> recall correctly on my Linux system (as I was using 6to4 at the time a= nd >> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3= ) is >> the way you change that). So if some hosts are still preferring tunnel= led >> 6to4 IPv6 over native IPv4 then perhaps they're also not going to be >> running a HE enabled browser either. >> >> Perhaps it might be possible for somebody at Google to produce a list = of >> the browser User-Agent strings for people still using 6to4 to see if t= he >> browsers being used are HE enabled, which might also give some insight= into >> RFC3484 support in the underlying OSes. >> >> Regards, >> Mark. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Jan 26 19:37:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E0B1A1BC5 for ; Mon, 26 Jan 2015 19:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 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, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaMLxhorRETB for ; Mon, 26 Jan 2015 19:37:06 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDA41A1BB9 for ; Mon, 26 Jan 2015 19:37:06 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rl12so12861373iec.11 for ; Mon, 26 Jan 2015 19:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CCM2sSuUSv65geGzRxoRtorGEfLpfmMnNL1vprTNtJ4=; b=SZIT1FlBZ7wzhIKpqFsx58r0W7DLJdYp7SXdUM2pbz0t7FUKJ661ITWdKrWZDdOD6S sDtdxVhaL66m+os3BW6zpz0Lugp78IVtLW4IJyo3ECrnAwhWpzRrRP+MQr6U0/gLcT6L Pi80pIgSUBRq9n1z4/dHSnHnyuxV1gpLMH6ra9r6Wiz2qy+pUwq5JEKFGq/K6LA/564m RJr5npeF+ef1ACIat92Jb6uLYkIPCVZWTRVVnrqwwfIGqrGdcRzY8FyNP82FQsNXG1mr AoPi36fEWhjIKk5FpxSWdI/fN8eE40qsBjuAHL9geHokjJxxr1VG144gtXfKzR7YFFca xFbQ== 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=CCM2sSuUSv65geGzRxoRtorGEfLpfmMnNL1vprTNtJ4=; b=UAjAOlVlmI2TwZOo0nDHh+NaLQ1LPUNM/T/kEyQanxx6wSlaWBF7q0B7zrKeM0vEQN 1U16Kqgax45q1NzVXOyUzK1PRO4HQjoh4s+xK4L6CCGSM7GOse+g2is8C5vdCXbTt7Ls 0RMZ0g2E2TCW9/0fJiPLukTDTp0RcskgFAtaq/buyW8kyAnnlZqgTxS8Hw5ir5ln5+ti KyGZEFDKYcTYpdHgJKJ5m7bOynEKEKo1VhYDUkMCbqj1X9Ht8MsU+K4T1iKsSOCiEzTU IyMY/0QRN0JWTdPEe2HHYVGst5B/0oa6mDrvuRp2i2PQU0J9FtvUgs8W3dkfvVj4ycAc i2LA== X-Gm-Message-State: ALoCoQlG3g6MofbjTCLT5uYHlXKgX28WvoWyT9iFAQ4IEL2pXuey/AXS0ibugtsXBCPQzNOhSBAh X-Received: by 10.50.117.41 with SMTP id kb9mr839516igb.37.1422329825236; Mon, 26 Jan 2015 19:37:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Mon, 26 Jan 2015 19:36:44 -0800 (PST) In-Reply-To: <54C70777.8080704@gmail.com> References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> From: Lorenzo Colitti Date: Tue, 27 Jan 2015 12:36:44 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e011605ccfcbe00050d99f7c1 Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 03:37:10 -0000 --089e011605ccfcbe00050d99f7c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are these probes made to an IPv6-only hostname? If so, then of course we'd expect OSes to attempt 6to4. On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Measurable, indeed. > > Windows 8? Really? > > Regards > Brian > > On 27/01/2015 15:07, George Michaelson wrote: > > Ask and ye shall receive > > > > Here is a days summary of os, browser, os+browser as determined by the > > APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Pyth= on > > httpagentparser module to detect OS and Version info. > > > > -George > > > > os,Windows+7,22287 > > os,Windows+8.1,1743 > > os,Windows+Vista,939 > > os,Windows+8,894 > > os,Windows+XP,431 > > os,Macintosh+[na],124 > > os,iOS+[na],44 > > os,Linux+[na],29 > > os,Windows+NT 6.4,6 > > os,Windows Phone+8.1,2 > > os,ChromeOS+6310.68.0,2 > > > > browser,Chrome,18297 > > browser,Firefox,3774 > > browser,Microsoft Internet Explorer,2872 > > browser,Opera,1439 > > browser,Safari,110 > > browser,AndroidBrowser,5 > > browser,[na],2 > > browser,SeaMonkey,2 > > > > os+browser,Windows+7.Chrome,15539 > > os+browser,Windows+7.Firefox,3033 > > os+browser,Windows+7.Microsoft Internet Explorer,2432 > > os+browser,Windows+8.1.Chrome,1305 > > os+browser,Windows+7.Opera,1277 > > os+browser,Windows+8.Chrome,644 > > os+browser,Windows+Vista.Chrome,537 > > os+browser,Windows+8.1.Firefox,311 > > os+browser,Windows+Vista.Microsoft Internet Explorer,230 > > os+browser,Windows+XP.Chrome,216 > > os+browser,Windows+Vista.Firefox,148 > > os+browser,Windows+XP.Firefox,134 > > os+browser,Windows+8.Firefox,116 > > os+browser,Windows+8.Microsoft Internet Explorer,87 > > os+browser,Windows+8.1.Opera,64 > > os+browser,Windows+8.1.Microsoft Internet Explorer,63 > > os+browser,Macintosh+[na].Safari,60 > > os+browser,Windows+XP.Microsoft Internet Explorer,54 > > os+browser,Windows+8.Opera,45 > > os+browser,iOS+[na].Safari,44 > > os+browser,Macintosh+[na].Chrome,36 > > os+browser,Windows+XP.Opera,25 > > os+browser,Windows+Vista.Opera,24 > > os+browser,Macintosh+[na].Firefox,24 > > os+browser,Linux+[na].Chrome,16 > > os+browser,Linux+[na].Firefox,8 > > os+browser,Windows+7.Safari,6 > > os+browser,Linux+[na].AndroidBrowser,5 > > os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 > > os+browser,Macintosh+[na].Opera,4 > > os+browser,Windows+XP.SeaMonkey,2 > > os+browser,Windows+NT 6.4.Chrome,2 > > os+browser,Windows+8.[na],2 > > os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 > > os+browser,ChromeOS+6310.68.0.Chrome,2 > > > > > > On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith < > markzzzsmith@yahoo.com.au> > > wrote: > > > >> I'm fine with that. > >> > >> If it is easy enough, I think it would be interesting to get a bit mor= e > of > >> an insight into who/what is still using 6to4 either in preference to o= r > in > >> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 > users. > >> > >> ------------------------------ > >> *From:* Lorenzo Colitti > >> *To:* Mark ZZZ Smith > >> *Cc:* Brian E Carpenter ; Tore Anderson < > >> tore@fud.no>; "v6ops@ietf.org" > >> *Sent:* Wednesday, 21 January 2015, 23:16 > >> > >> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >> > >> Yes, those users will definitely be impacted. Which is why the documen= t > >> does not suggest dropping the packets or turning off the relays, excep= t > by > >> saying things like "operators SHOULD [...] consider carefully whether > the > >> [...] relay can be discontinued as traffic diminishes". That's quite > >> reasonable guidance, I think. > >> > >> Remember: 0.01% is really a very small number. Multiplying it by 1 > billion > >> (like Brian did) makes it seem large, but that's just a trick of the > light. > >> Look at it this way: if all the relays in the world were turned off > >> overnight and all the 6to4 users were unable to reach a given website, > that > >> website's reliability would still be 99.99% of what it was before. > >> > >> I support this document in its current form. I only have three comment= s > >> beyond seconding Tore's objection to the draft calling 6to4 > "substantial": > >> > >> 1. Is it necessary to formally deprecate RFC 6732? It's an individu= al > >> submission. (Not that I support RFC 6732 in any way, to be sure.) > >> 2. I don't think the sentence "some content providers have been > >> reluctant to make content available over IPv6" is true, or at least > any > >> true for any non-trivial value of "some". 6to4 was a problem for > content > >> providers a few years ago, but we've moved past it. > >> 3. It might be useful to cite that another reason 6to4 is being > >> deprecated is that IPv6 is actually being deployed these days > (finally). > >> > >> > >> > >> > >> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith < > markzzzsmith@yahoo.com.au > >>> wrote: > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> From: Brian E Carpenter > >> To: Tore Anderson ; v6ops@ietf.org > >> Cc: > >> Sent: Wednesday, 21 January 2015, 7:14 > >> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >> > >> On 21/01/2015 02:16, Tore Anderson wrote: > >>> * fred@cisco.com > >>> > >>>> This is to initiate a one week working group last call of > >>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > >>> > >>> I have read this document, and I think it is ready to move forward. > >>> > >>> Its operational need for this document is less pressing now than when > >>> the -00 version was published back in 2011. Nevertheless, I find it > >>> valuable and correct to put the final nail in 6to4's coffin at this > >>> point in time. While the operational community for the most part has > >>> already realised that 6to4 has no future, there might be some who hav= e > >>> not been paying attention and formal deprecation of the protocol may > >>> help prevent them from making the mistake of attempting to base > >>> production systems on it. > >>> > >>> I have one minor comment though: In section 1, it says =C2=ABa substa= ntial > >>> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB. > >>> While I do see 6to4 traffic, it is quite far from being of > "substantial" > >>> levels. I would therefore recommend replacing "substantial" with > >>> something milder like "noticeable", "measurable", or something along > >>> those lines. > >>> > >>> For what it's worth, today the Google public IPv6 graph shows just a > >>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's n= ot > >>> just me. > >> > >> "Tore, > >> > >> However, that fraction of Google traffic multipled by Google users > >> represents something like 100000 users. I don't think we can dismiss > >> that number of people too easily. It's a matter of taste whether > >> that's "substantial" or "noticeable". > >> > >> Brian" > >> > >> Actually, to those end users, the impact might be both quite significa= nt > >> and noticeable. > >> > >> I think one explanation for the use of 6to4 tunnelled IPv6 is that the= ir > >> hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Goog= le > >> make their services equally available over both, which I think they > do), as > >> per RFC3484 address selection rules. > >> > >> The other explanation for it could be that these users have Happy > Eyeballs > >> enabled browsers and the browser is choosing to try to use both IPv4 a= nd > >> IPv6, despite the IPv6 being tunnelled rather than native. From a Happ= y > >> Eyeballs robustness perspective, that would be quite a reasonable thin= g > to > >> do I think. > >> > >> If the end-hosts aren't following RFC3484's default preferences, then > >> breaking 6to4 might cause the sorts of timeouts that HE is designed to > >> overcome. RFC3484 is quite old now (2003), and as a minor data point I > >> first encountered the implementation of them in around 2008/2009 if I > >> recall correctly on my Linux system (as I was using 6to4 at the time a= nd > >> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3= ) > is > >> the way you change that). So if some hosts are still preferring > tunnelled > >> 6to4 IPv6 over native IPv4 then perhaps they're also not going to be > >> running a HE enabled browser either. > >> > >> Perhaps it might be possible for somebody at Google to produce a list = of > >> the browser User-Agent strings for people still using 6to4 to see if t= he > >> browsers being used are HE enabled, which might also give some insight > into > >> RFC3484 support in the underlying OSes. > >> > >> Regards, > >> Mark. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >> > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e011605ccfcbe00050d99f7c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Are these probes made to an IPv6-only hostname? If so, the= n of course we'd expect OSes to attempt 6to4.

On Tue, Jan 27, 2015 at 12:35 PM, Bri= an E Carpenter <brian.e.carpenter@gmail.com> wrote= :
Measurable, indeed.

Windows 8? Really?

Regards
=C2=A0 =C2=A0Brian

On 27/01/2015 15:07, George Michaelson wrote:
> Ask and ye shall receive
>
> Here is a days summary of os, browser, os+browser as determined by the=
> APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Pyt= hon
> httpagentparser module to detect OS and Version info.
>
> -George
>
> os,Windows+7,22287
> os,Windows+8.1,1743
> os,Windows+Vista,939
> os,Windows+8,894
> os,Windows+XP,431
> os,Macintosh+[na],124
> os,iOS+[na],44
> os,Linux+[na],29
> os,Windows+NT 6.4,6
> os,Windows Phone+8.1,2
> os,ChromeOS+6310.68.0,2
>
> browser,Chrome,18297
> browser,Firefox,3774
> browser,Microsoft Internet Explorer,2872
> browser,Opera,1439
> browser,Safari,110
> browser,AndroidBrowser,5
> browser,[na],2
> browser,SeaMonkey,2
>
> os+browser,Windows+7.Chrome,15539
> os+browser,Windows+7.Firefox,3033
> os+browser,Windows+7.Microsoft Internet Explorer,2432
> os+browser,Windows+8.1.Chrome,1305
> os+browser,Windows+7.Opera,1277
> os+browser,Windows+8.Chrome,644
> os+browser,Windows+Vista.Chrome,537
> os+browser,Windows+8.1.Firefox,311
> os+browser,Windows+Vista.Microsoft Internet Explorer,230
> os+browser,Windows+XP.Chrome,216
> os+browser,Windows+Vista.Firefox,148
> os+browser,Windows+XP.Firefox,134
> os+browser,Windows+8.Firefox,116
> os+browser,Windows+8.Microsoft Internet Explorer,87
> os+browser,Windows+8.1.Opera,64
> os+browser,Windows+8.1.Microsoft Internet Explorer,63
> os+browser,Macintosh+[na].Safari,60
> os+browser,Windows+XP.Microsoft Internet Explorer,54
> os+browser,Windows+8.Opera,45
> os+browser,iOS+[na].Safari,44
> os+browser,Macintosh+[na].Chrome,36
> os+browser,Windows+XP.Opera,25
> os+browser,Windows+Vista.Opera,24
> os+browser,Macintosh+[na].Firefox,24
> os+browser,Linux+[na].Chrome,16
> os+browser,Linux+[na].Firefox,8
> os+browser,Windows+7.Safari,6
> os+browser,Linux+[na].AndroidBrowser,5
> os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4
> os+browser,Macintosh+[na].Opera,4
> os+browser,Windows+XP.SeaMonkey,2
> os+browser,Windows+NT 6.4.Chrome,2
> os+browser,Windows+8.[na],2
> os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2
> os+browser,ChromeOS+6310.68.0.Chrome,2
>
>
> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
> wrote:
>
>> I'm fine with that.
>>
>> If it is easy enough, I think it would be interesting to get a bit= more of
>> an insight into who/what is still using 6to4 either in preference = to or in
>> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6t= o4 users.
>>
>>=C2=A0 =C2=A0------------------------------
>>=C2=A0 *From:* Lorenzo Colitti <lorenzo@google.com>
>> *To:* Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>> *Cc:* Brian E Carpenter <brian.e.carpenter@gmail.com>; Tore Anderson <
>> tore@fud.no>; "v6ops@ietf.org" <v6ops@ietf.org>
>> *Sent:* Wednesday, 21 January 2015, 23:16
>>
>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
>>
>> Yes, those users will definitely be impacted. Which is why the doc= ument
>> does not suggest dropping the packets or turning off the relays, e= xcept by
>> saying things like "operators SHOULD [...] consider carefully= whether the
>> [...] relay can be discontinued as traffic diminishes". That&= #39;s quite
>> reasonable guidance, I think.
>>
>> Remember: 0.01% is really a very small number. Multiplying it by 1= billion
>> (like Brian did) makes it seem large, but that's just a trick = of the light.
>> Look at it this way: if all the relays in the world were turned of= f
>> overnight and all the 6to4 users were unable to reach a given webs= ite, that
>> website's reliability would still be 99.99% of what it was bef= ore.
>>
>> I support this document in its current form. I only have three com= ments
>> beyond seconding Tore's objection to the draft calling 6to4 &q= uot;substantial":
>>
>>=C2=A0 =C2=A0 1. Is it necessary to formally deprecate RFC 6= 732? It's an individual
>>=C2=A0 =C2=A0 submission. (Not that I support RFC = 6732 in any way, to be sure.)
>>=C2=A0 =C2=A0 2. I don't think the sentence "some c= ontent providers have been
>>=C2=A0 =C2=A0 reluctant to make content available = over IPv6" is true, or at least any
>>=C2=A0 =C2=A0 true for any non-trivial value of "some". 6= to4 was a problem for content
>>=C2=A0 =C2=A0 providers a few years ago, but we've moved past i= t.
>>=C2=A0 =C2=A0 3. It might be useful to cite that another rea= son 6to4 is being
>>=C2=A0 =C2=A0 deprecated is= that IPv6 is actually being deployed these days (finally).
>>
>>
>>
>>
>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au
>>> wrote:
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> To: Tore Anderson <tore@fud.no>; v6ops@ietf.org
>> Cc:
>> Sent: Wednesday, 21 January 2015, 7:14
>> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
>>
>> On 21/01/2015 02:16, Tore Anderson wrote:
>>> * fred@cisco.com
>>>
>>>> This is to initiate a one week working group last call of<= br> >>>> http://tools.ietf.org/html/draft-ietf-v6op= s-6to4-to-historic.
>>>
>>> I have read this document, and I think it is ready to move for= ward.
>>>
>>> Its operational need for this document is less pressing now th= an when
>>> the -00 version was published back in 2011. Nevertheless, I fi= nd it
>>> valuable and correct to put the final nail in 6to4's coffi= n at this
>>> point in time. While the operational community for the most pa= rt has
>>> already realised that 6to4 has no future, there might be some = who have
>>> not been paying attention and formal deprecation of the protoc= ol may
>>> help prevent them from making the mistake of attempting to bas= e
>>> production systems on it.
>>>
>>> I have one minor comment though: In section 1, it says =C2=ABa= substantial
>>> amount of 6to4 traffic is still observed by IPv6 content provi= ders=C2=BB.
>>> While I do see 6to4 traffic, it is quite far from being of &qu= ot;substantial"
>>> levels. I would therefore recommend replacing "substantia= l" with
>>> something milder like "noticeable", "measurable= ", or something along
>>> those lines.
>>>
>>> For what it's worth, today the Google public IPv6 graph sh= ows just a
>>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so= it's not
>>> just me.
>>
>> "Tore,
>>
>> However, that fraction of Google traffic multipled by Google users=
>> represents something like 100000 users. I don't think we can d= ismiss
>> that number of people too easily. It's a matter of taste wheth= er
>> that's "substantial" or "noticeable".
>>
>>=C2=A0 =C2=A0 =C2=A0Brian"
>>
>> Actually, to those end users, the impact might be both quite signi= ficant
>> and noticeable.
>>
>> I think one explanation for the use of 6to4 tunnelled IPv6 is that= their
>> hosts aren't preferring native IPv4 over tunnelled IPv6 (assum= ing Google
>> make their services equally available over both, which I think the= y do), as
>> per RFC3484 address selection rules.
>>
>> The other explanation for it could be that these users have Happy = Eyeballs
>> enabled browsers and the browser is choosing to try to use both IP= v4 and
>> IPv6, despite the IPv6 being tunnelled rather than native. From a = Happy
>> Eyeballs robustness perspective, that would be quite a reasonable = thing to
>> do I think.
>>
>> If the end-hosts aren't following RFC3484's default prefer= ences, then
>> breaking 6to4 might cause the sorts of timeouts that HE is designe= d to
>> overcome. RFC3484 is quite old now (2003), and as a minor data poi= nt I
>> first encountered the implementation of them in around 2008/2009 i= f I
>> recall correctly on my Linux system (as I was using 6to4 at the ti= me and
>> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.co= nf(3) is
>> the way you change that). So if some hosts are still preferring tu= nnelled
>> 6to4 IPv6 over native IPv4 then perhaps they're also not going= to be
>> running a HE enabled browser either.
>>
>> Perhaps it might be possible for somebody at Google to produce a l= ist of
>> the browser User-Agent strings for people still using 6to4 to see = if the
>> browsers being used are HE enabled, which might also give some ins= ight into
>> RFC3484 support in the underlying OSes.
>>
>> Regards,
>> Mark.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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

--089e011605ccfcbe00050d99f7c1-- From nobody Mon Jan 26 19:37:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CAE1B2A5A for ; Mon, 26 Jan 2015 19:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, 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 zuQ9oTbiu4Ko for ; Mon, 26 Jan 2015 19:37:37 -0800 (PST) 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 0F9C71B2AB0 for ; Mon, 26 Jan 2015 19:37:33 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id ey11so15675997pad.7 for ; Mon, 26 Jan 2015 19:37:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pJ/ObnbctmoNaoP/axETICf80EOKmcGgL98o6fTvqw0=; b=FsLn/rMrT0Y18HLcUkUlsUR4Gnv0fvNQlt6X/8d0hijBZlgJioxUOpTQEZq21xBhNp +jYPD+7jPBmTrRz9C44c81MXr/ccU2Vu0027hogn4+kLcJd2bPlrkH/3vmhXe6D77r7B AiRB3XAlKmKMnZqwWzSd6GkRGmeN/yWxCJFG7hy07FotZ40hYXgsczaSWVyHHzUqNUEh xa5uq8A2Mla/kzLPAeFZ98UxtQDCz8I7ODfq3LYCtiSw1r9bUVWBS4kr4uDYluKfpfqD iLDV09fPR8s7RFDjn93VGwV4B+Jton1O6xXpy3GL8mgdajAwl3KnsQkH17bh843EZXsq Qk0A== X-Gm-Message-State: ALoCoQmTRHdjWP+nodOplnRw+s56H0E26I9+qsm5DfrSUveXh4GRXipXzOC0seEcTRuROMMP5e+u MIME-Version: 1.0 X-Received: by 10.70.91.201 with SMTP id cg9mr39687731pdb.57.1422329853541; Mon, 26 Jan 2015 19:37:33 -0800 (PST) Received: by 10.70.67.226 with HTTP; Mon, 26 Jan 2015 19:37:33 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:149e:8b1c:d990:2562] In-Reply-To: <54C70777.8080704@gmail.com> References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> Date: Tue, 27 Jan 2015 13:37:33 +1000 Message-ID: From: George Michaelson To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c232acac99cb050d99f9f6 Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 03:37:40 -0000 --001a11c232acac99cb050d99f9f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Browser Match strings are a black art. Its entirely possible its a misreport. -G On Tue, Jan 27, 2015 at 1:35 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Measurable, indeed. > > Windows 8? Really? > > Regards > Brian > > On 27/01/2015 15:07, George Michaelson wrote: > > Ask and ye shall receive > > > > Here is a days summary of os, browser, os+browser as determined by the > > APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Pyth= on > > httpagentparser module to detect OS and Version info. > > > > -George > > > > os,Windows+7,22287 > > os,Windows+8.1,1743 > > os,Windows+Vista,939 > > os,Windows+8,894 > > os,Windows+XP,431 > > os,Macintosh+[na],124 > > os,iOS+[na],44 > > os,Linux+[na],29 > > os,Windows+NT 6.4,6 > > os,Windows Phone+8.1,2 > > os,ChromeOS+6310.68.0,2 > > > > browser,Chrome,18297 > > browser,Firefox,3774 > > browser,Microsoft Internet Explorer,2872 > > browser,Opera,1439 > > browser,Safari,110 > > browser,AndroidBrowser,5 > > browser,[na],2 > > browser,SeaMonkey,2 > > > > os+browser,Windows+7.Chrome,15539 > > os+browser,Windows+7.Firefox,3033 > > os+browser,Windows+7.Microsoft Internet Explorer,2432 > > os+browser,Windows+8.1.Chrome,1305 > > os+browser,Windows+7.Opera,1277 > > os+browser,Windows+8.Chrome,644 > > os+browser,Windows+Vista.Chrome,537 > > os+browser,Windows+8.1.Firefox,311 > > os+browser,Windows+Vista.Microsoft Internet Explorer,230 > > os+browser,Windows+XP.Chrome,216 > > os+browser,Windows+Vista.Firefox,148 > > os+browser,Windows+XP.Firefox,134 > > os+browser,Windows+8.Firefox,116 > > os+browser,Windows+8.Microsoft Internet Explorer,87 > > os+browser,Windows+8.1.Opera,64 > > os+browser,Windows+8.1.Microsoft Internet Explorer,63 > > os+browser,Macintosh+[na].Safari,60 > > os+browser,Windows+XP.Microsoft Internet Explorer,54 > > os+browser,Windows+8.Opera,45 > > os+browser,iOS+[na].Safari,44 > > os+browser,Macintosh+[na].Chrome,36 > > os+browser,Windows+XP.Opera,25 > > os+browser,Windows+Vista.Opera,24 > > os+browser,Macintosh+[na].Firefox,24 > > os+browser,Linux+[na].Chrome,16 > > os+browser,Linux+[na].Firefox,8 > > os+browser,Windows+7.Safari,6 > > os+browser,Linux+[na].AndroidBrowser,5 > > os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 > > os+browser,Macintosh+[na].Opera,4 > > os+browser,Windows+XP.SeaMonkey,2 > > os+browser,Windows+NT 6.4.Chrome,2 > > os+browser,Windows+8.[na],2 > > os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 > > os+browser,ChromeOS+6310.68.0.Chrome,2 > > > > > > On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith < > markzzzsmith@yahoo.com.au> > > wrote: > > > >> I'm fine with that. > >> > >> If it is easy enough, I think it would be interesting to get a bit mor= e > of > >> an insight into who/what is still using 6to4 either in preference to o= r > in > >> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 > users. > >> > >> ------------------------------ > >> *From:* Lorenzo Colitti > >> *To:* Mark ZZZ Smith > >> *Cc:* Brian E Carpenter ; Tore Anderson < > >> tore@fud.no>; "v6ops@ietf.org" > >> *Sent:* Wednesday, 21 January 2015, 23:16 > >> > >> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >> > >> Yes, those users will definitely be impacted. Which is why the documen= t > >> does not suggest dropping the packets or turning off the relays, excep= t > by > >> saying things like "operators SHOULD [...] consider carefully whether > the > >> [...] relay can be discontinued as traffic diminishes". That's quite > >> reasonable guidance, I think. > >> > >> Remember: 0.01% is really a very small number. Multiplying it by 1 > billion > >> (like Brian did) makes it seem large, but that's just a trick of the > light. > >> Look at it this way: if all the relays in the world were turned off > >> overnight and all the 6to4 users were unable to reach a given website, > that > >> website's reliability would still be 99.99% of what it was before. > >> > >> I support this document in its current form. I only have three comment= s > >> beyond seconding Tore's objection to the draft calling 6to4 > "substantial": > >> > >> 1. Is it necessary to formally deprecate RFC 6732? It's an individu= al > >> submission. (Not that I support RFC 6732 in any way, to be sure.) > >> 2. I don't think the sentence "some content providers have been > >> reluctant to make content available over IPv6" is true, or at least > any > >> true for any non-trivial value of "some". 6to4 was a problem for > content > >> providers a few years ago, but we've moved past it. > >> 3. It might be useful to cite that another reason 6to4 is being > >> deprecated is that IPv6 is actually being deployed these days > (finally). > >> > >> > >> > >> > >> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith < > markzzzsmith@yahoo.com.au > >>> wrote: > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> From: Brian E Carpenter > >> To: Tore Anderson ; v6ops@ietf.org > >> Cc: > >> Sent: Wednesday, 21 January 2015, 7:14 > >> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >> > >> On 21/01/2015 02:16, Tore Anderson wrote: > >>> * fred@cisco.com > >>> > >>>> This is to initiate a one week working group last call of > >>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > >>> > >>> I have read this document, and I think it is ready to move forward. > >>> > >>> Its operational need for this document is less pressing now than when > >>> the -00 version was published back in 2011. Nevertheless, I find it > >>> valuable and correct to put the final nail in 6to4's coffin at this > >>> point in time. While the operational community for the most part has > >>> already realised that 6to4 has no future, there might be some who hav= e > >>> not been paying attention and formal deprecation of the protocol may > >>> help prevent them from making the mistake of attempting to base > >>> production systems on it. > >>> > >>> I have one minor comment though: In section 1, it says =C2=ABa substa= ntial > >>> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB. > >>> While I do see 6to4 traffic, it is quite far from being of > "substantial" > >>> levels. I would therefore recommend replacing "substantial" with > >>> something milder like "noticeable", "measurable", or something along > >>> those lines. > >>> > >>> For what it's worth, today the Google public IPv6 graph shows just a > >>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's n= ot > >>> just me. > >> > >> "Tore, > >> > >> However, that fraction of Google traffic multipled by Google users > >> represents something like 100000 users. I don't think we can dismiss > >> that number of people too easily. It's a matter of taste whether > >> that's "substantial" or "noticeable". > >> > >> Brian" > >> > >> Actually, to those end users, the impact might be both quite significa= nt > >> and noticeable. > >> > >> I think one explanation for the use of 6to4 tunnelled IPv6 is that the= ir > >> hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Goog= le > >> make their services equally available over both, which I think they > do), as > >> per RFC3484 address selection rules. > >> > >> The other explanation for it could be that these users have Happy > Eyeballs > >> enabled browsers and the browser is choosing to try to use both IPv4 a= nd > >> IPv6, despite the IPv6 being tunnelled rather than native. From a Happ= y > >> Eyeballs robustness perspective, that would be quite a reasonable thin= g > to > >> do I think. > >> > >> If the end-hosts aren't following RFC3484's default preferences, then > >> breaking 6to4 might cause the sorts of timeouts that HE is designed to > >> overcome. RFC3484 is quite old now (2003), and as a minor data point I > >> first encountered the implementation of them in around 2008/2009 if I > >> recall correctly on my Linux system (as I was using 6to4 at the time a= nd > >> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3= ) > is > >> the way you change that). So if some hosts are still preferring > tunnelled > >> 6to4 IPv6 over native IPv4 then perhaps they're also not going to be > >> running a HE enabled browser either. > >> > >> Perhaps it might be possible for somebody at Google to produce a list = of > >> the browser User-Agent strings for people still using 6to4 to see if t= he > >> browsers being used are HE enabled, which might also give some insight > into > >> RFC3484 support in the underlying OSes. > >> > >> Regards, > >> Mark. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >> > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > --001a11c232acac99cb050d99f9f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Browser Match strings are a black art. Its entirely possib= le its a misreport.
-G


On Tue, Jan 27, 2015 at 1:35 PM, Brian = E Carpenter <brian.e.carpenter@gmail.com> wrote:
Measurable, indeed.

Windows 8? Really?

Regards
=C2=A0 =C2=A0Brian

On 27/01/2015 15:07, George Michaelson wrote:
> Ask and ye shall receive
>
> Here is a days summary of os, browser, os+browser as determined by the=
> APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Pyt= hon
> httpagentparser module to detect OS and Version info.
>
> -George
>
> os,Windows+7,22287
> os,Windows+8.1,1743
> os,Windows+Vista,939
> os,Windows+8,894
> os,Windows+XP,431
> os,Macintosh+[na],124
> os,iOS+[na],44
> os,Linux+[na],29
> os,Windows+NT 6.4,6
> os,Windows Phone+8.1,2
> os,ChromeOS+6310.68.0,2
>
> browser,Chrome,18297
> browser,Firefox,3774
> browser,Microsoft Internet Explorer,2872
> browser,Opera,1439
> browser,Safari,110
> browser,AndroidBrowser,5
> browser,[na],2
> browser,SeaMonkey,2
>
> os+browser,Windows+7.Chrome,15539
> os+browser,Windows+7.Firefox,3033
> os+browser,Windows+7.Microsoft Internet Explorer,2432
> os+browser,Windows+8.1.Chrome,1305
> os+browser,Windows+7.Opera,1277
> os+browser,Windows+8.Chrome,644
> os+browser,Windows+Vista.Chrome,537
> os+browser,Windows+8.1.Firefox,311
> os+browser,Windows+Vista.Microsoft Internet Explorer,230
> os+browser,Windows+XP.Chrome,216
> os+browser,Windows+Vista.Firefox,148
> os+browser,Windows+XP.Firefox,134
> os+browser,Windows+8.Firefox,116
> os+browser,Windows+8.Microsoft Internet Explorer,87
> os+browser,Windows+8.1.Opera,64
> os+browser,Windows+8.1.Microsoft Internet Explorer,63
> os+browser,Macintosh+[na].Safari,60
> os+browser,Windows+XP.Microsoft Internet Explorer,54
> os+browser,Windows+8.Opera,45
> os+browser,iOS+[na].Safari,44
> os+browser,Macintosh+[na].Chrome,36
> os+browser,Windows+XP.Opera,25
> os+browser,Windows+Vista.Opera,24
> os+browser,Macintosh+[na].Firefox,24
> os+browser,Linux+[na].Chrome,16
> os+browser,Linux+[na].Firefox,8
> os+browser,Windows+7.Safari,6
> os+browser,Linux+[na].AndroidBrowser,5
> os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4
> os+browser,Macintosh+[na].Opera,4
> os+browser,Windows+XP.SeaMonkey,2
> os+browser,Windows+NT 6.4.Chrome,2
> os+browser,Windows+8.[na],2
> os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2
> os+browser,ChromeOS+6310.68.0.Chrome,2
>
>
> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
> wrote:
>
>> I'm fine with that.
>>
>> If it is easy enough, I think it would be interesting to get a bit= more of
>> an insight into who/what is still using 6to4 either in preference = to or in
>> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6t= o4 users.
>>
>>=C2=A0 =C2=A0------------------------------
>>=C2=A0 *From:* Lorenzo Colitti <lorenzo@google.com>
>> *To:* Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>> *Cc:* Brian E Carpenter <brian.e.carpenter@gmail.com>; Tore Anderson <
>> tore@fud.no>; "v6ops@ietf.org" <v6ops@ietf.org>
>> *Sent:* Wednesday, 21 January 2015, 23:16
>>
>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
>>
>> Yes, those users will definitely be impacted. Which is why the doc= ument
>> does not suggest dropping the packets or turning off the relays, e= xcept by
>> saying things like "operators SHOULD [...] consider carefully= whether the
>> [...] relay can be discontinued as traffic diminishes". That&= #39;s quite
>> reasonable guidance, I think.
>>
>> Remember: 0.01% is really a very small number. Multiplying it by 1= billion
>> (like Brian did) makes it seem large, but that's just a trick = of the light.
>> Look at it this way: if all the relays in the world were turned of= f
>> overnight and all the 6to4 users were unable to reach a given webs= ite, that
>> website's reliability would still be 99.99% of what it was bef= ore.
>>
>> I support this document in its current form. I only have three com= ments
>> beyond seconding Tore's objection to the draft calling 6to4 &q= uot;substantial":
>>
>>=C2=A0 =C2=A0 1. Is it necessary to formally deprecate RFC 6= 732? It's an individual
>>=C2=A0 =C2=A0 submission. (Not that I support RFC = 6732 in any way, to be sure.)
>>=C2=A0 =C2=A0 2. I don't think the sentence "some c= ontent providers have been
>>=C2=A0 =C2=A0 reluctant to make content available = over IPv6" is true, or at least any
>>=C2=A0 =C2=A0 true for any non-trivial value of "some". 6= to4 was a problem for content
>>=C2=A0 =C2=A0 providers a few years ago, but we've moved past i= t.
>>=C2=A0 =C2=A0 3. It might be useful to cite that another rea= son 6to4 is being
>>=C2=A0 =C2=A0 deprecated is= that IPv6 is actually being deployed these days (finally).
>>
>>
>>
>>
>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au
>>> wrote:
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> To: Tore Anderson <tore@fud.no>; v6ops@ietf.org
>> Cc:
>> Sent: Wednesday, 21 January 2015, 7:14
>> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
>>
>> On 21/01/2015 02:16, Tore Anderson wrote:
>>> * fred@cisco.com
>>>
>>>> This is to initiate a one week working group last call of<= br> >>>> http://tools.ietf.org/html/draft-ietf-v6op= s-6to4-to-historic.
>>>
>>> I have read this document, and I think it is ready to move for= ward.
>>>
>>> Its operational need for this document is less pressing now th= an when
>>> the -00 version was published back in 2011. Nevertheless, I fi= nd it
>>> valuable and correct to put the final nail in 6to4's coffi= n at this
>>> point in time. While the operational community for the most pa= rt has
>>> already realised that 6to4 has no future, there might be some = who have
>>> not been paying attention and formal deprecation of the protoc= ol may
>>> help prevent them from making the mistake of attempting to bas= e
>>> production systems on it.
>>>
>>> I have one minor comment though: In section 1, it says =C2=ABa= substantial
>>> amount of 6to4 traffic is still observed by IPv6 content provi= ders=C2=BB.
>>> While I do see 6to4 traffic, it is quite far from being of &qu= ot;substantial"
>>> levels. I would therefore recommend replacing "substantia= l" with
>>> something milder like "noticeable", "measurable= ", or something along
>>> those lines.
>>>
>>> For what it's worth, today the Google public IPv6 graph sh= ows just a
>>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so= it's not
>>> just me.
>>
>> "Tore,
>>
>> However, that fraction of Google traffic multipled by Google users=
>> represents something like 100000 users. I don't think we can d= ismiss
>> that number of people too easily. It's a matter of taste wheth= er
>> that's "substantial" or "noticeable".
>>
>>=C2=A0 =C2=A0 =C2=A0Brian"
>>
>> Actually, to those end users, the impact might be both quite signi= ficant
>> and noticeable.
>>
>> I think one explanation for the use of 6to4 tunnelled IPv6 is that= their
>> hosts aren't preferring native IPv4 over tunnelled IPv6 (assum= ing Google
>> make their services equally available over both, which I think the= y do), as
>> per RFC3484 address selection rules.
>>
>> The other explanation for it could be that these users have Happy = Eyeballs
>> enabled browsers and the browser is choosing to try to use both IP= v4 and
>> IPv6, despite the IPv6 being tunnelled rather than native. From a = Happy
>> Eyeballs robustness perspective, that would be quite a reasonable = thing to
>> do I think.
>>
>> If the end-hosts aren't following RFC3484's default prefer= ences, then
>> breaking 6to4 might cause the sorts of timeouts that HE is designe= d to
>> overcome. RFC3484 is quite old now (2003), and as a minor data poi= nt I
>> first encountered the implementation of them in around 2008/2009 i= f I
>> recall correctly on my Linux system (as I was using 6to4 at the ti= me and
>> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.co= nf(3) is
>> the way you change that). So if some hosts are still preferring tu= nnelled
>> 6to4 IPv6 over native IPv4 then perhaps they're also not going= to be
>> running a HE enabled browser either.
>>
>> Perhaps it might be possible for somebody at Google to produce a l= ist of
>> the browser User-Agent strings for people still using 6to4 to see = if the
>> browsers being used are HE enabled, which might also give some ins= ight into
>> RFC3484 support in the underlying OSes.
>>
>> Regards,
>> Mark.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


--001a11c232acac99cb050d99f9f6-- From nobody Mon Jan 26 19:39:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5359E1A1BB9 for ; Mon, 26 Jan 2015 19:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, 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 TUAxat0mziDp for ; Mon, 26 Jan 2015 19:39:19 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CFD1A1BAF for ; Mon, 26 Jan 2015 19:39:18 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id lj1so15674490pab.6 for ; Mon, 26 Jan 2015 19:39:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ktEgxp8YMnOSo3144hPa5kyIUk9s5PiMbbY99w0Zqe4=; b=YoOy6VTxV7Imnrmtj0gMwfIbuOmxz/ZAIFduMgSVyFssH6PPuwk/xtlTyQb0HR1aco bO8AChUxsU3K3ALSrZYue7Ug0GbH8MlxSY4Pyuu5DZ7hmwvQyTWqznyhqXNLlgRi4GBF YCy3Vhnt8YPqJC5thaxT6InM2V5O09p3PAOjDn1f/DXuTbaygqgyS7kQ98t2jYDCSglm 0TkT9lKwJRW0DL5vVKmvesH49D1CPJJKpxXXk/PPOar2LChkTGaEc35gCRuy+IP1WH0M kpe59IC2ZvVRYfVG5K5v37pbOLSPYE+XVQFlTLtdrKVy6sBUcdvGhB2kSoQM4iggcDY9 HtkQ== X-Gm-Message-State: ALoCoQlQuXxZbdPR+Sb6eVGLIQor5dJzD6jkkbBaRzVBmXtXKX8XbwGo3fWh6HBJ8yAbs/LBv96/ MIME-Version: 1.0 X-Received: by 10.70.89.207 with SMTP id bq15mr39382675pdb.68.1422329958634; Mon, 26 Jan 2015 19:39:18 -0800 (PST) Received: by 10.70.67.226 with HTTP; Mon, 26 Jan 2015 19:39:18 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:149e:8b1c:d990:2562] In-Reply-To: References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> Date: Tue, 27 Jan 2015 13:39:18 +1000 Message-ID: From: George Michaelson To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=e89a8ff1c008f0308f050d99ffa2 Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 03:39:22 -0000 --e89a8ff1c008f0308f050d99ffa2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2015 at 1:36 PM, Lorenzo Colitti wrote= : > Are these probes made to an IPv6-only hostname? If so, then of course we'= d > expect OSes to attempt 6to4. > Yes and yes. I thought about pruning, and decided to make it complete. Its certainly not a strong reflection of the real world dynamic, but it shows how many people are still sitting on vestigial 6to4 technology which can be woken. Since we know some ISPs had deployment models which included this, Its not surprising. Functionally its dead technology. But its zombie dead. not stone-cold. -G > > On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Measurable, indeed. >> >> Windows 8? Really? >> >> Regards >> Brian >> >> On 27/01/2015 15:07, George Michaelson wrote: >> > Ask and ye shall receive >> > >> > Here is a days summary of os, browser, os+browser as determined by the >> > APNIC 1x1 capture, using 2002: as the source IPv6 address, and the >> Python >> > httpagentparser module to detect OS and Version info. >> > >> > -George >> > >> > os,Windows+7,22287 >> > os,Windows+8.1,1743 >> > os,Windows+Vista,939 >> > os,Windows+8,894 >> > os,Windows+XP,431 >> > os,Macintosh+[na],124 >> > os,iOS+[na],44 >> > os,Linux+[na],29 >> > os,Windows+NT 6.4,6 >> > os,Windows Phone+8.1,2 >> > os,ChromeOS+6310.68.0,2 >> > >> > browser,Chrome,18297 >> > browser,Firefox,3774 >> > browser,Microsoft Internet Explorer,2872 >> > browser,Opera,1439 >> > browser,Safari,110 >> > browser,AndroidBrowser,5 >> > browser,[na],2 >> > browser,SeaMonkey,2 >> > >> > os+browser,Windows+7.Chrome,15539 >> > os+browser,Windows+7.Firefox,3033 >> > os+browser,Windows+7.Microsoft Internet Explorer,2432 >> > os+browser,Windows+8.1.Chrome,1305 >> > os+browser,Windows+7.Opera,1277 >> > os+browser,Windows+8.Chrome,644 >> > os+browser,Windows+Vista.Chrome,537 >> > os+browser,Windows+8.1.Firefox,311 >> > os+browser,Windows+Vista.Microsoft Internet Explorer,230 >> > os+browser,Windows+XP.Chrome,216 >> > os+browser,Windows+Vista.Firefox,148 >> > os+browser,Windows+XP.Firefox,134 >> > os+browser,Windows+8.Firefox,116 >> > os+browser,Windows+8.Microsoft Internet Explorer,87 >> > os+browser,Windows+8.1.Opera,64 >> > os+browser,Windows+8.1.Microsoft Internet Explorer,63 >> > os+browser,Macintosh+[na].Safari,60 >> > os+browser,Windows+XP.Microsoft Internet Explorer,54 >> > os+browser,Windows+8.Opera,45 >> > os+browser,iOS+[na].Safari,44 >> > os+browser,Macintosh+[na].Chrome,36 >> > os+browser,Windows+XP.Opera,25 >> > os+browser,Windows+Vista.Opera,24 >> > os+browser,Macintosh+[na].Firefox,24 >> > os+browser,Linux+[na].Chrome,16 >> > os+browser,Linux+[na].Firefox,8 >> > os+browser,Windows+7.Safari,6 >> > os+browser,Linux+[na].AndroidBrowser,5 >> > os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 >> > os+browser,Macintosh+[na].Opera,4 >> > os+browser,Windows+XP.SeaMonkey,2 >> > os+browser,Windows+NT 6.4.Chrome,2 >> > os+browser,Windows+8.[na],2 >> > os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 >> > os+browser,ChromeOS+6310.68.0.Chrome,2 >> > >> > >> > On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith < >> markzzzsmith@yahoo.com.au> >> > wrote: >> > >> >> I'm fine with that. >> >> >> >> If it is easy enough, I think it would be interesting to get a bit >> more of >> >> an insight into who/what is still using 6to4 either in preference to >> or in >> >> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 >> users. >> >> >> >> ------------------------------ >> >> *From:* Lorenzo Colitti >> >> *To:* Mark ZZZ Smith >> >> *Cc:* Brian E Carpenter ; Tore Anderson = < >> >> tore@fud.no>; "v6ops@ietf.org" >> >> *Sent:* Wednesday, 21 January 2015, 23:16 >> >> >> >> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> >> >> >> Yes, those users will definitely be impacted. Which is why the docume= nt >> >> does not suggest dropping the packets or turning off the relays, >> except by >> >> saying things like "operators SHOULD [...] consider carefully whether >> the >> >> [...] relay can be discontinued as traffic diminishes". That's quite >> >> reasonable guidance, I think. >> >> >> >> Remember: 0.01% is really a very small number. Multiplying it by 1 >> billion >> >> (like Brian did) makes it seem large, but that's just a trick of the >> light. >> >> Look at it this way: if all the relays in the world were turned off >> >> overnight and all the 6to4 users were unable to reach a given website= , >> that >> >> website's reliability would still be 99.99% of what it was before. >> >> >> >> I support this document in its current form. I only have three commen= ts >> >> beyond seconding Tore's objection to the draft calling 6to4 >> "substantial": >> >> >> >> 1. Is it necessary to formally deprecate RFC 6732? It's an >> individual >> >> submission. (Not that I support RFC 6732 in any way, to be sure.) >> >> 2. I don't think the sentence "some content providers have been >> >> reluctant to make content available over IPv6" is true, or at leas= t >> any >> >> true for any non-trivial value of "some". 6to4 was a problem for >> content >> >> providers a few years ago, but we've moved past it. >> >> 3. It might be useful to cite that another reason 6to4 is being >> >> deprecated is that IPv6 is actually being deployed these days >> (finally). >> >> >> >> >> >> >> >> >> >> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith < >> markzzzsmith@yahoo.com.au >> >>> wrote: >> >> >> >> >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> From: Brian E Carpenter >> >> To: Tore Anderson ; v6ops@ietf.org >> >> Cc: >> >> Sent: Wednesday, 21 January 2015, 7:14 >> >> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> >> >> >> On 21/01/2015 02:16, Tore Anderson wrote: >> >>> * fred@cisco.com >> >>> >> >>>> This is to initiate a one week working group last call of >> >>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. >> >>> >> >>> I have read this document, and I think it is ready to move forward. >> >>> >> >>> Its operational need for this document is less pressing now than whe= n >> >>> the -00 version was published back in 2011. Nevertheless, I find it >> >>> valuable and correct to put the final nail in 6to4's coffin at this >> >>> point in time. While the operational community for the most part has >> >>> already realised that 6to4 has no future, there might be some who ha= ve >> >>> not been paying attention and formal deprecation of the protocol may >> >>> help prevent them from making the mistake of attempting to base >> >>> production systems on it. >> >>> >> >>> I have one minor comment though: In section 1, it says =C2=ABa subst= antial >> >>> amount of 6to4 traffic is still observed by IPv6 content providers= =C2=BB. >> >>> While I do see 6to4 traffic, it is quite far from being of >> "substantial" >> >>> levels. I would therefore recommend replacing "substantial" with >> >>> something milder like "noticeable", "measurable", or something along >> >>> those lines. >> >>> >> >>> For what it's worth, today the Google public IPv6 graph shows just a >> >>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's >> not >> >>> just me. >> >> >> >> "Tore, >> >> >> >> However, that fraction of Google traffic multipled by Google users >> >> represents something like 100000 users. I don't think we can dismiss >> >> that number of people too easily. It's a matter of taste whether >> >> that's "substantial" or "noticeable". >> >> >> >> Brian" >> >> >> >> Actually, to those end users, the impact might be both quite >> significant >> >> and noticeable. >> >> >> >> I think one explanation for the use of 6to4 tunnelled IPv6 is that >> their >> >> hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming >> Google >> >> make their services equally available over both, which I think they >> do), as >> >> per RFC3484 address selection rules. >> >> >> >> The other explanation for it could be that these users have Happy >> Eyeballs >> >> enabled browsers and the browser is choosing to try to use both IPv4 >> and >> >> IPv6, despite the IPv6 being tunnelled rather than native. From a Hap= py >> >> Eyeballs robustness perspective, that would be quite a reasonable >> thing to >> >> do I think. >> >> >> >> If the end-hosts aren't following RFC3484's default preferences, then >> >> breaking 6to4 might cause the sorts of timeouts that HE is designed t= o >> >> overcome. RFC3484 is quite old now (2003), and as a minor data point = I >> >> first encountered the implementation of them in around 2008/2009 if I >> >> recall correctly on my Linux system (as I was using 6to4 at the time >> and >> >> wanted to use tunnelled IPv6 in preference to native IPv4 - >> gai.conf(3) is >> >> the way you change that). So if some hosts are still preferring >> tunnelled >> >> 6to4 IPv6 over native IPv4 then perhaps they're also not going to be >> >> running a HE enabled browser either. >> >> >> >> Perhaps it might be possible for somebody at Google to produce a list >> of >> >> the browser User-Agent strings for people still using 6to4 to see if >> the >> >> browsers being used are HE enabled, which might also give some insigh= t >> into >> >> RFC3484 support in the underlying OSes. >> >> >> >> Regards, >> >> Mark. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> > >> > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > --e89a8ff1c008f0308f050d99ffa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 27, 2015 at 1:36 PM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
Ar= e these probes made to an IPv6-only hostname? If so, then of course we'= d expect OSes to attempt 6to4.

Yes an= d yes. I thought about pruning, and decided to make it complete. Its certai= nly not a strong reflection of the real world dynamic, but it shows how man= y people are still sitting on vestigial 6to4 technology which can be woken.= Since we know some ISPs had deployment models which included this, Its not= surprising.

Functionally its dead technology. But= its zombie dead. not stone-cold.

-G
=C2= =A0

On Tue, Jan = 27, 2015 at 12:35 PM, Brian E Carpenter <brian.e.carpenter@gmail= .com> wrote:
Measurable, in= deed.

Windows 8? Really?

Regards
=C2=A0 =C2=A0Brian

On 27/01/2015 15:07, George Michaelson wrote:
> Ask and ye shall receive
>
> Here is a days summary of os, browser, os+browser as determined by the=
> APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Pyt= hon
> httpagentparser module to detect OS and Version info.
>
> -George
>
> os,Windows+7,22287
> os,Windows+8.1,1743
> os,Windows+Vista,939
> os,Windows+8,894
> os,Windows+XP,431
> os,Macintosh+[na],124
> os,iOS+[na],44
> os,Linux+[na],29
> os,Windows+NT 6.4,6
> os,Windows Phone+8.1,2
> os,ChromeOS+6310.68.0,2
>
> browser,Chrome,18297
> browser,Firefox,3774
> browser,Microsoft Internet Explorer,2872
> browser,Opera,1439
> browser,Safari,110
> browser,AndroidBrowser,5
> browser,[na],2
> browser,SeaMonkey,2
>
> os+browser,Windows+7.Chrome,15539
> os+browser,Windows+7.Firefox,3033
> os+browser,Windows+7.Microsoft Internet Explorer,2432
> os+browser,Windows+8.1.Chrome,1305
> os+browser,Windows+7.Opera,1277
> os+browser,Windows+8.Chrome,644
> os+browser,Windows+Vista.Chrome,537
> os+browser,Windows+8.1.Firefox,311
> os+browser,Windows+Vista.Microsoft Internet Explorer,230
> os+browser,Windows+XP.Chrome,216
> os+browser,Windows+Vista.Firefox,148
> os+browser,Windows+XP.Firefox,134
> os+browser,Windows+8.Firefox,116
> os+browser,Windows+8.Microsoft Internet Explorer,87
> os+browser,Windows+8.1.Opera,64
> os+browser,Windows+8.1.Microsoft Internet Explorer,63
> os+browser,Macintosh+[na].Safari,60
> os+browser,Windows+XP.Microsoft Internet Explorer,54
> os+browser,Windows+8.Opera,45
> os+browser,iOS+[na].Safari,44
> os+browser,Macintosh+[na].Chrome,36
> os+browser,Windows+XP.Opera,25
> os+browser,Windows+Vista.Opera,24
> os+browser,Macintosh+[na].Firefox,24
> os+browser,Linux+[na].Chrome,16
> os+browser,Linux+[na].Firefox,8
> os+browser,Windows+7.Safari,6
> os+browser,Linux+[na].AndroidBrowser,5
> os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4
> os+browser,Macintosh+[na].Opera,4
> os+browser,Windows+XP.SeaMonkey,2
> os+browser,Windows+NT 6.4.Chrome,2
> os+browser,Windows+8.[na],2
> os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2
> os+browser,ChromeOS+6310.68.0.Chrome,2
>
>
> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au&= gt;
> wrote:
>
>> I'm fine with that.
>>
>> If it is easy enough, I think it would be interesting to get a bit= more of
>> an insight into who/what is still using 6to4 either in preference = to or in
>> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6t= o4 users.
>>
>>=C2=A0 =C2=A0------------------------------
>>=C2=A0 *From:* Lorenzo Colitti <lorenzo@google.com>
>> *To:* Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>> *Cc:* Brian E Carpenter <brian.e.carpenter@gmail.com>; Tore Anders= on <
>> tore@fud.no&g= t;; "v6ops@ietf.or= g" <v6ops@i= etf.org>
>> *Sent:* Wednesday, 21 January 2015, 23:16
>>
>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
>>
>> Yes, those users will definitely be impacted. Which is why the doc= ument
>> does not suggest dropping the packets or turning off the relays, e= xcept by
>> saying things like "operators SHOULD [...] consider carefully= whether the
>> [...] relay can be discontinued as traffic diminishes". That&= #39;s quite
>> reasonable guidance, I think.
>>
>> Remember: 0.01% is really a very small number. Multiplying it by 1= billion
>> (like Brian did) makes it seem large, but that's just a trick = of the light.
>> Look at it this way: if all the relays in the world were turned of= f
>> overnight and all the 6to4 users were unable to reach a given webs= ite, that
>> website's reliability would still be 99.99% of what it was bef= ore.
>>
>> I support this document in its current form. I only have three com= ments
>> beyond seconding Tore's objection to the draft calling 6to4 &q= uot;substantial":
>>
>>=C2=A0 =C2=A0 1. Is it necessary to formally deprecate RFC 6= 732? It's an individual
>>=C2=A0 =C2=A0 submission. (Not that I support RFC 6732 in any= way, to be sure.)
>>=C2=A0 =C2=A0 2. I don't think the sentence "some c= ontent providers have been
>>=C2=A0 =C2=A0 reluctant to make content available over IPv6&q= uot; is true, or at least any
>>=C2=A0 =C2=A0 true for any non-trivial value of "some". 6= to4 was a problem for content
>>=C2=A0 =C2=A0 providers a few years ago, but we've moved past i= t.
>>=C2=A0 =C2=A0 3. It might be useful to cite that another rea= son 6to4 is being
>>=C2=A0 =C2=A0 deprecated is that IPv6 is actually being d= eployed these days (finally).
>>
>>
>>
>>
>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au<= /a>
>>> wrote:
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> To: Tore Anderson <tore@fud.no>; v6ops@ietf.org
>> Cc:
>> Sent: Wednesday, 21 January 2015, 7:14
>> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
>>
>> On 21/01/2015 02:16, Tore Anderson wrote:
>>> * fred@cis= co.com
>>>
>>>> This is to initiate a one week working group last call of<= br> >>>> http://tools.ietf.org/html/draft-ietf-v6op= s-6to4-to-historic.
>>>
>>> I have read this document, and I think it is ready to move for= ward.
>>>
>>> Its operational need for this document is less pressing now th= an when
>>> the -00 version was published back in 2011. Nevertheless, I fi= nd it
>>> valuable and correct to put the final nail in 6to4's coffi= n at this
>>> point in time. While the operational community for the most pa= rt has
>>> already realised that 6to4 has no future, there might be some = who have
>>> not been paying attention and formal deprecation of the protoc= ol may
>>> help prevent them from making the mistake of attempting to bas= e
>>> production systems on it.
>>>
>>> I have one minor comment though: In section 1, it says =C2=ABa= substantial
>>> amount of 6to4 traffic is still observed by IPv6 content provi= ders=C2=BB.
>>> While I do see 6to4 traffic, it is quite far from being of &qu= ot;substantial"
>>> levels. I would therefore recommend replacing "substantia= l" with
>>> something milder like "noticeable", "measurable= ", or something along
>>> those lines.
>>>
>>> For what it's worth, today the Google public IPv6 graph sh= ows just a
>>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so= it's not
>>> just me.
>>
>> "Tore,
>>
>> However, that fraction of Google traffic multipled by Google users=
>> represents something like 100000 users. I don't think we can d= ismiss
>> that number of people too easily. It's a matter of taste wheth= er
>> that's "substantial" or "noticeable".
>>
>>=C2=A0 =C2=A0 =C2=A0Brian"
>>
>> Actually, to those end users, the impact might be both quite signi= ficant
>> and noticeable.
>>
>> I think one explanation for the use of 6to4 tunnelled IPv6 is that= their
>> hosts aren't preferring native IPv4 over tunnelled IPv6 (assum= ing Google
>> make their services equally available over both, which I think the= y do), as
>> per RFC3484 address selection rules.
>>
>> The other explanation for it could be that these users have Happy = Eyeballs
>> enabled browsers and the browser is choosing to try to use both IP= v4 and
>> IPv6, despite the IPv6 being tunnelled rather than native. From a = Happy
>> Eyeballs robustness perspective, that would be quite a reasonable = thing to
>> do I think.
>>
>> If the end-hosts aren't following RFC3484's default prefer= ences, then
>> breaking 6to4 might cause the sorts of timeouts that HE is designe= d to
>> overcome. RFC3484 is quite old now (2003), and as a minor data poi= nt I
>> first encountered the implementation of them in around 2008/2009 i= f I
>> recall correctly on my Linux system (as I was using 6to4 at the ti= me and
>> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.co= nf(3) is
>> the way you change that). So if some hosts are still preferring tu= nnelled
>> 6to4 IPv6 over native IPv4 then perhaps they're also not going= to be
>> running a HE enabled browser either.
>>
>> Perhaps it might be possible for somebody at Google to produce a l= ist of
>> the browser User-Agent strings for people still using 6to4 to see = if the
>> browsers being used are HE enabled, which might also give some ins= ight into
>> RFC3484 support in the underlying OSes.
>>
>> Regards,
>> Mark.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


--e89a8ff1c008f0308f050d99ffa2-- From nobody Mon Jan 26 19:55:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FD41B2A5A for ; Mon, 26 Jan 2015 19:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=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 FybElc_ly6Y3 for ; Mon, 26 Jan 2015 19:54:58 -0800 (PST) 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 999241AC3B0 for ; Mon, 26 Jan 2015 19:54:58 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id v10so16274070pde.3 for ; Mon, 26 Jan 2015 19:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3ltOBuFIP4oKAb4C/zkogbl5mqEvW0lP+WFDZ5CqmYc=; b=EkVtK/465tmRTPGqF4MIrjBpuybNNoT4BtpBiqw8M0sBMcidbB3fhIgD5vDYbSbibM P8uB59g3wS7PfOBERnvvAAVh1rHurJiqa1Gnlth+j71WLA5SIT77o6unRsf8U0jmJpyx /13YSTYB2TT3I55qiq23ymdrxY6bMi8c497ftDFVXClptch2emjB7sZuu+4Q47snYScr YWniKHTpuFJplKfLIrd+Uak6ClTfyzhEF8FQuQ8eal/ZTIQAGPCyy+ZISjSorvaSBY8A o7w8d9Q3vi2LH6FoWTsM5/EOUCbqXiIzZ3gdgqA3mawrPHoFg5do/prmmkDzNufGxZEL CjSQ== X-Received: by 10.68.129.193 with SMTP id ny1mr23540pbb.85.1422330897927; Mon, 26 Jan 2015 19:54:57 -0800 (PST) Received: from ?IPv6:2406:e007:73ff:1:28cc:dc4c:9703:6781? ([2406:e007:73ff:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id nk6sm11037167pdb.89.2015.01.26.19.54.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 19:54:56 -0800 (PST) Message-ID: <54C70C10.2090505@gmail.com> Date: Tue, 27 Jan 2015 16:54:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: George Michaelson , Lorenzo Colitti References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 03:55:01 -0000 On 27/01/2015 16:39, George Michaelson wrote: > On Tue, Jan 27, 2015 at 1:36 PM, Lorenzo Colitti w= rote: >=20 >> Are these probes made to an IPv6-only hostname? If so, then of course = we'd >> expect OSes to attempt 6to4. >> >=20 > Yes and yes. I thought about pruning, and decided to make it complete. = Its > certainly not a strong reflection of the real world dynamic, but it sho= ws > how many people are still sitting on vestigial 6to4 technology which ca= n be > woken. Since we know some ISPs had deployment models which included thi= s, > Its not surprising. >=20 > Functionally its dead technology. But its zombie dead. not stone-cold. Good input. IMHO it confirms the position taken by 6to4-to-historic (deprecate but do not block). Brian >=20 > -G >=20 >=20 >> >> On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> Measurable, indeed. >>> >>> Windows 8? Really? >>> >>> Regards >>> Brian >>> >>> On 27/01/2015 15:07, George Michaelson wrote: >>>> Ask and ye shall receive >>>> >>>> Here is a days summary of os, browser, os+browser as determined by t= he >>>> APNIC 1x1 capture, using 2002: as the source IPv6 address, and the >>> Python >>>> httpagentparser module to detect OS and Version info. >>>> >>>> -George >>>> >>>> os,Windows+7,22287 >>>> os,Windows+8.1,1743 >>>> os,Windows+Vista,939 >>>> os,Windows+8,894 >>>> os,Windows+XP,431 >>>> os,Macintosh+[na],124 >>>> os,iOS+[na],44 >>>> os,Linux+[na],29 >>>> os,Windows+NT 6.4,6 >>>> os,Windows Phone+8.1,2 >>>> os,ChromeOS+6310.68.0,2 >>>> >>>> browser,Chrome,18297 >>>> browser,Firefox,3774 >>>> browser,Microsoft Internet Explorer,2872 >>>> browser,Opera,1439 >>>> browser,Safari,110 >>>> browser,AndroidBrowser,5 >>>> browser,[na],2 >>>> browser,SeaMonkey,2 >>>> >>>> os+browser,Windows+7.Chrome,15539 >>>> os+browser,Windows+7.Firefox,3033 >>>> os+browser,Windows+7.Microsoft Internet Explorer,2432 >>>> os+browser,Windows+8.1.Chrome,1305 >>>> os+browser,Windows+7.Opera,1277 >>>> os+browser,Windows+8.Chrome,644 >>>> os+browser,Windows+Vista.Chrome,537 >>>> os+browser,Windows+8.1.Firefox,311 >>>> os+browser,Windows+Vista.Microsoft Internet Explorer,230 >>>> os+browser,Windows+XP.Chrome,216 >>>> os+browser,Windows+Vista.Firefox,148 >>>> os+browser,Windows+XP.Firefox,134 >>>> os+browser,Windows+8.Firefox,116 >>>> os+browser,Windows+8.Microsoft Internet Explorer,87 >>>> os+browser,Windows+8.1.Opera,64 >>>> os+browser,Windows+8.1.Microsoft Internet Explorer,63 >>>> os+browser,Macintosh+[na].Safari,60 >>>> os+browser,Windows+XP.Microsoft Internet Explorer,54 >>>> os+browser,Windows+8.Opera,45 >>>> os+browser,iOS+[na].Safari,44 >>>> os+browser,Macintosh+[na].Chrome,36 >>>> os+browser,Windows+XP.Opera,25 >>>> os+browser,Windows+Vista.Opera,24 >>>> os+browser,Macintosh+[na].Firefox,24 >>>> os+browser,Linux+[na].Chrome,16 >>>> os+browser,Linux+[na].Firefox,8 >>>> os+browser,Windows+7.Safari,6 >>>> os+browser,Linux+[na].AndroidBrowser,5 >>>> os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 >>>> os+browser,Macintosh+[na].Opera,4 >>>> os+browser,Windows+XP.SeaMonkey,2 >>>> os+browser,Windows+NT 6.4.Chrome,2 >>>> os+browser,Windows+8.[na],2 >>>> os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 >>>> os+browser,ChromeOS+6310.68.0.Chrome,2 >>>> >>>> >>>> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith < >>> markzzzsmith@yahoo.com.au> >>>> wrote: >>>> >>>>> I'm fine with that. >>>>> >>>>> If it is easy enough, I think it would be interesting to get a bit >>> more of >>>>> an insight into who/what is still using 6to4 either in preference t= o >>> or in >>>>> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to= 4 >>> users. >>>>> >>>>> ------------------------------ >>>>> *From:* Lorenzo Colitti >>>>> *To:* Mark ZZZ Smith >>>>> *Cc:* Brian E Carpenter ; Tore Anderso= n < >>>>> tore@fud.no>; "v6ops@ietf.org" >>>>> *Sent:* Wednesday, 21 January 2015, 23:16 >>>>> >>>>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >>>>> >>>>> Yes, those users will definitely be impacted. Which is why the docu= ment >>>>> does not suggest dropping the packets or turning off the relays, >>> except by >>>>> saying things like "operators SHOULD [...] consider carefully wheth= er >>> the >>>>> [...] relay can be discontinued as traffic diminishes". That's quit= e >>>>> reasonable guidance, I think. >>>>> >>>>> Remember: 0.01% is really a very small number. Multiplying it by 1 >>> billion >>>>> (like Brian did) makes it seem large, but that's just a trick of th= e >>> light. >>>>> Look at it this way: if all the relays in the world were turned off= >>>>> overnight and all the 6to4 users were unable to reach a given websi= te, >>> that >>>>> website's reliability would still be 99.99% of what it was before. >>>>> >>>>> I support this document in its current form. I only have three comm= ents >>>>> beyond seconding Tore's objection to the draft calling 6to4 >>> "substantial": >>>>> >>>>> 1. Is it necessary to formally deprecate RFC 6732? It's an >>> individual >>>>> submission. (Not that I support RFC 6732 in any way, to be sure.= ) >>>>> 2. I don't think the sentence "some content providers have been >>>>> reluctant to make content available over IPv6" is true, or at le= ast >>> any >>>>> true for any non-trivial value of "some". 6to4 was a problem for= >>> content >>>>> providers a few years ago, but we've moved past it. >>>>> 3. It might be useful to cite that another reason 6to4 is being >>>>> deprecated is that IPv6 is actually being deployed these days >>> (finally). >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith < >>> markzzzsmith@yahoo.com.au >>>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Brian E Carpenter >>>>> To: Tore Anderson ; v6ops@ietf.org >>>>> Cc: >>>>> Sent: Wednesday, 21 January 2015, 7:14 >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >>>>> >>>>> On 21/01/2015 02:16, Tore Anderson wrote: >>>>>> * fred@cisco.com >>>>>> >>>>>>> This is to initiate a one week working group last call of >>>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. >>>>>> >>>>>> I have read this document, and I think it is ready to move forward= =2E >>>>>> >>>>>> Its operational need for this document is less pressing now than w= hen >>>>>> the -00 version was published back in 2011. Nevertheless, I find i= t >>>>>> valuable and correct to put the final nail in 6to4's coffin at thi= s >>>>>> point in time. While the operational community for the most part h= as >>>>>> already realised that 6to4 has no future, there might be some who = have >>>>>> not been paying attention and formal deprecation of the protocol m= ay >>>>>> help prevent them from making the mistake of attempting to base >>>>>> production systems on it. >>>>>> >>>>>> I have one minor comment though: In section 1, it says =C2=ABa sub= stantial >>>>>> amount of 6to4 traffic is still observed by IPv6 content providers= =C2=BB. >>>>>> While I do see 6to4 traffic, it is quite far from being of >>> "substantial" >>>>>> levels. I would therefore recommend replacing "substantial" with >>>>>> something milder like "noticeable", "measurable", or something alo= ng >>>>>> those lines. >>>>>> >>>>>> For what it's worth, today the Google public IPv6 graph shows just= a >>>>>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it'= s >>> not >>>>>> just me. >>>>> >>>>> "Tore, >>>>> >>>>> However, that fraction of Google traffic multipled by Google users >>>>> represents something like 100000 users. I don't think we can dismis= s >>>>> that number of people too easily. It's a matter of taste whether >>>>> that's "substantial" or "noticeable". >>>>> >>>>> Brian" >>>>> >>>>> Actually, to those end users, the impact might be both quite >>> significant >>>>> and noticeable. >>>>> >>>>> I think one explanation for the use of 6to4 tunnelled IPv6 is that >>> their >>>>> hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming >>> Google >>>>> make their services equally available over both, which I think they= >>> do), as >>>>> per RFC3484 address selection rules. >>>>> >>>>> The other explanation for it could be that these users have Happy >>> Eyeballs >>>>> enabled browsers and the browser is choosing to try to use both IPv= 4 >>> and >>>>> IPv6, despite the IPv6 being tunnelled rather than native. From a H= appy >>>>> Eyeballs robustness perspective, that would be quite a reasonable >>> thing to >>>>> do I think. >>>>> >>>>> If the end-hosts aren't following RFC3484's default preferences, th= en >>>>> breaking 6to4 might cause the sorts of timeouts that HE is designed= to >>>>> overcome. RFC3484 is quite old now (2003), and as a minor data poin= t I >>>>> first encountered the implementation of them in around 2008/2009 if= I >>>>> recall correctly on my Linux system (as I was using 6to4 at the tim= e >>> and >>>>> wanted to use tunnelled IPv6 in preference to native IPv4 - >>> gai.conf(3) is >>>>> the way you change that). So if some hosts are still preferring >>> tunnelled >>>>> 6to4 IPv6 over native IPv4 then perhaps they're also not going to b= e >>>>> running a HE enabled browser either. >>>>> >>>>> Perhaps it might be possible for somebody at Google to produce a li= st >>> of >>>>> the browser User-Agent strings for people still using 6to4 to see i= f >>> the >>>>> browsers being used are HE enabled, which might also give some insi= ght >>> into >>>>> RFC3484 support in the underlying OSes. >>>>> >>>>> Regards, >>>>> Mark. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >=20 From nobody Mon Jan 26 23:35:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612701B2BA8 for ; Mon, 26 Jan 2015 23:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, SPF_HELO_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 DRd4rHIOtgbZ for ; Mon, 26 Jan 2015 23:35:25 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD2A1B2BAC for ; Mon, 26 Jan 2015 23:35:24 -0800 (PST) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 07:35:00 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 07:35:00 +0000 From: "Metzler, Dan J" To: Lorenzo Colitti , Brian E Carpenter Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHQOcBG7zVfg+P0Jkqw7Tp1ugb9QJzTOHMAgAAYmICAAABlAIAANeSQ Date: Tue, 27 Jan 2015 07:34:59 +0000 Message-ID: References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.55.230.66] authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=uiowa.edu; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO2PR04MB587; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51704005)(479174004)(13464003)(24454002)(54206007)(74316001)(14971765001)(19580395003)(87936001)(2656002)(19580405001)(90282001)(16236675004)(19300405004)(88552001)(86362001)(122556002)(40100003)(106116001)(89122001)(19609705001)(54606007)(50986999)(62966003)(76576001)(54356999)(76176999)(33656002)(77156002)(15975445007)(102836002)(19617315012)(2950100001)(77096005)(230783001)(2900100001)(46102003)(99286002)(92566002)(19625215002)(93886004)(75432002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CO2PR04MB585F5568616227C5624EF52FE320CO2PR04MB585namprd_" MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 07:34:59.5901 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587 Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 07:35:29 -0000 --_000_CO2PR04MB585F5568616227C5624EF52FE320CO2PR04MB585namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcQXJlIHRoZXNlIHByb2JlcyBtYWRlIHRvIGFuIElQdjYtb25seSBob3N0bmFtZT8gSWYgc28s IHRoZW4gb2YgY291cnNlIHdlJ2QgZXhwZWN0IE9TZXMgdG8gYXR0ZW1wdCA2dG80LuKAnQ0KDQpJ IHdvdWxkIGhvcGUgc28uICBJZiB0aGUgd2hvbGUgcHJlbWlzZSBvZiA2dG80IGJlaW5nIGEgZGVh ZCB0ZWNobm9sb2d5IHdlcmUgYmFzZWQgb24gdGhlIGlkZWEgdGhhdCB3ZSBhcmUgb25seSB0YWxr aW5nIGFib3V0IGR1YWwgc3RhY2sgaG9zdHMsIHRoZW4gdGhpcyB3aG9sZSBleGVyY2lzZSBpcyBz aWxseS4NClByb2JlcyB0byBJUHY2LW9ubHkgaG9zdG5hbWVzIGFyZSBleGFjdGx5IHdoYXQgbWF0 dGVycywgYW5kIEkgd291bGQgYXJndWUgdGhhdCB0aGlzIHRoaW5nIGlzIHJlYWxseSBhIG1vdmlu ZyB0YXJnZXQgdW50aWwgYWxsIElTUHMgYXJlIHByb3ZpZGluZyBJUHY2IGNvbm5lY3Rpdml0eS4N Cg0KVW5sZXNzIGFuIGFsdGVybmF0aXZlIGF1dG8tY29uZmlndXJlZCBzb2x1dGlvbiBpcyBwcm92 aWRlZCBvdXQtb2YtdGhlLWJveCBieSB2ZW5kb3JzLCAobm90IGxpa2VseSBpZiBXR3MgYXJlIGNs YWltaW5nIGl0IGlzbuKAmXQgbmVlZGVkKSwgdGhlbiA2dG80IGlzIGxpa2VseSB0byBoYW5nIGFy b3VuZDsgZXZlbiBpZiBpdCBpc27igJl0IHRoZSBvcHRpbWFsIHNvbHV0aW9uLiAgSSBoZWFyZCBj bGFpbXMgdGhhdCBpdCB3b3VsZCBiZSBhIGdvb2QgNS02IHllYXJzIGJlZm9yZSB2ZW5kb3JzIHdv dWxkIGJlIGFibGUgdG8gcHVzaCBhbiBhbHRlcm5hdGl2ZSBzb2x1dGlvbiBvdXQgdGhlIGRvb3Is IGFuZCBieSB0aGF0IHRpbWUgSVB2NiB3aWxsIGhhdmUgcmVhY2hlZCBjcml0aWNhbCBtYXNzLiAg V2VsbCBpZiB0aGF0IGlzIHRoZSBmdXR1cmUgd2XigJlyZSBwdXR0aW5nIGZvcndhcmQgYW5kIHdl IGFyZW7igJl0IHB1cnN1aW5nIGFuIGFsdGVybmF0aXZlIHNvbHV0aW9uLCB0aGVuIHdlIGFyZSB3 YWl0aW5nIGZvciBJUHY2IHRvIHJlYWNoIGNyaXRpY2FsIG1hc3MgYmVmb3JlIDZ0bzQgcmVhbGx5 IGJlY29tZXMg4oCcZGVhZOKAnTsgb3IgYXQgbGVhc3Qgd2FpdGluZyBmb3IgYWxsIElTUHMgdG8g cHJvdmlkZSBzb21lIGtpbmQgb2YgSVB2NiBjb25uZWN0aXZpdHkuICAoT3IsIHdl4oCZcmUgd2Fp dGluZyBmb3IgdGhlIHJlbGF5IG9wZXJhdG9ycyB0byBjdXQgb2ZmIHRoZWlyIGFjY2Vzcy4pICBV bnRpbCB0aGVuIGl0IGlzIGxpa2VseSB0aGF0IDZ0bzQgd2lsbCBoYW5nIGFyb3VuZCBpbiBhdCB2 YXJpb3VzIGxldmVscyBiZWNhdXNlIHRoZXJlIHdpbGwgYWx3YXlzIGJlIGEgZ3JvdXAgb2YgaW50 ZXJuZXQgdXNlcnMgdGhhdCBhcmUgdXNpbmcgdGhlIGV4aXN0aW5nIDZ0bzQgcmVsYXlzIHRvIGJl IGFibGUgdG8gcmVhY2ggSVB2NiBvbmx5IGhvc3RzLCBhbmQgb3ZlciB0aW1lIHdlIGNhbiBleHBl Y3QgdGhlIG51bWJlciBvZiB2NiBvbmx5IGhvc3RzIHRvIGdvIHVwOyBub3QgZG93bi4NCg0KSSBo YXZlIG5vIG9iamVjdGlvbiB0byB0aGUgZG9jdW1lbnQgYXMgaXQgYWR2b2NhdGVzIGRlcHJlY2F0 aW5nLCBub3QgYnJlYWtpbmcgNnRvNC1QTVQsICh0aGUgYW55Y2FzdCBzdHVmZikuICBJIHdvdWxk IGp1c3QgcG9pbnQgb3V0IHRoYXQgd2UgYXJlIG5vdCB3YWl0aW5nIGZvciBjb250ZW50IHByb3Zp ZGVycyB0byBkbyBzb21ldGhpbmcuICBXZSBhcmUgd2FpdGluZyBmb3IgSVNQcyB0byBwcm92aWRl IG5hdGl2ZSBJUHY2LCBzbyB0aGF0IHBlb3BsZSB3aG8gZG9u4oCZdCByZWFkIFJGQ3Mgb3IgY2Fy ZSBhYm91dCB0aGVtIHdpbGwgZ2V0IHRoZWlyIElQdjYgY29ubmVjdGl2aXR5IHRocm91Z2ggbWV0 aG9kcyBvdGhlciB0aGFuIFRlcmVkbyBhbmQgNnRvNC4gIEkgZG9u4oCZdCBrbm93IGhvdyB5b3Ug bWVhc3VyZSB0aGUgbnVtYmVyIG9mIElTUHMgdGhhdCBhcmUgSVB2NCBvbmx5IHN0aWxsLCBidXQg dG8gbWUgdGhhdOKAmXMgdGhlIGltcG9ydGFudCBtZWFzdXJlbWVudCwgYW5kIHRoZSA2dG80LVBN VCB1c2VycyBhcmUgYSBzdWJzZXQgb2YgdGhlaXIgY3VzdG9tZXJzIHdobyBoYXBwZW4gdG8gaGF2 ZSA2dG80IGNhcGFibGUgZW5kcG9pbnRzIGFuZCBnYXRld2F5cy4NCg0KUmVnYXJkcywNCiAgRGFu DQoNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTG9yZW56byBDb2xpdHRpDQpTZW50OiBNb25kYXksIEphbnVhcnkgMjYsIDIwMTUgOToz NyBQTQ0KVG86IEJyaWFuIEUgQ2FycGVudGVyDQpDYzogVG9yZSBBbmRlcnNvbjsgdjZvcHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtNnRvNC10by1oaXN0 b3JpYyBXR0xDDQoNCkFyZSB0aGVzZSBwcm9iZXMgbWFkZSB0byBhbiBJUHY2LW9ubHkgaG9zdG5h bWU/IElmIHNvLCB0aGVuIG9mIGNvdXJzZSB3ZSdkIGV4cGVjdCBPU2VzIHRvIGF0dGVtcHQgNnRv NC4NCg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTI6MzUgUE0sIEJyaWFuIEUgQ2FycGVudGVy IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbT4+IHdyb3RlOg0KTWVhc3VyYWJsZSwgaW5kZWVkLg0KDQpXaW5kb3dzIDg/IFJlYWxs eT8NCg0KUmVnYXJkcw0KICAgQnJpYW4NCg0KT24gMjcvMDEvMjAxNSAxNTowNywgR2VvcmdlIE1p Y2hhZWxzb24gd3JvdGU6DQo+IEFzayBhbmQgeWUgc2hhbGwgcmVjZWl2ZQ0KPg0KPiBIZXJlIGlz IGEgZGF5cyBzdW1tYXJ5IG9mIG9zLCBicm93c2VyLCBvcyticm93c2VyIGFzIGRldGVybWluZWQg YnkgdGhlDQo+IEFQTklDIDF4MSBjYXB0dXJlLCB1c2luZyAyMDAyOiBhcyB0aGUgc291cmNlIElQ djYgYWRkcmVzcywgYW5kIHRoZSBQeXRob24NCj4gaHR0cGFnZW50cGFyc2VyIG1vZHVsZSB0byBk ZXRlY3QgT1MgYW5kIFZlcnNpb24gaW5mby4NCj4NCj4gLUdlb3JnZQ0KPg0KPiBvcyxXaW5kb3dz KzcsMjIyODcNCj4gb3MsV2luZG93cys4LjEsMTc0Mw0KPiBvcyxXaW5kb3dzK1Zpc3RhLDkzOQ0K PiBvcyxXaW5kb3dzKzgsODk0DQo+IG9zLFdpbmRvd3MrWFAsNDMxDQo+IG9zLE1hY2ludG9zaCtb bmFdLDEyNA0KPiBvcyxpT1MrW25hXSw0NA0KPiBvcyxMaW51eCtbbmFdLDI5DQo+IG9zLFdpbmRv d3MrTlQgNi40LDYNCj4gb3MsV2luZG93cyBQaG9uZSs4LjEsMg0KPiBvcyxDaHJvbWVPUys2MzEw LjY4LjAsMg0KPg0KPiBicm93c2VyLENocm9tZSwxODI5Nw0KPiBicm93c2VyLEZpcmVmb3gsMzc3 NA0KPiBicm93c2VyLE1pY3Jvc29mdCBJbnRlcm5ldCBFeHBsb3JlciwyODcyDQo+IGJyb3dzZXIs T3BlcmEsMTQzOQ0KPiBicm93c2VyLFNhZmFyaSwxMTANCj4gYnJvd3NlcixBbmRyb2lkQnJvd3Nl ciw1DQo+IGJyb3dzZXIsW25hXSwyDQo+IGJyb3dzZXIsU2VhTW9ua2V5LDINCj4NCj4gb3MrYnJv d3NlcixXaW5kb3dzKzcuQ2hyb21lLDE1NTM5DQo+IG9zK2Jyb3dzZXIsV2luZG93cys3LkZpcmVm b3gsMzAzMw0KPiBvcyticm93c2VyLFdpbmRvd3MrNy5NaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9y ZXIsMjQzMg0KPiBvcyticm93c2VyLFdpbmRvd3MrOC4xLkNocm9tZSwxMzA1DQo+IG9zK2Jyb3dz ZXIsV2luZG93cys3Lk9wZXJhLDEyNzcNCj4gb3MrYnJvd3NlcixXaW5kb3dzKzguQ2hyb21lLDY0 NA0KPiBvcyticm93c2VyLFdpbmRvd3MrVmlzdGEuQ2hyb21lLDUzNw0KPiBvcyticm93c2VyLFdp bmRvd3MrOC4xLkZpcmVmb3gsMzExDQo+IG9zK2Jyb3dzZXIsV2luZG93cytWaXN0YS5NaWNyb3Nv ZnQgSW50ZXJuZXQgRXhwbG9yZXIsMjMwDQo+IG9zK2Jyb3dzZXIsV2luZG93cytYUC5DaHJvbWUs MjE2DQo+IG9zK2Jyb3dzZXIsV2luZG93cytWaXN0YS5GaXJlZm94LDE0OA0KPiBvcyticm93c2Vy LFdpbmRvd3MrWFAuRmlyZWZveCwxMzQNCj4gb3MrYnJvd3NlcixXaW5kb3dzKzguRmlyZWZveCwx MTYNCj4gb3MrYnJvd3NlcixXaW5kb3dzKzguTWljcm9zb2Z0IEludGVybmV0IEV4cGxvcmVyLDg3 DQo+IG9zK2Jyb3dzZXIsV2luZG93cys4LjEuT3BlcmEsNjQNCj4gb3MrYnJvd3NlcixXaW5kb3dz KzguMS5NaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9yZXIsNjMNCj4gb3MrYnJvd3NlcixNYWNpbnRv c2grW25hXS5TYWZhcmksNjANCj4gb3MrYnJvd3NlcixXaW5kb3dzK1hQLk1pY3Jvc29mdCBJbnRl cm5ldCBFeHBsb3Jlciw1NA0KPiBvcyticm93c2VyLFdpbmRvd3MrOC5PcGVyYSw0NQ0KPiBvcyti cm93c2VyLGlPUytbbmFdLlNhZmFyaSw0NA0KPiBvcyticm93c2VyLE1hY2ludG9zaCtbbmFdLkNo cm9tZSwzNg0KPiBvcyticm93c2VyLFdpbmRvd3MrWFAuT3BlcmEsMjUNCj4gb3MrYnJvd3NlcixX aW5kb3dzK1Zpc3RhLk9wZXJhLDI0DQo+IG9zK2Jyb3dzZXIsTWFjaW50b3NoK1tuYV0uRmlyZWZv eCwyNA0KPiBvcyticm93c2VyLExpbnV4K1tuYV0uQ2hyb21lLDE2DQo+IG9zK2Jyb3dzZXIsTGlu dXgrW25hXS5GaXJlZm94LDgNCj4gb3MrYnJvd3NlcixXaW5kb3dzKzcuU2FmYXJpLDYNCj4gb3Mr YnJvd3NlcixMaW51eCtbbmFdLkFuZHJvaWRCcm93c2VyLDUNCj4gb3MrYnJvd3NlcixXaW5kb3dz K05UIDYuNC5NaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9yZXIsNA0KPiBvcyticm93c2VyLE1hY2lu dG9zaCtbbmFdLk9wZXJhLDQNCj4gb3MrYnJvd3NlcixXaW5kb3dzK1hQLlNlYU1vbmtleSwyDQo+ IG9zK2Jyb3dzZXIsV2luZG93cytOVCA2LjQuQ2hyb21lLDINCj4gb3MrYnJvd3NlcixXaW5kb3dz KzguW25hXSwyDQo+IG9zK2Jyb3dzZXIsV2luZG93cyBQaG9uZSs4LjEuTWljcm9zb2Z0IEludGVy bmV0IEV4cGxvcmVyLDINCj4gb3MrYnJvd3NlcixDaHJvbWVPUys2MzEwLjY4LjAuQ2hyb21lLDIN Cj4NCj4NCj4gT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgOTozMSBBTSwgTWFyayBaWlogU21pdGgg PG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU8bWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20u YXU+Pg0KPiB3cm90ZToNCj4NCj4+IEknbSBmaW5lIHdpdGggdGhhdC4NCj4+DQo+PiBJZiBpdCBp cyBlYXN5IGVub3VnaCwgSSB0aGluayBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBnZXQgYSBi aXQgbW9yZSBvZg0KPj4gYW4gaW5zaWdodCBpbnRvIHdoby93aGF0IGlzIHN0aWxsIHVzaW5nIDZ0 bzQgZWl0aGVyIGluIHByZWZlcmVuY2UgdG8gb3IgaW4NCj4+IChIRSkgcGFyYWxsZWwgdG8gbmF0 aXZlIElQdjQgYnkgZS5nLiwgY29sbGVjdGluZyBVc2VyLUFnZW50IGZvciA2dG80IHVzZXJzLg0K Pj4NCj4+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAgKkZyb206KiBMb3Jl bnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29t Pj4NCj4+ICpUbzoqIE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PG1h aWx0bzptYXJrenp6c21pdGhAeWFob28uY29tLmF1Pj4NCj4+ICpDYzoqIEJyaWFuIEUgQ2FycGVu dGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVy QGdtYWlsLmNvbT4+OyBUb3JlIEFuZGVyc29uIDwNCj4+IHRvcmVAZnVkLm5vPG1haWx0bzp0b3Jl QGZ1ZC5ubz4+OyAidjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPiIgPHY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQo+PiAqU2VudDoqIFdlZG5lc2RheSwg MjEgSmFudWFyeSAyMDE1LCAyMzoxNg0KPj4NCj4+ICpTdWJqZWN0OiogUmU6IFt2Nm9wc10gZHJh ZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljIFdHTEMNCj4+DQo+PiBZZXMsIHRob3NlIHVz ZXJzIHdpbGwgZGVmaW5pdGVseSBiZSBpbXBhY3RlZC4gV2hpY2ggaXMgd2h5IHRoZSBkb2N1bWVu dA0KPj4gZG9lcyBub3Qgc3VnZ2VzdCBkcm9wcGluZyB0aGUgcGFja2V0cyBvciB0dXJuaW5nIG9m ZiB0aGUgcmVsYXlzLCBleGNlcHQgYnkNCj4+IHNheWluZyB0aGluZ3MgbGlrZSAib3BlcmF0b3Jz IFNIT1VMRCBbLi4uXSBjb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB0aGUNCj4+IFsuLi5dIHJl bGF5IGNhbiBiZSBkaXNjb250aW51ZWQgYXMgdHJhZmZpYyBkaW1pbmlzaGVzIi4gVGhhdCdzIHF1 aXRlDQo+PiByZWFzb25hYmxlIGd1aWRhbmNlLCBJIHRoaW5rLg0KPj4NCj4+IFJlbWVtYmVyOiAw LjAxJSBpcyByZWFsbHkgYSB2ZXJ5IHNtYWxsIG51bWJlci4gTXVsdGlwbHlpbmcgaXQgYnkgMSBi aWxsaW9uDQo+PiAobGlrZSBCcmlhbiBkaWQpIG1ha2VzIGl0IHNlZW0gbGFyZ2UsIGJ1dCB0aGF0 J3MganVzdCBhIHRyaWNrIG9mIHRoZSBsaWdodC4NCj4+IExvb2sgYXQgaXQgdGhpcyB3YXk6IGlm IGFsbCB0aGUgcmVsYXlzIGluIHRoZSB3b3JsZCB3ZXJlIHR1cm5lZCBvZmYNCj4+IG92ZXJuaWdo dCBhbmQgYWxsIHRoZSA2dG80IHVzZXJzIHdlcmUgdW5hYmxlIHRvIHJlYWNoIGEgZ2l2ZW4gd2Vi c2l0ZSwgdGhhdA0KPj4gd2Vic2l0ZSdzIHJlbGlhYmlsaXR5IHdvdWxkIHN0aWxsIGJlIDk5Ljk5 JSBvZiB3aGF0IGl0IHdhcyBiZWZvcmUuDQo+Pg0KPj4gSSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQg aW4gaXRzIGN1cnJlbnQgZm9ybS4gSSBvbmx5IGhhdmUgdGhyZWUgY29tbWVudHMNCj4+IGJleW9u ZCBzZWNvbmRpbmcgVG9yZSdzIG9iamVjdGlvbiB0byB0aGUgZHJhZnQgY2FsbGluZyA2dG80ICJz dWJzdGFudGlhbCI6DQo+Pg0KPj4gICAgMS4gSXMgaXQgbmVjZXNzYXJ5IHRvIGZvcm1hbGx5IGRl cHJlY2F0ZSBSRkMgNjczMj8gSXQncyBhbiBpbmRpdmlkdWFsDQo+PiAgICBzdWJtaXNzaW9uLiAo Tm90IHRoYXQgSSBzdXBwb3J0IFJGQyA2NzMyIGluIGFueSB3YXksIHRvIGJlIHN1cmUuKQ0KPj4g ICAgMi4gSSBkb24ndCB0aGluayB0aGUgc2VudGVuY2UgInNvbWUgY29udGVudCBwcm92aWRlcnMg aGF2ZSBiZWVuDQo+PiAgICByZWx1Y3RhbnQgdG8gbWFrZSBjb250ZW50IGF2YWlsYWJsZSBvdmVy IElQdjYiIGlzIHRydWUsIG9yIGF0IGxlYXN0IGFueQ0KPj4gICAgdHJ1ZSBmb3IgYW55IG5vbi10 cml2aWFsIHZhbHVlIG9mICJzb21lIi4gNnRvNCB3YXMgYSBwcm9ibGVtIGZvciBjb250ZW50DQo+ PiAgICBwcm92aWRlcnMgYSBmZXcgeWVhcnMgYWdvLCBidXQgd2UndmUgbW92ZWQgcGFzdCBpdC4N Cj4+ICAgIDMuIEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBjaXRlIHRoYXQgYW5vdGhlciByZWFzb24g NnRvNCBpcyBiZWluZw0KPj4gICAgZGVwcmVjYXRlZCBpcyB0aGF0IElQdjYgaXMgYWN0dWFsbHkg YmVpbmcgZGVwbG95ZWQgdGhlc2UgZGF5cyAoZmluYWxseSkuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4g T24gV2VkLCBKYW4gMjEsIDIwMTUgYXQgOTozMCBBTSwgTWFyayBaWlogU21pdGggPG1hcmt6enpz bWl0aEB5YWhvby5jb20uYXU8bWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU+DQo+Pj4g d3JvdGU6DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCj4+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j b208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4+DQo+PiBUbzogVG9yZSBBbmRl cnNvbiA8dG9yZUBmdWQubm88bWFpbHRvOnRvcmVAZnVkLm5vPj47IHY2b3BzQGlldGYub3JnPG1h aWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4+IENjOg0KPj4gU2VudDogV2VkbmVzZGF5LCAyMSBKYW51 YXJ5IDIwMTUsIDc6MTQNCj4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMt NnRvNC10by1oaXN0b3JpYyBXR0xDDQo+Pg0KPj4gT24gMjEvMDEvMjAxNSAwMjoxNiwgVG9yZSBB bmRlcnNvbiB3cm90ZToNCj4+PiAqIGZyZWRAY2lzY28uY29tPG1haWx0bzpmcmVkQGNpc2NvLmNv bT4NCj4+Pg0KPj4+PiBUaGlzIGlzIHRvIGluaXRpYXRlIGEgb25lIHdlZWsgd29ya2luZyBncm91 cCBsYXN0IGNhbGwgb2YNCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljLg0KPj4+DQo+Pj4gSSBoYXZlIHJlYWQgdGhpcyBkb2N1 bWVudCwgYW5kIEkgdGhpbmsgaXQgaXMgcmVhZHkgdG8gbW92ZSBmb3J3YXJkLg0KPj4+DQo+Pj4g SXRzIG9wZXJhdGlvbmFsIG5lZWQgZm9yIHRoaXMgZG9jdW1lbnQgaXMgbGVzcyBwcmVzc2luZyBu b3cgdGhhbiB3aGVuDQo+Pj4gdGhlIC0wMCB2ZXJzaW9uIHdhcyBwdWJsaXNoZWQgYmFjayBpbiAy MDExLiBOZXZlcnRoZWxlc3MsIEkgZmluZCBpdA0KPj4+IHZhbHVhYmxlIGFuZCBjb3JyZWN0IHRv IHB1dCB0aGUgZmluYWwgbmFpbCBpbiA2dG80J3MgY29mZmluIGF0IHRoaXMNCj4+PiBwb2ludCBp biB0aW1lLiBXaGlsZSB0aGUgb3BlcmF0aW9uYWwgY29tbXVuaXR5IGZvciB0aGUgbW9zdCBwYXJ0 IGhhcw0KPj4+IGFscmVhZHkgcmVhbGlzZWQgdGhhdCA2dG80IGhhcyBubyBmdXR1cmUsIHRoZXJl IG1pZ2h0IGJlIHNvbWUgd2hvIGhhdmUNCj4+PiBub3QgYmVlbiBwYXlpbmcgYXR0ZW50aW9uIGFu ZCBmb3JtYWwgZGVwcmVjYXRpb24gb2YgdGhlIHByb3RvY29sIG1heQ0KPj4+IGhlbHAgcHJldmVu dCB0aGVtIGZyb20gbWFraW5nIHRoZSBtaXN0YWtlIG9mIGF0dGVtcHRpbmcgdG8gYmFzZQ0KPj4+ IHByb2R1Y3Rpb24gc3lzdGVtcyBvbiBpdC4NCj4+Pg0KPj4+IEkgaGF2ZSBvbmUgbWlub3IgY29t bWVudCB0aG91Z2g6IEluIHNlY3Rpb24gMSwgaXQgc2F5cyDCq2Egc3Vic3RhbnRpYWwNCj4+PiBh bW91bnQgb2YgNnRvNCB0cmFmZmljIGlzIHN0aWxsIG9ic2VydmVkIGJ5IElQdjYgY29udGVudCBw cm92aWRlcnPCuy4NCj4+PiBXaGlsZSBJIGRvIHNlZSA2dG80IHRyYWZmaWMsIGl0IGlzIHF1aXRl IGZhciBmcm9tIGJlaW5nIG9mICJzdWJzdGFudGlhbCINCj4+PiBsZXZlbHMuIEkgd291bGQgdGhl cmVmb3JlIHJlY29tbWVuZCByZXBsYWNpbmcgInN1YnN0YW50aWFsIiB3aXRoDQo+Pj4gc29tZXRo aW5nIG1pbGRlciBsaWtlICJub3RpY2VhYmxlIiwgIm1lYXN1cmFibGUiLCBvciBzb21ldGhpbmcg YWxvbmcNCj4+PiB0aG9zZSBsaW5lcy4NCj4+Pg0KPj4+IEZvciB3aGF0IGl0J3Mgd29ydGgsIHRv ZGF5IHRoZSBHb29nbGUgcHVibGljIElQdjYgZ3JhcGggc2hvd3MganVzdCBhDQo+Pj4gbWVhc2x5 IDAuMDElIG9mIHRoZWlyIHRvdGFsIElQdjYgdHJhZmZpYyBiZWluZyBUZXJlZG8vNnRvNCwgc28g aXQncyBub3QNCj4+PiBqdXN0IG1lLg0KPj4NCj4+ICJUb3JlLA0KPj4NCj4+IEhvd2V2ZXIsIHRo YXQgZnJhY3Rpb24gb2YgR29vZ2xlIHRyYWZmaWMgbXVsdGlwbGVkIGJ5IEdvb2dsZSB1c2Vycw0K Pj4gcmVwcmVzZW50cyBzb21ldGhpbmcgbGlrZSAxMDAwMDAgdXNlcnMuIEkgZG9uJ3QgdGhpbmsg d2UgY2FuIGRpc21pc3MNCj4+IHRoYXQgbnVtYmVyIG9mIHBlb3BsZSB0b28gZWFzaWx5LiBJdCdz IGEgbWF0dGVyIG9mIHRhc3RlIHdoZXRoZXINCj4+IHRoYXQncyAic3Vic3RhbnRpYWwiIG9yICJu b3RpY2VhYmxlIi4NCj4+DQo+PiAgICAgQnJpYW4iDQo+Pg0KPj4gQWN0dWFsbHksIHRvIHRob3Nl IGVuZCB1c2VycywgdGhlIGltcGFjdCBtaWdodCBiZSBib3RoIHF1aXRlIHNpZ25pZmljYW50DQo+ PiBhbmQgbm90aWNlYWJsZS4NCj4+DQo+PiBJIHRoaW5rIG9uZSBleHBsYW5hdGlvbiBmb3IgdGhl IHVzZSBvZiA2dG80IHR1bm5lbGxlZCBJUHY2IGlzIHRoYXQgdGhlaXINCj4+IGhvc3RzIGFyZW4n dCBwcmVmZXJyaW5nIG5hdGl2ZSBJUHY0IG92ZXIgdHVubmVsbGVkIElQdjYgKGFzc3VtaW5nIEdv b2dsZQ0KPj4gbWFrZSB0aGVpciBzZXJ2aWNlcyBlcXVhbGx5IGF2YWlsYWJsZSBvdmVyIGJvdGgs IHdoaWNoIEkgdGhpbmsgdGhleSBkbyksIGFzDQo+PiBwZXIgUkZDMzQ4NCBhZGRyZXNzIHNlbGVj dGlvbiBydWxlcy4NCj4+DQo+PiBUaGUgb3RoZXIgZXhwbGFuYXRpb24gZm9yIGl0IGNvdWxkIGJl IHRoYXQgdGhlc2UgdXNlcnMgaGF2ZSBIYXBweSBFeWViYWxscw0KPj4gZW5hYmxlZCBicm93c2Vy cyBhbmQgdGhlIGJyb3dzZXIgaXMgY2hvb3NpbmcgdG8gdHJ5IHRvIHVzZSBib3RoIElQdjQgYW5k DQo+PiBJUHY2LCBkZXNwaXRlIHRoZSBJUHY2IGJlaW5nIHR1bm5lbGxlZCByYXRoZXIgdGhhbiBu YXRpdmUuIEZyb20gYSBIYXBweQ0KPj4gRXllYmFsbHMgcm9idXN0bmVzcyBwZXJzcGVjdGl2ZSwg dGhhdCB3b3VsZCBiZSBxdWl0ZSBhIHJlYXNvbmFibGUgdGhpbmcgdG8NCj4+IGRvIEkgdGhpbmsu DQo+Pg0KPj4gSWYgdGhlIGVuZC1ob3N0cyBhcmVuJ3QgZm9sbG93aW5nIFJGQzM0ODQncyBkZWZh dWx0IHByZWZlcmVuY2VzLCB0aGVuDQo+PiBicmVha2luZyA2dG80IG1pZ2h0IGNhdXNlIHRoZSBz b3J0cyBvZiB0aW1lb3V0cyB0aGF0IEhFIGlzIGRlc2lnbmVkIHRvDQo+PiBvdmVyY29tZS4gUkZD MzQ4NCBpcyBxdWl0ZSBvbGQgbm93ICgyMDAzKSwgYW5kIGFzIGEgbWlub3IgZGF0YSBwb2ludCBJ DQo+PiBmaXJzdCBlbmNvdW50ZXJlZCB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlbSBpbiBhcm91 bmQgMjAwOC8yMDA5IGlmIEkNCj4+IHJlY2FsbCBjb3JyZWN0bHkgb24gbXkgTGludXggc3lzdGVt IChhcyBJIHdhcyB1c2luZyA2dG80IGF0IHRoZSB0aW1lIGFuZA0KPj4gd2FudGVkIHRvIHVzZSB0 dW5uZWxsZWQgSVB2NiBpbiBwcmVmZXJlbmNlIHRvIG5hdGl2ZSBJUHY0IC0gZ2FpLmNvbmYoMykg aXMNCj4+IHRoZSB3YXkgeW91IGNoYW5nZSB0aGF0KS4gU28gaWYgc29tZSBob3N0cyBhcmUgc3Rp bGwgcHJlZmVycmluZyB0dW5uZWxsZWQNCj4+IDZ0bzQgSVB2NiBvdmVyIG5hdGl2ZSBJUHY0IHRo ZW4gcGVyaGFwcyB0aGV5J3JlIGFsc28gbm90IGdvaW5nIHRvIGJlDQo+PiBydW5uaW5nIGEgSEUg ZW5hYmxlZCBicm93c2VyIGVpdGhlci4NCj4+DQo+PiBQZXJoYXBzIGl0IG1pZ2h0IGJlIHBvc3Np YmxlIGZvciBzb21lYm9keSBhdCBHb29nbGUgdG8gcHJvZHVjZSBhIGxpc3Qgb2YNCj4+IHRoZSBi cm93c2VyIFVzZXItQWdlbnQgc3RyaW5ncyBmb3IgcGVvcGxlIHN0aWxsIHVzaW5nIDZ0bzQgdG8g c2VlIGlmIHRoZQ0KPj4gYnJvd3NlcnMgYmVpbmcgdXNlZCBhcmUgSEUgZW5hYmxlZCwgd2hpY2gg bWlnaHQgYWxzbyBnaXZlIHNvbWUgaW5zaWdodCBpbnRvDQo+PiBSRkMzNDg0IHN1cHBvcnQgaW4g dGhlIHVuZGVybHlpbmcgT1Nlcy4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gTWFyay4NCj4+DQo+Pg0K Pj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHY2b3BzIG1haWxp bmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+DQo+Pg0KPj4NCj4+DQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYu b3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4N Cj4+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZv cHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= --_000_CO2PR04MB585F5568616227C5624EF52FE320CO2PR04MB585namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTU4MDg3MjA5MTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMDM4NTQ0NzggLTk4NTUyMTY5MCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjEy ODsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+QXJlIHRoZXNlIHByb2Jl cyBtYWRlIHRvIGFuIElQdjYtb25seSBob3N0bmFtZT8gSWYgc28sIHRoZW4gb2YgY291cnNlIHdl J2QgZXhwZWN0IE9TZXMgdG8gYXR0ZW1wdCA2dG80LjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd291 bGQgaG9wZSBzby4mbmJzcDsgSWYgdGhlIHdob2xlIHByZW1pc2Ugb2YgNnRvNCBiZWluZyBhIGRl YWQgdGVjaG5vbG9neSB3ZXJlIGJhc2VkIG9uIHRoZSBpZGVhIHRoYXQgd2UgYXJlIG9ubHkgdGFs a2luZyBhYm91dCBkdWFsIHN0YWNrIGhvc3RzLCB0aGVuIHRoaXMgd2hvbGUNCiBleGVyY2lzZSBp cyBzaWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UHJvYmVzIHRvIElQdjYtb25seSBob3N0bmFtZXMg YXJlIGV4YWN0bHkgd2hhdCBtYXR0ZXJzLCBhbmQgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoaXMgdGhp bmcgaXMgcmVhbGx5IGEgbW92aW5nIHRhcmdldCB1bnRpbCBhbGwgSVNQcyBhcmUgcHJvdmlkaW5n IElQdjYgY29ubmVjdGl2aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VW5sZXNzIGFuIGFsdGVybmF0aXZlIGF1dG8tY29uZmlndXJlZCBzb2x1dGlvbiBpcyBw cm92aWRlZCBvdXQtb2YtdGhlLWJveCBieSB2ZW5kb3JzLCAobm90IGxpa2VseSBpZiBXR3MgYXJl IGNsYWltaW5nIGl0IGlzbuKAmXQgbmVlZGVkKSwgdGhlbiA2dG80IGlzIGxpa2VseSB0bw0KIGhh bmcgYXJvdW5kOyBldmVuIGlmIGl0IGlzbuKAmXQgdGhlIG9wdGltYWwgc29sdXRpb24uJm5ic3A7 IEkgaGVhcmQgY2xhaW1zIHRoYXQgaXQgd291bGQgYmUgYSBnb29kIDUtNiB5ZWFycyBiZWZvcmUg dmVuZG9ycyB3b3VsZCBiZSBhYmxlIHRvIHB1c2ggYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gb3V0 IHRoZSBkb29yLCBhbmQgYnkgdGhhdCB0aW1lIElQdjYgd2lsbCBoYXZlIHJlYWNoZWQgY3JpdGlj YWwgbWFzcy4mbmJzcDsgV2VsbCBpZiB0aGF0IGlzIHRoZSBmdXR1cmUNCiB3ZeKAmXJlIHB1dHRp bmcgZm9yd2FyZCBhbmQgd2UgYXJlbuKAmXQgcHVyc3VpbmcgYW4gYWx0ZXJuYXRpdmUgc29sdXRp b24sIHRoZW4gd2UgYXJlIHdhaXRpbmcgZm9yIElQdjYgdG8gcmVhY2ggY3JpdGljYWwgbWFzcyBi ZWZvcmUgNnRvNCByZWFsbHkgYmVjb21lcyDigJxkZWFk4oCdOyBvciBhdCBsZWFzdCB3YWl0aW5n IGZvciBhbGwgSVNQcyB0byBwcm92aWRlIHNvbWUga2luZCBvZiBJUHY2IGNvbm5lY3Rpdml0eS4m bmJzcDsgKE9yLCB3ZeKAmXJlIHdhaXRpbmcgZm9yDQogdGhlIHJlbGF5IG9wZXJhdG9ycyB0byBj dXQgb2ZmIHRoZWlyIGFjY2Vzcy4pJm5ic3A7IFVudGlsIHRoZW4gaXQgaXMgbGlrZWx5IHRoYXQg NnRvNCB3aWxsIGhhbmcgYXJvdW5kIGluIGF0IHZhcmlvdXMgbGV2ZWxzIGJlY2F1c2UgdGhlcmUg d2lsbCBhbHdheXMgYmUgYSBncm91cCBvZiBpbnRlcm5ldCB1c2VycyB0aGF0IGFyZSB1c2luZyB0 aGUgZXhpc3RpbmcgNnRvNCByZWxheXMgdG8gYmUgYWJsZSB0byByZWFjaCBJUHY2IG9ubHkgaG9z dHMsIGFuZCBvdmVyDQogdGltZSB3ZSBjYW4gZXhwZWN0IHRoZSBudW1iZXIgb2YgdjYgb25seSBo b3N0cyB0byBnbyB1cDsgbm90IGRvd24uJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIG5vIG9iamVjdGlvbiB0byB0aGUgZG9jdW1lbnQgYXMg aXQgYWR2b2NhdGVzIGRlcHJlY2F0aW5nLCBub3QgYnJlYWtpbmcgNnRvNC1QTVQsICh0aGUgYW55 Y2FzdCBzdHVmZikuJm5ic3A7IEkgd291bGQganVzdCBwb2ludCBvdXQgdGhhdCB3ZSBhcmUgbm90 IHdhaXRpbmcgZm9yDQogY29udGVudCBwcm92aWRlcnMgdG8gZG8gc29tZXRoaW5nLiZuYnNwOyBX ZSBhcmUgd2FpdGluZyBmb3IgSVNQcyB0byBwcm92aWRlIG5hdGl2ZSBJUHY2LCBzbyB0aGF0IHBl b3BsZSB3aG8gZG9u4oCZdCByZWFkIFJGQ3Mgb3IgY2FyZSBhYm91dCB0aGVtIHdpbGwgZ2V0IHRo ZWlyIElQdjYgY29ubmVjdGl2aXR5IHRocm91Z2ggbWV0aG9kcyBvdGhlciB0aGFuIFRlcmVkbyBh bmQgNnRvNC4mbmJzcDsgSSBkb27igJl0IGtub3cgaG93IHlvdSBtZWFzdXJlIHRoZSBudW1iZXIN CiBvZiBJU1BzIHRoYXQgYXJlIElQdjQgb25seSBzdGlsbCwgYnV0IHRvIG1lIHRoYXTigJlzIHRo ZSBpbXBvcnRhbnQgbWVhc3VyZW1lbnQsIGFuZCB0aGUgNnRvNC1QTVQgdXNlcnMgYXJlIGEgc3Vi c2V0IG9mIHRoZWlyIGN1c3RvbWVycyB3aG8gaGFwcGVuIHRvIGhhdmUgNnRvNCBjYXBhYmxlIGVu ZHBvaW50cyBhbmQgZ2F0ZXdheXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsgRGFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDk6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+ IEJyaWFuIEUgQ2FycGVudGVyPGJyPg0KPGI+Q2M6PC9iPiBUb3JlIEFuZGVyc29uOyB2Nm9wc0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3Bz LTZ0bzQtdG8taGlzdG9yaWMgV0dMQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgdGhlc2UgcHJvYmVzIG1hZGUgdG8gYW4gSVB2Ni1vbmx5 IGhvc3RuYW1lPyBJZiBzbywgdGhlbiBvZiBjb3Vyc2Ugd2UnZCBleHBlY3QgT1NlcyB0byBhdHRl bXB0IDZ0bzQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg SmFuIDI3LCAyMDE1IGF0IDEyOjM1IFBNLCBCcmlhbiBFIENhcnBlbnRlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lYXN1cmFibGUsIGluZGVlZC48YnI+DQo8 YnI+DQpXaW5kb3dzIDg/IFJlYWxseT88YnI+DQo8YnI+DQpSZWdhcmRzPGJyPg0KJm5ic3A7ICZu YnNwO0JyaWFuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCk9uIDI3LzAxLzIwMTUgMTU6MDcsIEdlb3JnZSBNaWNoYWVsc29uIHdyb3RlOjxi cj4NCiZndDsgQXNrIGFuZCB5ZSBzaGFsbCByZWNlaXZlPGJyPg0KJmd0Ozxicj4NCiZndDsgSGVy ZSBpcyBhIGRheXMgc3VtbWFyeSBvZiBvcywgYnJvd3Nlciwgb3MmIzQzO2Jyb3dzZXIgYXMgZGV0 ZXJtaW5lZCBieSB0aGU8YnI+DQomZ3Q7IEFQTklDIDF4MSBjYXB0dXJlLCB1c2luZyAyMDAyOiBh cyB0aGUgc291cmNlIElQdjYgYWRkcmVzcywgYW5kIHRoZSBQeXRob248YnI+DQomZ3Q7IGh0dHBh Z2VudHBhcnNlciBtb2R1bGUgdG8gZGV0ZWN0IE9TIGFuZCBWZXJzaW9uIGluZm8uPGJyPg0KJmd0 Ozxicj4NCiZndDsgLUdlb3JnZTxicj4NCiZndDs8YnI+DQomZ3Q7IG9zLFdpbmRvd3MmIzQzOzcs MjIyODc8YnI+DQomZ3Q7IG9zLFdpbmRvd3MmIzQzOzguMSwxNzQzPGJyPg0KJmd0OyBvcyxXaW5k b3dzJiM0MztWaXN0YSw5Mzk8YnI+DQomZ3Q7IG9zLFdpbmRvd3MmIzQzOzgsODk0PGJyPg0KJmd0 OyBvcyxXaW5kb3dzJiM0MztYUCw0MzE8YnI+DQomZ3Q7IG9zLE1hY2ludG9zaCYjNDM7W25hXSwx MjQ8YnI+DQomZ3Q7IG9zLGlPUyYjNDM7W25hXSw0NDxicj4NCiZndDsgb3MsTGludXgmIzQzO1tu YV0sMjk8YnI+DQomZ3Q7IG9zLFdpbmRvd3MmIzQzO05UIDYuNCw2PGJyPg0KJmd0OyBvcyxXaW5k b3dzIFBob25lJiM0Mzs4LjEsMjxicj4NCiZndDsgb3MsQ2hyb21lT1MmIzQzOzYzMTAuNjguMCwy PGJyPg0KJmd0Ozxicj4NCiZndDsgYnJvd3NlcixDaHJvbWUsMTgyOTc8YnI+DQomZ3Q7IGJyb3dz ZXIsRmlyZWZveCwzNzc0PGJyPg0KJmd0OyBicm93c2VyLE1pY3Jvc29mdCBJbnRlcm5ldCBFeHBs b3JlciwyODcyPGJyPg0KJmd0OyBicm93c2VyLE9wZXJhLDE0Mzk8YnI+DQomZ3Q7IGJyb3dzZXIs U2FmYXJpLDExMDxicj4NCiZndDsgYnJvd3NlcixBbmRyb2lkQnJvd3Nlciw1PGJyPg0KJmd0OyBi cm93c2VyLFtuYV0sMjxicj4NCiZndDsgYnJvd3NlcixTZWFNb25rZXksMjxicj4NCiZndDs8YnI+ DQomZ3Q7IG9zJiM0Mzticm93c2VyLFdpbmRvd3MmIzQzOzcuQ2hyb21lLDE1NTM5PGJyPg0KJmd0 OyBvcyYjNDM7YnJvd3NlcixXaW5kb3dzJiM0Mzs3LkZpcmVmb3gsMzAzMzxicj4NCiZndDsgb3Mm IzQzO2Jyb3dzZXIsV2luZG93cyYjNDM7Ny5NaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9yZXIsMjQz Mjxicj4NCiZndDsgb3MmIzQzO2Jyb3dzZXIsV2luZG93cyYjNDM7OC4xLkNocm9tZSwxMzA1PGJy Pg0KJmd0OyBvcyYjNDM7YnJvd3NlcixXaW5kb3dzJiM0Mzs3Lk9wZXJhLDEyNzc8YnI+DQomZ3Q7 IG9zJiM0Mzticm93c2VyLFdpbmRvd3MmIzQzOzguQ2hyb21lLDY0NDxicj4NCiZndDsgb3MmIzQz O2Jyb3dzZXIsV2luZG93cyYjNDM7VmlzdGEuQ2hyb21lLDUzNzxicj4NCiZndDsgb3MmIzQzO2Jy b3dzZXIsV2luZG93cyYjNDM7OC4xLkZpcmVmb3gsMzExPGJyPg0KJmd0OyBvcyYjNDM7YnJvd3Nl cixXaW5kb3dzJiM0MztWaXN0YS5NaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9yZXIsMjMwPGJyPg0K Jmd0OyBvcyYjNDM7YnJvd3NlcixXaW5kb3dzJiM0MztYUC5DaHJvbWUsMjE2PGJyPg0KJmd0OyBv cyYjNDM7YnJvd3NlcixXaW5kb3dzJiM0MztWaXN0YS5GaXJlZm94LDE0ODxicj4NCiZndDsgb3Mm IzQzO2Jyb3dzZXIsV2luZG93cyYjNDM7WFAuRmlyZWZveCwxMzQ8YnI+DQomZ3Q7IG9zJiM0Mzti cm93c2VyLFdpbmRvd3MmIzQzOzguRmlyZWZveCwxMTY8YnI+DQomZ3Q7IG9zJiM0Mzticm93c2Vy LFdpbmRvd3MmIzQzOzguTWljcm9zb2Z0IEludGVybmV0IEV4cGxvcmVyLDg3PGJyPg0KJmd0OyBv cyYjNDM7YnJvd3NlcixXaW5kb3dzJiM0Mzs4LjEuT3BlcmEsNjQ8YnI+DQomZ3Q7IG9zJiM0Mzti cm93c2VyLFdpbmRvd3MmIzQzOzguMS5NaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9yZXIsNjM8YnI+ DQomZ3Q7IG9zJiM0Mzticm93c2VyLE1hY2ludG9zaCYjNDM7W25hXS5TYWZhcmksNjA8YnI+DQom Z3Q7IG9zJiM0Mzticm93c2VyLFdpbmRvd3MmIzQzO1hQLk1pY3Jvc29mdCBJbnRlcm5ldCBFeHBs b3Jlciw1NDxicj4NCiZndDsgb3MmIzQzO2Jyb3dzZXIsV2luZG93cyYjNDM7OC5PcGVyYSw0NTxi cj4NCiZndDsgb3MmIzQzO2Jyb3dzZXIsaU9TJiM0MztbbmFdLlNhZmFyaSw0NDxicj4NCiZndDsg b3MmIzQzO2Jyb3dzZXIsTWFjaW50b3NoJiM0MztbbmFdLkNocm9tZSwzNjxicj4NCiZndDsgb3Mm IzQzO2Jyb3dzZXIsV2luZG93cyYjNDM7WFAuT3BlcmEsMjU8YnI+DQomZ3Q7IG9zJiM0Mzticm93 c2VyLFdpbmRvd3MmIzQzO1Zpc3RhLk9wZXJhLDI0PGJyPg0KJmd0OyBvcyYjNDM7YnJvd3NlcixN YWNpbnRvc2gmIzQzO1tuYV0uRmlyZWZveCwyNDxicj4NCiZndDsgb3MmIzQzO2Jyb3dzZXIsTGlu dXgmIzQzO1tuYV0uQ2hyb21lLDE2PGJyPg0KJmd0OyBvcyYjNDM7YnJvd3NlcixMaW51eCYjNDM7 W25hXS5GaXJlZm94LDg8YnI+DQomZ3Q7IG9zJiM0Mzticm93c2VyLFdpbmRvd3MmIzQzOzcuU2Fm YXJpLDY8YnI+DQomZ3Q7IG9zJiM0Mzticm93c2VyLExpbnV4JiM0MztbbmFdLkFuZHJvaWRCcm93 c2VyLDU8YnI+DQomZ3Q7IG9zJiM0Mzticm93c2VyLFdpbmRvd3MmIzQzO05UIDYuNC5NaWNyb3Nv ZnQgSW50ZXJuZXQgRXhwbG9yZXIsNDxicj4NCiZndDsgb3MmIzQzO2Jyb3dzZXIsTWFjaW50b3No JiM0MztbbmFdLk9wZXJhLDQ8YnI+DQomZ3Q7IG9zJiM0Mzticm93c2VyLFdpbmRvd3MmIzQzO1hQ LlNlYU1vbmtleSwyPGJyPg0KJmd0OyBvcyYjNDM7YnJvd3NlcixXaW5kb3dzJiM0MztOVCA2LjQu Q2hyb21lLDI8YnI+DQomZ3Q7IG9zJiM0Mzticm93c2VyLFdpbmRvd3MmIzQzOzguW25hXSwyPGJy Pg0KJmd0OyBvcyYjNDM7YnJvd3NlcixXaW5kb3dzIFBob25lJiM0Mzs4LjEuTWljcm9zb2Z0IElu dGVybmV0IEV4cGxvcmVyLDI8YnI+DQomZ3Q7IG9zJiM0Mzticm93c2VyLENocm9tZU9TJiM0Mzs2 MzEwLjY4LjAuQ2hyb21lLDI8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gVHVlLCBK YW4gMjcsIDIwMTUgYXQgOTozMSBBTSwgTWFyayBaWlogU21pdGggJmx0OzxhIGhyZWY9Im1haWx0 bzptYXJrenp6c21pdGhAeWFob28uY29tLmF1Ij5tYXJrenp6c21pdGhAeWFob28uY29tLmF1PC9h PiZndDs8YnI+DQomZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBJJ20gZmluZSB3 aXRoIHRoYXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiBpdCBpcyBlYXN5IGVub3Vn aCwgSSB0aGluayBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBnZXQgYSBiaXQgbW9yZSBvZjxi cj4NCiZndDsmZ3Q7IGFuIGluc2lnaHQgaW50byB3aG8vd2hhdCBpcyBzdGlsbCB1c2luZyA2dG80 IGVpdGhlciBpbiBwcmVmZXJlbmNlIHRvIG9yIGluPGJyPg0KJmd0OyZndDsgKEhFKSBwYXJhbGxl bCB0byBuYXRpdmUgSVB2NCBieSBlLmcuLCBjb2xsZWN0aW5nIFVzZXItQWdlbnQgZm9yIDZ0bzQg dXNlcnMuPGJyPg0KJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZuYnNwOyAmbmJzcDstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyZuYnNwOyAqRnJvbToqIExvcmVuem8gQ29saXR0aSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSI+bG9yZW56b0Bnb29nbGUuY29t PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAqVG86KiBNYXJrIFpaWiBTbWl0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXUiPm1hcmt6enpzbWl0aEB5YWhvby5jb20u YXU8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICpDYzoqIEJyaWFuIEUgQ2FycGVudGVyICZsdDs8YSBo cmVmPSJtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tIj5icmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb208L2E+Jmd0OzsgVG9yZSBBbmRlcnNvbiAmbHQ7PGJyPg0KJmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOnRvcmVAZnVkLm5vIj50b3JlQGZ1ZC5ubzwvYT4mZ3Q7OyAmcXVvdDs8YSBo cmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KJmd0OyZndDsgKlNlbnQ6KiBXZWRuZXNkYXksIDIxIEphbnVhcnkgMjAxNSwgMjM6MTY8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICpTdWJqZWN0OiogUmU6IFt2Nm9wc10gZHJhZnQtaWV0 Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljIFdHTEM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IFllcywgdGhvc2UgdXNlcnMgd2lsbCBkZWZpbml0ZWx5IGJlIGltcGFjdGVkLiBXaGljaCBpcyB3 aHkgdGhlIGRvY3VtZW50PGJyPg0KJmd0OyZndDsgZG9lcyBub3Qgc3VnZ2VzdCBkcm9wcGluZyB0 aGUgcGFja2V0cyBvciB0dXJuaW5nIG9mZiB0aGUgcmVsYXlzLCBleGNlcHQgYnk8YnI+DQomZ3Q7 Jmd0OyBzYXlpbmcgdGhpbmdzIGxpa2UgJnF1b3Q7b3BlcmF0b3JzIFNIT1VMRCBbLi4uXSBjb25z aWRlciBjYXJlZnVsbHkgd2hldGhlciB0aGU8YnI+DQomZ3Q7Jmd0OyBbLi4uXSByZWxheSBjYW4g YmUgZGlzY29udGludWVkIGFzIHRyYWZmaWMgZGltaW5pc2hlcyZxdW90Oy4gVGhhdCdzIHF1aXRl PGJyPg0KJmd0OyZndDsgcmVhc29uYWJsZSBndWlkYW5jZSwgSSB0aGluay48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IFJlbWVtYmVyOiAwLjAxJSBpcyByZWFsbHkgYSB2ZXJ5IHNtYWxsIG51 bWJlci4gTXVsdGlwbHlpbmcgaXQgYnkgMSBiaWxsaW9uPGJyPg0KJmd0OyZndDsgKGxpa2UgQnJp YW4gZGlkKSBtYWtlcyBpdCBzZWVtIGxhcmdlLCBidXQgdGhhdCdzIGp1c3QgYSB0cmljayBvZiB0 aGUgbGlnaHQuPGJyPg0KJmd0OyZndDsgTG9vayBhdCBpdCB0aGlzIHdheTogaWYgYWxsIHRoZSBy ZWxheXMgaW4gdGhlIHdvcmxkIHdlcmUgdHVybmVkIG9mZjxicj4NCiZndDsmZ3Q7IG92ZXJuaWdo dCBhbmQgYWxsIHRoZSA2dG80IHVzZXJzIHdlcmUgdW5hYmxlIHRvIHJlYWNoIGEgZ2l2ZW4gd2Vi c2l0ZSwgdGhhdDxicj4NCiZndDsmZ3Q7IHdlYnNpdGUncyByZWxpYWJpbGl0eSB3b3VsZCBzdGls bCBiZSA5OS45OSUgb2Ygd2hhdCBpdCB3YXMgYmVmb3JlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgSSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgaW4gaXRzIGN1cnJlbnQgZm9ybS4gSSBvbmx5 IGhhdmUgdGhyZWUgY29tbWVudHM8YnI+DQomZ3Q7Jmd0OyBiZXlvbmQgc2Vjb25kaW5nIFRvcmUn cyBvYmplY3Rpb24gdG8gdGhlIGRyYWZ0IGNhbGxpbmcgNnRvNCAmcXVvdDtzdWJzdGFudGlhbCZx dW90Ozo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAxLiBJcyBpdCBu ZWNlc3NhcnkgdG8gZm9ybWFsbHkgZGVwcmVjYXRlIFJGQyA2NzMyPyBJdCdzIGFuIGluZGl2aWR1 YWw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgc3VibWlzc2lvbi4gKE5vdCB0aGF0IEkgc3Vw cG9ydCBSRkMgNjczMiBpbiBhbnkgd2F5LCB0byBiZSBzdXJlLik8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgMi4gSSBkb24ndCB0aGluayB0aGUgc2VudGVuY2UgJnF1b3Q7c29tZSBjb250ZW50 IHByb3ZpZGVycyBoYXZlIGJlZW48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgcmVsdWN0YW50 IHRvIG1ha2UgY29udGVudCBhdmFpbGFibGUgb3ZlciBJUHY2JnF1b3Q7IGlzIHRydWUsIG9yIGF0 IGxlYXN0IGFueTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0cnVlIGZvciBhbnkgbm9uLXRy aXZpYWwgdmFsdWUgb2YgJnF1b3Q7c29tZSZxdW90Oy4gNnRvNCB3YXMgYSBwcm9ibGVtIGZvciBj b250ZW50PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IHByb3ZpZGVycyBhIGZldyB5ZWFycyBh Z28sIGJ1dCB3ZSd2ZSBtb3ZlZCBwYXN0IGl0Ljxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAz LiBJdCBtaWdodCBiZSB1c2VmdWwgdG8gY2l0ZSB0aGF0IGFub3RoZXIgcmVhc29uIDZ0bzQgaXMg YmVpbmc8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyZndDsmbmJzcDsgJm5ic3A7IGRlcHJlY2F0ZWQgaXMgdGhhdCBJUHY2IGlzIGFjdHVhbGx5 IGJlaW5nIGRlcGxveWVkIHRoZXNlIGRheXMgKGZpbmFsbHkpLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gV2Vk LCBKYW4gMjEsIDIwMTUgYXQgOTozMCBBTSwgTWFyayBaWlogU21pdGggJmx0OzxhIGhyZWY9Im1h aWx0bzptYXJrenp6c21pdGhAeWFob28uY29tLmF1Ij5tYXJrenp6c21pdGhAeWFob28uY29tLmF1 PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IEJyaWFuIEUg Q2FycGVudGVyICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29t Ij5icmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IFRvOiBU b3JlIEFuZGVyc29uICZsdDs8YSBocmVmPSJtYWlsdG86dG9yZUBmdWQubm8iPnRvcmVAZnVkLm5v PC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+DQp2Nm9wc0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Jmd0OyBDYzo8YnI+DQomZ3Q7Jmd0OyBTZW50OiBXZWRuZXNkYXksIDIx IEphbnVhcnkgMjAxNSwgNzoxNDxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRy YWZ0LWlldGYtdjZvcHMtNnRvNC10by1oaXN0b3JpYyBXR0xDPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBPbiAyMS8wMS8yMDE1IDAyOjE2LCBUb3JlIEFuZGVyc29uIHdyb3RlOjxicj4NCiZn dDsmZ3Q7Jmd0OyAqIDxhIGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+ZnJlZEBjaXNjby5j b208L2E+PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIHRv IGluaXRpYXRlIGEgb25lIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb2Y8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdjZvcHMtNnRvNC10by1oaXN0b3JpYyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljPC9hPi48YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSSBoYXZlIHJlYWQgdGhpcyBkb2N1bWVu dCwgYW5kIEkgdGhpbmsgaXQgaXMgcmVhZHkgdG8gbW92ZSBmb3J3YXJkLjxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJdHMgb3BlcmF0aW9uYWwgbmVlZCBmb3IgdGhpcyBkb2N1 bWVudCBpcyBsZXNzIHByZXNzaW5nIG5vdyB0aGFuIHdoZW48YnI+DQomZ3Q7Jmd0OyZndDsgdGhl IC0wMCB2ZXJzaW9uIHdhcyBwdWJsaXNoZWQgYmFjayBpbiAyMDExLiBOZXZlcnRoZWxlc3MsIEkg ZmluZCBpdDxicj4NCiZndDsmZ3Q7Jmd0OyB2YWx1YWJsZSBhbmQgY29ycmVjdCB0byBwdXQgdGhl IGZpbmFsIG5haWwgaW4gNnRvNCdzIGNvZmZpbiBhdCB0aGlzPGJyPg0KJmd0OyZndDsmZ3Q7IHBv aW50IGluIHRpbWUuIFdoaWxlIHRoZSBvcGVyYXRpb25hbCBjb21tdW5pdHkgZm9yIHRoZSBtb3N0 IHBhcnQgaGFzPGJyPg0KJmd0OyZndDsmZ3Q7IGFscmVhZHkgcmVhbGlzZWQgdGhhdCA2dG80IGhh cyBubyBmdXR1cmUsIHRoZXJlIG1pZ2h0IGJlIHNvbWUgd2hvIGhhdmU8YnI+DQomZ3Q7Jmd0OyZn dDsgbm90IGJlZW4gcGF5aW5nIGF0dGVudGlvbiBhbmQgZm9ybWFsIGRlcHJlY2F0aW9uIG9mIHRo ZSBwcm90b2NvbCBtYXk8YnI+DQomZ3Q7Jmd0OyZndDsgaGVscCBwcmV2ZW50IHRoZW0gZnJvbSBt YWtpbmcgdGhlIG1pc3Rha2Ugb2YgYXR0ZW1wdGluZyB0byBiYXNlPGJyPg0KJmd0OyZndDsmZ3Q7 IHByb2R1Y3Rpb24gc3lzdGVtcyBvbiBpdC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgSSBoYXZlIG9uZSBtaW5vciBjb21tZW50IHRob3VnaDogSW4gc2VjdGlvbiAxLCBpdCBz YXlzIMKrYSBzdWJzdGFudGlhbDxicj4NCiZndDsmZ3Q7Jmd0OyBhbW91bnQgb2YgNnRvNCB0cmFm ZmljIGlzIHN0aWxsIG9ic2VydmVkIGJ5IElQdjYgY29udGVudCBwcm92aWRlcnPCuy48YnI+DQom Z3Q7Jmd0OyZndDsgV2hpbGUgSSBkbyBzZWUgNnRvNCB0cmFmZmljLCBpdCBpcyBxdWl0ZSBmYXIg ZnJvbSBiZWluZyBvZiAmcXVvdDtzdWJzdGFudGlhbCZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OyBs ZXZlbHMuIEkgd291bGQgdGhlcmVmb3JlIHJlY29tbWVuZCByZXBsYWNpbmcgJnF1b3Q7c3Vic3Rh bnRpYWwmcXVvdDsgd2l0aDxicj4NCiZndDsmZ3Q7Jmd0OyBzb21ldGhpbmcgbWlsZGVyIGxpa2Ug JnF1b3Q7bm90aWNlYWJsZSZxdW90OywgJnF1b3Q7bWVhc3VyYWJsZSZxdW90Oywgb3Igc29tZXRo aW5nIGFsb25nPGJyPg0KJmd0OyZndDsmZ3Q7IHRob3NlIGxpbmVzLjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBGb3Igd2hhdCBpdCdzIHdvcnRoLCB0b2RheSB0aGUgR29vZ2xl IHB1YmxpYyBJUHY2IGdyYXBoIHNob3dzIGp1c3QgYTxicj4NCiZndDsmZ3Q7Jmd0OyBtZWFzbHkg MC4wMSUgb2YgdGhlaXIgdG90YWwgSVB2NiB0cmFmZmljIGJlaW5nIFRlcmVkby82dG80LCBzbyBp dCdzIG5vdDxicj4NCiZndDsmZ3Q7Jmd0OyBqdXN0IG1lLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJnF1b3Q7VG9yZSw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhvd2V2ZXIsIHRo YXQgZnJhY3Rpb24gb2YgR29vZ2xlIHRyYWZmaWMgbXVsdGlwbGVkIGJ5IEdvb2dsZSB1c2Vyczxi cj4NCiZndDsmZ3Q7IHJlcHJlc2VudHMgc29tZXRoaW5nIGxpa2UgMTAwMDAwIHVzZXJzLiBJIGRv bid0IHRoaW5rIHdlIGNhbiBkaXNtaXNzPGJyPg0KJmd0OyZndDsgdGhhdCBudW1iZXIgb2YgcGVv cGxlIHRvbyBlYXNpbHkuIEl0J3MgYSBtYXR0ZXIgb2YgdGFzdGUgd2hldGhlcjxicj4NCiZndDsm Z3Q7IHRoYXQncyAmcXVvdDtzdWJzdGFudGlhbCZxdW90OyBvciAmcXVvdDtub3RpY2VhYmxlJnF1 b3Q7Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0JyaWFu JnF1b3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBY3R1YWxseSwgdG8gdGhvc2UgZW5k IHVzZXJzLCB0aGUgaW1wYWN0IG1pZ2h0IGJlIGJvdGggcXVpdGUgc2lnbmlmaWNhbnQ8YnI+DQom Z3Q7Jmd0OyBhbmQgbm90aWNlYWJsZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgdGhp bmsgb25lIGV4cGxhbmF0aW9uIGZvciB0aGUgdXNlIG9mIDZ0bzQgdHVubmVsbGVkIElQdjYgaXMg dGhhdCB0aGVpcjxicj4NCiZndDsmZ3Q7IGhvc3RzIGFyZW4ndCBwcmVmZXJyaW5nIG5hdGl2ZSBJ UHY0IG92ZXIgdHVubmVsbGVkIElQdjYgKGFzc3VtaW5nIEdvb2dsZTxicj4NCiZndDsmZ3Q7IG1h a2UgdGhlaXIgc2VydmljZXMgZXF1YWxseSBhdmFpbGFibGUgb3ZlciBib3RoLCB3aGljaCBJIHRo aW5rIHRoZXkgZG8pLCBhczxicj4NCiZndDsmZ3Q7IHBlciBSRkMzNDg0IGFkZHJlc3Mgc2VsZWN0 aW9uIHJ1bGVzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIG90aGVyIGV4cGxhbmF0 aW9uIGZvciBpdCBjb3VsZCBiZSB0aGF0IHRoZXNlIHVzZXJzIGhhdmUgSGFwcHkgRXllYmFsbHM8 YnI+DQomZ3Q7Jmd0OyBlbmFibGVkIGJyb3dzZXJzIGFuZCB0aGUgYnJvd3NlciBpcyBjaG9vc2lu ZyB0byB0cnkgdG8gdXNlIGJvdGggSVB2NCBhbmQ8YnI+DQomZ3Q7Jmd0OyBJUHY2LCBkZXNwaXRl IHRoZSBJUHY2IGJlaW5nIHR1bm5lbGxlZCByYXRoZXIgdGhhbiBuYXRpdmUuIEZyb20gYSBIYXBw eTxicj4NCiZndDsmZ3Q7IEV5ZWJhbGxzIHJvYnVzdG5lc3MgcGVyc3BlY3RpdmUsIHRoYXQgd291 bGQgYmUgcXVpdGUgYSByZWFzb25hYmxlIHRoaW5nIHRvPGJyPg0KJmd0OyZndDsgZG8gSSB0aGlu ay48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IElmIHRoZSBlbmQtaG9zdHMgYXJlbid0IGZv bGxvd2luZyBSRkMzNDg0J3MgZGVmYXVsdCBwcmVmZXJlbmNlcywgdGhlbjxicj4NCiZndDsmZ3Q7 IGJyZWFraW5nIDZ0bzQgbWlnaHQgY2F1c2UgdGhlIHNvcnRzIG9mIHRpbWVvdXRzIHRoYXQgSEUg aXMgZGVzaWduZWQgdG88YnI+DQomZ3Q7Jmd0OyBvdmVyY29tZS4gUkZDMzQ4NCBpcyBxdWl0ZSBv bGQgbm93ICgyMDAzKSwgYW5kIGFzIGEgbWlub3IgZGF0YSBwb2ludCBJPGJyPg0KJmd0OyZndDsg Zmlyc3QgZW5jb3VudGVyZWQgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZW0gaW4gYXJvdW5kIDIw MDgvMjAwOSBpZiBJPGJyPg0KJmd0OyZndDsgcmVjYWxsIGNvcnJlY3RseSBvbiBteSBMaW51eCBz eXN0ZW0gKGFzIEkgd2FzIHVzaW5nIDZ0bzQgYXQgdGhlIHRpbWUgYW5kPGJyPg0KJmd0OyZndDsg d2FudGVkIHRvIHVzZSB0dW5uZWxsZWQgSVB2NiBpbiBwcmVmZXJlbmNlIHRvIG5hdGl2ZSBJUHY0 IC0gZ2FpLmNvbmYoMykgaXM8YnI+DQomZ3Q7Jmd0OyB0aGUgd2F5IHlvdSBjaGFuZ2UgdGhhdCku IFNvIGlmIHNvbWUgaG9zdHMgYXJlIHN0aWxsIHByZWZlcnJpbmcgdHVubmVsbGVkPGJyPg0KJmd0 OyZndDsgNnRvNCBJUHY2IG92ZXIgbmF0aXZlIElQdjQgdGhlbiBwZXJoYXBzIHRoZXkncmUgYWxz byBub3QgZ29pbmcgdG8gYmU8YnI+DQomZ3Q7Jmd0OyBydW5uaW5nIGEgSEUgZW5hYmxlZCBicm93 c2VyIGVpdGhlci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFBlcmhhcHMgaXQgbWlnaHQg YmUgcG9zc2libGUgZm9yIHNvbWVib2R5IGF0IEdvb2dsZSB0byBwcm9kdWNlIGEgbGlzdCBvZjxi cj4NCiZndDsmZ3Q7IHRoZSBicm93c2VyIFVzZXItQWdlbnQgc3RyaW5ncyBmb3IgcGVvcGxlIHN0 aWxsIHVzaW5nIDZ0bzQgdG8gc2VlIGlmIHRoZTxicj4NCiZndDsmZ3Q7IGJyb3dzZXJzIGJlaW5n IHVzZWQgYXJlIEhFIGVuYWJsZWQsIHdoaWNoIG1pZ2h0IGFsc28gZ2l2ZSBzb21lIGluc2lnaHQg aW50bzxicj4NCiZndDsmZ3Q7IFJGQzM0ODQgc3VwcG9ydCBpbiB0aGUgdW5kZXJseWluZyBPU2Vz Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyBNYXJr Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHY2b3BzIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZv cHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wczwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4N CiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHM8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO2PR04MB585F5568616227C5624EF52FE320CO2PR04MB585namprd_-- From nobody Tue Jan 27 07:56:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80511A1A68; Tue, 27 Jan 2015 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLIN8tP0DnvQ; Tue, 27 Jan 2015 07:56:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D541A1B35; Tue, 27 Jan 2015 07:53:14 -0800 (PST) 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.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127155314.23877.42694.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 07:53:14 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-2xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 15:56:50 -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 : SIIT-DC: Dual Translation Mode Author : Tore Anderson Filename : draft-ietf-v6ops-siit-dc-2xlat-00.txt Pages : 19 Date : 2015-01-25 Abstract: This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Data Centre Environments architecture (SIIT-DC), which allows applications, protocols, or nodes that are incompatible with IPv6, SIIT-DC and/or Network Address Translation in general to operate correctly in an SIIT-DC environment. This is accomplished by introducing a new component called an Edge Translator, which reverses the translations made by an SIIT-DC Gateway. The application or device is thus provided with seemingly native IPv4 connectivity. The reader is expected to be familiar with the SIIT-DC architecture described in I-D.ietf-v6ops-siit-dc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 27 11:42:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B28D1A89A2 for ; Tue, 27 Jan 2015 11:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-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 RUU1ACKmb2CO for ; Tue, 27 Jan 2015 11:42:09 -0800 (PST) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72661A89A4 for ; Tue, 27 Jan 2015 11:42:07 -0800 (PST) Received: by mail-oi0-f41.google.com with SMTP id z81so14097390oif.0 for ; Tue, 27 Jan 2015 11:42:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=UUg55s1AJqvYr57anMuhrb+RfX/kqwqCmJgf3yyrCmU=; b=PARNG/jxp9wTmUv2N5JOgzR+2sJoMdUK8CuMToHtpSx+8PldkiDclC/1mPwCQBwDq9 94JJiztMZ3wFnv3PIaSVEdyCLGMkIUP1eXP9UdcwgVvB09/O8GqTvxTS7wm5YetXy5Zw ZHDnvDuq6DhXe1JMeahnQZRwoSbdz40q8aF/NdaoTyGsxrWDlQv8zmvNjJPUDOgtarpc NfWPXALa8B6g/blA/AvTtFpLxJKyyVzSa0d71thTkXXePhQVOCzBbprivalOGBxkIUkv U1gpQndZ7x+63nZRCeU0k+Yj0fYJP0+nCk17GdvCtdPqluaKzlGMUdlmc5LqKmTf5YO3 tvcw== X-Gm-Message-State: ALoCoQlhbzfkgMwFUd9s4R0fKKRfm2Vw8ASisRS+1y+uU04zAt1qYES1acZmU9rGNkmBuJNKi/pX MIME-Version: 1.0 X-Received: by 10.202.95.7 with SMTP id t7mr1752232oib.104.1422387727266; Tue, 27 Jan 2015 11:42:07 -0800 (PST) Received: by 10.76.150.2 with HTTP; Tue, 27 Jan 2015 11:42:07 -0800 (PST) In-Reply-To: References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> Date: Tue, 27 Jan 2015 11:42:07 -0800 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a113cdf7037893f050da773d0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 19:42:10 -0000 --001a113cdf7037893f050da773d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 26, 2015 at 11:34 PM, Metzler, Dan J wrote: > > > Unless an alternative auto-configured solution is provided out-of-the-box > by vendors, (not likely if WGs are claiming it isn=E2=80=99t needed), the= n 6to4 is > likely to hang around; even if it isn=E2=80=99t the optimal solution. I = heard > claims that it would be a good 5-6 years before vendors would be able to > push an alternative solution out the door, and by that time IPv6 will hav= e > reached critical mass. Well if that is the future we=E2=80=99re putting = forward > and we aren=E2=80=99t pursuing an alternative solution, then we are waiti= ng for > IPv6 to reach critical mass before 6to4 really becomes =E2=80=9Cdead=E2= =80=9D; or at least > waiting for all ISPs to provide some kind of IPv6 connectivity. (Or, we= =E2=80=99re > waiting for the relay operators to cut off their access.) Until then it = is > likely that 6to4 will hang around in at various levels because there will > always be a group of internet users that are using the existing 6to4 rela= ys > to be able to reach IPv6 only hosts, and over time we can expect the numb= er > of v6 only hosts to go up; not down. > I hate to be That Guy, but I can't keep myself from wondering aloud if we might see measurable *intentional* usage of 6to4 [RFC 3056] in the wild for as long as we still see IPv4 in the wild. When I'm feeling especially depressed about this topic, I wonder if we might see 6to4 as the *last* major application of IPv4 before we turn off its lights in the default free zone. p.s. My thanks to George Michaelson for capturing that information. Very illuminating. --=20 james woodyatt Nest Labs, Communications Engineering --001a113cdf7037893f050da773d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 26, 2015 at 11:34 PM, Metzler, Dan J <dan-metzler@uiowa.edu> wrote:

=C2=A0

Unless an alternative auto-configured= solution is provided out-of-the-box by vendors, (not likely if WGs are cla= iming it isn=E2=80=99t needed), then 6to4 is likely to hang around; even if it isn=E2=80=99t the optimal solution.=C2=A0 I heard = claims that it would be a good 5-6 years before vendors would be able to pu= sh an alternative solution out the door, and by that time IPv6 will have re= ached critical mass.=C2=A0 Well if that is the future we=E2=80=99re putting forward and we aren=E2=80=99t pursuing an alternativ= e solution, then we are waiting for IPv6 to reach critical mass before 6to4= really becomes =E2=80=9Cdead=E2=80=9D; or at least waiting for all ISPs to= provide some kind of IPv6 connectivity.=C2=A0 (Or, we=E2=80=99re waiting f= or the relay operators to cut off their access.)=C2=A0 Until then it is likel= y that 6to4 will hang around in at various levels because there will always= be a group of internet users that are using the existing 6to4 relays to be= able to reach IPv6 only hosts, and over time we can expect the number of v6 only hosts to go up; not down.=C2=A0


I hate to be= That Guy, but I can't keep myself from wondering aloud if we might see= measurable *intentional* usage of 6to4 [RFC 3056] in the wild for as long = as we still see IPv4 in the wild.=C2=A0 When I'm feeling especially dep= ressed about this topic, I wonder if we might see 6to4 as the *last* major = application of IPv4 before we turn off its lights in the default free zone.=

p.s. My thanks to George Michaelson for capturing= that information.=C2=A0 Very illuminating.

--001a113cdf7037893f050da773d0-- From nobody Tue Jan 27 11:57:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6910E1A8A28 for ; Tue, 27 Jan 2015 11:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjIMZw9R1UCV for ; Tue, 27 Jan 2015 11:57:28 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAEF1A6FF0 for ; Tue, 27 Jan 2015 11:57:28 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id t0RJriW2010802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jan 2015 11:53:44 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com t0RJriW2010802 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1422388424; bh=8NVkTn5rSG3yLtf+zLjrpXPl6ok=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=wDxSeG/qKEbnlHc3qfctyRAkUTB5jCIT3XYJj3MWS0GXbMb/7z8zQ6/vzyrY0P2l+ PXqRLGyqq7qL0p/nvdP0YCpMTaFlDq83GoDt0JEjrKj9+VUUVyq0jyDHxn91ucpqIL 5oe9Rzw7QA8JD8JPhBXGsdUgCmcwmojVJdjAu2Zk= Content-Type: multipart/alternative; boundary="Apple-Mail=_9BE68BAB-7818-4F58-9224-0E782451D960" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Owen DeLong In-Reply-To: Date: Tue, 27 Jan 2015 11:53:41 -0800 Message-Id: <0CFB7162-4F60-411F-901A-8500F2690E4E@delong.com> References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> To: James Woodyatt X-Mailer: Apple Mail (2.1993) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 27 Jan 2015 11:53:44 -0800 (PST) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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, 27 Jan 2015 19:57:30 -0000 --Apple-Mail=_9BE68BAB-7818-4F58-9224-0E782451D960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 27, 2015, at 11:42 , James Woodyatt wrote: >=20 > On Mon, Jan 26, 2015 at 11:34 PM, Metzler, Dan J = > wrote: > =20 >=20 > Unless an alternative auto-configured solution is provided = out-of-the-box by vendors, (not likely if WGs are claiming it isn=E2=80=99= t needed), then 6to4 is likely to hang around; even if it isn=E2=80=99t = the optimal solution. I heard claims that it would be a good 5-6 years = before vendors would be able to push an alternative solution out the = door, and by that time IPv6 will have reached critical mass. Well if = that is the future we=E2=80=99re putting forward and we aren=E2=80=99t = pursuing an alternative solution, then we are waiting for IPv6 to reach = critical mass before 6to4 really becomes =E2=80=9Cdead=E2=80=9D; or at = least waiting for all ISPs to provide some kind of IPv6 connectivity. = (Or, we=E2=80=99re waiting for the relay operators to cut off their = access.) Until then it is likely that 6to4 will hang around in at = various levels because there will always be a group of internet users = that are using the existing 6to4 relays to be able to reach IPv6 only = hosts, and over time we can expect the number of v6 only hosts to go up; = not down.=20 >=20 >=20 > I hate to be That Guy, but I can't keep myself from wondering aloud if = we might see measurable *intentional* usage of 6to4 [RFC 3056] in the = wild for as long as we still see IPv4 in the wild. When I'm feeling = especially depressed about this topic, I wonder if we might see 6to4 as = the *last* major application of IPv4 before we turn off its lights in = the default free zone. I think that=E2=80=99s pretty unlikely. 6to4 really doesn=E2=80=99t do you much good if you=E2=80=99ve got IPv6 = connectivity available, and I can=E2=80=99t imagine that a network would = be the last vestigial holdout of transition rather than some arcane = application or end device. Owen --Apple-Mail=_9BE68BAB-7818-4F58-9224-0E782451D960 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 27, 2015, at 11:42 , James Woodyatt <jhw@nestlabs.com> = wrote:

On Mon, Jan 26, 2015 at 11:34 PM, Metzler, Dan J = <dan-metzler@uiowa.edu> = wrote:

 

Unless an alternative auto-configured solution is = provided out-of-the-box by vendors, (not likely if WGs are claiming it = isn=E2=80=99t needed), then 6to4 is likely to hang around; even if it isn=E2=80=99t the optimal solution.  I = heard claims that it would be a good 5-6 years before vendors would be = able to push an alternative solution out the door, and by that time IPv6 = will have reached critical mass.  Well if that is the future we=E2=80=99re putting forward and we aren=E2=80=99t pursuing an = alternative solution, then we are waiting for IPv6 to reach critical = mass before 6to4 really becomes =E2=80=9Cdead=E2=80=9D; or at least = waiting for all ISPs to provide some kind of IPv6 connectivity.  = (Or, we=E2=80=99re waiting for the relay operators to cut off their access.)  Until then it is = likely that 6to4 will hang around in at various levels because there = will always be a group of internet users that are using the existing = 6to4 relays to be able to reach IPv6 only hosts, and over time we can expect the number of v6 only hosts to go up; not = down. 


I hate to be That Guy, but I can't keep = myself from wondering aloud if we might see measurable *intentional* = usage of 6to4 [RFC 3056] in the wild for as long as we still see IPv4 in = the wild.  When I'm feeling especially depressed about this topic, = I wonder if we might see 6to4 as the *last* major application of IPv4 = before we turn off its lights in the default free = zone.

I = think that=E2=80=99s pretty unlikely.

6to4 really doesn=E2=80=99t do you much good if = you=E2=80=99ve got IPv6 connectivity available, and I can=E2=80=99t = imagine that a network would be the last vestigial holdout of transition = rather than some arcane application or end device.

Owen

= --Apple-Mail=_9BE68BAB-7818-4F58-9224-0E782451D960-- From nobody Tue Jan 27 12:05:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6E21A8A41 for ; Tue, 27 Jan 2015 12:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs_4TtfxQQVi for ; Tue, 27 Jan 2015 12:05:04 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2468D1A8A50 for ; Tue, 27 Jan 2015 12:05:04 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 27 Jan 2015 14:05:01 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f181.google.com [209.85.213.181] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f181.google.com with SMTP id hn18so6929890igb.2 for ; Tue, 27 Jan 2015 12:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0FsOqt9iXTFP8iAeTppUO20SYw1RwBnhwJmZ0h+Y7+8=; b=CIG38mb1ExflOiKAnhilzNkVzqDfox9qcaIyuI4wsm4GmT9vVAD0DlrsZRRHDtJLEX 9ARI/HePv0+tgQan7BBOOOBzIz3DL+nfSNzn6SnJutevu2gxor126s9VAYVaoqD+AEk9 KynN3WxaO8hwxy2X0GG9ZRbKP5Tgm0zJNfYuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0FsOqt9iXTFP8iAeTppUO20SYw1RwBnhwJmZ0h+Y7+8=; b=Sy2gpTRusSX5osXQTu1TeGAtfhG/nWPs5VV6heLIkNwKLAkfNdF9pmskyVrIC8cb1u N6XBO0n6iLh0cLzDnxLzxgbYKCKDDZTMIsmj2ax/3SxWpzEwxF1z3XWoi1FeyNuhoPOL euWbXm3QJ4Ec3C5gAwUy9hb6xDv2b0WwGHQsXeugrx99LkWjz6KtAHgkEoJgVdIyF1tA 8cLzql01tGraNfkufZjc0JBYE9/qXoTN5ar2t86/8eVQG4yBis+9nNc0mZv6RxQhbA21 73wRAwCLPfqolMXrwz+3H7feR7WbZ0x/L19irX9ONjA33oGauhon2CzvVXVnZ+tnEGjB y/DA== X-Gm-Message-State: ALoCoQk8gylFIQb43Dt83EL+YdGlHFGA9pKoex9QW7yEbtF+g2w0uV6OWyO284HXsguUooZ709kJeq4DAKUXaZ+kaTE1A59dsNJpA/3XrbXaP4F982h0LeMAQShZup/Wtc415F5xpvpo X-Received: by 10.107.15.36 with SMTP id x36mr652388ioi.75.1422389100634; Tue, 27 Jan 2015 12:05:00 -0800 (PST) X-Received: by 10.107.15.36 with SMTP id x36mr652374ioi.75.1422389100473; Tue, 27 Jan 2015 12:05:00 -0800 (PST) Received: from x-134-84-88-41.nts.umn.edu ([2607:ea00:101:2001:e9a3:c07b:5cc7:44d8]) by mx.google.com with ESMTPSA id l29sm1251613iod.31.2015.01.27.12.04.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jan 2015 12:04:59 -0800 (PST) Message-ID: <54C7EF68.8070804@umn.edu> Date: Tue, 27 Jan 2015 14:04:56 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian E Carpenter , Lorenzo Colitti References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> <54C6DD1D.2030000@gmail.com> <54C6E63D.3090805@gmail.com> In-Reply-To: <54C6E63D.3090805@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 20:05:07 -0000 On 1/26/15 19:13 , Brian E Carpenter wrote: > On 27/01/2015 13:43, Lorenzo Colitti wrote: >> On Tue, Jan 27, 2015 at 9:34 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >>> Well, reviewing the emails I've archived, I see mild support for >>> formally obsoleting it and no strong opposition. >>> >> I suppose my question was really only procedural: *can* we even obsolete an >> individual submission? It's not a document based on IETF consensus, so if >> IETF consensus was not necessary to publish it, then how can IETF consensus >> be sufficient to obsolete it? > > Terminology alert: it's an *independent* submission, not an *individual* > submission (the latter is an IETF stream draft but with no associated WG). > > So, your question is valid. I suggest we leave it as "obsoletes" for now > and let somebody with a higher IETF pay grade decide. Next time I bump > into the Independent Series Editor (which will be later this week > in Rotorua NZ, as it happens) I will ask if there's a precedent. I think a metadata link obsoleting 6732 is appropriate either way. 6to4-PMT is basically a special case anycast relay and return relay bolted together and to a 66 prefix translator. So, would a 6to4-PMT version of the relay operator recommendation be applicable. Current operators of a 6to4-PMT relay SHOULD review the information in the present document, and then consider carefully whether the 6to4-PMT relay can be discontinued as traffic diminishes. Or, maybe better yet consolidate the three different relay operator recommendations into a generic and unified 6to4 relay recommendation for all relay type, like; Current operators of all 6to4 relays (anycast using 192.88.99.1, return using 2002::/16 , or 6to4-PMT) SHOULD review the information in [RFC6343] and the present document, and then consider carefully whether the 6to4 relay can be discontinued as traffic diminishes. The further discussion of 6to4-PMT got me thinking. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Jan 27 16:48:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C90E1A00A2 for ; Tue, 27 Jan 2015 16:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8GreMyff7p4 for ; Tue, 27 Jan 2015 16:48:32 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41BF1A0079 for ; Tue, 27 Jan 2015 16:48:32 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id r10so7765639igi.4 for ; Tue, 27 Jan 2015 16:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=318xW0NpZ1bWIErnp1FbkDJF6en6WbniCCdQ9KhPSMU=; b=YKSSIEr3z68aV+w9KHf/Hd/u3GOfgXy238JmlvmrlF8FqOtUc8fpwvETLuHNJsfEq5 lL7FUUHBCUdCmKiajujemrWTjxw90qWThnulFCvl1MmkFnYF9Y/tevDqYHU1h0B0ho72 z0VaGUWdMkTC8HT+BsbM8/E0nazFpGTkQPpkha6MnNeO4+l40BDU46yIdQwNO35P+k7K CsKRPqveZFkbcMtHK1AG80+M+yhorhIX0We95ZQtw9Gvzeo4oKR5et3cv1YL3+jNuoif JXB8kSxDSLonpZweHIC8AaLOWK72f7XK8dIOrm6P8oDSp+OsUtpGi9/h+HqfJiYxe+E8 UvQA== 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=318xW0NpZ1bWIErnp1FbkDJF6en6WbniCCdQ9KhPSMU=; b=ejF5hUK5Az/Jy4VWTl26sqjKcAhNZByFqK3ivnnVWFIVUFX+FJfH1zX/82CJrAgTXy 8MhBjJwYhM8Bt3Xf3gkyI3c0Wjj5K9gl58ov2eEc1/9qP5J9DO6/A4HUjh9ZsdbwLcDC yaPlecAbe4wXdyaXEM990hNKAz8RwV2Dy4unxFup/Y2XMYIhwyLnPWesH6JR9rYTOivM vxh2LeOhC3c7PI9cOI9+uI1xsQz2ElZNvsMj0/ACzbkaIcRg6GT7kNS3bHMTngKw390z XWRBUtUgEnWJ2HF+FJhIt3yhC86KyMYqftZVlb/vMQQgI4nyZ4m1oh9S8AVbgFS8lpzq sv3g== X-Gm-Message-State: ALoCoQnc6RtJjCV9zOeMaLkymAJ2ls9rWro3f4X5ktSGh6R2d9w8TPneJhRD24O1TdjeGnsrUf5k X-Received: by 10.42.102.148 with SMTP id i20mr789193ico.39.1422406111883; Tue, 27 Jan 2015 16:48:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Tue, 27 Jan 2015 16:48:10 -0800 (PST) In-Reply-To: References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> From: Lorenzo Colitti Date: Wed, 28 Jan 2015 09:48:10 +0900 Message-ID: To: James Woodyatt Content-Type: multipart/alternative; boundary=20cf3011e325069bd6050dabbb5b Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 00:48:34 -0000 --20cf3011e325069bd6050dabbb5b Content-Type: text/plain; charset=UTF-8 On Wed, Jan 28, 2015 at 4:42 AM, James Woodyatt wrote: > I hate to be That Guy, but I can't keep myself from wondering aloud if we > might see measurable *intentional* usage of 6to4 [RFC 3056] in the wild for > as long as we still see IPv4 in the wild. > Personally I doubt it. I think the reason we still have nonzero 6to4 usage is because a) MS made it "a requirement" for some versions of Windows, b) some CPE manufacturers included it and turned it on by default, and c) some OSes prefer it to IPv4. That was all long ago, but old hardware dies hard. I just saw a bug report from a Nexus Player user where the CPE was not only announcing a default route 6to4 prefix with a 10.0.0.0/8 IPv4 address, but a *link-local address as DNS server* (that was a new one even for me). These days, if you're an enthusiast, you're more likely to use a configured tunnel, and if you're a CPE manufacturer, you're likely to go for parity with other CPE feature sets, which are essentially DHCPv6 PD and/or 6rd (and declaring RFC3056 will help here). As the old hardware ages out, 6to4 will slowly disappear. When I'm feeling especially depressed about this topic, I wonder if we > might see 6to4 as the *last* major application of IPv4 before we turn off > its lights in the default free zone. > If we could agree on a definition of "major" that was measurable, I'd take a bet against that. :-) --20cf3011e325069bd6050dabbb5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 28, 2015 at 4:42 AM, James Woodyatt <jhw@nestlabs.com> wrote:
I hate to be That= Guy, but I can't keep myself from wondering aloud if we might see meas= urable *intentional* usage of 6to4 [RFC 3056] in the wild for as long as we= still see IPv4 in the wild.

=
Personally I doubt it. I think the reason we still have nonzero = 6to4 usage is because a) MS made it "a requirement" for some vers= ions of Windows, b) some CPE manufacturers included it and turned it on by = default, and c) some OSes prefer it to IPv4. That was all long ago, but old= hardware dies hard. I just saw a bug report from a Nexus Player user where= the CPE was not only announcing a default route 6to4 prefix with a 10.0.0.0/8 IPv4 address, but a *link-local addre= ss as DNS server* (that was a new one even for me).

These days, if you're an enthusiast, you're more likely to use a = configured tunnel, and if you're a CPE manufacturer, you're likely = to go for parity with other CPE feature sets, which are essentially DHCPv6 = PD and/or 6rd (and declaring RFC3056 will help here). As the old hardware a= ges out, 6to4 will slowly disappear.

=
=C2=A0 When I'm feeling especially depressed= about this topic, I wonder if we might see 6to4 as the *last* major applic= ation of IPv4 before we turn off its lights in the default free zone.
=

If we could agree on a = definition of "major" that was measurable, I'd take a bet aga= inst that. :-)
--20cf3011e325069bd6050dabbb5b-- From nobody Wed Jan 28 02:07:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4946B1A034F for ; Wed, 28 Jan 2015 02:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.783 X-Spam-Level: X-Spam-Status: No, score=-3.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da8hJ-72k5pt for ; Wed, 28 Jan 2015 02:07:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AFB1A033A for ; Wed, 28 Jan 2015 02:07:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0SA7H2h028669 for ; Wed, 28 Jan 2015 11:07:17 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9B70A201656 for ; Wed, 28 Jan 2015 11:07:48 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 93874200B5B for ; Wed, 28 Jan 2015 11:07:48 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0SA7CSv015262 for ; Wed, 28 Jan 2015 11:07:16 +0100 Message-ID: <54C8B4D0.1050007@gmail.com> Date: Wed, 28 Jan 2015 11:07:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 10:07:27 -0000 Le 27/01/2015 03:07, George Michaelson a écrit : > Ask and ye shall receive > > Here is a days summary of os, browser, os+browser as determined by the > APNIC 1x1 capture, using 2002: as the source IPv6 address, and the > Python httpagentparser module to detect OS and Version info. Thank you. That is 26501 unique OSs using 2002 in the first hextet of the src. The number of `uniq` 2002::/48 prefixes was? There could be more Clients behind 6to4 routers. Alex > > -George > > os,Windows+7,22287 > os,Windows+8.1,1743 > os,Windows+Vista,939 > os,Windows+8,894 > os,Windows+XP,431 > os,Macintosh+[na],124 > os,iOS+[na],44 > os,Linux+[na],29 > os,Windows+NT 6.4,6 > os,Windows Phone+8.1,2 > os,ChromeOS+6310.68.0,2 > > browser,Chrome,18297 > browser,Firefox,3774 > browser,Microsoft Internet Explorer,2872 > browser,Opera,1439 > browser,Safari,110 > browser,AndroidBrowser,5 > browser,[na],2 > browser,SeaMonkey,2 > > os+browser,Windows+7.Chrome,15539 > os+browser,Windows+7.Firefox,3033 > os+browser,Windows+7.Microsoft Internet Explorer,2432 > os+browser,Windows+8.1.Chrome,1305 > os+browser,Windows+7.Opera,1277 > os+browser,Windows+8.Chrome,644 > os+browser,Windows+Vista.Chrome,537 > os+browser,Windows+8.1.Firefox,311 > os+browser,Windows+Vista.Microsoft Internet Explorer,230 > os+browser,Windows+XP.Chrome,216 > os+browser,Windows+Vista.Firefox,148 > os+browser,Windows+XP.Firefox,134 > os+browser,Windows+8.Firefox,116 > os+browser,Windows+8.Microsoft Internet Explorer,87 > os+browser,Windows+8.1.Opera,64 > os+browser,Windows+8.1.Microsoft Internet Explorer,63 > os+browser,Macintosh+[na].Safari,60 > os+browser,Windows+XP.Microsoft Internet Explorer,54 > os+browser,Windows+8.Opera,45 > os+browser,iOS+[na].Safari,44 > os+browser,Macintosh+[na].Chrome,36 > os+browser,Windows+XP.Opera,25 > os+browser,Windows+Vista.Opera,24 > os+browser,Macintosh+[na].Firefox,24 > os+browser,Linux+[na].Chrome,16 > os+browser,Linux+[na].Firefox,8 > os+browser,Windows+7.Safari,6 > os+browser,Linux+[na].AndroidBrowser,5 > os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 > os+browser,Macintosh+[na].Opera,4 > os+browser,Windows+XP.SeaMonkey,2 > os+browser,Windows+NT 6.4.Chrome,2 > os+browser,Windows+8.[na],2 > os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 > os+browser,ChromeOS+6310.68.0.Chrome,2 > > > On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith > > wrote: > > I'm fine with that. > > If it is easy enough, I think it would be interesting to get a bit > more of an insight into who/what is still using 6to4 either in > preference to or in (HE) parallel to native IPv4 by e.g., collecting > User-Agent for 6to4 users. > > ------------------------------------------------------------------------ > *From:* Lorenzo Colitti > > *To:* Mark ZZZ Smith > > *Cc:* Brian E Carpenter >; Tore Anderson >; "v6ops@ietf.org " > > > *Sent:* Wednesday, 21 January 2015, 23:16 > > *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > Yes, those users will definitely be impacted. Which is why the > document does not suggest dropping the packets or turning off the > relays, except by saying things like "operators SHOULD [...] > consider carefully whether the [...] relay can be discontinued as > traffic diminishes". That's quite reasonable guidance, I think. > > Remember: 0.01% is really a very small number. Multiplying it by 1 > billion (like Brian did) makes it seem large, but that's just a > trick of the light. Look at it this way: if all the relays in the > world were turned off overnight and all the 6to4 users were unable > to reach a given website, that website's reliability would still be > 99.99% of what it was before. > > I support this document in its current form. I only have three > comments beyond seconding Tore's objection to the draft calling 6to4 > "substantial": > > 1. Is it necessary to formally deprecate RFC 6732? It's an > individual submission. (Not that I support RFC 6732 in any way, > to be sure.) > 2. I don't think the sentence "some content providers have been > reluctant to make content available over IPv6" is true, or at > least any true for any non-trivial value of "some". 6to4 was a > problem for content providers a few years ago, but we've moved > past it. > 3. It might be useful to cite that another reason 6to4 is being > deprecated is that IPv6 is actually being deployed these days > (finally). > > > > > On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith > > wrote: > > > > > > ----- Original Message ----- > From: Brian E Carpenter > > To: Tore Anderson >; > v6ops@ietf.org > Cc: > Sent: Wednesday, 21 January 2015, 7:14 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > On 21/01/2015 02:16, Tore Anderson wrote: > > * fred@cisco.com > > > >> This is to initiate a one week working group last call of > >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > > > > I have read this document, and I think it is ready to move > forward. > > > > Its operational need for this document is less pressing now > than when > > the -00 version was published back in 2011. Nevertheless, I > find it > > valuable and correct to put the final nail in 6to4's coffin > at this > > point in time. While the operational community for the most > part has > > already realised that 6to4 has no future, there might be some > who have > > not been paying attention and formal deprecation of the > protocol may > > help prevent them from making the mistake of attempting to base > > production systems on it. > > > > I have one minor comment though: In section 1, it says «a > substantial > > amount of 6to4 traffic is still observed by IPv6 content > providers». > > While I do see 6to4 traffic, it is quite far from being of > "substantial" > > levels. I would therefore recommend replacing "substantial" with > > something milder like "noticeable", "measurable", or > something along > > those lines. > > > > For what it's worth, today the Google public IPv6 graph shows > just a > > measly 0.01% of their total IPv6 traffic being Teredo/6to4, > so it's not > > just me. > > "Tore, > > However, that fraction of Google traffic multipled by Google users > represents something like 100000 users. I don't think we can dismiss > that number of people too easily. It's a matter of taste whether > that's "substantial" or "noticeable". > > Brian" > > Actually, to those end users, the impact might be both quite > significant and noticeable. > > I think one explanation for the use of 6to4 tunnelled IPv6 is > that their hosts aren't preferring native IPv4 over tunnelled > IPv6 (assuming Google make their services equally available over > both, which I think they do), as per RFC3484 address selection > rules. > > The other explanation for it could be that these users have > Happy Eyeballs enabled browsers and the browser is choosing to > try to use both IPv4 and IPv6, despite the IPv6 being tunnelled > rather than native. From a Happy Eyeballs robustness > perspective, that would be quite a reasonable thing to do I think. > > If the end-hosts aren't following RFC3484's default preferences, > then breaking 6to4 might cause the sorts of timeouts that HE is > designed to overcome. RFC3484 is quite old now (2003), and as a > minor data point I first encountered the implementation of them > in around 2008/2009 if I recall correctly on my Linux system (as > I was using 6to4 at the time and wanted to use tunnelled IPv6 in > preference to native IPv4 - gai.conf(3) is the way you change > that). So if some hosts are still preferring tunnelled 6to4 IPv6 > over native IPv4 then perhaps they're also not going to be > running a HE enabled browser either. > > Perhaps it might be possible for somebody at Google to produce a > list of the browser User-Agent strings for people still using > 6to4 to see if the browsers being used are HE enabled, which > might also give some insight into RFC3484 support in the > underlying OSes. > > Regards, > Mark. > > > > > > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 28 02:30:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A7A1A044D for ; Wed, 28 Jan 2015 02:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kei72WN8BeR for ; Wed, 28 Jan 2015 02:30:50 -0800 (PST) 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 5EDA41A03AA for ; Wed, 28 Jan 2015 02:30:50 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 69E14A4; Wed, 28 Jan 2015 11:30:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1422441048; bh=BeRBT8okJ4r4mb6gc3OJRmRvMuu2kpDsCP5dBTMYF74=; h=Date:From:To:Subject:In-Reply-To:References:From; b=M8HIiwB5jcp2IHjJpBICGM1gKTjlgNN710iClJvxTBmns897Fxp/JdLvy1EQUMW/7 EeTJEr/eLP5UZpEUDUC8QotUztgHOHMT40plmCd8TBPoaSzEgJo0nniO0FfmYfNexM XmiJPYOSiqnl7IWaBZVXZGPs6XjsE4VTJoaPN4XA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5F72CA3 for ; Wed, 28 Jan 2015 11:30:48 +0100 (CET) Date: Wed, 28 Jan 2015 11:30:48 +0100 (CET) From: Mikael Abrahamsson To: IPv6 Ops WG In-Reply-To: Message-ID: References: <799288670.862323.1422315117216.JavaMail.yahoo@mail.yahoo.com> <54C70777.8080704@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 10:30:52 -0000 On Wed, 28 Jan 2015, Lorenzo Colitti wrote: > some CPE manufacturers included it and turned it on by default, and c) some > OSes prefer it to IPv4. That was all long ago, but old hardware dies hard. I have a datapoint here. For instance at least one software version (the one that was on the one I used at the time) on the Linksys EA4500, if IPv6 is set to the default "automatic", it'll do nothing unless it gets a DHCPv6-PD or other signalling. If you however turn it to "off" (I believe, this was two years ago), it'll start to do 6to4 and send out RAs on the wifi/LAN ports with the derived IPv4-GUA 6to4 IPv6 prefix. So there might very well be plenty of people out there who changed something on their home gateway, didn't know what they did, but now they're running 6to4 and they have no idea about it and it's not something they want to do. Here is my email about this I found from two years ago: http://lists.cluenet.de/pipermail/ipv6-ops/2013-February/008520.html -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jan 28 04:15:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F169A1A047A for ; Wed, 28 Jan 2015 04:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CneMJtcqBkI for ; Wed, 28 Jan 2015 04:15:52 -0800 (PST) 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 51BC41A1A86 for ; Wed, 28 Jan 2015 04:15:52 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=56852 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YGRXB-00029X-NO; Wed, 28 Jan 2015 13:15:49 +0100 Date: Wed, 28 Jan 2015 13:15:48 +0100 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20150128131548.24a0e5b3@envy.fud.no> In-Reply-To: <20150127155314.23877.42694.idtracker@ietfa.amsl.com> References: <20150127155314.23877.42694.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-2xlat-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, 28 Jan 2015 12:15:55 -0000 Hi WG, The main changes since the previous version are: - Describe how the translation service could also be implemented as a network device rather than a host-centric software agent. This facilitates the use of the IPv4-only devices, devices that are dual-stack capable but _requrires_ IPv4 network connectivity, and so forth. Thanks to Ray Hunter for this idea. - Because of the above change, the previous =C2=ABHost Agent=C2=BB has been renamed to =C2=ABEdge Translator=C2=BB (because it isn't necessarily host-based). - Add a section explaining how the IPv4 Identification value is only carried end-to-end if IPv6 Atomic Fragments are enabled. Thanks to Andrew Yourtchenko. - Add a section describing how an IPv4-only service or device behind an Edge Translator could communicate with other services in the data centre (possibly also behind another Edge Translator). Thanks to Andrew Yourtchenko and Will LIU. I look forward to your feedback on the updated draft. Tore * internet-drafts@ietf.org > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the IE= TF. >=20 > Title : SIIT-DC: Dual Translation Mode > Author : Tore Anderson > Filename : draft-ietf-v6ops-siit-dc-2xlat-00.txt > Pages : 19 > Date : 2015-01-25 >=20 > Abstract: > This document describes an extension of the Stateless IP/ICMP > Translation for IPv6 Data Centre Environments architecture (SIIT-DC), > which allows applications, protocols, or nodes that are incompatible > with IPv6, SIIT-DC and/or Network Address Translation in general to > operate correctly in an SIIT-DC environment. This is accomplished by > introducing a new component called an Edge Translator, which reverses > the translations made by an SIIT-DC Gateway. The application or > device is thus provided with seemingly native IPv4 connectivity. >=20 > The reader is expected to be familiar with the SIIT-DC architecture > described in I-D.ietf-v6ops-siit-dc. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 28 04:47:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D391A1EF5 for ; Wed, 28 Jan 2015 04:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9RLUe_ryFss for ; Wed, 28 Jan 2015 04:47:03 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750741A1EF1 for ; Wed, 28 Jan 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=130; q=dns/txt; s=iport; t=1422449224; x=1423658824; h=date:from:message-id:to:subject:cc; bh=5q7bCeHPipM6igSubjFFnmBC1Einc9LVMph9b/ckGZ0=; b=RFqZjVFOInIrMLiJf+bEHSg+UYVEHKIR7CD2u2MK5yQlV1x5ZgxN1YFt xBpi65uhpzjMespB3SHnC4cyz4lso9jiB0gsGc/pSczuSmvGEXN4jB8VE BQunYWwpm1AuuUxGNaVWeFvCMPandJL9/bYE+Ie3hFouLz1xG55Rz9K3R Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYHAGXZyFStJV2a/2dsb2JhbABagwZSWrU0AY8hhWgJgRlDAQEBAQF9hQw8NIkMAQ3VIAEBCAIBH494HYQTBYoHiDKGazaCSY4oIoQPgxABAQE X-IronPort-AV: E=Sophos;i="5.09,480,1418083200"; d="scan'208";a="388302378" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 28 Jan 2015 12:47:03 +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 t0SCl29Z027625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2015 12: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 t0SCl1IQ009171; Wed, 28 Jan 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t0SCl1XY009170; Wed, 28 Jan 2015 04:47:01 -0800 Date: Wed, 28 Jan 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201501281247.t0SCl1XY009170@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-siit-dc-2xlat@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-siit-dc-2xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 12:47:04 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat. Please take a look at it and comment. From nobody Wed Jan 28 08:57:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584711A1A68 for ; Wed, 28 Jan 2015 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zpkr18jtoGFG for ; Wed, 28 Jan 2015 08:57:45 -0800 (PST) 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 B11731A00A3 for ; Wed, 28 Jan 2015 08:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1536; q=dns/txt; s=iport; t=1422464265; x=1423673865; h=from:to:cc:subject:date:message-id:mime-version; bh=7+Oplqzjm3SZ2IIa6rvbtYSyN3e+Z2iWz/qG0u+NAUI=; b=VcDWcXyj+5oAQTPdOp9h7oYyUH6iu9BH8sHztOAoRD4UMGH31X1RpTwI Tu/6Ug5YCEXAMIdob1lPdJUrmkShzq29MfzLvqODvlpHZYApIYrzTw86T 4TpNTZx3gIDo8/0XRIZwOf3ZuO4jsp20i9+UTpf/Lmr1MiT9SeMCgLI7I o=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAFUUyVStJA2H/2dsb2JhbABagwaBL8pDgRxDAQEBAQF9hBN5EgGBACcEDhOIHtYkAQEBAQEBAQEBAQEBAQEBAQEbj3iDHYETBY5ugVOBKYYlgRWCf4JBi2cig26CM34BAQE X-IronPort-AV: E=Sophos;i="5.09,481,1418083200"; d="asc'?scan'208";a="391496673" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jan 2015 16:57:45 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0SGvi6c030883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Jan 2015 16:57:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 10:57:44 -0600 From: "Fred Baker (fred)" To: V6 Ops List Thread-Topic: draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKQ== Date: Wed, 28 Jan 2015 16:57:44 +0000 Message-ID: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@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.121] Content-Type: multipart/signed; boundary="Apple-Mail=_E0D1BF64-7CFF-4473-A565-DC83A7D229C4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" Subject: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Jan 2015 16:57:47 -0000 --Apple-Mail=_E0D1BF64-7CFF-4473-A565-DC83A7D229C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of = change in the IESG. The ADs would like to see the working group read it = again and comment - working group last call - before they proceed. To = summarize, it provides requirements for handsets that would work in a = specific business model. As such, it builds on RFC 6434 and 7066, = strengthening some of those requirements, and going on to add = requirements related to 464xlat and other technologies. Please read it now, and comment. This WGLC will run until 15 February. --Apple-Mail=_E0D1BF64-7CFF-4473-A565-DC83A7D229C4 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 iQEVAwUBVMkVBp9ieig10VPpAQL0Rgf9HIbvMOQs+eBgPCq0tHzmK/hoDqWAxwR1 NLdJskYT4yn76oflTqRzsvtTkxoiyfFvgCG4nhLXyMG/hLuOrlNT76L93Bk0xpU+ UPwjlDCk6hxyfL0Hjt2zRw7IDhgvmbUP2VXJYd+NRlrsV+lBEnSDlkkOH/eIZN4i jPYZJkJCMVpYZdBE1u065VvqhaYJW4T1wQIP4HMZXFVC8xe/HFvLcaAmRwrzgP4y 1SWZUdBhkIc3nTeq6e4fCRpfyH5grjnHbao3sQ4cRq390zdM9whMdH5nidwcz8Z9 hExPFqx7Q/bOcg6G1bcmcdG+1jRUykkYvWEK9Svx0/9UF4Ki9tUAWw== =XAst -----END PGP SIGNATURE----- --Apple-Mail=_E0D1BF64-7CFF-4473-A565-DC83A7D229C4-- From nobody Wed Jan 28 12:09:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EB01A1AC1 for ; Wed, 28 Jan 2015 12:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nptz-D9rYE7 for ; Wed, 28 Jan 2015 12:08:56 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917081A1AB0 for ; Wed, 28 Jan 2015 12:08:56 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar1so24485980iec.6 for ; Wed, 28 Jan 2015 12:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8LW/ymxQjhJEeZW0R9LIv4HrMCCxixJYKWFIUGJUNnw=; b=d/ubE8VPlmPf4dIAI1D6izUSuXhfPzO/rk2XmugmDrYF3ka1E5jeRZCesaoyj9PAOo uF6gC8KjAmHLjvbf1n9qgMFWztv1/juEn1tQyxiWdh59GWdlZQbLafksFfpns5XB1EeM HueIpraOSm3Kku8jbnXye4zlhVXzVd2uUDe43XcU3vOOprNJDCUdLZkNBMAaLA3jCwYc kVWciYzuiH21921KY4RV3sCZe1gKYP6DWTcikELcto+EPVPhOincsX9HgSEsuofsZ3IX 8ihp6n04yYArm8nzBXaAExj8Gb/uT2j+Did340k5J/mZmOVLEUfkr8hcvHixY4jCRUzu f+OA== X-Received: by 10.68.202.194 with SMTP id kk2mr8459284pbc.41.1422475735717; Wed, 28 Jan 2015 12:08:55 -0800 (PST) Received: from ?IPv6:2401:c80:3:0:28cc:dc4c:9703:6781? ([2401:c80:3:0:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id h6sm5581613pdp.15.2015.01.28.12.08.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 12:08:54 -0800 (PST) Message-ID: <54C941D3.2060206@gmail.com> Date: Thu, 29 Jan 2015 09:08:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> <54C6DD1D.2030000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 20:08:58 -0000 Hi Lorenzo, On 27/01/2015 13:43, Lorenzo Colitti wrote: ... >> Well, reviewing the emails I've archived, I see mild support for >> formally obsoleting it and no strong opposition. >> > > I suppose my question was really only procedural: *can* we even obsolete an > individual submission? It's not a document based on IETF consensus, so if > IETF consensus was not necessary to publish it, then how can IETF consensus > be sufficient to obsolete it? I am now sitting next to the Independent Series Editor at the NZNOG meeting in warm, sunny Rotorua and he sees no problem of principle in doing this, but we should ensure that it's checked with the ISE during the IESG process. He would probably check with the original authors of RFC 6732 to be sure. Therefore this will need to be noted in the document writeup when the draft is passed on from the WG. Brian From nobody Wed Jan 28 19:26:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4DD1A8AFA for ; Wed, 28 Jan 2015 19:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GK7c8ms-OJ2 for ; Wed, 28 Jan 2015 19:26:33 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D2B1A8AFB for ; Wed, 28 Jan 2015 19:26:32 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id bj1so33403606pad.1 for ; Wed, 28 Jan 2015 19:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5ol95Nx1bCstqti7aPvaPQBq0EitSkccuuTm7Yy5k+0=; b=BpKJR2IUU2SSJxHnYJTvDU25J6JF2e8sTD++I/gGmZuct35EbPJPDvhhrQB1F9Vu4A IuKBKy70GEdjD5Z+ZErg4QYlB/x7bnHoIRWIB/eBvG6u7xq90WrX6aGISsIyA4ZCS/HK EeMoPvj3NzQu3xYjMcXpvMHg8zpZosx8fWWkVIZPbAlzbKy7T4wcaa4ffqYdVKaXFjrr UOp1QPWOMg68U+kjjewDvCd+vd/Ljf9+puYezRV8FqlbGdkEN/g6eUyfzjDCJxpJHZZ3 k44j4trB0J6WZjHfbfTVRTbri1DLDJThoy10JA7LrCuJ3QUy/AnuBJ2e6JP7U5QAS8yn pm4g== X-Received: by 10.68.136.163 with SMTP id qb3mr11068783pbb.63.1422501992278; Wed, 28 Jan 2015 19:26:32 -0800 (PST) Received: from ?IPv6:2401:c80:3:0:28cc:dc4c:9703:6781? ([2401:c80:3:0:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id nb1sm6090099pdb.85.2015.01.28.19.26.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 19:26:30 -0800 (PST) Message-ID: <54C9A86A.7060604@gmail.com> Date: Thu, 29 Jan 2015 16:26:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Farmer , Lorenzo Colitti References: <54BEB741.8060709@gmail.com> <248188907.4210717.1421800222689.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> <54C6DD1D.2030000@gmail.com> <54C6E63D.3090805@gmail.com> <54C7EF68.8070804@umn.edu> In-Reply-To: <54C7EF68.8070804@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 03:26:37 -0000 On 28/01/2015 09:04, David Farmer wrote: > On 1/26/15 19:13 , Brian E Carpenter wrote: >> On 27/01/2015 13:43, Lorenzo Colitti wrote: >>> On Tue, Jan 27, 2015 at 9:34 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>>> Well, reviewing the emails I've archived, I see mild support for >>>> formally obsoleting it and no strong opposition. >>>> >>> I suppose my question was really only procedural: *can* we even obsolete an >>> individual submission? It's not a document based on IETF consensus, so if >>> IETF consensus was not necessary to publish it, then how can IETF consensus >>> be sufficient to obsolete it? >> >> Terminology alert: it's an *independent* submission, not an *individual* >> submission (the latter is an IETF stream draft but with no associated WG). >> >> So, your question is valid. I suggest we leave it as "obsoletes" for now >> and let somebody with a higher IETF pay grade decide. Next time I bump >> into the Independent Series Editor (which will be later this week >> in Rotorua NZ, as it happens) I will ask if there's a precedent. > > I think a metadata link obsoleting 6732 is appropriate either way. > > 6to4-PMT is basically a special case anycast relay and return relay bolted together and to a 66 prefix translator. So, would a > 6to4-PMT version of the relay operator recommendation be applicable. > > Current operators of a 6to4-PMT relay SHOULD review the information > in the present document, and then consider carefully whether the > 6to4-PMT relay can be discontinued as traffic diminishes. > > Or, maybe better yet consolidate the three different relay operator recommendations into a generic and unified 6to4 relay > recommendation for all relay type, like; > > Current operators of all 6to4 relays (anycast using 192.88.99.1, return using 2002::/16 , or 6to4-PMT) SHOULD review the > information in [RFC6343] and the present document, and then consider carefully whether the 6to4 relay can be discontinued as > traffic diminishes. I'm reluctant to do that, because the decisions about forward and reverse relays are quite independent and should not be viewed as a single decision point. Brian > > The further discussion of 6to4-PMT got me thinking. > > Thanks. From nobody Wed Jan 28 19:46:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8821A1B4E; Wed, 28 Jan 2015 19:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUm7D_6WSnW5; Wed, 28 Jan 2015 19:46:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8BB1A1AB4; Wed, 28 Jan 2015 19:46:12 -0800 (PST) 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.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129034612.14822.20520.idtracker@ietfa.amsl.com> Date: Wed, 28 Jan 2015 19:46:12 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 03:46:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Deprecating Anycast Prefix for 6to4 Relay Routers Authors : Ole Troan Brian Carpenter Filename : draft-ietf-v6ops-6to4-to-historic-11.txt Pages : 9 Date : 2015-01-28 Abstract: Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that when used in its anycast mode, the mechanism is unsuitable for widespread deployment and use in the Internet. This document therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It also obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 28 19:53:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A21F1A1B32 for ; Wed, 28 Jan 2015 19:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFB1bcgQZrT7 for ; Wed, 28 Jan 2015 19:53:25 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e: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 F0FA31A1B2F for ; Wed, 28 Jan 2015 19:53:24 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id kx10so33549857pab.11 for ; Wed, 28 Jan 2015 19:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FpCUhEZJJuhtwSnR61QdX1qVKyX5SAFdXGN4ZyHc8tw=; b=z6lMr76LUl7cKbxxAPLSQZQwp71nDxRmZHUA3Xv1SlsUZ4H3pS2hjPyElPzlZvKnbh jKMGPwx7NmtGJNA39lH8scGv61a3UMTKqHcmAB6dWU8sNtLZstWCg4UinS32kVM4qYEM 9JCM3hRtcM1hQNCsXBFKZ7mtq31I1X2MaXOv6NRxm0bAXW8dCvvjJDRnjrzUSFF7z5dV oAeSie4aAJCEl1oEl7nb9GZaDNWCIdqFb1j8BU9kbndcqeIF8veyWULUGr1rcWM/H31q Zr5YORgeCEpbNI0J6uZaB7WORIS6lkI/5zTA2sPtqSTcuUiGfKfzroK5bQZPxyqTbu04 WxwA== X-Received: by 10.70.16.35 with SMTP id c3mr177072pdd.137.1422503604302; Wed, 28 Jan 2015 19:53:24 -0800 (PST) Received: from ?IPv6:2401:c80:3:0:28cc:dc4c:9703:6781? ([2401:c80:3:0:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id dm7sm6155518pdb.68.2015.01.28.19.53.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 19:53:23 -0800 (PST) Message-ID: <54C9AEB7.709@gmail.com> Date: Thu, 29 Jan 2015 16:53:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150129034612.14822.20520.idtracker@ietfa.amsl.com> In-Reply-To: <20150129034612.14822.20520.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-11.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, 29 Jan 2015 03:53:28 -0000 Hi, This version mainly has the "friendly amendments" suggested by David Farmer, plus a few other changes from the last couple of weeks' discussion. Since the "Deprecation" section has been split and reorganized, the diffs look a bit complex, but the changes are mainly editorial. Note to Ole: sorry, I'm on travel so submitted this without checking with you. Note to Fred: I ran idnits and the resulting warnings can be safely ignored. Note to everybody: if you feel you're missing from the Acknowledgments please let me know. Regards Brian On 29/01/2015 16:46, 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 : Deprecating Anycast Prefix for 6to4 Relay Routers > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-11.txt > Pages : 9 > Date : 2015-01-28 > > Abstract: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that > when used in its anycast mode, the mechanism is unsuitable for > widespread deployment and use in the Internet. This document > therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay > Routers", be made obsolete and moved to historic status. It also > obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends > that future products should not support 6to4 anycast and that > existing deployments should be reviewed. This complements the > guidelines in RFC 6343. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 Thu Jan 29 03:53:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B701A0204 for ; Thu, 29 Jan 2015 03:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dpNwG-RhoZC for ; Thu, 29 Jan 2015 03:53:43 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707B01A01FA for ; Thu, 29 Jan 2015 03:53:43 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id y20so32528902ier.1 for ; Thu, 29 Jan 2015 03:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cQlVIpqLqIwtCH3b6X3LhEwDQIWJo3O+pf1oeFkvL/o=; b=htY9lSdUdyjWBMDk8Kh+1AGlIoLoMBOkMZmOTysFBRDC+JyP6EPRbCzO1Vyq0X+jjn nQCn9iVktUBays5DAsu/xAsiwvJAk+MfZGxXU2VmoE5KsSQFZzfJgL/CGVrrXj+vmT2e GI++O9s6DwVx+D2lECC8SkbrfbZQs7OfMivADFGhNfB8iu6njhYE3c9u5a5TqtqFJmj7 9VhLspIaSxvkgWCX61DdJmEqz0p41rDxUniMppYSGIPGh81NSjNwhxlvy33ZYu4JfFFz Rubdmy1xKEk/6NFrOdazt567qL/4vlHfAfKM+4uR1yLw/Rj00k1eqNsl/3ekDQDX64oJ +EKA== 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=cQlVIpqLqIwtCH3b6X3LhEwDQIWJo3O+pf1oeFkvL/o=; b=nAUU/cG9GElXbD1cvgM2aJ9jpenOukKW0Up5EjOimPMG46O8QuC+w6q3Emj0zjgWtt j267P43Xz33OZiBhvMyArGOhHap7x4ncYuHQEipku/7QwmeIgC/fyV5EpM2URSrBRxki G540xSVWVwyiDUNwHkER9y4+L6ELLAY3YMXx/14j8fro/bo/aephcd12lgPfDOpRaiCl gwwNMxCXGCAd0/MO9fPs9/2iw5uxbb4JoqwklOZN3D00ODYeJ6cSAPl7K0DWUhiouQmi fsRHWnhtYsAjXwFf0ctoSRyAXV5cwO3aVkBAj6j7u42rBlc7rWCe2k4N+J1XqGA4rRg+ EWSg== X-Gm-Message-State: ALoCoQkisa+56R6l3ACBueIV0gr1CiC2one+cjEtLF3KX8HNYvuREOMnCCAtRoT/nJ5bFIVWQf1V X-Received: by 10.50.138.226 with SMTP id qt2mr2728436igb.1.1422532416321; Thu, 29 Jan 2015 03:53:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Thu, 29 Jan 2015 03:53:16 -0800 (PST) In-Reply-To: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> From: Lorenzo Colitti Date: Thu, 29 Jan 2015 20:53:16 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e0122a2085b5a08050dc9237c Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jan 2015 11:53:45 -0000 --089e0122a2085b5a08050dc9237c Content-Type: text/plain; charset=UTF-8 On Thu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) wrote: > draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of > change in the IESG. The ADs would like to see the working group read it > again and comment - working group last call - before they proceed. Ok, off we go again then. I have objected to this document already, and was found to be in the rough. Therefore, I must assume that rough WG consensus is that we need a document that looks something like this, and I will accordingly refrain from making any general statements on the scope, utility, and general content of the document, with which I continue to disagree. However, I would be remiss if I did not at least draw attention to the following factual errors and/or inappropriate statements. 1. The wording "required features to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network" is factually incorrect. The vast majority of these recommendations are not required to connect to such networks, and are many are not even implemented by many popular mobile operating systems - which manage to connect just fine. After long discussions, that text was removed in -06. Why was it readded? 2. Previous versions of the document, including the version that passed IETF last call, contained the text: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some deployment contexts. The authors believe that the support of a subset of the features included in this protocol may lead to degraded level of service in some deployment contexts. That text remains accurate and that statement is still necessary. Why was it removed? It has been in the document since -06, and the words "this document is not a standard" have been in this document since -01. 3. I object to the statement "One of the major hurdles encountered by mobile operators is the availability of non-broken IPv6 implementation in mobile devices." I submit that if it were true, then we would observe no IPv6 deployment in mobile networks... but publicly-available data - e.g., http://www.worldipv6launch.org/measurements/ - shows that multiple operators have deployed IPv6 to up to 30-65% of their footprint, using the same commercially-available devices that are used by customers of other operators. So claiming that "broken IPv6 implementations in mobile devices" are a major hurdle is at best incomplete and at worst incorrect. At the risk of sounding like a broken record, I am going yet again to say that that operational documents should be based on operational experience. I am not aware of any of the authors' employers having a substantial IPv6 deployment (though I would be happy to see any data that the authors could provide to the contrary). On the other hand, the IPv6 lead on one of the operators that *has* deployed IPv6 no longer appears in the list of authors. Regards, Lorenzo --089e0122a2085b5a08050dc9237c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) <fred@cisco.com>= wrote:
draft-ietf-v6ops-mobile-device-profile has been= through Quite a bit of change in the IESG. The ADs would like to see the w= orking group read it again and comment - working group last call - before t= hey proceed.

Ok, off we go again then.

I have objected to this document already, and was foun= d to be in the rough. Therefore, I must assume that rough WG consensus is t= hat we need a document that looks something like this, and I will according= ly refrain from making any general statements on the scope, utility, and ge= neral content of the document, with which I continue to disagree.

However, I would be remiss if I did not at least draw atten= tion to the following factual errors and/or inappropriate statements.
=


1. The wording "required features t= o connect 3GPP mobile devices to an IPv6-only or dual-stack wireless networ= k" is factually incorrect. The vast majority of these recommendations = are not required to connect to such networks, and are many are not even imp= lemented by many popular mobile operating systems - which manage to connect= just fine. After long discussions, that text was removed in -06. Why was i= t readded?


2. Previous versions of = the document, including the version that passed IETF last call, contained t= he text:

=C2=A0 =C2=A0This document is not a = standard, and conformance with it is not
=C2=A0 =C2=A0required in= order to claim conformance with IETF standards for IPv6.
=C2=A0 = =C2=A0The support of the full set of features may not be required in some
=C2=A0 =C2=A0deployment contexts.=C2=A0 The authors believe that t= he support of a
=C2=A0 =C2=A0subset of the features included in t= his protocol may lead to degraded
=C2=A0 =C2=A0level of service i= n some deployment contexts.

That text remain= s accurate and that statement is still necessary. Why was it removed? It ha= s been in the document since -06, and the words "this document is not = a standard" have been in this document since -01.

=

3. I object to the statement "One of the major hur= dles encountered by mobile operators is the availability of non-broken IPv6= implementation in mobile devices." I submit that if it were true, the= n we would observe no IPv6 deployment in mobile networks... but publicly-av= ailable data - e.g., http://www.worldipv6launch.org/measurements/ - sho= ws that multiple operators have deployed IPv6 to up to 30-65% of their foot= print, using the same commercially-available devices that are used by custo= mers of other operators. So claiming that "broken IPv6 implementations= in mobile devices" are a major hurdle is at best incomplete and at wo= rst incorrect.


At the risk of sound= ing like a broken record, I am going yet again to say that that operational= documents should be based on operational experience. I am not aware of any= of the authors' employers having a substantial IPv6 deployment (though= I would be happy to see any data that the authors could provide to the con= trary). On the other hand, the IPv6 lead on one of the operators that *has*= deployed IPv6 no longer appears in the list of authors.


Regards,
Lorenzo
--089e0122a2085b5a08050dc9237c-- From nobody Thu Jan 29 04:15:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B7A1A0318 for ; Thu, 29 Jan 2015 04:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsPggWOSPeOo for ; Thu, 29 Jan 2015 04:15:09 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A271A0275 for ; Thu, 29 Jan 2015 04:15:09 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 7E2F961E9; Thu, 29 Jan 2015 04:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=Beezg9YNROxgNOdGAVNEbUrDXAA=; b=pGvn+nJ7UBkdoZ4Ce9 cyZ3p4WpN9tr6hKBHOgjbEzASRLWgx6sDCe0tgEjMQ5kXnGg9YMT2XpvUp31bjjt Zel0i38CziVa8Wabf67y9k0pkqVGjQdpRhbfQiDznDP+p6JYpOz6BihYm9LBKqex Lyt5Rii53AEhaBuldkdB3QGho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=dyTLHJZysdgDqtmnFzNdgaw/cx3Rf2jA/NrI5XhZdMmyFlCJxnm GcJ9CqwlWYVtZU4wXFHi8RT95DZamDbW1EP7ht3gsW4CSRpp8jguzE9iPxFvGlNQ GbeM6p4NSv2MXrEefJpLsA9aWinSXoct1wpQ0eJ8P1imAZRyi0ERTVEU= Received: from OTROAN-M-Q0RH.localdomain (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 27CB461C5; Thu, 29 Jan 2015 04:15:07 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by OTROAN-M-Q0RH.localdomain (Postfix) with ESMTP id DD3793D85726; Thu, 29 Jan 2015 13:15:04 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.4\)) From: Ole Troan In-Reply-To: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> Date: Thu, 29 Jan 2015 13:15:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.2070.4) Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jan 2015 12:15:10 -0000 > On 28 Jan 2015, at 17:57 , Fred Baker (fred) wrote: >=20 > draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of = change in the IESG. The ADs would like to see the working group read it = again and comment - working group last call - before they proceed. To = summarize, it provides requirements for handsets that would work in a = specific business model. As such, it builds on RFC 6434 and 7066, = strengthening some of those requirements, and going on to add = requirements related to 464xlat and other technologies. >=20 > Please read it now, and comment. This WGLC will run until 15 February. +1 to Lorenzo's comments. in addition. C_REC#11: If the cellular host receives the DNS information in several channels for the same interface, the following preference order must be followed: 1. PCO 2. RA 3. DHCPv6 in the other areas this issue has come up. then the conclusion has been = that the host uses all the information received. I think it would be = quite unfortunate that the host stack much behave differently depending = on the link-layer. I would suggest either to drop the requirement, or to = say that the implementation must use all DNS servers learnt. same comment applies to W_REC#4. I can't see a good reason why hosts that also have cellular interfaces = should work differently on a WLAN as opposed to those that don't have = cellular interfaces. why does e.g. A_REC#3 refer to NATs? "Tracking a host is still possible based on the first 64 bits of the IPv6 address. Means to prevent against such tracking issues may be enabled in the network side." what does this allude to? From nobody Thu Jan 29 12:07:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C6B1A6FEF for ; Thu, 29 Jan 2015 12:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 GHVXIy9PzLuU for ; Thu, 29 Jan 2015 12:07:14 -0800 (PST) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04961A6FFA for ; Thu, 29 Jan 2015 12:07:13 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id a141so30662221oig.5 for ; Thu, 29 Jan 2015 12:07:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4W/LRJl9KKjwtysIyZkr2mZaUS6/JFELpBoX092MwWI=; b=edTFcEla1RzlyKrH7NsHyZFbrvjXSHKWN0PG/GMzFXzg76rhskCgBMTQak3DdGJiz2 HjAV3P+BMNf/GnqK+mz10aeG6cKf86ZksXp+56dkrAg/2rl60AILhXdN3xebJrfcnByi qXIXj/q8RdoeTmefgVEYHkEyZYYYaXFukPKWE2Avuhs5WAjwlKdcpmgb5pfJEJa2mcbx CnzM+/bZgi27iXYe6XM3WswfAqJRL7NGgIf2Of1pJ5sYUChXwZxAO+cgaJ3wgOXdlNTo S26OjKCLoirDyMJStsdtxSuFMHOQL94MwZ5K9XhIVKelXeFJNejP8rXN/oa8Ams8JKjQ hOoQ== X-Gm-Message-State: ALoCoQkSQZqy4zbEmPXtJCDSdFV4qA2nGad0Mlf+fDz/pGEH2hToSYrOPQBI/dSzmrejCcUmw/Ji MIME-Version: 1.0 X-Received: by 10.182.130.166 with SMTP id of6mr1564693obb.53.1422562033180; Thu, 29 Jan 2015 12:07:13 -0800 (PST) Received: by 10.76.150.2 with HTTP; Thu, 29 Jan 2015 12:07:13 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> Date: Thu, 29 Jan 2015 12:07:13 -0800 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=e89a8f503a5ca8b41e050dd0085a Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jan 2015 20:07:16 -0000 --e89a8f503a5ca8b41e050dd0085a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Additionally=E2=80=94 Editorial: the section for Security Considerations currently says this: Security-related considerations that apply when the cellular > device provides LAN features are specified in [RFC6092 > ]. This sentence is a bit awkward=E2=80=94 but more importantly, RFC 6092 is n= ot a specification, and the chain of citation that lead to its reference here is far from clear. I suggest the following wordier but more helpful replacement: In the case of cellular devices that provide LAN features, compliance with > L_REC#2 entails compliance with RFC 6204, which in turn recommends > compliance with Recommended Simple Security Capabilities in Customer > Premises Equipment (CPE) for Providing Residential IPv6 Internet Service = [ > RFC6092 ]. Therefore, the security > considerations in section 6 of that document are relevant. In particular, > it bears repeating here that the true impact of stateful filtering may be= a > reduction in security, and that IETF make no statement, expressed or > implied, as to whether using the capabilities described in any of these > documents ultimately improves security for any individual users or for th= e > Internet community as a whole. p.s. I also share all of Lorenzo's other specific concerns about this draft, as well as his broad general objections. --=20 james woodyatt Nest Labs, Communications Engineering --e89a8f503a5ca8b41e050dd0085a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Addi= tionally=E2=80=94

Editorial: the section for Security Considerations currently sa= ys this:

Security-related considerations that apply when the = cellular device=C2=A0provides LAN features are specified in [RFC6092].

This sentence is a bit awkward=E2=80=94 but more importantly, RFC = 6092 is not a specification, and the chain of citation that lead to its ref= erence here is far from clear.=C2=A0 I suggest the following wordier but mo= re helpful replacement:

In the case of cellular devices that provide LAN features= , compliance with L_REC#2 entails compliance with RFC 6204, which in turn r= ecommends compliance with Recommended Simple Security Capabilities in Custo= mer Premises Equipment (CPE) for Providing Residential IPv6 Internet Servic= e [RFC6092]. Therefore, t= he security considerations in section 6 of that document are relevant. In p= articular, it bears repeating here that the true impact of stateful filteri= ng may be a reduction in security, and that IETF make no statement, express= ed or implied, as to whether using the capabilities described in any of the= se documents ultimately improves security for any individual users or for t= he Internet community as a whole.

p.s. I al= so share all of Lorenzo's other specific concerns about this draft, as = well as his broad general objections.


--
james wood= yatt <jhw@nestlabs= .com>
Nest Labs, Communications Engineering
--e89a8f503a5ca8b41e050dd0085a-- From nobody Thu Jan 29 12:13:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775181A1A28 for ; Thu, 29 Jan 2015 12:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVREtBOfEMpn for ; Thu, 29 Jan 2015 12:12:55 -0800 (PST) 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 7FE021A6FF5 for ; Thu, 29 Jan 2015 12:12:53 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DBA5160B99 for ; Thu, 29 Jan 2015 21:12:51 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A1E7760B5E for ; Thu, 29 Jan 2015 21:12:51 +0100 (CET) Received: (qmail 31527 invoked by uid 1007); 29 Jan 2015 21:12:51 +0100 Date: Thu, 29 Jan 2015 21:12:51 +0100 From: Gert Doering To: Ole Troan Message-ID: <20150129201251.GD34798@Space.Net> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jan 2015 20:12:57 -0000 Hi, On Thu, Jan 29, 2015 at 01:15:04PM +0100, Ole Troan wrote: > +1 to Lorenzo's comments. Another +1 - I can't see this reflecting WG consensus, more "everybody besides Lorenzo has given up". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 29 12:13:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4761A1AF2 for ; Thu, 29 Jan 2015 12:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOLFIUyTETUa for ; Thu, 29 Jan 2015 12:13:48 -0800 (PST) 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 4C4A91A1A28 for ; Thu, 29 Jan 2015 12:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4198; q=dns/txt; s=iport; t=1422562428; x=1423772028; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=BCYPcieHmNa4QizRuR1N1Gmm3ijPQj+GY+/ezAcR8ik=; b=kOOXlXVL/sqN0nykeOLNf9tJAsu8TQ/qdHB7nbcy02UaMxft17HMpVbn 0lA8a7E4qYxTyu/zSCtz+4AxZFXEqRE8lbYGA3Aun/WO8Ib4HmDOBdyS8 Ge5qcP6YzpxwsW1yYxG01AGBa//9fVww+kVIQeYsu7X5LjhO8VoCW2Wn2 k=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBQB2k8pU/5xdJa1agwZSVAUEgn3BVQqFcQKBJUMBAQEBAX2EDAEBAQMBAQEBIEsQCwIBCBgqAgIhBgslAgQBEgkFiAoDCQgIBcFVkCUNhUYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjU6CLAWCaC6BEwWNG4FhgVOBKU+EEYFGgRc2gkuIPQOFeSKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,487,1418083200"; d="asc'?scan'208";a="118788509" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 29 Jan 2015 20:13:47 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0TKDlC0013513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 20:13:47 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 14:13:47 -0600 From: "Fred Baker (fred)" To: Brian E Carpenter , V6 Ops List Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-11.txt Thread-Index: AQHQPAAWOjdKmFiXM0+iXtfu0ek71A== Date: Thu, 29 Jan 2015 20:13:46 +0000 Message-ID: <82EC2F29-DED3-4DF0-9F93-B758EA30EC5D@cisco.com> References: <20150129034612.14822.20520.idtracker@ietfa.amsl.com> <54C9AEB7.709@gmail.com> In-Reply-To: <54C9AEB7.709@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_2581A414-155D-4E7E-900C-8F91ECA179C9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-11.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, 29 Jan 2015 20:13:53 -0000 --Apple-Mail=_2581A414-155D-4E7E-900C-8F91ECA179C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks much. Folks - are we good with this? I=E2=80=99ll give people a few days to = say otherwise, but plan to send it to Joel next week barring issues. > On Jan 28, 2015, at 7:53 PM, Brian E Carpenter = wrote: >=20 > Hi, >=20 > This version mainly has the "friendly amendments" suggested by David = Farmer, > plus a few other changes from the last couple of weeks' discussion. >=20 > Since the "Deprecation" section has been split and reorganized, > the diffs look a bit complex, but the changes are mainly editorial. >=20 > Note to Ole: sorry, I'm on travel so submitted this without checking > with you. >=20 > Note to Fred: I ran idnits and the resulting warnings can be safely > ignored. >=20 > Note to everybody: if you feel you're missing from the Acknowledgments > please let me know. >=20 > Regards > Brian >=20 > On 29/01/2015 16:46, 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 : Deprecating Anycast Prefix for 6to4 Relay = Routers >> Authors : Ole Troan >> Brian Carpenter >> Filename : draft-ietf-v6ops-6to4-to-historic-11.txt >> Pages : 9 >> Date : 2015-01-28 >>=20 >> Abstract: >> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >> (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown = that >> when used in its anycast mode, the mechanism is unsuitable for >> widespread deployment and use in the Internet. This document >> therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay >> Routers", be made obsolete and moved to historic status. It also >> obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends >> that future products should not support 6to4 anycast and that >> existing deployments should be reviewed. This complements the >> guidelines in RFC 6343. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-11 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6to4-to-historic-11= >>=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 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_2581A414-155D-4E7E-900C-8F91ECA179C9 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 iQEVAwUBVMqUeJ9ieig10VPpAQI9TQgAg/S+q+EhFLFjwz5BEgEl62Z6leZBxIBN LzPGs6Ic9r0vC6aAfkE+3kmmHIO0LvWTFMgAxPNQAPnpbTxqT1ELsXfKf8noLcFp wz48CGrPjmvo4PsvVfeaI9PXwSE4m5JHAKwlqAirGT5miHngseBga6m0uVwNMd+o oGtJeaMTl4YHM4x2ARo45nc+ERvclfYS/mvpp/QjlK0KI8NyB6GU0UmrAa0vWphT py1RHLl6JEV+yvcwmowU/i0Yw3KUR8lRCwmE9dQQW7Dt+/4rV4TCu+6PgvVaae04 8mm36KQi2HcR+Q9datiTnV2E6oUBRd5xY5UxU+KplDKdN02ObNTs0w== =Dbb0 -----END PGP SIGNATURE----- --Apple-Mail=_2581A414-155D-4E7E-900C-8F91ECA179C9-- From nobody Thu Jan 29 12:23:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505CF1A01A9 for ; Thu, 29 Jan 2015 12:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2Gl9sDou_eS for ; Thu, 29 Jan 2015 12:23:22 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5C11A01A8 for ; Thu, 29 Jan 2015 12:23:22 -0800 (PST) Received: from mb-aye.local (64.125.197.170.IPYX-102339-ZYO.zip.zayo.com [64.125.197.170] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t0TKNCBW009467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 Jan 2015 20:23:13 GMT (envelope-from joelja@bogus.com) Message-ID: <54CA96A9.1090403@bogus.com> Date: Thu, 29 Jan 2015 12:23:05 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Brian E Carpenter , V6 Ops List References: <20150129034612.14822.20520.idtracker@ietfa.amsl.com> <54C9AEB7.709@gmail.com> <82EC2F29-DED3-4DF0-9F93-B758EA30EC5D@cisco.com> In-Reply-To: <82EC2F29-DED3-4DF0-9F93-B758EA30EC5D@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DvDaSNaURqBkgG0MkrHIWR3Rn8abUBLi5" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-11.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, 29 Jan 2015 20:23:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DvDaSNaURqBkgG0MkrHIWR3Rn8abUBLi5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, looking forward to it. joel On 1/29/15 12:13 PM, Fred Baker (fred) wrote: > Thanks much. >=20 > Folks - are we good with this? I=92ll give people a few days to say oth= erwise, but plan to send it to Joel next week barring issues. >=20 >> On Jan 28, 2015, at 7:53 PM, Brian E Carpenter wrote: >> >> Hi, >> >> This version mainly has the "friendly amendments" suggested by David F= armer, >> plus a few other changes from the last couple of weeks' discussion. >> >> Since the "Deprecation" section has been split and reorganized, >> the diffs look a bit complex, but the changes are mainly editorial. >> >> Note to Ole: sorry, I'm on travel so submitted this without checking >> with you. >> >> Note to Fred: I ran idnits and the resulting warnings can be safely >> ignored. >> >> Note to everybody: if you feel you're missing from the Acknowledgments= >> please let me know. >> >> Regards >> Brian >> >> On 29/01/2015 16:46, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>> This draft is a work item of the IPv6 Operations Working Group of the= IETF. >>> >>> Title : Deprecating Anycast Prefix for 6to4 Relay Ro= uters >>> Authors : Ole Troan >>> Brian Carpenter >>> Filename : draft-ietf-v6ops-6to4-to-historic-11.txt >>> Pages : 9 >>> Date : 2015-01-28 >>> >>> Abstract: >>> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >>> (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown tha= t >>> when used in its anycast mode, the mechanism is unsuitable for >>> widespread deployment and use in the Internet. This document >>> therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay= >>> Routers", be made obsolete and moved to historic status. It also >>> obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends >>> that future products should not support 6to4 anycast and that >>> existing deployments should be reviewed. This complements the >>> guidelines in RFC 6343. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-11 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6to4-to-historic-= 11 >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --DvDaSNaURqBkgG0MkrHIWR3Rn8abUBLi5 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 iEUEARECAAYFAlTKlqoACgkQ8AA1q7Z/VrITFgCgg8GbNvBRT7oitXmClR2+EJXb IV8Al1qoSDjjjRWo/EZfc7GQvlmTRNc= =iDF3 -----END PGP SIGNATURE----- --DvDaSNaURqBkgG0MkrHIWR3Rn8abUBLi5-- From nobody Thu Jan 29 12:39:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839BB1A6FFF for ; Thu, 29 Jan 2015 12:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hnbt0XHJaWRc for ; Thu, 29 Jan 2015 12:39:17 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696B61A1A2C for ; Thu, 29 Jan 2015 12:39:17 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id rd3so43223449pab.3 for ; Thu, 29 Jan 2015 12:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RKpbKYygLtwYax8ZjzzNtUyR7O5jmfjxzDYh+2IQ6uY=; b=qmny/6TyTyn7b4Bm9uN2NStwrJfuudBuSar8kDb7Srho4sBcUC9vSTT3XxHwBhJEl2 8J/HmlJD1KG8UNhGJfX2VBg+zDQR3ETK6xyI/J0OL3MRx+9Egt6dyy8U9B3vWywIbbIj sxRmyL6o9pkXJdTzRIckxqIuQFCqpBKGBLnsmx8GZRaQ6V3MXUcV5MiN5xo+siTqsXjW O0Othq6Ns2j/04ehgObPIeMYuVsR1kmnzQe1UNyaygq0FA5iVHbxEZUYSLNCz8MrEObF q56Y7OJztNl9MFa37X4qpzxbSBaViAH51hu4RMMpkqG98r+jFV4Dcve7ZZvblEZuKP1q 9dcg== X-Received: by 10.70.26.196 with SMTP id n4mr3406781pdg.85.1422563956701; Thu, 29 Jan 2015 12:39:16 -0800 (PST) Received: from ?IPv6:2401:c80:3:0:28cc:dc4c:9703:6781? ([2401:c80:3:0:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id di10sm8721311pad.41.2015.01.29.12.39.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 12:39:15 -0800 (PST) Message-ID: <54CA9A77.3080609@gmail.com> Date: Fri, 30 Jan 2015 09:39:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Colitti , "Fred Baker (fred)" References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jan 2015 20:39:19 -0000 To be honest I stopped tracking this draft a long time ago, so didn't speak up during the first WGLC. But I think I'm in the rough with Lorenzo. The document reads like somebody's procurement spec, not like a set of recommendations for generic interoperability. And the devil is in the details. For example, I noticed a point where I have a little skin in the game: APP_REC#3: Applications provided by the mobile device vendor that use Uniform Resource Identifiers (URIs) must follow [RFC3986]. For example, SIP applications must follow the correction defined in [RFC5954]. So, does that requirement include the updates to RFC 3986 (i.e. RFC 6874 and 7320)? And how is applying a correction to RFC 3261 an "example" of following RFC 3986? And anyway, shouldn't this be in a SIP profile, not here? That's an illustration of why this document positioned as an IETF work product makes me uncomfortable. I imagine there are many other similar hidden issues. Brian On 30/01/2015 00:53, Lorenzo Colitti wrote: > On Thu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) wrote: > >> draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of >> change in the IESG. The ADs would like to see the working group read it >> again and comment - working group last call - before they proceed. > > > Ok, off we go again then. > > I have objected to this document already, and was found to be in the rough. > Therefore, I must assume that rough WG consensus is that we need a document > that looks something like this, and I will accordingly refrain from making > any general statements on the scope, utility, and general content of the > document, with which I continue to disagree. > > However, I would be remiss if I did not at least draw attention to the > following factual errors and/or inappropriate statements. > > > 1. The wording "required features to connect 3GPP mobile devices to an > IPv6-only or dual-stack wireless network" is factually incorrect. The vast > majority of these recommendations are not required to connect to such > networks, and are many are not even implemented by many popular mobile > operating systems - which manage to connect just fine. After long > discussions, that text was removed in -06. Why was it readded? > > > 2. Previous versions of the document, including the version that passed > IETF last call, contained the text: > > This document is not a standard, and conformance with it is not > required in order to claim conformance with IETF standards for IPv6. > The support of the full set of features may not be required in some > deployment contexts. The authors believe that the support of a > subset of the features included in this protocol may lead to degraded > level of service in some deployment contexts. > > That text remains accurate and that statement is still necessary. Why was > it removed? It has been in the document since -06, and the words "this > document is not a standard" have been in this document since -01. > > > 3. I object to the statement "One of the major hurdles encountered by > mobile operators is the availability of non-broken IPv6 implementation in > mobile devices." I submit that if it were true, then we would observe no > IPv6 deployment in mobile networks... but publicly-available data - e.g., > http://www.worldipv6launch.org/measurements/ - shows that multiple > operators have deployed IPv6 to up to 30-65% of their footprint, using the > same commercially-available devices that are used by customers of other > operators. So claiming that "broken IPv6 implementations in mobile devices" > are a major hurdle is at best incomplete and at worst incorrect. > > > At the risk of sounding like a broken record, I am going yet again to say > that that operational documents should be based on operational experience. > I am not aware of any of the authors' employers having a substantial IPv6 > deployment (though I would be happy to see any data that the authors could > provide to the contrary). On the other hand, the IPv6 lead on one of the > operators that *has* deployed IPv6 no longer appears in the list of authors. > > > Regards, > Lorenzo > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 29 14:03:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2A01A885A for ; Thu, 29 Jan 2015 14:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pz4YdvZxNcg for ; Thu, 29 Jan 2015 14:02:58 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id EA0171A8853 for ; Thu, 29 Jan 2015 14:02:54 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 29 Jan 2015 16:02:53 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f169.google.com [209.85.223.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f169.google.com with SMTP id rl12so334511iec.0 for ; Thu, 29 Jan 2015 14:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A7HuMNjbxKu0ENCB6cdwBjtirJQk3ITAM+FnPcgqynA=; b=YfqsIhE5lmvSQVlFGwgoUvw+40ICtAr1LEpW9asWBI30bMBfiRK0E2DB3rwMukiz/t FHYuTzsi5Oaf3KVuqUDi8tZmvIjjcWG2D9pBXwOC7VRtQDFyXPJt5xB+tkzpEJGPSdcc tg6Z+W5sUSglG7MvwoSnpj3HnyRB1u4mnjCQY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=A7HuMNjbxKu0ENCB6cdwBjtirJQk3ITAM+FnPcgqynA=; b=RZjQm4+nJ6MSwkxNPW2e9awTiX+IT1nKNLNE+7t5oZA1gszjj81tx2+rH7/1ofpGV1 lDDh54pS856Ch5J2JJK1gxOlUSsrp72FoszI62XPZmP0PT+lmcVAuPJLGGMwW5Ygx985 kQL5zI5rHoDY0PhrvMnNVGExXGlW00txm8ROvn5ZJaWNCk2CM9uLiNqNLardf2FbcMUR yGvi2Ug/z5CKMLejZRhPgcSr1ACTp1W+g43vG5IV6FfFMwe0UqHMx52V68qBy75yCMcP QHsKXKALZlerm1HWaJzABKJDFkLhXobva+JhARqSVcoVARVqBFworR3FfZLcIF3Xdun5 3qQw== X-Received: by 10.50.50.142 with SMTP id c14mr3623447igo.42.1422568971702; Thu, 29 Jan 2015 14:02:51 -0800 (PST) X-Gm-Message-State: ALoCoQkqHsqzpALYuL+j/O8ah5e7cSEGh5qhpx0QzfweAOurp5uKrWKZvbWlV2OFZvhWRtl4IhbgUL/jIkJVggtZgM8uROsd+C1oLzkXJ0aU3LTlmgH67+spRwWWiBxkIzt9Rsf921rt X-Received: by 10.50.50.142 with SMTP id c14mr3623427igo.42.1422568971552; Thu, 29 Jan 2015 14:02:51 -0800 (PST) Received: from x-128-101-233-187.uofm-secure.wireless.umn.edu (x-128-101-233-187.uofm-secure.wireless.umn.edu. [128.101.233.187]) by mx.google.com with ESMTPSA id q7sm143910igx.9.2015.01.29.14.02.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 14:02:50 -0800 (PST) Message-ID: <54CAAE04.9060109@umn.edu> Date: Thu, 29 Jan 2015 16:02:44 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Brian E Carpenter , V6 Ops List References: <20150129034612.14822.20520.idtracker@ietfa.amsl.com> <54C9AEB7.709@gmail.com> <82EC2F29-DED3-4DF0-9F93-B758EA30EC5D@cisco.com> In-Reply-To: <82EC2F29-DED3-4DF0-9F93-B758EA30EC5D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:03:01 -0000 Brian's magic editing fingers did a wonderful job. :) Covers, my comments on the previous version, and as far as I'm concerned its ready to go. Thanks. On 1/29/15 14:13 , Fred Baker (fred) wrote: > Thanks much. > > Folks - are we good with this? I’ll give people a few days to say otherwise, but plan to send it to Joel next week barring issues. > >> On Jan 28, 2015, at 7:53 PM, Brian E Carpenter wrote: >> >> Hi, >> >> This version mainly has the "friendly amendments" suggested by David Farmer, >> plus a few other changes from the last couple of weeks' discussion. >> >> Since the "Deprecation" section has been split and reorganized, >> the diffs look a bit complex, but the changes are mainly editorial. >> >> Note to Ole: sorry, I'm on travel so submitted this without checking >> with you. >> >> Note to Fred: I ran idnits and the resulting warnings can be safely >> ignored. >> >> Note to everybody: if you feel you're missing from the Acknowledgments >> please let me know. >> >> Regards >> Brian >> >> On 29/01/2015 16:46, 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 : Deprecating Anycast Prefix for 6to4 Relay Routers >>> Authors : Ole Troan >>> Brian Carpenter >>> Filename : draft-ietf-v6ops-6to4-to-historic-11.txt >>> Pages : 9 >>> Date : 2015-01-28 >>> >>> Abstract: >>> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >>> (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that >>> when used in its anycast mode, the mechanism is unsuitable for >>> widespread deployment and use in the Internet. This document >>> therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay >>> Routers", be made obsolete and moved to historic status. It also >>> obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends >>> that future products should not support 6to4 anycast and that >>> existing deployments should be reviewed. This complements the >>> guidelines in RFC 6343. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-11 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-11 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Thu Jan 29 23:13:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0F01A88AF for ; Thu, 29 Jan 2015 23:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQx_aBslOgz4 for ; Thu, 29 Jan 2015 23:13:47 -0800 (PST) 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 ABC0B1A891C for ; Thu, 29 Jan 2015 23:13:46 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id BF9E83742DC; Fri, 30 Jan 2015 08:13:44 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 9E6D438404E; Fri, 30 Jan 2015 08:13:44 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 08:13:44 +0100 From: To: "Fred Baker (fred)" , V6 Ops List Thread-Topic: draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzYQVRg Date: Fri, 30 Jan 2015 07:13:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049024B2@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> In-Reply-To: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.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.1] 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: 2015.1.30.14818 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 07:13:49 -0000 Hi Fred, Thank you for initiating the call.=20 >From my editor window, the recommendations as included in this version have= all been listed in the version that passed the WGLC and IETF LC. The main = change is that we removed all the reco that are present in RFC7066/RFC6436 = + remove the "special language" as per the IESG's request.=20 Saying that, we are open to tweak the text to record the feedback from this= call. Cheers, Med =20 -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Fred Baker (fred= ) Envoy=E9=A0: mercredi 28 janvier 2015 17:58 =C0=A0: V6 Ops List Cc=A0: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org Objet=A0: [v6ops] draft-ietf-v6ops-mobile-device-profile last call draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of chan= ge in the IESG. The ADs would like to see the working group read it again a= nd comment - working group last call - before they proceed. To summarize, i= t provides requirements for handsets that would work in a specific business= model. As such, it builds on RFC 6434 and 7066, strengthening some of thos= e requirements, and going on to add requirements related to 464xlat and oth= er technologies. Please read it now, and comment. This WGLC will run until 15 February. From nobody Thu Jan 29 23:35:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893D11A1B28 for ; Thu, 29 Jan 2015 23:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrlHWbX1T7sV for ; Thu, 29 Jan 2015 23:35:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2F01A898F for ; Thu, 29 Jan 2015 23:35:20 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id A17933744C8; Fri, 30 Jan 2015 08:35:18 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6662A15804E; Fri, 30 Jan 2015 08:35:18 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 08:35:18 +0100 From: To: Lorenzo Colitti , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW7VoAgAFTUoA= Date: Fri, 30 Jan 2015 07:35:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049024FB@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049024FBOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 07:35:23 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049024FBOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCkVudm95w6kgOiBq ZXVkaSAyOSBqYW52aWVyIDIwMTUgMTI6NTMNCsOAIDogRnJlZCBCYWtlciAoZnJlZCkNCkNjIDog VjYgT3BzIExpc3Q7IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLmFsbEB0 b29scy5pZXRmLm9yZw0KT2JqZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmls ZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KT24gVGh1LCBKYW4gMjksIDIwMTUgYXQgMTo1 NyBBTSwgRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPG1haWx0bzpmcmVkQGNpc2Nv LmNvbT4+IHdyb3RlOg0KZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgaGFz IGJlZW4gdGhyb3VnaCBRdWl0ZSBhIGJpdCBvZiBjaGFuZ2UgaW4gdGhlIElFU0cuIFRoZSBBRHMg d291bGQgbGlrZSB0byBzZWUgdGhlIHdvcmtpbmcgZ3JvdXAgcmVhZCBpdCBhZ2FpbiBhbmQgY29t bWVudCAtIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIC0gYmVmb3JlIHRoZXkgcHJvY2VlZC4NCg0K T2ssIG9mZiB3ZSBnbyBhZ2FpbiB0aGVuLg0KDQpJIGhhdmUgb2JqZWN0ZWQgdG8gdGhpcyBkb2N1 bWVudCBhbHJlYWR5LCBhbmQgd2FzIGZvdW5kIHRvIGJlIGluIHRoZSByb3VnaC4gVGhlcmVmb3Jl LCBJIG11c3QgYXNzdW1lIHRoYXQgcm91Z2ggV0cgY29uc2Vuc3VzIGlzIHRoYXQgd2UgbmVlZCBh IGRvY3VtZW50IHRoYXQgbG9va3Mgc29tZXRoaW5nIGxpa2UgdGhpcywgYW5kIEkgd2lsbCBhY2Nv cmRpbmdseSByZWZyYWluIGZyb20gbWFraW5nIGFueSBnZW5lcmFsIHN0YXRlbWVudHMgb24gdGhl IHNjb3BlLCB1dGlsaXR5LCBhbmQgZ2VuZXJhbCBjb250ZW50IG9mIHRoZSBkb2N1bWVudCwgd2l0 aCB3aGljaCBJIGNvbnRpbnVlIHRvIGRpc2FncmVlLg0KDQpIb3dldmVyLCBJIHdvdWxkIGJlIHJl bWlzcyBpZiBJIGRpZCBub3QgYXQgbGVhc3QgZHJhdyBhdHRlbnRpb24gdG8gdGhlIGZvbGxvd2lu ZyBmYWN0dWFsIGVycm9ycyBhbmQvb3IgaW5hcHByb3ByaWF0ZSBzdGF0ZW1lbnRzLg0KDQoNCjEu IFRoZSB3b3JkaW5nICJyZXF1aXJlZCBmZWF0dXJlcyB0byBjb25uZWN0IDNHUFAgbW9iaWxlIGRl dmljZXMgdG8gYW4gSVB2Ni1vbmx5IG9yIGR1YWwtc3RhY2sgd2lyZWxlc3MgbmV0d29yayIgaXMg ZmFjdHVhbGx5IGluY29ycmVjdC4gVGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlc2UgcmVjb21tZW5k YXRpb25zIGFyZSBub3QgcmVxdWlyZWQgdG8gY29ubmVjdCB0byBzdWNoIG5ldHdvcmtzLCBhbmQg YXJlIG1hbnkgYXJlIG5vdCBldmVuIGltcGxlbWVudGVkIGJ5IG1hbnkgcG9wdWxhciBtb2JpbGUg b3BlcmF0aW5nIHN5c3RlbXMgLSB3aGljaCBtYW5hZ2UgdG8gY29ubmVjdCBqdXN0IGZpbmUuIEFm dGVyIGxvbmcgZGlzY3Vzc2lvbnMsIHRoYXQgdGV4dCB3YXMgcmVtb3ZlZCBpbiAtMDYuIFdoeSB3 YXMgaXQgcmVhZGRlZD8NCg0KW01lZF0gVGhpcyB0ZXh0IHdhcyByZWRpdGVkIGFzIGEgc2lkZSBl ZmZlY3Qgb2YgaW1wbGVtZW50aW5nIHRoZSByZXF1ZXN0IGZyb20gdGhlIElFU0cgdG8gcG9zaXRp b24gdGhpcyBkb2N1bWVudCBhcyBhIHN1cGVyc2V0IG9mIGV4aXN0aW5nIFJGQ3MuICBUaGUgcmVj b21tZW5kYXRpb25zIGFyZSBub3Qgb25seSBhYm91dCBJUHY2IGJ1dCBhbHNvLCBhcyBpbmRpY2F0 ZWQgaW4gdGhlIHNhbWUgc2VudGVuY2UgeW91IHF1b3RlZCwg4oCcZmVhdHVyZXMgdG8gZGVsaXZl ciBJUHY0IGNvbm5lY3Rpdml0eSBzZXJ2aWNlIG92ZXIgYW4gSVB2Ni1vbmx5IHRyYW5zcG9ydOKA nS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KMi4gUHJldmlvdXMgdmVyc2lvbnMgb2YgdGhl IGRvY3VtZW50LCBpbmNsdWRpbmcgdGhlIHZlcnNpb24gdGhhdCBwYXNzZWQgSUVURiBsYXN0IGNh bGwsIGNvbnRhaW5lZCB0aGUgdGV4dDoNCg0KICAgVGhpcyBkb2N1bWVudCBpcyBub3QgYSBzdGFu ZGFyZCwgYW5kIGNvbmZvcm1hbmNlIHdpdGggaXQgaXMgbm90DQogICByZXF1aXJlZCBpbiBvcmRl ciB0byBjbGFpbSBjb25mb3JtYW5jZSB3aXRoIElFVEYgc3RhbmRhcmRzIGZvciBJUHY2Lg0KICAg VGhlIHN1cHBvcnQgb2YgdGhlIGZ1bGwgc2V0IG9mIGZlYXR1cmVzIG1heSBub3QgYmUgcmVxdWly ZWQgaW4gc29tZQ0KICAgZGVwbG95bWVudCBjb250ZXh0cy4gIFRoZSBhdXRob3JzIGJlbGlldmUg dGhhdCB0aGUgc3VwcG9ydCBvZiBhDQogICBzdWJzZXQgb2YgdGhlIGZlYXR1cmVzIGluY2x1ZGVk IGluIHRoaXMgcHJvdG9jb2wgbWF5IGxlYWQgdG8gZGVncmFkZWQNCiAgIGxldmVsIG9mIHNlcnZp Y2UgaW4gc29tZSBkZXBsb3ltZW50IGNvbnRleHRzLg0KDQpUaGF0IHRleHQgcmVtYWlucyBhY2N1 cmF0ZSBhbmQgdGhhdCBzdGF0ZW1lbnQgaXMgc3RpbGwgbmVjZXNzYXJ5LiBXaHkgd2FzIGl0IHJl bW92ZWQ/IEl0IGhhcyBiZWVuIGluIHRoZSBkb2N1bWVudCBzaW5jZSAtMDYsIGFuZCB0aGUgd29y ZHMgInRoaXMgZG9jdW1lbnQgaXMgbm90IGEgc3RhbmRhcmQiIGhhdmUgYmVlbiBpbiB0aGlzIGRv Y3VtZW50IHNpbmNlIC0wMS4NCg0KW01lZF0gSXQgd2FzIHJlbW92ZWQgYXMgcGVyIGEgcmVxdWVz dCBmcm9tIHRoZSBJRVNHIChBLiBGYXJyZWwpLg0KDQoNCjMuIEkgb2JqZWN0IHRvIHRoZSBzdGF0 ZW1lbnQgIk9uZSBvZiB0aGUgbWFqb3IgaHVyZGxlcyBlbmNvdW50ZXJlZCBieSBtb2JpbGUgb3Bl cmF0b3JzIGlzIHRoZSBhdmFpbGFiaWxpdHkgb2Ygbm9uLWJyb2tlbiBJUHY2IGltcGxlbWVudGF0 aW9uIGluIG1vYmlsZSBkZXZpY2VzLiIgSSBzdWJtaXQgdGhhdCBpZiBpdCB3ZXJlIHRydWUsIHRo ZW4gd2Ugd291bGQgb2JzZXJ2ZSBubyBJUHY2IGRlcGxveW1lbnQgaW4gbW9iaWxlIG5ldHdvcmtz Li4uIGJ1dCBwdWJsaWNseS1hdmFpbGFibGUgZGF0YSAtIGUuZy4sIGh0dHA6Ly93d3cud29ybGRp cHY2bGF1bmNoLm9yZy9tZWFzdXJlbWVudHMvIC0gc2hvd3MgdGhhdCBtdWx0aXBsZSBvcGVyYXRv cnMgaGF2ZSBkZXBsb3llZCBJUHY2IHRvIHVwIHRvIDMwLTY1JSBvZiB0aGVpciBmb290cHJpbnQs IHVzaW5nIHRoZSBzYW1lIGNvbW1lcmNpYWxseS1hdmFpbGFibGUgZGV2aWNlcyB0aGF0IGFyZSB1 c2VkIGJ5IGN1c3RvbWVycyBvZiBvdGhlciBvcGVyYXRvcnMuIFNvIGNsYWltaW5nIHRoYXQgImJy b2tlbiBJUHY2IGltcGxlbWVudGF0aW9ucyBpbiBtb2JpbGUgZGV2aWNlcyIgYXJlIGEgbWFqb3Ig aHVyZGxlIGlzIGF0IGJlc3QgaW5jb21wbGV0ZSBhbmQgYXQgd29yc3QgaW5jb3JyZWN0Lg0KDQpb TWVkXSBUaGF0IHNlbnRlbmNlIHdhcyB0aGVyZSBzaW5jZSB3ZSBlZGl0ZWQgdGhlIGluZGl2aWR1 YWwgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuIE9mIGNvdXJzZSwgY3VycmVudCBpbXBsZW1lbnRh dGlvbnMgcGVyZm9ybSBiZXR0ZXIgdGhhdCB3aGVuIHdlIGVkaXRlZCB0aGUgLTAwIG9mIHRoZSBk b2N1bWVudC4gU3RpbGwsIHRoZSBmZWVkYmFjayB3ZSBoYWQgZnJvbSBvdXIgZGV2aWNlIHRlYW0g aXMgdGhhdCB0aGVyZSBhcmUgc3RpbGwgYSBsb3QgdG8gYmUgZG9uZS4NCg0KDQpBdCB0aGUgcmlz ayBvZiBzb3VuZGluZyBsaWtlIGEgYnJva2VuIHJlY29yZCwgSSBhbSBnb2luZyB5ZXQgYWdhaW4g dG8gc2F5IHRoYXQgdGhhdCBvcGVyYXRpb25hbCBkb2N1bWVudHMgc2hvdWxkIGJlIGJhc2VkIG9u IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIEkgYW0gbm90IGF3YXJlIG9mIGFueSBvZiB0aGUgYXV0 aG9ycycgZW1wbG95ZXJzIGhhdmluZyBhIHN1YnN0YW50aWFsIElQdjYgZGVwbG95bWVudCAodGhv dWdoIEkgd291bGQgYmUgaGFwcHkgdG8gc2VlIGFueSBkYXRhIHRoYXQgdGhlIGF1dGhvcnMgY291 bGQgcHJvdmlkZSB0byB0aGUgY29udHJhcnkpLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIElQdjYg bGVhZCBvbiBvbmUgb2YgdGhlIG9wZXJhdG9ycyB0aGF0ICpoYXMqIGRlcGxveWVkIElQdjYgbm8g bG9uZ2VyIGFwcGVhcnMgaW4gdGhlIGxpc3Qgb2YgYXV0aG9ycy4NCg0KDQpbTWVkXSBJIGNhbiBn aXZlIHlvdSB0aGUgZXhhbXBsZSBvZiBPcmFuZ2UgaW4gUG9sYW5kLCBmb3Igb25lLiBZb3UgY2Fu IGFsc28gY2hlY2sgdGhlIE9yYW5nZSBHcm91ZCBEZXZpY2UgcmVxdWlyZW1lbnRzIChJUHY2IENo YXB0ZXIpOiBodHRwczovL3d3dy5vZ2RyLW9ubGluZS5jb20vb2dkci9pbmRleC5waHAvY29tcG9u ZW50L2V4dGVuZGVkcmVnL2xvZ2luLiBJIGhvcGUgd2UgY2FuIGZvY3VzIG9uIHRlY2huaWNhbCBj b21tZW50IHJhdGhlciB0aGFuIGRpdmVydGluZy4gVGhhbmtzLg0KDQoNClJlZ2FyZHMsDQpMb3Jl bnpvDQo= --_000_787AE7BB302AE849A7480A190F8B9330049024FBOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLmRl bGV0ZQ0KCXttc28tc3R5bGUtbmFtZTpkZWxldGU7fQ0Kc3Bhbi5pbnNlcnQNCgl7bXNvLXN0eWxl LW5hbWU6aW5zZXJ0O30NCnNwYW4uVGV4dGVicnV0Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0 ZSBicnV0IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJU ZXh0ZSBicnV0IjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgTG9yZW56byw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNl IHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdv b2dsZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMjkgamFudmllciAy MDE1IDEyOjUzPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBGcmVkIEJha2VyIChmcmVkKTxicj4NCjxi PkNjJm5ic3A7OjwvYj4gVjYgT3BzIExpc3Q7IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmlj ZS1wcm9maWxlLmFsbEB0b29scy5pZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6 IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIEphbiAyOSwgMjAxNSBhdCAxOjU3IEFNLCBGcmVkIEJha2VyIChmcmVkKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZyZWRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZnJlZEBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRyYWZ0 LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGhhcyBiZWVuIHRocm91Z2ggUXVpdGUg YSBiaXQgb2YgY2hhbmdlIGluIHRoZSBJRVNHLiBUaGUgQURzIHdvdWxkIGxpa2UgdG8gc2VlIHRo ZSB3b3JraW5nIGdyb3VwIHJlYWQgaXQgYWdhaW4gYW5kIGNvbW1lbnQgLSB3b3JraW5nIGdyb3Vw IGxhc3QgY2FsbCAtIGJlZm9yZSB0aGV5IHByb2NlZWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Paywgb2ZmIHdlIGdvIGFnYWluIHRoZW4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBvYmpl Y3RlZCB0byB0aGlzIGRvY3VtZW50IGFscmVhZHksIGFuZCB3YXMgZm91bmQgdG8gYmUgaW4gdGhl IHJvdWdoLiBUaGVyZWZvcmUsIEkgbXVzdCBhc3N1bWUgdGhhdCByb3VnaCBXRyBjb25zZW5zdXMg aXMgdGhhdCB3ZSBuZWVkIGEgZG9jdW1lbnQgdGhhdCBsb29rcyBzb21ldGhpbmcgbGlrZSB0aGlz LCBhbmQgSSB3aWxsIGFjY29yZGluZ2x5IHJlZnJhaW4gZnJvbSBtYWtpbmcgYW55IGdlbmVyYWwN CiBzdGF0ZW1lbnRzIG9uIHRoZSBzY29wZSwgdXRpbGl0eSwgYW5kIGdlbmVyYWwgY29udGVudCBv ZiB0aGUgZG9jdW1lbnQsIHdpdGggd2hpY2ggSSBjb250aW51ZSB0byBkaXNhZ3JlZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwg SSB3b3VsZCBiZSByZW1pc3MgaWYgSSBkaWQgbm90IGF0IGxlYXN0IGRyYXcgYXR0ZW50aW9uIHRv IHRoZSBmb2xsb3dpbmcgZmFjdHVhbCBlcnJvcnMgYW5kL29yIGluYXBwcm9wcmlhdGUgc3RhdGVt ZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MS4gVGhlIHdvcmRpbmcgJnF1b3Q7cmVxdWlyZWQgZmVh dHVyZXMgdG8gY29ubmVjdCAzR1BQIG1vYmlsZSBkZXZpY2VzIHRvIGFuIElQdjYtb25seSBvciBk dWFsLXN0YWNrIHdpcmVsZXNzIG5ldHdvcmsmcXVvdDsgaXMgZmFjdHVhbGx5IGluY29ycmVjdC4N Cjwvc3Bhbj5UaGUgdmFzdCBtYWpvcml0eSBvZiB0aGVzZSByZWNvbW1lbmRhdGlvbnMgYXJlIG5v dCByZXF1aXJlZCB0byBjb25uZWN0IHRvIHN1Y2ggbmV0d29ya3MsIGFuZCBhcmUgbWFueSBhcmUg bm90IGV2ZW4gaW1wbGVtZW50ZWQgYnkgbWFueSBwb3B1bGFyIG1vYmlsZSBvcGVyYXRpbmcgc3lz dGVtcyAtIHdoaWNoIG1hbmFnZSB0byBjb25uZWN0IGp1c3QgZmluZS4gQWZ0ZXIgbG9uZyBkaXNj dXNzaW9ucywgdGhhdCB0ZXh0IHdhcyByZW1vdmVkDQogaW4gLTA2LiBXaHkgd2FzIGl0IHJlYWRk ZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+W01lZF0gPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyB0ZXh0IHdhcyByZWRpdGVkIGFzIGEgc2lkZSBl ZmZlY3Qgb2YgaW1wbGVtZW50aW5nIHRoZSByZXF1ZXN0IGZyb20gdGhlIElFU0cgdG8gcG9zaXRp b24gdGhpcyBkb2N1bWVudCBhcyBhIHN1cGVyc2V0IG9mIGV4aXN0aW5nDQogUkZDcy4gJm5ic3A7 VGhlIHJlY29tbWVuZGF0aW9ucyBhcmUgbm90IG9ubHkgYWJvdXQgSVB2NiBidXQgYWxzbywgYXMg aW5kaWNhdGVkIGluIHRoZSBzYW1lIHNlbnRlbmNlIHlvdSBxdW90ZWQsIOKAnDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+ZmVhdHVyZXMgdG8gZGVsaXZlciBJUHY0IGNvbm5lY3Rpdml0eSBzZXJ2 aWNlIG92ZXIgYW4gSVB2Ni1vbmx5DQo8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50cmFuc3BvcnQ8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7igJ0uIDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIuIFByZXZpb3VzIHZlcnNpb25z IG9mIHRoZSBkb2N1bWVudCwgaW5jbHVkaW5nIHRoZSB2ZXJzaW9uIHRoYXQgcGFzc2VkIElFVEYg bGFzdCBjYWxsLCBjb250YWluZWQgdGhlIHRleHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQg aXMgPC9zcGFuPm5vdCBhIHN0YW5kYXJkLCBhbmQgY29uZm9ybWFuY2Ugd2l0aCBpdCBpcyBub3Q8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDtyZXF1aXJlZCBpbiBvcmRlciB0byBjbGFpbSBjb25mb3JtYW5jZSB3aXRoIElFVEYg c3RhbmRhcmRzIGZvciBJUHY2LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1RoZSBzdXBwb3J0IG9mIHRoZSBmdWxsIHNldCBv ZiBmZWF0dXJlcyBtYXkgbm90IGJlIHJlcXVpcmVkIGluIHNvbWU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtkZXBsb3ltZW50 IGNvbnRleHRzLiZuYnNwOyBUaGUgYXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhlIHN1cHBvcnQgb2Yg YTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO3N1YnNldCBvZiB0aGUgZmVhdHVyZXMgaW5jbHVkZWQgaW4gdGhpcyBwcm90b2Nv bCBtYXkgbGVhZCB0byBkZWdyYWRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2xldmVsIG9mIHNlcnZpY2UgaW4gc29tZSBk ZXBsb3ltZW50IGNvbnRleHRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgdGV4dCByZW1haW5zIGFjY3VyYXRlIGFuZCB0 aGF0IHN0YXRlbWVudCBpcyBzdGlsbCBuZWNlc3NhcnkuIFdoeSB3YXMgaXQgcmVtb3ZlZD8gSXQg aGFzIGJlZW4gaW4gdGhlIGRvY3VtZW50IHNpbmNlIC0wNiwgYW5kIHRoZSB3b3JkcyAmcXVvdDt0 aGlzIGRvY3VtZW50IGlzIG5vdCBhIHN0YW5kYXJkJnF1b3Q7IGhhdmUgYmVlbiBpbiB0aGlzIGRv Y3VtZW50IHNpbmNlIC0wMS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEl0 IHdhcyByZW1vdmVkIGFzIHBlciBhIHJlcXVlc3QgZnJvbSB0aGUgSUVTRyAoQS4gRmFycmVsKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMuIEkgb2JqZWN0IHRvIHRoZSBzdGF0ZW1lbnQgJnF1b3Q7T25lIG9mIHRoZSBtYWpvciBodXJk bGVzIGVuY291bnRlcmVkIGJ5IG1vYmlsZSBvcGVyYXRvcnMgaXMgdGhlIGF2YWlsYWJpbGl0eSBv ZiBub24tYnJva2VuIElQdjYgaW1wbGVtZW50YXRpb24gaW4gbW9iaWxlIGRldmljZXMuJnF1b3Q7 IEkgc3VibWl0IHRoYXQgaWYgaXQgd2VyZSB0cnVlLCB0aGVuIHdlIHdvdWxkIG9ic2VydmUgbm8g SVB2NiBkZXBsb3ltZW50IGluDQogbW9iaWxlIG5ldHdvcmtzLi4uIGJ1dCBwdWJsaWNseS1hdmFp bGFibGUgZGF0YSAtIGUuZy4sIDxhIGhyZWY9Imh0dHA6Ly93d3cud29ybGRpcHY2bGF1bmNoLm9y Zy9tZWFzdXJlbWVudHMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LndvcmxkaXB2Nmxh dW5jaC5vcmcvbWVhc3VyZW1lbnRzLzwvYT4gLSBzaG93cyB0aGF0IG11bHRpcGxlIG9wZXJhdG9y cyBoYXZlIGRlcGxveWVkIElQdjYgdG8gdXAgdG8gMzAtNjUlIG9mIHRoZWlyIGZvb3RwcmludCwg dXNpbmcgdGhlIHNhbWUgY29tbWVyY2lhbGx5LWF2YWlsYWJsZSBkZXZpY2VzIHRoYXQgYXJlIHVz ZWQgYnkgY3VzdG9tZXJzIG9mIG90aGVyIG9wZXJhdG9ycy4gU28gY2xhaW1pbmcgdGhhdCAmcXVv dDticm9rZW4gSVB2Ng0KIGltcGxlbWVudGF0aW9ucyBpbiBtb2JpbGUgZGV2aWNlcyZxdW90OyBh cmUgYSBtYWpvciBodXJkbGUgaXMgYXQgYmVzdCBpbmNvbXBsZXRlIGFuZCBhdCB3b3JzdCBpbmNv cnJlY3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGF0IHNlbnRlbmNl IHdhcyB0aGVyZSBzaW5jZSB3ZSBlZGl0ZWQgdGhlIGluZGl2aWR1YWwgdmVyc2lvbiBvZiB0aGUg ZG9jdW1lbnQuIE9mIGNvdXJzZSwgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBiZXR0 ZXIgdGhhdCB3aGVuIHdlIGVkaXRlZA0KIHRoZSAtMDAgb2YgdGhlIGRvY3VtZW50LiBTdGlsbCwg dGhlIGZlZWRiYWNrIHdlIGhhZCBmcm9tIG91ciBkZXZpY2UgdGVhbSBpcyB0aGF0IHRoZXJlIGFy ZSBzdGlsbCBhIGxvdCB0byBiZSBkb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkF0IHRoZSByaXNr IG9mIHNvdW5kaW5nIGxpa2UgYSBicm9rZW4gcmVjb3JkLCBJIGFtIGdvaW5nIHlldCBhZ2FpbiB0 byBzYXkgdGhhdCB0aGF0IG9wZXJhPC9zcGFuPnRpb25hbCBkb2N1bWVudHMgc2hvdWxkIGJlIGJh c2VkIG9uIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIEkgYW0gbm90IGF3YXJlIG9mIGFueSBvZiB0 aGUgYXV0aG9ycycgZW1wbG95ZXJzIGhhdmluZyBhIHN1YnN0YW50aWFsDQogSVB2NiBkZXBsb3lt ZW50ICh0aG91Z2ggSSB3b3VsZCBiZSBoYXBweSB0byBzZWUgYW55IGRhdGEgdGhhdCB0aGUgYXV0 aG9ycyBjb3VsZCBwcm92aWRlIHRvIHRoZSBjb250cmFyeSkuIE9uIHRoZSBvdGhlciBoYW5kLCB0 aGUgSVB2NiBsZWFkIG9uIG9uZSBvZiB0aGUgb3BlcmF0b3JzIHRoYXQgKmhhcyogZGVwbG95ZWQg SVB2NiBubyBsb25nZXIgYXBwZWFycyBpbiB0aGUgbGlzdCBvZiBhdXRob3JzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5bTWVkXSBJIGNhbiBnaXZlIHlvdSB0aGUgZXhhbXBsZSBvZiBPcmFuZ2UgaW4gUG9s YW5kLCBmb3Igb25lLiBZb3UgY2FuIGFsc28gY2hlY2sgdGhlIE9yYW5nZSBHcm91ZCBEZXZpY2Ug cmVxdWlyZW1lbnRzIChJUHY2IENoYXB0ZXIpOg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 Lm9nZHItb25saW5lLmNvbS9vZ2RyL2luZGV4LnBocC9jb21wb25lbnQvZXh0ZW5kZWRyZWcvbG9n aW4iPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3d3dy5vZ2RyLW9ubGluZS5jb20vb2dkci9p bmRleC5waHAvY29tcG9uZW50L2V4dGVuZGVkcmVnL2xvZ2luPC9zcGFuPjwvYT48c3BhbiBsYW5n PSJFTi1VUyI+LiBJIGhvcGUgd2UgY2FuIGZvY3VzIG9uIHRlY2huaWNhbCBjb21tZW50IHJhdGhl cg0KIHRoYW4gZGl2ZXJ0aW5nLiBUaGFua3MuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TG9yZW56bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330049024FBOPEXCLILM23corp_-- From nobody Fri Jan 30 00:05:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1371A89AE for ; Fri, 30 Jan 2015 00:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BNu6UDOXZSQ for ; Fri, 30 Jan 2015 00:04:58 -0800 (PST) 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 B794E1A899A for ; Fri, 30 Jan 2015 00:04:57 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 4EC8A3744CD; Fri, 30 Jan 2015 09:04:56 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 61D0C1800A0; Fri, 30 Jan 2015 09:04:54 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 09:04:54 +0100 From: To: Ole Troan , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgAFVDgA= Date: Fri, 30 Jan 2015 08:04:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004902552@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] 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.12.16.134821 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 08:05:00 -0000 Hi Ole, Thank you for the comments. Please see inline. Cheers, Med -----Message d'origine----- De=A0: Ole Troan [mailto:otroan@employees.org]=20 Envoy=E9=A0: jeudi 29 janvier 2015 13:15 =C0=A0: Fred Baker (fred) Cc=A0: V6 Ops List; draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.o= rg Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call > On 28 Jan 2015, at 17:57 , Fred Baker (fred) wrote: >=20 > draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of ch= ange in the IESG. The ADs would like to see the working group read it again= and comment - working group last call - before they proceed. To summarize,= it provides requirements for handsets that would work in a specific busine= ss model. As such, it builds on RFC 6434 and 7066, strengthening some of th= ose requirements, and going on to add requirements related to 464xlat and o= ther technologies. >=20 > Please read it now, and comment. This WGLC will run until 15 February. +1 to Lorenzo's comments. in addition. C_REC#11: If the cellular host receives the DNS information in several channels for the same interface, the following preference order must be followed: 1. PCO 2. RA 3. DHCPv6 in the other areas this issue has come up. then the conclusion has been tha= t the host uses all the information received. I think it would be quite unf= ortunate that the host stack much behave differently depending on the link-= layer. I would suggest either to drop the requirement, or to say that the i= mplementation must use all DNS servers learnt. [Med] FWIW, this was added to have a more deterministic behavior at the cel= lular side. I may lost the context since early stages of the draft, but I r= ecall there was a discussion in the list asking to make the ordering more s= trict: see for instance: http://www.ietf.org/mail-archive/web/v6ops/current= /msg14375.html. Using all the information or follow the selection modes are= two ways to achieve the same objective: determinist behavior at the termin= al side. The draft recorded the feedback we received at that time. same comment applies to W_REC#4. [Med] There is no W_REC# in the current version. I think you are referring = to W_REC#2. Same as above. I can't see a good reason why hosts that also have cellular interfaces shou= ld work differently on a WLAN as opposed to those that don't have cellular = interfaces. [Med] The main motivation for this section was the test we have conducted o= n some IPv6-enabled devices that do not behave correctly when IPv6-only mod= e (you can see for instance what we reported here: https://tools.ietf.org/h= tml/draft-boucadair-pcp-nat64-experiments-00#section-3.3). This is an examp= le of implementation brokenness to be avoided. why does e.g. A_REC#3 refer to NATs? [Med] A_REC#3 is when IPv4 service continuity is provided over IPv6.=20 "Tracking a host is still possible based on the first 64 bits of the IPv6 address. Means to prevent against such tracking issues may be enabled in the network side." what does this allude to? [Med] All what it says is that if a host doesn't want to be tracked, changi= ng the last 64 bits may not be sufficient.=20 From nobody Fri Jan 30 00:07:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE9B1A89B3 for ; Fri, 30 Jan 2015 00:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOUxir2QP-Do for ; Fri, 30 Jan 2015 00:07:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DE01A899A for ; Fri, 30 Jan 2015 00:07:51 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 76D6B374169; Fri, 30 Jan 2015 09:07:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id BD5E815809E; Fri, 30 Jan 2015 09:07:48 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 09:07:48 +0100 From: To: James Woodyatt Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgACD6oCAANm6QA== Date: Fri, 30 Jan 2015 08:07:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004902567OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 08:07:53 -0000 --_000_787AE7BB302AE849A7480A190F8B933004902567OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBKYW1lcywNCg0KWW91ciBwcm9wb3NlZCB3b3JkaW5nIGlzIE9LIHdpdGggbWUuDQoNCkkg aW1wbGVtZW50ZWQgaXQgaW4gbXkgbG9jYWwgY29weSwgdGhhbmtzLg0KDQpDaGVlcnMsDQpNZWQN Cg0KRGUgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUgSmFtZXMgV29vZHlhdHQNCkVudm95w6kgOiBqZXVkaSAyOSBqYW52aWVyIDIwMTUgMjE6MDcN CsOAIDogSVB2NiBPcHMgV0cNCk9iamV0IDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsDQoNCkFkZGl0aW9uYWxseeKAlA0KDQpFZGl0 b3JpYWw6IHRoZSBzZWN0aW9uIGZvciBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBjdXJyZW50bHkg c2F5cyB0aGlzOg0KDQpTZWN1cml0eS1yZWxhdGVkIGNvbnNpZGVyYXRpb25zIHRoYXQgYXBwbHkg d2hlbiB0aGUgY2VsbHVsYXIgZGV2aWNlIHByb3ZpZGVzIExBTiBmZWF0dXJlcyBhcmUgc3BlY2lm aWVkIGluIFtSRkM2MDkyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDkyPl0uDQoN ClRoaXMgc2VudGVuY2UgaXMgYSBiaXQgYXdrd2FyZOKAlCBidXQgbW9yZSBpbXBvcnRhbnRseSwg UkZDIDYwOTIgaXMgbm90IGEgc3BlY2lmaWNhdGlvbiwgYW5kIHRoZSBjaGFpbiBvZiBjaXRhdGlv biB0aGF0IGxlYWQgdG8gaXRzIHJlZmVyZW5jZSBoZXJlIGlzIGZhciBmcm9tIGNsZWFyLiAgSSBz dWdnZXN0IHRoZSBmb2xsb3dpbmcgd29yZGllciBidXQgbW9yZSBoZWxwZnVsIHJlcGxhY2VtZW50 Og0KDQpJbiB0aGUgY2FzZSBvZiBjZWxsdWxhciBkZXZpY2VzIHRoYXQgcHJvdmlkZSBMQU4gZmVh dHVyZXMsIGNvbXBsaWFuY2Ugd2l0aCBMX1JFQyMyIGVudGFpbHMgY29tcGxpYW5jZSB3aXRoIFJG QyA2MjA0LCB3aGljaCBpbiB0dXJuIHJlY29tbWVuZHMgY29tcGxpYW5jZSB3aXRoIFJlY29tbWVu ZGVkIFNpbXBsZSBTZWN1cml0eSBDYXBhYmlsaXRpZXMgaW4gQ3VzdG9tZXIgUHJlbWlzZXMgRXF1 aXBtZW50IChDUEUpIGZvciBQcm92aWRpbmcgUmVzaWRlbnRpYWwgSVB2NiBJbnRlcm5ldCBTZXJ2 aWNlIFtSRkM2MDkyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDkyPl0uIFRoZXJl Zm9yZSwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHNlY3Rpb24gNiBvZiB0aGF0IGRv Y3VtZW50IGFyZSByZWxldmFudC4gSW4gcGFydGljdWxhciwgaXQgYmVhcnMgcmVwZWF0aW5nIGhl cmUgdGhhdCB0aGUgdHJ1ZSBpbXBhY3Qgb2Ygc3RhdGVmdWwgZmlsdGVyaW5nIG1heSBiZSBhIHJl ZHVjdGlvbiBpbiBzZWN1cml0eSwgYW5kIHRoYXQgSUVURiBtYWtlIG5vIHN0YXRlbWVudCwgZXhw cmVzc2VkIG9yIGltcGxpZWQsIGFzIHRvIHdoZXRoZXIgdXNpbmcgdGhlIGNhcGFiaWxpdGllcyBk ZXNjcmliZWQgaW4gYW55IG9mIHRoZXNlIGRvY3VtZW50cyB1bHRpbWF0ZWx5IGltcHJvdmVzIHNl Y3VyaXR5IGZvciBhbnkgaW5kaXZpZHVhbCB1c2VycyBvciBmb3IgdGhlIEludGVybmV0IGNvbW11 bml0eSBhcyBhIHdob2xlLg0KDQpwLnMuIEkgYWxzbyBzaGFyZSBhbGwgb2YgTG9yZW56bydzIG90 aGVyIHNwZWNpZmljIGNvbmNlcm5zIGFib3V0IHRoaXMgZHJhZnQsIGFzIHdlbGwgYXMgaGlzIGJy b2FkIGdlbmVyYWwgb2JqZWN0aW9ucy4NCg0KDQotLQ0KamFtZXMgd29vZHlhdHQgPGpod0BuZXN0 bGFicy5jb208bWFpbHRvOmpod0BuZXN0bGFicy5jb20+Pg0KTmVzdCBMYWJzLCBDb21tdW5pY2F0 aW9ucyBFbmdpbmVlcmluZw0K --_000_787AE7BB302AE849A7480A190F8B933004902567OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIEphbWVz LCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5Zb3VyIHByb3Bvc2VkIHdvcmRpbmcgaXMgT0sgd2l0aCBtZS4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGltcGxlbWVudGVkIGl0IGluIG15 IGxvY2FsIGNvcHksIHRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEphbWVzIFdvb2R5YXR0PGJyPg0KPGI+ RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDI5IGphbnZpZXIgMjAxNSAyMTowNzxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gSVB2NiBPcHMgV0c8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdjZv cHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRpb25h bGx54oCUPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkVkaXRvcmlhbDogdGhlIHNlY3Rpb24gZm9yIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGN1 cnJlbnRseSBzYXlzIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN1cml0eS1yZWxhdGVkIGNvbnNpZGVyYXRp b25zIHRoYXQgYXBwbHkgd2hlbiB0aGUgY2VsbHVsYXIgZGV2aWNlJm5ic3A7cHJvdmlkZXMgTEFO IGZlYXR1cmVzIGFyZSBzcGVjaWZpZWQgaW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2MDkyIiB0aXRsZT0iJnF1b3Q7UmVjb21tZW5kZWQgU2ltcGxlIFNlY3VyaXR5 IENhcGFiaWxpdGllcyBpbiBDdXN0b21lciBQcmVtaXNlcyBFcXVpcG1lbnQgKENQRSkgZm9yIFBy b3ZpZGluZyBSZXNpZGVudGlhbCBJUHY2IEludGVybmV0IFNlcnZpY2UmcXVvdDsiPlJGQzYwOTI8 L2E+XS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzZW50ZW5jZSBpcyBhIGJpdCBhd2t3YXJk4oCUIGJ1dCBt b3JlIGltcG9ydGFudGx5LCBSRkMgNjA5MiBpcyBub3QgYSBzcGVjaWZpY2F0aW9uLCBhbmQgdGhl IGNoYWluIG9mIGNpdGF0aW9uIHRoYXQgbGVhZCB0byBpdHMgcmVmZXJlbmNlIGhlcmUgaXMgZmFy IGZyb20gY2xlYXIuJm5ic3A7IEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIHdvcmRpZXIgYnV0IG1v cmUgaGVscGZ1bCByZXBsYWNlbWVudDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgY2FzZSBvZiBj ZWxsdWxhciBkZXZpY2VzIHRoYXQgcHJvdmlkZSBMQU4gZmVhdHVyZXMsIGNvbXBsaWFuY2Ugd2l0 aCBMX1JFQyMyIGVudGFpbHMgY29tcGxpYW5jZSB3aXRoIFJGQyA2MjA0LCB3aGljaCBpbiB0dXJu IHJlY29tbWVuZHMgY29tcGxpYW5jZSB3aXRoIFJlY29tbWVuZGVkIFNpbXBsZSBTZWN1cml0eSBD YXBhYmlsaXRpZXMgaW4gQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IChDUEUpDQogZm9yIFBy b3ZpZGluZyBSZXNpZGVudGlhbCBJUHY2IEludGVybmV0IFNlcnZpY2UgWzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDkyIiB0aXRsZT0iJnF1b3Q7UmVjb21tZW5kZWQg U2ltcGxlIFNlY3VyaXR5IENhcGFiaWxpdGllcyBpbiBDdXN0b21lciBQcmVtaXNlcyBFcXVpcG1l bnQgKENQRSkgZm9yIFByb3ZpZGluZyBSZXNpZGVudGlhbCBJUHY2IEludGVybmV0IFNlcnZpY2Um cXVvdDsiPlJGQzYwOTI8L2E+XS4gVGhlcmVmb3JlLA0KIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBpbiBzZWN0aW9uIDYgb2YgdGhhdCBkb2N1bWVudCBhcmUgcmVsZXZhbnQuIEluIHBhcnRp Y3VsYXIsIGl0IGJlYXJzIHJlcGVhdGluZyBoZXJlIHRoYXQgdGhlIHRydWUgaW1wYWN0IG9mIHN0 YXRlZnVsIGZpbHRlcmluZyBtYXkgYmUgYSByZWR1Y3Rpb24gaW4gc2VjdXJpdHksIGFuZCB0aGF0 IElFVEYgbWFrZSBubyBzdGF0ZW1lbnQsIGV4cHJlc3NlZCBvciBpbXBsaWVkLCBhcyB0byB3aGV0 aGVyIHVzaW5nDQogdGhlIGNhcGFiaWxpdGllcyBkZXNjcmliZWQgaW4gYW55IG9mIHRoZXNlIGRv Y3VtZW50cyB1bHRpbWF0ZWx5IGltcHJvdmVzIHNlY3VyaXR5IGZvciBhbnkgaW5kaXZpZHVhbCB1 c2VycyBvciBmb3IgdGhlIEludGVybmV0IGNvbW11bml0eSBhcyBhIHdob2xlLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cC5zLiBJ IGFsc28gc2hhcmUgYWxsIG9mIExvcmVuem8ncyBvdGhlciBzcGVjaWZpYyBjb25jZXJucyBhYm91 dCB0aGlzIGRyYWZ0LCBhcyB3ZWxsIGFzIGhpcyBicm9hZCBnZW5lcmFsIG9iamVjdGlvbnMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmphbWVzIHdvb2R5YXR0ICZsdDs8YSBocmVmPSJtYWlsdG86amh3QG5lc3RsYWJzLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmpod0BuZXN0bGFicy5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5lc3QgTGFicywgQ29tbXVuaWNhdGlvbnMgRW5n aW5lZXJpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933004902567OPEXCLILM23corp_-- From nobody Fri Jan 30 00:20:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42091A8A0F for ; Fri, 30 Jan 2015 00:20:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, 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 fQVD4KMirY7m for ; Fri, 30 Jan 2015 00:20:49 -0800 (PST) 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 9021B1A8A0E for ; Fri, 30 Jan 2015 00:20:48 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DE12122C3F7; Fri, 30 Jan 2015 09:20:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AC25D238055; Fri, 30 Jan 2015 09:20:46 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 09:20:46 +0100 From: To: Brian E Carpenter , Lorenzo Colitti , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW7VoAgACS+oCAANGTUA== Date: Fri, 30 Jan 2015 08:20:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049025A4@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <54CA9A77.3080609@gmail.com> In-Reply-To: <54CA9A77.3080609@gmail.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.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 08:20:53 -0000 SGkgQnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLg0KDQpQbGVhc2Ugc2VlIGlu bGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXC oDogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21d IA0KRW52b3nDqcKgOiBqZXVkaSAyOSBqYW52aWVyIDIwMTUgMjE6MzkNCsOAwqA6IExvcmVuem8g Q29saXR0aTsgRnJlZCBCYWtlciAoZnJlZCkNCkNjwqA6IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxl LWRldmljZS1wcm9maWxlLmFsbEB0b29scy5pZXRmLm9yZzsgVjYgT3BzIExpc3QNCk9iamV0wqA6 IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3Qg Y2FsbA0KDQpUbyBiZSBob25lc3QgSSBzdG9wcGVkIHRyYWNraW5nIHRoaXMgZHJhZnQgYSBsb25n IHRpbWUgYWdvLA0Kc28gZGlkbid0IHNwZWFrIHVwIGR1cmluZyB0aGUgZmlyc3QgV0dMQy4gQnV0 IEkgdGhpbmsgSSdtDQppbiB0aGUgcm91Z2ggd2l0aCBMb3JlbnpvLiBUaGUgZG9jdW1lbnQgcmVh ZHMgbGlrZSBzb21lYm9keSdzDQpwcm9jdXJlbWVudCBzcGVjLCBub3QgbGlrZSBhIHNldCBvZiBy ZWNvbW1lbmRhdGlvbnMgZm9yDQpnZW5lcmljIGludGVyb3BlcmFiaWxpdHkuIEFuZCB0aGUgZGV2 aWwgaXMgaW4gdGhlIGRldGFpbHMuDQpGb3IgZXhhbXBsZSwgSSBub3RpY2VkIGEgcG9pbnQgd2hl cmUgSSBoYXZlIGEgbGl0dGxlIHNraW4NCmluIHRoZSBnYW1lOg0KDQogICBBUFBfUkVDIzM6ICBB cHBsaWNhdGlvbnMgcHJvdmlkZWQgYnkgdGhlIG1vYmlsZSBkZXZpY2UgdmVuZG9yIHRoYXQNCiAg ICAgICAgICAgICAgIHVzZSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXJzIChVUklzKSBtdXN0 IGZvbGxvdw0KICAgICAgICAgICAgICAgW1JGQzM5ODZdLiAgRm9yIGV4YW1wbGUsIFNJUCBhcHBs aWNhdGlvbnMgbXVzdCBmb2xsb3cgdGhlDQogICAgICAgICAgICAgICBjb3JyZWN0aW9uIGRlZmlu ZWQgaW4gW1JGQzU5NTRdLg0KDQpTbywgZG9lcyB0aGF0IHJlcXVpcmVtZW50IGluY2x1ZGUgdGhl IHVwZGF0ZXMgdG8gUkZDIDM5ODYgKGkuZS4gUkZDIDY4NzQNCmFuZCA3MzIwKT8NCg0KW01lZF0g VGhlIG1haW4gZW50cnkgaXMgUkZDMzk4NjsgdXBkYXRlcyB0byB0aGF0IFJGQyBjYW4gYmUgYWRk ZWQuICANCg0KIEFuZCBob3cgaXMgYXBwbHlpbmcgYSBjb3JyZWN0aW9uIHRvIFJGQyAzMjYxIGFu ICJleGFtcGxlIg0Kb2YgZm9sbG93aW5nIFJGQyAzOTg2PyBBbmQgYW55d2F5LCBzaG91bGRuJ3Qg dGhpcyBiZSBpbiBhIFNJUCBwcm9maWxlLA0Kbm90IGhlcmU/DQoNCltNZWRdIFNJUCBpcyBhbiBl eGFtcGxlIG9mIGFwcGxpY2F0aW9uIGZvciB3aGljaCB0aGUgaW5pdGlhbCBzcGVjaWZpY2F0aW9u IGluY2x1ZGVkIGEgYnJva2VuIElQdjYgQUJORiArIGJyb2tlbiBVUkkgY29tcGFyaXNvbiBydWxl cy4gV2UgcHJvdmlkZWQgdGhlIFNJUCBleGFtcGxlIHRvIGlsbHVzdHJhdGUgd2hpY2ggcnVsZXMg bXVzdCBiZSBmb2xsb3dlZC4gIA0KDQoNClRoYXQncyBhbiBpbGx1c3RyYXRpb24gb2Ygd2h5IHRo aXMgZG9jdW1lbnQgcG9zaXRpb25lZCBhcyBhbiBJRVRGIHdvcmsNCnByb2R1Y3QgbWFrZXMgbWUg dW5jb21mb3J0YWJsZS4gSSBpbWFnaW5lIHRoZXJlIGFyZSBtYW55IG90aGVyIHNpbWlsYXINCmhp ZGRlbiBpc3N1ZXMuDQoNCltNZWRdIEl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgdGhvc2Ugd2VyZSBj YWxsZWQgb3V0LCBubz8NCg0KICAgIEJyaWFuDQoNCk9uIDMwLzAxLzIwMTUgMDA6NTMsIExvcmVu em8gQ29saXR0aSB3cm90ZToNCj4gT24gVGh1LCBKYW4gMjksIDIwMTUgYXQgMTo1NyBBTSwgRnJl ZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+PiBkcmFmdC1pZXRm LXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBoYXMgYmVlbiB0aHJvdWdoIFF1aXRlIGEgYml0 IG9mDQo+PiBjaGFuZ2UgaW4gdGhlIElFU0cuIFRoZSBBRHMgd291bGQgbGlrZSB0byBzZWUgdGhl IHdvcmtpbmcgZ3JvdXAgcmVhZCBpdA0KPj4gYWdhaW4gYW5kIGNvbW1lbnQgLSB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCAtIGJlZm9yZSB0aGV5IHByb2NlZWQuDQo+IA0KPiANCj4gT2ssIG9mZiB3 ZSBnbyBhZ2FpbiB0aGVuLg0KPiANCj4gSSBoYXZlIG9iamVjdGVkIHRvIHRoaXMgZG9jdW1lbnQg YWxyZWFkeSwgYW5kIHdhcyBmb3VuZCB0byBiZSBpbiB0aGUgcm91Z2guDQo+IFRoZXJlZm9yZSwg SSBtdXN0IGFzc3VtZSB0aGF0IHJvdWdoIFdHIGNvbnNlbnN1cyBpcyB0aGF0IHdlIG5lZWQgYSBk b2N1bWVudA0KPiB0aGF0IGxvb2tzIHNvbWV0aGluZyBsaWtlIHRoaXMsIGFuZCBJIHdpbGwgYWNj b3JkaW5nbHkgcmVmcmFpbiBmcm9tIG1ha2luZw0KPiBhbnkgZ2VuZXJhbCBzdGF0ZW1lbnRzIG9u IHRoZSBzY29wZSwgdXRpbGl0eSwgYW5kIGdlbmVyYWwgY29udGVudCBvZiB0aGUNCj4gZG9jdW1l bnQsIHdpdGggd2hpY2ggSSBjb250aW51ZSB0byBkaXNhZ3JlZS4NCj4gDQo+IEhvd2V2ZXIsIEkg d291bGQgYmUgcmVtaXNzIGlmIEkgZGlkIG5vdCBhdCBsZWFzdCBkcmF3IGF0dGVudGlvbiB0byB0 aGUNCj4gZm9sbG93aW5nIGZhY3R1YWwgZXJyb3JzIGFuZC9vciBpbmFwcHJvcHJpYXRlIHN0YXRl bWVudHMuDQo+IA0KPiANCj4gMS4gVGhlIHdvcmRpbmcgInJlcXVpcmVkIGZlYXR1cmVzIHRvIGNv bm5lY3QgM0dQUCBtb2JpbGUgZGV2aWNlcyB0byBhbg0KPiBJUHY2LW9ubHkgb3IgZHVhbC1zdGFj ayB3aXJlbGVzcyBuZXR3b3JrIiBpcyBmYWN0dWFsbHkgaW5jb3JyZWN0LiBUaGUgdmFzdA0KPiBt YWpvcml0eSBvZiB0aGVzZSByZWNvbW1lbmRhdGlvbnMgYXJlIG5vdCByZXF1aXJlZCB0byBjb25u ZWN0IHRvIHN1Y2gNCj4gbmV0d29ya3MsIGFuZCBhcmUgbWFueSBhcmUgbm90IGV2ZW4gaW1wbGVt ZW50ZWQgYnkgbWFueSBwb3B1bGFyIG1vYmlsZQ0KPiBvcGVyYXRpbmcgc3lzdGVtcyAtIHdoaWNo IG1hbmFnZSB0byBjb25uZWN0IGp1c3QgZmluZS4gQWZ0ZXIgbG9uZw0KPiBkaXNjdXNzaW9ucywg dGhhdCB0ZXh0IHdhcyByZW1vdmVkIGluIC0wNi4gV2h5IHdhcyBpdCByZWFkZGVkPw0KPiANCj4g DQo+IDIuIFByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkb2N1bWVudCwgaW5jbHVkaW5nIHRoZSB2 ZXJzaW9uIHRoYXQgcGFzc2VkDQo+IElFVEYgbGFzdCBjYWxsLCBjb250YWluZWQgdGhlIHRleHQ6 DQo+IA0KPiAgICBUaGlzIGRvY3VtZW50IGlzIG5vdCBhIHN0YW5kYXJkLCBhbmQgY29uZm9ybWFu Y2Ugd2l0aCBpdCBpcyBub3QNCj4gICAgcmVxdWlyZWQgaW4gb3JkZXIgdG8gY2xhaW0gY29uZm9y bWFuY2Ugd2l0aCBJRVRGIHN0YW5kYXJkcyBmb3IgSVB2Ni4NCj4gICAgVGhlIHN1cHBvcnQgb2Yg dGhlIGZ1bGwgc2V0IG9mIGZlYXR1cmVzIG1heSBub3QgYmUgcmVxdWlyZWQgaW4gc29tZQ0KPiAg ICBkZXBsb3ltZW50IGNvbnRleHRzLiAgVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoZSBzdXBw b3J0IG9mIGENCj4gICAgc3Vic2V0IG9mIHRoZSBmZWF0dXJlcyBpbmNsdWRlZCBpbiB0aGlzIHBy b3RvY29sIG1heSBsZWFkIHRvIGRlZ3JhZGVkDQo+ICAgIGxldmVsIG9mIHNlcnZpY2UgaW4gc29t ZSBkZXBsb3ltZW50IGNvbnRleHRzLg0KPiANCj4gVGhhdCB0ZXh0IHJlbWFpbnMgYWNjdXJhdGUg YW5kIHRoYXQgc3RhdGVtZW50IGlzIHN0aWxsIG5lY2Vzc2FyeS4gV2h5IHdhcw0KPiBpdCByZW1v dmVkPyBJdCBoYXMgYmVlbiBpbiB0aGUgZG9jdW1lbnQgc2luY2UgLTA2LCBhbmQgdGhlIHdvcmRz ICJ0aGlzDQo+IGRvY3VtZW50IGlzIG5vdCBhIHN0YW5kYXJkIiBoYXZlIGJlZW4gaW4gdGhpcyBk b2N1bWVudCBzaW5jZSAtMDEuDQo+IA0KPiANCj4gMy4gSSBvYmplY3QgdG8gdGhlIHN0YXRlbWVu dCAiT25lIG9mIHRoZSBtYWpvciBodXJkbGVzIGVuY291bnRlcmVkIGJ5DQo+IG1vYmlsZSBvcGVy YXRvcnMgaXMgdGhlIGF2YWlsYWJpbGl0eSBvZiBub24tYnJva2VuIElQdjYgaW1wbGVtZW50YXRp b24gaW4NCj4gbW9iaWxlIGRldmljZXMuIiBJIHN1Ym1pdCB0aGF0IGlmIGl0IHdlcmUgdHJ1ZSwg dGhlbiB3ZSB3b3VsZCBvYnNlcnZlIG5vDQo+IElQdjYgZGVwbG95bWVudCBpbiBtb2JpbGUgbmV0 d29ya3MuLi4gYnV0IHB1YmxpY2x5LWF2YWlsYWJsZSBkYXRhIC0gZS5nLiwNCj4gaHR0cDovL3d3 dy53b3JsZGlwdjZsYXVuY2gub3JnL21lYXN1cmVtZW50cy8gLSBzaG93cyB0aGF0IG11bHRpcGxl DQo+IG9wZXJhdG9ycyBoYXZlIGRlcGxveWVkIElQdjYgdG8gdXAgdG8gMzAtNjUlIG9mIHRoZWly IGZvb3RwcmludCwgdXNpbmcgdGhlDQo+IHNhbWUgY29tbWVyY2lhbGx5LWF2YWlsYWJsZSBkZXZp Y2VzIHRoYXQgYXJlIHVzZWQgYnkgY3VzdG9tZXJzIG9mIG90aGVyDQo+IG9wZXJhdG9ycy4gU28g Y2xhaW1pbmcgdGhhdCAiYnJva2VuIElQdjYgaW1wbGVtZW50YXRpb25zIGluIG1vYmlsZSBkZXZp Y2VzIg0KPiBhcmUgYSBtYWpvciBodXJkbGUgaXMgYXQgYmVzdCBpbmNvbXBsZXRlIGFuZCBhdCB3 b3JzdCBpbmNvcnJlY3QuDQo+IA0KPiANCj4gQXQgdGhlIHJpc2sgb2Ygc291bmRpbmcgbGlrZSBh IGJyb2tlbiByZWNvcmQsIEkgYW0gZ29pbmcgeWV0IGFnYWluIHRvIHNheQ0KPiB0aGF0IHRoYXQg b3BlcmF0aW9uYWwgZG9jdW1lbnRzIHNob3VsZCBiZSBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBl cmllbmNlLg0KPiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgb2YgdGhlIGF1dGhvcnMnIGVtcGxveWVy cyBoYXZpbmcgYSBzdWJzdGFudGlhbCBJUHY2DQo+IGRlcGxveW1lbnQgKHRob3VnaCBJIHdvdWxk IGJlIGhhcHB5IHRvIHNlZSBhbnkgZGF0YSB0aGF0IHRoZSBhdXRob3JzIGNvdWxkDQo+IHByb3Zp ZGUgdG8gdGhlIGNvbnRyYXJ5KS4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBJUHY2IGxlYWQgb24g b25lIG9mIHRoZQ0KPiBvcGVyYXRvcnMgdGhhdCAqaGFzKiBkZXBsb3llZCBJUHY2IG5vIGxvbmdl ciBhcHBlYXJzIGluIHRoZSBsaXN0IG9mIGF1dGhvcnMuDQo+IA0KPiANCj4gUmVnYXJkcywNCj4g TG9yZW56bw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCg== From nobody Fri Jan 30 00:27:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0FC1A8A11 for ; Fri, 30 Jan 2015 00:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRJl_KHLxzqt for ; Fri, 30 Jan 2015 00:27:30 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5E31A8A0F for ; Fri, 30 Jan 2015 00:27:29 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id vy18so1945620iec.5 for ; Fri, 30 Jan 2015 00:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hio75A9/mBTWoCX0OKZvGZZnBlaIzXvtxWfkewZoNiA=; b=FgK5sDO1WarTIaUHAdxoltFXWiAKQXTyOzka0qs5P0yFB8omqyKWP6QUhXoJTdCggl DXgMMYEep/jnie2HCmf87Xpsdq9PsLEJKx4phw7F9RsXO2aY6/Fck3oYahXXqrdByp3i Q2v/5vt3TptOsvoVu5sa2Z5U0stdZplnj2ao8QtYTBv2tIqisptqD+a1lsLY0DlMKDwN M+moKgMbDbB8eN5ceubj7Qz0QRpjNw+6I04b+07zkE/BHvLgtmtctCLW5A0m21aI5B3m Vc8piNDcG4fnq4OgsEuo/ZaR9JDpslFhjVHhY4jJXi3abnFeNQsZFakJ29naX4rRbIIG XiJA== 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=Hio75A9/mBTWoCX0OKZvGZZnBlaIzXvtxWfkewZoNiA=; b=Y4vhC6dLJmS5hXBX9x6blVRyDl3Vrnm6ly2BGT7KqYk64Qsv24I7agGqyE8Y8MG8OH tPh00QoCa+9xGC4Y4Hc9Pcj7l44f/HCDzpumsGB5+6tciYM0nDUl2m7b0L75/pWjlG1j /aBS5L+yRETQSz/xQaXlKovOkU/HAiKyVk3crYgS2hy0hfKkFiHxoNmenPb72Sby+L6c PMKykCxc0VesJAIsXxKKFvsUieoXZQHmP8YjqSVjebtNRgH6uqFvlb3LPRZqbej9z0Gn yA4/ZGFdF2z8eLufz1rOrRyLj7juD7yGj7pxQjBCZ4iOmrNz5d1BjxWvl22SADzNFd13 Gigw== X-Gm-Message-State: ALoCoQngQvgLXWWiMyw3r8kStuZi8nUlrAH8XRKg6kq5w4/bE978cYsq4QxCiH97432A+qMRaxzi X-Received: by 10.50.112.98 with SMTP id ip2mr1329491igb.15.1422606448949; Fri, 30 Jan 2015 00:27:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Fri, 30 Jan 2015 00:27:08 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049024FB@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049024FB@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Fri, 30 Jan 2015 17:27:08 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7b4141620ba085050dda606b Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , adrian@olddog.co.uk, V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 08:27:32 -0000 --047d7b4141620ba085050dda606b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 30, 2015 at 4:35 PM, wrote: > 1. The wording "required features to connect 3GPP mobile devices to an > IPv6-only or dual-stack wireless network" is factually incorrect. The > vast majority of these recommendations are not required to connect to suc= h > networks, and are many are not even implemented by many popular mobile > operating systems - which manage to connect just fine. After long > discussions, that text was removed in -06. Why was it readded? > > > > *[Med] *This text was redited as a side effect of implementing the > request from the IESG to position this document as a superset of existing > RFCs. The recommendations are not only about IPv6 but also, as indicated > in the same sentence you quoted, =E2=80=9Cfeatures to deliver IPv4 connec= tivity > service over an IPv6-only transport=E2=80=9D. > But that doesn't change the fact that the statement is incorrect. The vast majority of those features are not "required to connect". As for the feature required to deliver IPv4 connectivity service over IPv6-only transport, only one feature (out of the dozes in this draft) is required for that - 464xlat. If you want to turn this into a document of features that are required to connect, I support that... but that would mean that the majority of recommendations should be removed, because they're not required. Also - this document passed WG and IETF last call with the understanding that it explicitly did *not* define an IETF-approved device profile, but only a profile "that a number of operators recommend". That text was in the document as recently as -14, but it was removed. Making this documean IETF-approved device profile is a substantial change and has much broader implications than what the WG and IETF had consensus on. Adding that text was essential to overcome the objections of those in the WG that felt that it is not the place of an operational WG, or indeed of the IETF, to place the RFC seal of approval on a device profile document (or, as Brian puts it, "on somebody's procurement spec"). That text should be restored. > 2. Previous versions of the document, including the version that passed > IETF last call, contained the text: > > > > This document is not a standard, and conformance with it is not > > required in order to claim conformance with IETF standards for IPv6. > > The support of the full set of features may not be required in some > > deployment contexts. The authors believe that the support of a > > subset of the features included in this protocol may lead to degraded > > level of service in some deployment contexts. > > > > That text remains accurate and that statement is still necessary. Why was > it removed? It has been in the document since -06, and the words "this > document is not a standard" have been in this document since -01. > > > > [Med] It was removed as per a request from the IESG (A. Farrel). > Adrian, why did you request that this text be removed? The text that passed last call went out of its way to state it was not a standard, and that compliance with it was not required. This text helped defuse substantial objections within the WG and the IETF that pointed out that only a fraction of these features are actually necessary to deploy, and called attention to the harm to IPv6 deployment that would occur if mobile operators and device manufacturers believed that all these features needed to be implemented before deployment could occur. > 3. I object to the statement "One of the major hurdles encountered by > mobile operators is the availability of non-broken IPv6 implementation in > mobile devices." I submit that if it were true, then we would observe no > IPv6 deployment in mobile networks... but publicly-available data - e.g., > http://www.worldipv6launch.org/measurements/ - shows that multiple > operators have deployed IPv6 to up to 30-65% of their footprint, using th= e > same commercially-available devices that are used by customers of other > operators. So claiming that "broken IPv6 implementations in mobile device= s" > are a major hurdle is at best incomplete and at worst incorrect. > > > > [Med] That sentence was there since we edited the individual version of > the document. Of course, current implementations perform better that when > we edited the -00 of the document. Still, the feedback we had from our > device team is that there are still a lot to be done. > But you see, the problem with that is that it's just the opinion of your device team. For example, if instead you asked the device teams of Verizon Wireless and T-Mobile, they might well say that the features that are necessary to deploy IPv6 are already supported just fine (with the possible exception of 464xlat on iOS) - and that's why they deployed IPv6 to 30-65% of their devices. The IETF should not document matters of opinion. It should make technical statements that are supported by evidence. The available evidence does not support the statement that "IPv6 deployment is blocked because mobile device implementations are broken"; in fact, the existence of large mobile deployments proves that statement wrong. > I am not aware of any of the authors' employers having a substantial > IPv6 deployment (though I would be happy to see any data that the authors > could provide to the contrary). On the other hand, the IPv6 lead on one o= f > the operators that *has* deployed IPv6 no longer appears in the list of > authors. > > [Med] I can give you the example of Orange in Poland, for one. > http://www.worldipv6launch.org/measurements/ says 1.81% , yes. What about the others? > You can also check the Orange Groud Device requirements (IPv6 Chapter): > https://www.ogdr-online.com/ogdr/index.php/component/extendedreg/login. I > hope we can focus on technical comment rather than diverting. Thanks. > The problem with that is that there is very little technical content in this document. Most of the document is just a laundry list of desired features. Regards, Lorenzo --047d7b4141620ba085050dda606b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 30, 2015 at 4:35 PM, <mohamed.boucadair@orange.com= > wrote:

1. The wording "required f= eatures to connect 3GPP mobile devices to an IPv6-only or dual-stack wirele= ss network" is factually incorrect. The vast majority of these recommendations are not required to conne= ct to such networks, and are many are not even implemented by many popular = mobile operating systems - which manage to connect just fine. After long di= scussions, that text was removed in -06. Why was it readded?

=C2=A0

[Me= d] This text was = redited as a side effect of implementing the request from the IESG to posit= ion this document as a superset of existing RFCs.=C2=A0 The recommendations are not only about IPv6 but also, as indic= ated in the same sentence you quoted, =E2=80=9C= features to deliver IPv4 connectivity service over an IPv6-only transport=E2=80=9D.<= /p>


But that doesn't change the fact that the statem= ent is incorrect. The vast majority of those features are not "require= d to connect". As for the feature required to deliver IPv4 connectivit= y service over IPv6-only transport, only one feature (out of the dozes in t= his draft) is required for that -=C2=A0464xlat.

If you want to turn this int= o a document of features that are required to connect, I support that... bu= t that would mean that the majority of recommendations should be removed, b= ecause they're not required.


A= lso - this document passed WG and IETF last call with the understanding tha= t it explicitly did *not* define an IETF-approved device profile, but only = a profile "that a number of operators recommend". That text was i= n the document as recently as -14, but it was removed.

Mak= ing this documean IETF-approved device profile is a substantial change and = has much broader implications than what the WG and IETF had consensus on. A= dding that text was essential to overcome the objections of those in the WG= that felt that it is not the place of an operational WG, or indeed of the = IETF, to place the RFC seal of approval on a device profile document (or, a= s Brian puts it, "on somebody's procurement spec").
=

That text should be restored.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
<= div>

=

2. Previous versions of t= he document, including the version that passed IETF last call, contained th= e text:

=C2=A0

=C2=A0 =C2=A0This document is <= /span>not a standard, and conformance with it is not

=C2=A0 =C2=A0required in order to claim conformance = with IETF standards for IPv6.

=C2=A0 =C2=A0The support of the full set of features= may not be required in some

=C2=A0 =C2=A0deployment contexts.=C2=A0 The authors = believe that the support of a

=C2=A0 =C2=A0subset of the features included in this= protocol may lead to degraded

=C2=A0 =C2=A0level of service in some deployment con= texts.

=C2=A0

That text remains accurate and that statement is sti= ll necessary. Why was it removed? It has been in the document since -06, an= d the words "this document is not a standard" have been in this d= ocument since -01.

=C2=A0

[Med] It was removed as per = a request from the IESG (A. Farrel).


Adrian, why did you request that t= his text be removed?

The text that passed las= t call went out of its way to state it was not a standard, and that complia= nce with it was not required.=C2=A0 This text helped defuse substantial obj= ections within the WG and the IETF that pointed out that only a fraction of= these features are actually necessary to deploy, and called attention to t= he harm to IPv6 deployment that would occur if mobile operators and device = manufacturers believed that all these features needed to be implemented bef= ore deployment could occur.
=C2=A0

3. I object to the statement "One of the major = hurdles encountered by mobile operators is the availability of non-broken I= Pv6 implementation in mobile devices." I submit that if it were true, = then we would observe no IPv6 deployment in mobile networks... but publicly-available data - e.g., http://www.worldipv6launch.org/measurements/ - shows that multiple oper= ators have deployed IPv6 to up to 30-65% of their footprint, using the same= commercially-available devices that are used by customers of other operato= rs. So claiming that "broken IPv6 implementations in mobile devices" are a major hurdle is at best inco= mplete and at worst incorrect.

=C2=A0

[Med] That sentence was ther= e since we edited the individual version of the document. Of course, curren= t implementations perform better that when we edited the -00 of the document. Still, the feedback we had from our device team i= s that there are still a lot to be done.

=

But you see, the problem with = that is that it's just the opinion of your device team. For example, if= instead you asked the device teams of Verizon Wireless and T-Mobile, they = might well say that the features that are necessary to deploy IPv6 are alre= ady supported just fine (with the possible exception of 464xlat on iOS) - a= nd that's why they deployed IPv6 to 30-65% of their devices.
=
The IETF should not document matters of opinion. It should m= ake technical statements that are supported by evidence. The available evid= ence does not support the statement that "IPv6 deployment is blocked b= ecause mobile device implementations are broken"; in fact, the existen= ce of large mobile deployments proves that statement wrong.
=C2= =A0

I am not aware of any of the authors' employers = having a substantial IPv6 deployment (though I would be happy to see any data that the authors = could provide to the contrary). On the other hand, the IPv6 lead on one of = the operators that *has* deployed IPv6 no longer appears in the list of aut= hors.=C2=A0

[Med] I can give= you the example of Orange in Poland, for one.

http:/= /www.worldipv6launch.org/measurements/ says 1.81% , yes. What about the= others?

You can also check the= Orange Groud Device requirements (IPv6 Chapter): https://www.ogdr-onli= ne.com/ogdr/index.php/component/extendedreg/login. I hope we can focus on technical comment rather than diverting. Thanks.

The problem with that is that there is very little technical = content in this document. Most of the document is just a laundry list of de= sired features.

Regards,
Lorenzo
--047d7b4141620ba085050dda606b-- From nobody Fri Jan 30 01:12:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8F01A8A3E for ; Fri, 30 Jan 2015 01:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIY3fgVsKG5q for ; Fri, 30 Jan 2015 01:12:19 -0800 (PST) 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 C7A951A8A6D for ; Fri, 30 Jan 2015 01:12:18 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 158CB22C15B; Fri, 30 Jan 2015 10:12:17 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E29EB27C07C; Fri, 30 Jan 2015 10:12:16 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 10:12:16 +0100 From: To: Gert Doering , Ole Troan Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgACFfYCAAOoGUA== Date: Fri, 30 Jan 2015 09:12:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> In-Reply-To: <20150129201251.GD34798@Space.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.1] 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.12.16.73920 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 09:12:21 -0000 Dear Gert, Can you please help us identifying technical flaws that you think need to b= e fixed in the document? Thank you. Cheers, Med -----Message d'origine----- De=A0: Gert Doering [mailto:gert@space.net]=20 Envoy=E9=A0: jeudi 29 janvier 2015 21:13 =C0=A0: Ole Troan Cc=A0: Fred Baker (fred); draft-ietf-v6ops-mobile-device-profile.all@tools.= ietf.org; V6 Ops List Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Hi, On Thu, Jan 29, 2015 at 01:15:04PM +0100, Ole Troan wrote: > +1 to Lorenzo's comments. Another +1 - I can't see this reflecting WG consensus, more "everybody besides Lorenzo has given up". 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 From nobody Fri Jan 30 01:39:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFF61A8A82 for ; Fri, 30 Jan 2015 01:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj2ggLog3s3v for ; Fri, 30 Jan 2015 01:39:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199001A8A79 for ; Fri, 30 Jan 2015 01:39:36 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 4F25B1B834F; Fri, 30 Jan 2015 10:39:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E385D3840B3; Fri, 30 Jan 2015 10:39:33 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 10:39:33 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQPGaXse6f3Vmd8kuuI7VBYw52SZzYYoBg Date: Fri, 30 Jan 2015 09:39:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049026BC@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049024FB@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049026BCOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.30.70618 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , "adrian@olddog.co.uk" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 09:39:39 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049026BCOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IHZlbmRyZWRp IDMwIGphbnZpZXIgMjAxNSAwOToyNw0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpD YyA6IEZyZWQgQmFrZXIgKGZyZWQpOyBWNiBPcHMgTGlzdDsgZHJhZnQtaWV0Zi12Nm9wcy1tb2Jp bGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnOyBhZHJpYW5Ab2xkZG9nLmNvLnVr OyBqb2VsIGphZWdnbGkNCk9iamV0IDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2Jp bGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsDQoNCk9uIEZyaSwgSmFuIDMwLCAyMDE1IGF0IDQ6 MzUgUE0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQoxLiBUaGUgd29yZGluZyAicmVxdWlyZWQgZmVhdHVy ZXMgdG8gY29ubmVjdCAzR1BQIG1vYmlsZSBkZXZpY2VzIHRvIGFuIElQdjYtb25seSBvciBkdWFs LXN0YWNrIHdpcmVsZXNzIG5ldHdvcmsiIGlzIGZhY3R1YWxseSBpbmNvcnJlY3QuIFRoZSB2YXN0 IG1ham9yaXR5IG9mIHRoZXNlIHJlY29tbWVuZGF0aW9ucyBhcmUgbm90IHJlcXVpcmVkIHRvIGNv bm5lY3QgdG8gc3VjaCBuZXR3b3JrcywgYW5kIGFyZSBtYW55IGFyZSBub3QgZXZlbiBpbXBsZW1l bnRlZCBieSBtYW55IHBvcHVsYXIgbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zIC0gd2hpY2ggbWFu YWdlIHRvIGNvbm5lY3QganVzdCBmaW5lLiBBZnRlciBsb25nIGRpc2N1c3Npb25zLCB0aGF0IHRl eHQgd2FzIHJlbW92ZWQgaW4gLTA2LiBXaHkgd2FzIGl0IHJlYWRkZWQ/DQoNCltNZWRdIFRoaXMg dGV4dCB3YXMgcmVkaXRlZCBhcyBhIHNpZGUgZWZmZWN0IG9mIGltcGxlbWVudGluZyB0aGUgcmVx dWVzdCBmcm9tIHRoZSBJRVNHIHRvIHBvc2l0aW9uIHRoaXMgZG9jdW1lbnQgYXMgYSBzdXBlcnNl dCBvZiBleGlzdGluZyBSRkNzLiAgVGhlIHJlY29tbWVuZGF0aW9ucyBhcmUgbm90IG9ubHkgYWJv dXQgSVB2NiBidXQgYWxzbywgYXMgaW5kaWNhdGVkIGluIHRoZSBzYW1lIHNlbnRlbmNlIHlvdSBx dW90ZWQsIOKAnGZlYXR1cmVzIHRvIGRlbGl2ZXIgSVB2NCBjb25uZWN0aXZpdHkgc2VydmljZSBv dmVyIGFuIElQdjYtb25seSB0cmFuc3BvcnTigJ0uDQoNCg0KQnV0IHRoYXQgZG9lc24ndCBjaGFu Z2UgdGhlIGZhY3QgdGhhdCB0aGUgc3RhdGVtZW50IGlzIGluY29ycmVjdC4gVGhlIHZhc3QgbWFq b3JpdHkgb2YgdGhvc2UgZmVhdHVyZXMgYXJlIG5vdCAicmVxdWlyZWQgdG8gY29ubmVjdCIuIEFz IGZvciB0aGUgZmVhdHVyZSByZXF1aXJlZCB0byBkZWxpdmVyIElQdjQgY29ubmVjdGl2aXR5IHNl cnZpY2Ugb3ZlciBJUHY2LW9ubHkgdHJhbnNwb3J0LCBvbmx5IG9uZSBmZWF0dXJlIChvdXQgb2Yg dGhlIGRvemVzIGluIHRoaXMgZHJhZnQpIGlzIHJlcXVpcmVkIGZvciB0aGF0IC0gNDY0eGxhdC4N Cg0KSWYgeW91IHdhbnQgdG8gdHVybiB0aGlzIGludG8gYSBkb2N1bWVudCBvZiBmZWF0dXJlcyB0 aGF0IGFyZSByZXF1aXJlZCB0byBjb25uZWN0LCBJIHN1cHBvcnQgdGhhdC4uLiBidXQgdGhhdCB3 b3VsZCBtZWFuIHRoYXQgdGhlIG1ham9yaXR5IG9mIHJlY29tbWVuZGF0aW9ucyBzaG91bGQgYmUg cmVtb3ZlZCwgYmVjYXVzZSB0aGV5J3JlIG5vdCByZXF1aXJlZC4NCg0KW01lZF0gV2UgYWxyZWFk eSBkaXNjdXNzZWQgdGhpcyBwb2ludCBzZXZlcmFsIHRpbWVzLiBObyBuZWVkIHRvIHJlcGVhdCB0 aGlzIGRpc2N1c3Npb24gb25jZSBhZ2Fpbi4NCg0KQWxzbyAtIHRoaXMgZG9jdW1lbnQgcGFzc2Vk IFdHIGFuZCBJRVRGIGxhc3QgY2FsbCB3aXRoIHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgaXQgZXhw bGljaXRseSBkaWQgKm5vdCogZGVmaW5lIGFuIElFVEYtYXBwcm92ZWQgZGV2aWNlIHByb2ZpbGUs IGJ1dCBvbmx5IGEgcHJvZmlsZSAidGhhdCBhIG51bWJlciBvZiBvcGVyYXRvcnMgcmVjb21tZW5k Ii4gVGhhdCB0ZXh0IHdhcyBpbiB0aGUgZG9jdW1lbnQgYXMgcmVjZW50bHkgYXMgLTE0LCBidXQg aXQgd2FzIHJlbW92ZWQuDQoNCk1ha2luZyB0aGlzIGRvY3VtZWFuIElFVEYtYXBwcm92ZWQgZGV2 aWNlIHByb2ZpbGUgaXMgYSBzdWJzdGFudGlhbCBjaGFuZ2UgYW5kIGhhcyBtdWNoIGJyb2FkZXIg aW1wbGljYXRpb25zIHRoYW4gd2hhdCB0aGUgV0cgYW5kIElFVEYgaGFkIGNvbnNlbnN1cyBvbi4g QWRkaW5nIHRoYXQgdGV4dCB3YXMgZXNzZW50aWFsIHRvIG92ZXJjb21lIHRoZSBvYmplY3Rpb25z IG9mIHRob3NlIGluIHRoZSBXRyB0aGF0IGZlbHQgdGhhdCBpdCBpcyBub3QgdGhlIHBsYWNlIG9m IGFuIG9wZXJhdGlvbmFsIFdHLCBvciBpbmRlZWQgb2YgdGhlIElFVEYsIHRvIHBsYWNlIHRoZSBS RkMgc2VhbCBvZiBhcHByb3ZhbCBvbiBhIGRldmljZSBwcm9maWxlIGRvY3VtZW50IChvciwgYXMg QnJpYW4gcHV0cyBpdCwgIm9uIHNvbWVib2R5J3MgcHJvY3VyZW1lbnQgc3BlYyIpLg0KDQpUaGF0 IHRleHQgc2hvdWxkIGJlIHJlc3RvcmVkLg0KDQpbTWVkXSBZb3VyIHBvaW50IGFib3V0IHRoZSBw cm9jZXNzIGlzIGZhaXIuIEkgaGF2ZSBubyBwcm9ibGVtIHRvIHJlc3RvcmUgdGhhdCB0ZXh0IGlm IHRoaXMgaXMgd2hhdCB0aGUgV0cgd2FudHMuIFRoaXMgaXMgcmVhbGx5IHRoZSBraW5kIGZvIGZl ZWRiYWNrIEnigJltIGxvb2tpbmcgZm9yLiAgVW5sZXNzIEkgaGVhcmQgYW55IG9iamVjdGlvbiBm cm9tIHRoZSBXRywgdGhhdCB0ZXh0IHdpbGwgYmUgcmVzdG9yZWQuDQoNCg0KMi4gUHJldmlvdXMg dmVyc2lvbnMgb2YgdGhlIGRvY3VtZW50LCBpbmNsdWRpbmcgdGhlIHZlcnNpb24gdGhhdCBwYXNz ZWQgSUVURiBsYXN0IGNhbGwsIGNvbnRhaW5lZCB0aGUgdGV4dDoNCg0KICAgVGhpcyBkb2N1bWVu dCBpcyBub3QgYSBzdGFuZGFyZCwgYW5kIGNvbmZvcm1hbmNlIHdpdGggaXQgaXMgbm90DQogICBy ZXF1aXJlZCBpbiBvcmRlciB0byBjbGFpbSBjb25mb3JtYW5jZSB3aXRoIElFVEYgc3RhbmRhcmRz IGZvciBJUHY2Lg0KICAgVGhlIHN1cHBvcnQgb2YgdGhlIGZ1bGwgc2V0IG9mIGZlYXR1cmVzIG1h eSBub3QgYmUgcmVxdWlyZWQgaW4gc29tZQ0KICAgZGVwbG95bWVudCBjb250ZXh0cy4gIFRoZSBh dXRob3JzIGJlbGlldmUgdGhhdCB0aGUgc3VwcG9ydCBvZiBhDQogICBzdWJzZXQgb2YgdGhlIGZl YXR1cmVzIGluY2x1ZGVkIGluIHRoaXMgcHJvdG9jb2wgbWF5IGxlYWQgdG8gZGVncmFkZWQNCiAg IGxldmVsIG9mIHNlcnZpY2UgaW4gc29tZSBkZXBsb3ltZW50IGNvbnRleHRzLg0KDQpUaGF0IHRl eHQgcmVtYWlucyBhY2N1cmF0ZSBhbmQgdGhhdCBzdGF0ZW1lbnQgaXMgc3RpbGwgbmVjZXNzYXJ5 LiBXaHkgd2FzIGl0IHJlbW92ZWQ/IEl0IGhhcyBiZWVuIGluIHRoZSBkb2N1bWVudCBzaW5jZSAt MDYsIGFuZCB0aGUgd29yZHMgInRoaXMgZG9jdW1lbnQgaXMgbm90IGEgc3RhbmRhcmQiIGhhdmUg YmVlbiBpbiB0aGlzIGRvY3VtZW50IHNpbmNlIC0wMS4NCg0KW01lZF0gSXQgd2FzIHJlbW92ZWQg YXMgcGVyIGEgcmVxdWVzdCBmcm9tIHRoZSBJRVNHIChBLiBGYXJyZWwpLg0KDQpBZHJpYW4sIHdo eSBkaWQgeW91IHJlcXVlc3QgdGhhdCB0aGlzIHRleHQgYmUgcmVtb3ZlZD8NCg0KVGhlIHRleHQg dGhhdCBwYXNzZWQgbGFzdCBjYWxsIHdlbnQgb3V0IG9mIGl0cyB3YXkgdG8gc3RhdGUgaXQgd2Fz IG5vdCBhIHN0YW5kYXJkLCBhbmQgdGhhdCBjb21wbGlhbmNlIHdpdGggaXQgd2FzIG5vdCByZXF1 aXJlZC4gIFRoaXMgdGV4dCBoZWxwZWQgZGVmdXNlIHN1YnN0YW50aWFsIG9iamVjdGlvbnMgd2l0 aGluIHRoZSBXRyBhbmQgdGhlIElFVEYgdGhhdCBwb2ludGVkIG91dCB0aGF0IG9ubHkgYSBmcmFj dGlvbiBvZiB0aGVzZSBmZWF0dXJlcyBhcmUgYWN0dWFsbHkgbmVjZXNzYXJ5IHRvIGRlcGxveSwg YW5kIGNhbGxlZCBhdHRlbnRpb24gdG8gdGhlIGhhcm0gdG8gSVB2NiBkZXBsb3ltZW50IHRoYXQg d291bGQgb2NjdXIgaWYgbW9iaWxlIG9wZXJhdG9ycyBhbmQgZGV2aWNlIG1hbnVmYWN0dXJlcnMg YmVsaWV2ZWQgdGhhdCBhbGwgdGhlc2UgZmVhdHVyZXMgbmVlZGVkIHRvIGJlIGltcGxlbWVudGVk IGJlZm9yZSBkZXBsb3ltZW50IGNvdWxkIG9jY3VyLg0KDQpbTWVkXSBMb3JlbnpvLCB0aGUgZG9j dW1lbnQgZG9lcyBub3Qgc3RhdGVzIEFMTCBmZWF0dXJlcyBNVVNUIGJlIGltcGxlbWVudGVkLiBK dXN0IGxpa2UgYW55IG90aGVyIHJlY29tbWVuZGF0aW9uIGRvY3VtZW50LCB0aGVyZSBhcmUgc2V2 ZXJhbCBzdXBwb3J0IGxldmVscy4gQXMgZmFyIGFzIEnigJltIGNvbmNlcm5lZCwgSSBoYXZlIG5v IG9iamVjdGlvbiB0byBpbmNsdWRlIHRoYXQgdGV4dCBpZiB0aGUgSUVTRyBpcyBPSyB3aXRoIGl0 Lg0KDQozLiBJIG9iamVjdCB0byB0aGUgc3RhdGVtZW50ICJPbmUgb2YgdGhlIG1ham9yIGh1cmRs ZXMgZW5jb3VudGVyZWQgYnkgbW9iaWxlIG9wZXJhdG9ycyBpcyB0aGUgYXZhaWxhYmlsaXR5IG9m IG5vbi1icm9rZW4gSVB2NiBpbXBsZW1lbnRhdGlvbiBpbiBtb2JpbGUgZGV2aWNlcy4iIEkgc3Vi bWl0IHRoYXQgaWYgaXQgd2VyZSB0cnVlLCB0aGVuIHdlIHdvdWxkIG9ic2VydmUgbm8gSVB2NiBk ZXBsb3ltZW50IGluIG1vYmlsZSBuZXR3b3Jrcy4uLiBidXQgcHVibGljbHktYXZhaWxhYmxlIGRh dGEgLSBlLmcuLCBodHRwOi8vd3d3LndvcmxkaXB2NmxhdW5jaC5vcmcvbWVhc3VyZW1lbnRzLyAt IHNob3dzIHRoYXQgbXVsdGlwbGUgb3BlcmF0b3JzIGhhdmUgZGVwbG95ZWQgSVB2NiB0byB1cCB0 byAzMC02NSUgb2YgdGhlaXIgZm9vdHByaW50LCB1c2luZyB0aGUgc2FtZSBjb21tZXJjaWFsbHkt YXZhaWxhYmxlIGRldmljZXMgdGhhdCBhcmUgdXNlZCBieSBjdXN0b21lcnMgb2Ygb3RoZXIgb3Bl cmF0b3JzLiBTbyBjbGFpbWluZyB0aGF0ICJicm9rZW4gSVB2NiBpbXBsZW1lbnRhdGlvbnMgaW4g bW9iaWxlIGRldmljZXMiIGFyZSBhIG1ham9yIGh1cmRsZSBpcyBhdCBiZXN0IGluY29tcGxldGUg YW5kIGF0IHdvcnN0IGluY29ycmVjdC4NCg0KW01lZF0gVGhhdCBzZW50ZW5jZSB3YXMgdGhlcmUg c2luY2Ugd2UgZWRpdGVkIHRoZSBpbmRpdmlkdWFsIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LiBP ZiBjb3Vyc2UsIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIHBlcmZvcm0gYmV0dGVyIHRoYXQgd2hl biB3ZSBlZGl0ZWQgdGhlIC0wMCBvZiB0aGUgZG9jdW1lbnQuIFN0aWxsLCB0aGUgZmVlZGJhY2sg d2UgaGFkIGZyb20gb3VyIGRldmljZSB0ZWFtIGlzIHRoYXQgdGhlcmUgYXJlIHN0aWxsIGEgbG90 IHRvIGJlIGRvbmUuDQoNCkJ1dCB5b3Ugc2VlLCB0aGUgcHJvYmxlbSB3aXRoIHRoYXQgaXMgdGhh dCBpdCdzIGp1c3QgdGhlIG9waW5pb24gb2YgeW91ciBkZXZpY2UgdGVhbS4gRm9yIGV4YW1wbGUs IGlmIGluc3RlYWQgeW91IGFza2VkIHRoZSBkZXZpY2UgdGVhbXMgb2YgVmVyaXpvbiBXaXJlbGVz cyBhbmQgVC1Nb2JpbGUsIHRoZXkgbWlnaHQgd2VsbCBzYXkgdGhhdCB0aGUgZmVhdHVyZXMgdGhh dCBhcmUgbmVjZXNzYXJ5IHRvIGRlcGxveSBJUHY2IGFyZSBhbHJlYWR5IHN1cHBvcnRlZCBqdXN0 IGZpbmUgKHdpdGggdGhlIHBvc3NpYmxlIGV4Y2VwdGlvbiBvZiA0NjR4bGF0IG9uIGlPUykgLSBh bmQgdGhhdCdzIHdoeSB0aGV5IGRlcGxveWVkIElQdjYgdG8gMzAtNjUlIG9mIHRoZWlyIGRldmlj ZXMuDQpbTWVkXSBUaGlzIGlzIFVTLWNlbnRyaWMsIGJ1dCBhbnl3YXkgeW91IGFscmVhZHkgcmFp c2VkIHRoaXMgcG9pbnQgc2V2ZXJhbCB0aW1lczogc29tZSBhbnN3ZXJzIGFyZSBwcm92aWRlZCBo ZXJlIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9t c2cxNDc2OS5odG1sIG9yIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZv cHMvY3VycmVudC9tc2cyMDA4Ni5odG1sLiBJIGNhbiBhZGQgdGhhdCBpbiB0aGUgRXVyb3BlIGZv ciBpbnN0YW5jZSwgb3BlcmF0b3JzIGRvIG5vdCBjb250cm9sIHRoZSBkZXZpY2UgdXNlZCBieSAg dGhlIGN1c3RvbWVyLCBoZW5jZSB0aGUgbmVlZCB0byBoYXZlIGEgcHJvZmlsZS4NCg0KVGhlIElF VEYgc2hvdWxkIG5vdCBkb2N1bWVudCBtYXR0ZXJzIG9mIG9waW5pb24uDQpbTWVkXSBBZ3JlZS4N Cg0KSXQgc2hvdWxkIG1ha2UgdGVjaG5pY2FsIHN0YXRlbWVudHMgdGhhdCBhcmUgc3VwcG9ydGVk IGJ5IGV2aWRlbmNlLg0KW01lZF0gSVNPQyBvcmdhbml6ZWQgc2V2ZXJhbCBJUHY2IG1vYmlsZSB3 b3Jrc2hvcHMgdGhhdCByZXZlYWxlZCB0aGF0IG9wZXJhdG9ycyBwYXJ0aWNpcGF0ZWQgYSB0aG9z ZSB3b3Jrc2hvcCBhZ3JlZSBkZXZpY2VzIGFyZSBhIGh1cmRsZSBmb3IgdGhlaXIgSVB2NiBkZXBs b3ltZW50cy4gSSBkb27igJl0IGhhdmUgcHVibGljIHBvaW50ZXJzIGZvciB0aGUgcHJleiBtYWQg ZHVyaW5nIHRoZSB3b3Jrc2hvcCBidXQgeW91IGNhbiBnZXQgaW4gdG91Y2ggd2l0aCBJU09DIGlm IHlvdSBuZWVkIHNvLg0KDQpUaGUgYXZhaWxhYmxlIGV2aWRlbmNlIGRvZXMgbm90IHN1cHBvcnQg dGhlIHN0YXRlbWVudCB0aGF0ICJJUHY2IGRlcGxveW1lbnQgaXMgYmxvY2tlZCBiZWNhdXNlIG1v YmlsZSBkZXZpY2UgaW1wbGVtZW50YXRpb25zIGFyZSBicm9rZW4iOyBpbiBmYWN0LCB0aGUgZXhp c3RlbmNlIG9mIGxhcmdlIG1vYmlsZSBkZXBsb3ltZW50cyBwcm92ZXMgdGhhdCBzdGF0ZW1lbnQg d3JvbmcuDQpbTWVkXSBOb3Qgc3VyZSB0byB1bmRlcnN0YW5kIHRoZSBjYXVzYWxpdHkgZWZmZWN0 IGhlcmUuDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B9330049026BCOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5SZS0sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g TG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+RW52 b3nDqSZuYnNwOzo8L2I+IHZlbmRyZWRpIDMwIGphbnZpZXIgMjAxNSAwOToyNzxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7Ojwv Yj4gRnJlZCBCYWtlciAoZnJlZCk7IFY2IE9wcyBMaXN0OyBkcmFmdC1pZXRmLXY2b3BzLW1vYmls ZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IGFkcmlhbkBvbGRkb2cuY28udWs7 IGpvZWwgamFlZ2dsaTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQt aWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAzMCwgMjAx NSBhdCA0OjM1IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjEuIFRoZSB3b3JkaW5nICZxdW90O3JlcXVpcmVkIGZl YXR1cmVzIHRvIGNvbm5lY3QgM0dQUCBtb2JpbGUgZGV2aWNlcyB0byBhbiBJUHY2LW9ubHkgb3Ig ZHVhbC1zdGFjayB3aXJlbGVzcyBuZXR3b3JrJnF1b3Q7IGlzIGZhY3R1YWxseSBpbmNvcnJlY3Qu DQo8L3NwYW4+VGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlc2UgcmVjb21tZW5kYXRpb25zIGFyZSBu b3QgcmVxdWlyZWQgdG8gY29ubmVjdCB0byBzdWNoIG5ldHdvcmtzLCBhbmQgYXJlIG1hbnkgYXJl IG5vdCBldmVuIGltcGxlbWVudGVkIGJ5IG1hbnkgcG9wdWxhciBtb2JpbGUgb3BlcmF0aW5nIHN5 c3RlbXMgLSB3aGljaCBtYW5hZ2UgdG8gY29ubmVjdCBqdXN0IGZpbmUuIEFmdGVyIGxvbmcgZGlz Y3Vzc2lvbnMsIHRoYXQgdGV4dCB3YXMgcmVtb3ZlZA0KIGluIC0wNi4gV2h5IHdhcyBpdCByZWFk ZGVkPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+W01l ZF0NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PlRoaXMgdGV4dCB3YXMgcmVkaXRlZCBhcyBhIHNpZGUgZWZmZWN0IG9mIGltcGxlbWVudGluZyB0 aGUgcmVxdWVzdCBmcm9tIHRoZSBJRVNHIHRvIHBvc2l0aW9uIHRoaXMgZG9jdW1lbnQgYXMgYSBz dXBlcnNldCBvZiBleGlzdGluZyBSRkNzLiZuYnNwOyBUaGUgcmVjb21tZW5kYXRpb25zIGFyZSBu b3Qgb25seSBhYm91dCBJUHY2IGJ1dCBhbHNvLCBhcyBpbmRpY2F0ZWQNCiBpbiB0aGUgc2FtZSBz ZW50ZW5jZSB5b3UgcXVvdGVkLCDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPmZlYXR1cmVz IHRvIGRlbGl2ZXIgSVB2NCBjb25uZWN0aXZpdHkgc2VydmljZSBvdmVyIGFuIElQdjYtb25seSB0 cmFuc3BvcnQ8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuKAnS48L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJ1dCB0aGF0IGRvZXNuJ3QgY2hhbmdlIHRoZSBmYWN0IHRoYXQgdGhlIHN0YXRl bWVudCBpcyBpbmNvcnJlY3QuIFRoZSB2YXN0IG1ham9yaXR5IG9mIHRob3NlIGZlYXR1cmVzIGFy ZSBub3QgJnF1b3Q7cmVxdWlyZWQgdG8gY29ubmVjdCZxdW90Oy4gQXMgZm9yIHRoZSBmZWF0dXJl IHJlcXVpcmVkIHRvIGRlbGl2ZXIgSVB2NCBjb25uZWN0aXZpdHkgc2VydmljZSBvdmVyIElQdjYt b25seSB0cmFuc3BvcnQsIG9ubHkgb25lIGZlYXR1cmUNCiAob3V0IG9mIHRoZSBkb3plcyBpbiB0 aGlzIGRyYWZ0KSBpcyByZXF1aXJlZCBmb3IgdGhhdCAtJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIy MjIyMjtiYWNrZ3JvdW5kOndoaXRlIj40NjR4bGF0PC9zcGFuPi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IHdhbnQgdG8gdHVybiB0 aGlzIGludG8gYSBkb2N1bWVudCBvZiBmZWF0dXJlcyB0aGF0IGFyZSByZXF1aXJlZCB0byBjb25u ZWN0LCBJIHN1cHBvcnQgdGhhdC4uLiBidXQgdGhhdCB3b3VsZCBtZWFuIHRoYXQgdGhlIG1ham9y aXR5IG9mIHJlY29tbWVuZGF0aW9ucyBzaG91bGQgYmUgcmVtb3ZlZCwgYmVjYXVzZSB0aGV5J3Jl IG5vdCByZXF1aXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBXZSBhbHJlYWR5IGRpc2N1c3NlZCB0aGlzIHBvaW50IHNl dmVyYWwgdGltZXMuIE5vIG5lZWQgdG8gcmVwZWF0IHRoaXMgZGlzY3Vzc2lvbiBvbmNlIGFnYWlu Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ QWxzbyAtIHRoaXMgZG9jdW1lbnQgcGFzc2VkIFdHIGFuZCBJRVRGIGxhc3QgY2FsbCB3aXRoIHRo ZSB1bmRlcnN0YW5kaW5nIHRoYXQgaXQgZXhwbGljaXRseSBkaWQgKm5vdCogZGVmaW5lIGFuIElF VEYtYXBwcm92ZWQgZGV2aWNlIHByb2ZpbGUsIGJ1dCBvbmx5DQogYSBwcm9maWxlICZxdW90O3Ro YXQgYSBudW1iZXIgb2Ygb3BlcmF0b3JzIHJlY29tbWVuZCZxdW90Oy4gVGhhdCB0ZXh0IHdhcyBp biB0aGUgZG9jdW1lbnQgYXMgcmVjZW50bHkgYXMgLTE0LCBidXQgaXQgd2FzIHJlbW92ZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5NYWtpbmcg dGhpcyBkb2N1bWVhbiBJRVRGLWFwcHJvdmVkIGRldmljZSBwcm9maWxlIGlzIGEgc3Vic3RhbnRp YWwgY2hhbmdlIGFuZCBoYXMgbXVjaCBicm9hZGVyIGltcGxpY2F0aW9ucyB0aGFuIHdoYXQgdGhl IFdHIGFuZCBJRVRGIGhhZCBjb25zZW5zdXMgb24uDQogQWRkaW5nIHRoYXQgdGV4dCB3YXMgZXNz ZW50aWFsIHRvIG92ZXJjb21lIHRoZSBvYmplY3Rpb25zIG9mIHRob3NlIGluIHRoZSBXRyB0aGF0 IGZlbHQgdGhhdCBpdCBpcyBub3QgdGhlIHBsYWNlIG9mIGFuIG9wZXJhdGlvbmFsIFdHLCBvciBp bmRlZWQgb2YgdGhlIElFVEYsIHRvIHBsYWNlIHRoZSBSRkMgc2VhbCBvZiBhcHByb3ZhbCBvbiBh IGRldmljZSBwcm9maWxlIGRvY3VtZW50IChvciwgYXMgQnJpYW4gcHV0cyBpdCwgJnF1b3Q7b24g c29tZWJvZHkncw0KIHByb2N1cmVtZW50IHNwZWMmcXVvdDspLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+VGhhdCB0ZXh0IHNob3VsZCBiZSByZXN0 b3JlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFlvdXIgcG9pbnQgYWJv dXQgdGhlIHByb2Nlc3MgaXMgZmFpci4gSSBoYXZlIG5vIHByb2JsZW0gdG8gcmVzdG9yZSB0aGF0 IHRleHQgaWYgdGhpcyBpcyB3aGF0IHRoZSBXRyB3YW50cy4gVGhpcyBpcyByZWFsbHkgdGhlDQog a2luZCBmbyBmZWVkYmFjayBJ4oCZbSBsb29raW5nIGZvci4gJm5ic3A7VW5sZXNzIEkgaGVhcmQg YW55IG9iamVjdGlvbiBmcm9tIHRoZSBXRywgdGhhdCB0ZXh0IHdpbGwgYmUgcmVzdG9yZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Mi4gUHJl dmlvdXMgdmVyc2lvbnMgb2YgdGhlIGRvY3VtZW50LCBpbmNsdWRpbmcgdGhlIHZlcnNpb24gdGhh dCBwYXNzZWQgSUVURiBsYXN0IGNhbGwsIGNvbnRhaW5lZCB0aGUgdGV4dDo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwO1RoaXMgZG9jdW1lbnQgaXMNCjwvc3Bhbj5ub3QgYSBzdGFuZGFyZCwgYW5kIGNvbmZvcm1h bmNlIHdpdGggaXQgaXMgbm90PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtyZXF1aXJlZCBpbiBvcmRlciB0byBjbGFpbSBj b25mb3JtYW5jZSB3aXRoIElFVEYgc3RhbmRhcmRzIGZvciBJUHY2LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7VGhlIHN1 cHBvcnQgb2YgdGhlIGZ1bGwgc2V0IG9mIGZlYXR1cmVzIG1heSBub3QgYmUgcmVxdWlyZWQgaW4g c29tZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7ZGVwbG95bWVudCBjb250ZXh0cy4mbmJzcDsgVGhlIGF1dGhvcnMgYmVs aWV2ZSB0aGF0IHRoZSBzdXBwb3J0IG9mIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3N1YnNldCBvZiB0aGUgZmVhdHVy ZXMgaW5jbHVkZWQgaW4gdGhpcyBwcm90b2NvbCBtYXkgbGVhZCB0byBkZWdyYWRlZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7bGV2ZWwgb2Ygc2VydmljZSBpbiBzb21lIGRlcGxveW1lbnQgY29udGV4dHMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoYXQgdGV4dCByZW1haW5zIGFjY3VyYXRlIGFuZCB0aGF0IHN0YXRlbWVudCBpcyBzdGlsbCBu ZWNlc3NhcnkuIFdoeSB3YXMgaXQgcmVtb3ZlZD8gSXQgaGFzIGJlZW4gaW4gdGhlIGRvY3VtZW50 IHNpbmNlIC0wNiwgYW5kIHRoZSB3b3JkcyAmcXVvdDt0aGlzIGRvY3VtZW50IGlzIG5vdCBhIHN0 YW5kYXJkJnF1b3Q7IGhhdmUNCiBiZWVuIGluIHRoaXMgZG9jdW1lbnQgc2luY2UgLTAxLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEl0IHdhcyByZW1vdmVkIGFzIHBl ciBhIHJlcXVlc3QgZnJvbSB0aGUgSUVTRyAoQS4gRmFycmVsKS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZHJpYW4sIHdoeSBkaWQg eW91IHJlcXVlc3QgdGhhdCB0aGlzIHRleHQgYmUgcmVtb3ZlZD88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZXh0IHRoYXQg cGFzc2VkIGxhc3QgY2FsbCB3ZW50IG91dCBvZiBpdHMgd2F5IHRvIHN0YXRlIGl0IHdhcyBub3Qg YSBzdGFuZGFyZCwgYW5kIHRoYXQgY29tcGxpYW5jZSB3aXRoIGl0IHdhcyBub3QgcmVxdWlyZWQu Jm5ic3A7IFRoaXMgdGV4dCBoZWxwZWQgZGVmdXNlIHN1YnN0YW50aWFsIG9iamVjdGlvbnMgd2l0 aGluIHRoZSBXRyBhbmQgdGhlIElFVEYgdGhhdCBwb2ludGVkIG91dCB0aGF0IG9ubHkgYSBmcmFj dGlvbg0KIG9mIHRoZXNlIGZlYXR1cmVzIGFyZSBhY3R1YWxseSBuZWNlc3NhcnkgdG8gZGVwbG95 LCBhbmQgY2FsbGVkIGF0dGVudGlvbiB0byB0aGUgaGFybSB0byBJUHY2IGRlcGxveW1lbnQgdGhh dCB3b3VsZCBvY2N1ciBpZiBtb2JpbGUgb3BlcmF0b3JzIGFuZCBkZXZpY2UgbWFudWZhY3R1cmVy cyBiZWxpZXZlZCB0aGF0IGFsbCB0aGVzZSBmZWF0dXJlcyBuZWVkZWQgdG8gYmUgaW1wbGVtZW50 ZWQgYmVmb3JlIGRlcGxveW1lbnQgY291bGQgb2NjdXIuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gTG9yZW56bywgdGhlIGRvY3VtZW50IGRvZXMgbm90 IHN0YXRlcyBBTEwgZmVhdHVyZXMgTVVTVCBiZSBpbXBsZW1lbnRlZC4gSnVzdCBsaWtlIGFueSBv dGhlciByZWNvbW1lbmRhdGlvbiBkb2N1bWVudCwgdGhlcmUgYXJlIHNldmVyYWwgc3VwcG9ydCBs ZXZlbHMuDQogQXMgZmFyIGFzIEnigJltIGNvbmNlcm5lZCwgSSBoYXZlIG5vIG9iamVjdGlvbiB0 byBpbmNsdWRlIHRoYXQgdGV4dCBpZiB0aGUgSUVTRyBpcyBPSyB3aXRoIGl0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+My4gSSBvYmplY3QgdG8gdGhlIHN0YXRlbWVudCAmcXVvdDtP bmUgb2YgdGhlIG1ham9yIGh1cmRsZXMgZW5jb3VudGVyZWQgYnkgbW9iaWxlIG9wZXJhdG9ycyBp cyB0aGUgYXZhaWxhYmlsaXR5IG9mIG5vbi1icm9rZW4gSVB2NiBpbXBsZW1lbnRhdGlvbiBpbiBt b2JpbGUgZGV2aWNlcy4mcXVvdDsgSSBzdWJtaXQgdGhhdCBpZg0KIGl0IHdlcmUgdHJ1ZSwgdGhl biB3ZSB3b3VsZCBvYnNlcnZlIG5vIElQdjYgZGVwbG95bWVudCBpbiBtb2JpbGUgbmV0d29ya3Mu Li4gYnV0IHB1YmxpY2x5LWF2YWlsYWJsZSBkYXRhIC0gZS5nLiwNCjxhIGhyZWY9Imh0dHA6Ly93 d3cud29ybGRpcHY2bGF1bmNoLm9yZy9tZWFzdXJlbWVudHMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3d3dy53b3JsZGlwdjZsYXVuY2gub3JnL21lYXN1cmVtZW50cy88L2E+IC0gc2hvd3MgdGhh dCBtdWx0aXBsZSBvcGVyYXRvcnMgaGF2ZSBkZXBsb3llZCBJUHY2IHRvIHVwIHRvIDMwLTY1JSBv ZiB0aGVpciBmb290cHJpbnQsIHVzaW5nIHRoZSBzYW1lIGNvbW1lcmNpYWxseS1hdmFpbGFibGUg ZGV2aWNlcyB0aGF0DQogYXJlIHVzZWQgYnkgY3VzdG9tZXJzIG9mIG90aGVyIG9wZXJhdG9ycy4g U28gY2xhaW1pbmcgdGhhdCAmcXVvdDticm9rZW4gSVB2NiBpbXBsZW1lbnRhdGlvbnMgaW4gbW9i aWxlIGRldmljZXMmcXVvdDsgYXJlIGEgbWFqb3IgaHVyZGxlIGlzIGF0IGJlc3QgaW5jb21wbGV0 ZSBhbmQgYXQgd29yc3QgaW5jb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPltNZWRdIFRoYXQgc2VudGVuY2Ugd2FzIHRoZXJlIHNpbmNlIHdlIGVkaXRlZCB0aGUgaW5k aXZpZHVhbCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4gT2YgY291cnNlLA0KIGN1cnJlbnQgaW1w bGVtZW50YXRpb25zIHBlcmZvcm0gYmV0dGVyIHRoYXQgd2hlbiB3ZSBlZGl0ZWQgdGhlIC0wMCBv ZiB0aGUgZG9jdW1lbnQuIFN0aWxsLCB0aGUgZmVlZGJhY2sgd2UgaGFkIGZyb20gb3VyIGRldmlj ZSB0ZWFtIGlzIHRoYXQgdGhlcmUgYXJlIHN0aWxsIGEgbG90IHRvIGJlIGRvbmUuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHlv dSBzZWUsIHRoZSBwcm9ibGVtIHdpdGggdGhhdCBpcyB0aGF0IGl0J3MganVzdCB0aGUgb3Bpbmlv biBvZiB5b3VyIGRldmljZSB0ZWFtLiBGb3IgZXhhbXBsZSwgaWYgaW5zdGVhZCB5b3UgYXNrZWQg dGhlIGRldmljZSB0ZWFtcyBvZiBWZXJpem9uIFdpcmVsZXNzIGFuZCBULU1vYmlsZSwgdGhleSBt aWdodCB3ZWxsIHNheSB0aGF0IHRoZSBmZWF0dXJlcyB0aGF0IGFyZSBuZWNlc3NhcnkgdG8gZGVw bG95DQogSVB2NiBhcmUgYWxyZWFkeSBzdXBwb3J0ZWQganVzdCBmaW5lICh3aXRoIHRoZSBwb3Nz aWJsZSBleGNlcHRpb24gb2YgNDY0eGxhdCBvbiBpT1MpIC0gYW5kIHRoYXQncyB3aHkgdGhleSBk ZXBsb3llZCBJUHY2IHRvIDMwLTY1JSBvZiB0aGVpciBkZXZpY2VzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5b TWVkXSBUaGlzIGlzIFVTLWNlbnRyaWMsIGJ1dCBhbnl3YXkgeW91IGFscmVhZHkgcmFpc2VkIHRo aXMgcG9pbnQgc2V2ZXJhbCB0aW1lczogc29tZSBhbnN3ZXJzIGFyZSBwcm92aWRlZCBoZXJlDQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJl bnQvbXNnMTQ3NjkuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92 Nm9wcy9jdXJyZW50L21zZzE0NzY5Lmh0bWw8L2E+IG9yDQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjAwODYuaHRtbCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50L21zZzIwMDg2 Lmh0bWw8L2E+LiBJIGNhbiBhZGQgdGhhdCBpbiB0aGUgRXVyb3BlIGZvciBpbnN0YW5jZSwgb3Bl cmF0b3JzIGRvIG5vdCBjb250cm9sIHRoZSBkZXZpY2UgdXNlZCBieSZuYnNwOyB0aGUgY3VzdG9t ZXIsIGhlbmNlIHRoZQ0KIG5lZWQgdG8gaGF2ZSBhIHByb2ZpbGUuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIElFVEYgc2hvdWxkIG5vdCBkb2N1 bWVudCBtYXR0ZXJzIG9mIG9waW5pb24uPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBBZ3JlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JdCBzaG91bGQgbWFrZSB0ZWNobmljYWwgc3RhdGVtZW50cyB0aGF0IGFy ZSBzdXBwb3J0ZWQgYnkgZXZpZGVuY2UuPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJU09DIG9yZ2FuaXplZCBzZXZlcmFsIElQdjYg bW9iaWxlIHdvcmtzaG9wcyB0aGF0IHJldmVhbGVkIHRoYXQgb3BlcmF0b3JzIHBhcnRpY2lwYXRl ZCBhIHRob3NlIHdvcmtzaG9wIGFncmVlIGRldmljZXMgYXJlIGEgaHVyZGxlIGZvciB0aGVpciBJ UHY2IGRlcGxveW1lbnRzLg0KIEkgZG9u4oCZdCBoYXZlIHB1YmxpYyBwb2ludGVycyBmb3IgdGhl IHByZXogbWFkIGR1cmluZyB0aGUgd29ya3Nob3AgYnV0IHlvdSBjYW4gZ2V0IGluIHRvdWNoIHdp dGggSVNPQyBpZiB5b3UgbmVlZCBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGUgYXZhaWxhYmxlIGV2aWRlbmNlIGRvZXMgbm90IHN1cHBvcnQgdGhlIHN0YXRlbWVudCB0 aGF0ICZxdW90O0lQdjYgZGVwbG95bWVudCBpcyBibG9ja2VkIGJlY2F1c2UgbW9iaWxlIGRldmlj ZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGJyb2tlbiZxdW90OzsgaW4gZmFjdCwgdGhlIGV4aXN0ZW5j ZSBvZiBsYXJnZSBtb2JpbGUgZGVwbG95bWVudHMgcHJvdmVzIHRoYXQgc3RhdGVtZW50IHdyb25n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gTm90IHN1cmUgdG8gdW5kZXJzdGFuZCB0aGUg Y2F1c2FsaXR5IGVmZmVjdCBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B9330049026BCOPEXCLILM23corp_-- From nobody Fri Jan 30 02:39:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BDA1A0166 for ; Fri, 30 Jan 2015 02:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0933s65OiyuS for ; Fri, 30 Jan 2015 02:39:28 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DD31A01EA for ; Fri, 30 Jan 2015 02:39:27 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E0D2C60B72 for ; Fri, 30 Jan 2015 11:39:24 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4B188609D6 for ; Fri, 30 Jan 2015 11:39:24 +0100 (CET) Received: (qmail 71229 invoked by uid 1007); 30 Jan 2015 11:39:24 +0100 Date: Fri, 30 Jan 2015 11:39:24 +0100 From: Gert Doering To: mohamed.boucadair@orange.com Message-ID: <20150130103924.GG34798@Space.Net> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e0W8ZgW9slbJplro" Content-Disposition: inline In-Reply-To: <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 10:39:30 -0000 --e0W8ZgW9slbJplro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 30, 2015 at 09:12:16AM +0000, mohamed.boucadair@orange.com wrot= e: > Can you please help us identifying technical flaws that you think need to= be fixed in the document? I don't think there is a need for this document, and I can't truly see it reflecting WG consensus. So it's more fundamental than just individual technical issues. For the specifics, everything that Lorenzo said. 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 --e0W8ZgW9slbJplro Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVMtfXN9WwGXkzn/FAQJC5Q//eHx6HwIVh7/OBC2Bi5zHwk+IEzzaEahm ghx67D36ksDk1KUmCFpdiFjvpZprkKv9fAVa+eeksySsoqvcrKXOvoWE5odhOPNk Pt04cTnJPi/hoCnCvCSiIs4rC/flS6UVJHt4C6DZ1QAIP97b9TZUeddwHvnB0G44 uonPJ1rF0JONOY81Q+TsOb9tukXZHrf9qwJdag4TqeKhy3B5X6zTRiIGDduENRD4 iQhke/XX0wexbojUOlNZ96087kKJ76z54+nrCEdRj4aMefnL7DY+Xc/TykMTjXOY DkM25Yt1LFoA1cBMkZ7ioo6wcB3dYQFJ1J3InfGYSaOZJyLDpFqqZF6XWozqo1Xy zBn/8ebPbyExOTCdAxFw0VbBocLEDxD3t/KQAfXrHQSWPlK9M6im63ygDPiT+dcb MUJptsbN/6SzDkd92BJZy9jrbeJScRiEzgcJ7mjICymwga/2clRJZtZ0J1TKs/XK PASwg8Kc28IiTgSdplyo13qAPgLvSA9N+C6ulqIkxxEp+n8bFJ0Si/GOOSxw2+5o 5/ZkbLSoVWS9iHzuSuNH7TVFVhryIEk61R9IR57glMSRwhtgTg24QTncV3uBdl26 rlh/XxE/Me8SNqlY9ob3tcxTf8f7DG4MF6QnLB9CV39oT5QUiJy4sxRe5+oNnPM2 Ut8sxg1kv5I= =WM8C -----END PGP SIGNATURE----- --e0W8ZgW9slbJplro-- From nobody Fri Jan 30 04:21:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA68A1A8BC4 for ; Fri, 30 Jan 2015 04:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IocZQ3--3xmI for ; Fri, 30 Jan 2015 04:21:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0241A8BC3 for ; Fri, 30 Jan 2015 04:21:15 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 10F3B3744D2; Fri, 30 Jan 2015 13:21:14 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id D82C2158052; Fri, 30 Jan 2015 13:21:13 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 13:21:13 +0100 From: To: Gert Doering Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQPHkGQPkk8aYnL0u9Da/8/gnbI5zYk9Cw Date: Fri, 30 Jan 2015 12:21:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> In-Reply-To: <20150130103924.GG34798@Space.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.1] 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.12.16.134821 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 12:21:17 -0000 Re-, With all due respect, I'm afraid we are not discussing whether the document= is needed or not but (as I see it) whether the new version does not break = the WG consensus that was declared for the version sent to the IESG. I reca= ll that both the WG and IETF consensus were declared for the version sent t= o the IESG. Thank you. Cheers, Med -----Message d'origine----- De=A0: Gert Doering [mailto:gert@space.net]=20 Envoy=E9=A0: vendredi 30 janvier 2015 11:39 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: Gert Doering; Ole Troan; Fred Baker (fred); draft-ietf-v6ops-mobile-= device-profile.all@tools.ietf.org; V6 Ops List Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Hi, On Fri, Jan 30, 2015 at 09:12:16AM +0000, mohamed.boucadair@orange.com wrot= e: > Can you please help us identifying technical flaws that you think need to= be fixed in the document? I don't think there is a need for this document, and I can't truly see it reflecting WG consensus. So it's more fundamental than just individual technical issues. For the specifics, everything that Lorenzo said. 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 From nobody Fri Jan 30 04:52:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7F31A8F4A for ; Fri, 30 Jan 2015 04:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtjS_AWYFG3R for ; Fri, 30 Jan 2015 04:52:52 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A2F1A01F0 for ; Fri, 30 Jan 2015 04:52:52 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 949DADA0111 for ; Fri, 30 Jan 2015 12:52:52 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 54F0353E07E; Fri, 30 Jan 2015 04:52:52 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 30 Jan 2015 04:52:52 -0800 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: <787AE7BB302AE849A7480A190F8B9330049024FB@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Fri, 30 Jan 2015 07:52:37 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049024FB@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 12:52:55 -0000 On Jan 30, 2015, at 2:35 AM, mohamed.boucadair@orange.com wrote: > [Med] It was removed as per a request from the IESG (A. Farrel). It is well within the rights of the working group to say no to Adrian on = this point. He may not have been aware of the reason the working group = put it in the document. It may be that there's a better way to serve = the intent of the working group than this text, which could be = negotiated with Adrian, but the point is that the fact that Adrian put = it in a DISCUSS doesn't mean that the DISCUSsion is over. This is why = we bring documents back to working groups after addressing DISCUSses = that produce significant changes. From nobody Fri Jan 30 05:34:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566B81A0203 for ; Fri, 30 Jan 2015 05:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lol_VXJh68iY for ; Fri, 30 Jan 2015 05:34:11 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD681A026E for ; Fri, 30 Jan 2015 05:34:11 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3AA1620722 for ; Fri, 30 Jan 2015 08:34:10 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 30 Jan 2015 08:34:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=P+xw64Tfb7QHOxp50VBU0i iXqdI=; b=QlRwln3bkBfJd3XRfE5Z3iKg7q5Pep6ntygII2MOGZs/Wi1wezUEtk rtJqxI4ZF9jrseLNsok85D886Mx/9r4sWhf9bl6bLmv2qOjCtuMQZeR3pGka6any jbPD4XyiKVYTbtkPqb6jca/z4Dyz4Hu8T7gLKzc9iWhg18Qbc1WtQ= X-Sasl-enc: kg66esB32LQj4vpg/6s1pWD0VI1GufDf3ns47WL3nTHO 1422624849 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id D591BC0028B; Fri, 30 Jan 2015 08:34:09 -0500 (EST) Message-ID: <54CB8828.2010905@network-heretics.com> Date: Fri, 30 Jan 2015 08:33:28 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150129034612.14822.20520.idtracker@ietfa.amsl.com> <54C9AEB7.709@gmail.com> <82EC2F29-DED3-4DF0-9F93-B758EA30EC5D@cisco.com> In-Reply-To: <82EC2F29-DED3-4DF0-9F93-B758EA30EC5D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-11.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, 30 Jan 2015 13:34:14 -0000 On 01/29/2015 03:13 PM, Fred Baker (fred) wrote: > Folks - are we good with this? I’ll give people a few days to say otherwise, but plan to send it to Joel next week barring issues. I'm good with this. Keith From nobody Fri Jan 30 07:18:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF22A1A9051 for ; Fri, 30 Jan 2015 07:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Piv6F1N9-DpQ for ; Fri, 30 Jan 2015 07:18:06 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F371A9063 for ; Fri, 30 Jan 2015 07:18:04 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id ca0abc45.0.5010023.00-2081.14029980.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 30 Jan 2015 15:18:05 +0000 (UTC) X-MXL-Hash: 54cba0ad68e53b9a-f45a6bcbc6795662a6b1c9dbdccfdbfd578f9405 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0UFI3oV014875; Fri, 30 Jan 2015 10:18:04 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0UFHuOu014772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jan 2015 10:17:57 -0500 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 30 Jan 2015 15:17:42 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.10]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 10:17:42 -0500 From: "STARK, BARBARA H" To: "mohamed.boucadair@orange.com" , "James Woodyatt" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzXWAcAgACD64CAAMlUAIAAF8Pw Date: Fri, 30 Jan 2015 15:17:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F0D3B0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.156.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=L/KqtZv8 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=tXTwz62Y0oYA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YNv0rlydsVwA:10 a=f0wexdnya] X-AnalysisOut: [X2tzGKd3QIA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 15:18:07 -0000 UHJvcG9zZWQgdGV4dCBmcm9tIEphbWVzOg0KPiBJbiB0aGUgY2FzZSBvZiBjZWxsdWxhciBkZXZp Y2VzIHRoYXQgcHJvdmlkZSBMQU4gZmVhdHVyZXMsIGNvbXBsaWFuY2Ugd2l0aCBMX1JFQyMyIGVu dGFpbHMgY29tcGxpYW5jZSB3aXRoIFJGQyA2MjA0LCB3aGljaCBpbiB0dXJuIHJlY29tbWVuZHMg Y29tcGxpYW5jZSB3aXRoIFJlY29tbWVuZGVkIFNpbXBsZSBTZWN1cml0eSBDYXBhYmlsaXRpZXMg aW4gQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IChDUEUpIGZvciBQcm92aWRpbmcgUmVzaWRl bnRpYWwgSVB2NiBJbnRlcm5ldCBTZXJ2aWNlIFtSRkM2MDkyXS4gVGhlcmVmb3JlLCB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gc2VjdGlvbiA2IG9mIHRoYXQgZG9jdW1lbnQgYXJlIHJl bGV2YW50LiBJbiBwYXJ0aWN1bGFyLCBpdCBiZWFycyByZXBlYXRpbmcgaGVyZSB0aGF0IHRoZSB0 cnVlIGltcGFjdCBvZiBzdGF0ZWZ1bCBmaWx0ZXJpbmcgbWF5IGJlIGEgcmVkdWN0aW9uIGluIHNl Y3VyaXR5LCBhbmQgdGhhdCBJRVRGIG1ha2Ugbm8gc3RhdGVtZW50LCBleHByZXNzZWQgb3IgaW1w bGllZCwgYXMgdG8gd2hldGhlciB1c2luZyB0aGUgY2FwYWJpbGl0aWVzIGRlc2NyaWJlZCBpbiBh bnkgb2YgdGhlc2UgZG9jdW1lbnRzIHVsdGltYXRlbHkgaW1wcm92ZXMgc2VjdXJpdHkgZm9yIGFu eSBpbmRpdmlkdWFsIHVzZXJzIG9yIGZvciB0aGUgSW50ZXJuZXQgY29tbXVuaXR5IGFzIGEgd2hv bGUuDQotLQ0KDQpGWUkuIFJGQyA2MjA0IChpbiBKYW1lc+KAmSBwcm9wb3NlZCB0ZXh0IGFib3Zl KSB3YXMgb2Jzb2xldGVkIGJ5IFJGQyA3MDg0LiBJZiB0aGlzIHRleHQgaXMgdG8gYmUgaW5jbHVk ZWQsIHRoYXQgc2hvdWxkIGJlIGNoYW5nZWQuDQoNCkkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSBz b21lIG9mIHRoZSByZW1vdmVkIHRleHQgKHJlZmVycmluZyB0byBkaXNjdXNzaW9uIGFyb3VuZCBz b21lIG9mIExvcmVuem8ncyBjb21tZW50cykgcHV0IGJhY2suDQpCYXJiYXJhDQo= From nobody Fri Jan 30 07:25:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94C1A9050 for ; Fri, 30 Jan 2015 07:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aClaKf33H1Pl for ; Fri, 30 Jan 2015 07:25:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC961A904D for ; Fri, 30 Jan 2015 07:25:05 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 278E6C090D; Fri, 30 Jan 2015 16:25:04 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0123D158059; Fri, 30 Jan 2015 16:25:04 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 16:25:03 +0100 From: To: "STARK, BARBARA H" , James Woodyatt Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzXWAcAgACD64CAAMlUAIAAF8PwgAANrZA= Date: Fri, 30 Jan 2015 15:25:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61130F0D3B0@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F0D3B0@GAALPA1MSGUSRBF.ITServices.sbc.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.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 15:25:08 -0000 SGkgQmFyYmFyYSwNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudC4NCg0KSSdtIHBsYW5uaW5n IHRvIHB1dCBiYWNrIHRoYXQgdGV4dCBpZiB0aGVyZSBpcyBubyBvYmplY3Rpb24gZnJvbSB0aGUg V0cuIA0KDQpBcyBwZXIgUkZDNzA4NCwgd2UgZGlkbid0IGluY2x1ZGVkIGl0IGJlY2F1c2UgaXQg aW5jbHVkZWQgc29tZSBJUHY0IGNvbnRpbnVpdHkgc2VydmljZSBmZWF0dXJlcyB0aGF0IGFyZSBu b3QgdmFsaWQgZm9yIHRoZSBtb2JpbGUgY29udGV4dC4gVGhlIGRvY3VtZW50IGFscmVhZHkgbWVu dGlvbnMgdGhlIGZvbGxvd2luZzogDQoNCiAgICAgICAgICAgICAgICAiTm90ZSwgZXZlbiBpZiBS RkM3MDg0IG9ic29sZXRlcyBbUkZDNjIwNF0sIHRoaXMgcHJvZmlsZQ0KICAgICAgICAgICAgICAg IGRvZXMgbm90IHJlcXVpcmUgUkZDNzA4NCBiZWNhdXNlIElQdjQgc2VydmljZSBjb250aW51aXR5 DQogICAgICAgICAgICAgICAgdGVjaG5pcXVlcyB1c2VkIGluIG1vYmlsZSBuZXR3b3JrcyBhcmUg bm90IHRoZSBzYW1lIGFzDQogICAgICAgICAgICAgICAgaW4gZml4ZWQgbmV0d29ya3MuIg0KDQpU aGFuayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N CkRlwqA6IFNUQVJLLCBCQVJCQVJBIEggW21haWx0bzpiczc2NTJAYXR0LmNvbV0gDQpFbnZvecOp wqA6IHZlbmRyZWRpIDMwIGphbnZpZXIgMjAxNSAxNjoxOA0Kw4DCoDogQk9VQ0FEQUlSIE1vaGFt ZWQgSU1UL09MTjsgSmFtZXMgV29vZHlhdHQNCkNjwqA6IElQdjYgT3BzIFdHDQpPYmpldMKgOiBS RTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNh bGwNCg0KUHJvcG9zZWQgdGV4dCBmcm9tIEphbWVzOg0KPiBJbiB0aGUgY2FzZSBvZiBjZWxsdWxh ciBkZXZpY2VzIHRoYXQgcHJvdmlkZSBMQU4gZmVhdHVyZXMsIGNvbXBsaWFuY2Ugd2l0aCBMX1JF QyMyIGVudGFpbHMgY29tcGxpYW5jZSB3aXRoIFJGQyA2MjA0LCB3aGljaCBpbiB0dXJuIHJlY29t bWVuZHMgY29tcGxpYW5jZSB3aXRoIFJlY29tbWVuZGVkIFNpbXBsZSBTZWN1cml0eSBDYXBhYmls aXRpZXMgaW4gQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IChDUEUpIGZvciBQcm92aWRpbmcg UmVzaWRlbnRpYWwgSVB2NiBJbnRlcm5ldCBTZXJ2aWNlIFtSRkM2MDkyXS4gVGhlcmVmb3JlLCB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gc2VjdGlvbiA2IG9mIHRoYXQgZG9jdW1lbnQg YXJlIHJlbGV2YW50LiBJbiBwYXJ0aWN1bGFyLCBpdCBiZWFycyByZXBlYXRpbmcgaGVyZSB0aGF0 IHRoZSB0cnVlIGltcGFjdCBvZiBzdGF0ZWZ1bCBmaWx0ZXJpbmcgbWF5IGJlIGEgcmVkdWN0aW9u IGluIHNlY3VyaXR5LCBhbmQgdGhhdCBJRVRGIG1ha2Ugbm8gc3RhdGVtZW50LCBleHByZXNzZWQg b3IgaW1wbGllZCwgYXMgdG8gd2hldGhlciB1c2luZyB0aGUgY2FwYWJpbGl0aWVzIGRlc2NyaWJl ZCBpbiBhbnkgb2YgdGhlc2UgZG9jdW1lbnRzIHVsdGltYXRlbHkgaW1wcm92ZXMgc2VjdXJpdHkg Zm9yIGFueSBpbmRpdmlkdWFsIHVzZXJzIG9yIGZvciB0aGUgSW50ZXJuZXQgY29tbXVuaXR5IGFz IGEgd2hvbGUuDQotLQ0KDQpGWUkuIFJGQyA2MjA0IChpbiBKYW1lc+KAmSBwcm9wb3NlZCB0ZXh0 IGFib3ZlKSB3YXMgb2Jzb2xldGVkIGJ5IFJGQyA3MDg0LiBJZiB0aGlzIHRleHQgaXMgdG8gYmUg aW5jbHVkZWQsIHRoYXQgc2hvdWxkIGJlIGNoYW5nZWQuDQoNCkkgd291bGQgYWxzbyBsaWtlIHRv IHNlZSBzb21lIG9mIHRoZSByZW1vdmVkIHRleHQgKHJlZmVycmluZyB0byBkaXNjdXNzaW9uIGFy b3VuZCBzb21lIG9mIExvcmVuem8ncyBjb21tZW50cykgcHV0IGJhY2suDQpCYXJiYXJhDQo= From nobody Fri Jan 30 07:32:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11C11A90BA for ; Fri, 30 Jan 2015 07:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awBrVSLalkgG for ; Fri, 30 Jan 2015 07:32:33 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43551A90C4 for ; Fri, 30 Jan 2015 07:32:26 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id hn18so3963029igb.2 for ; Fri, 30 Jan 2015 07:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P1bc9Ru1sFymcgf333A8ocQ8iZmoWRrqjgO4/yjqCvk=; b=lSUwl3KHKfIySLWF0Pt6JULJzTkiB5Rhh/O8BBmeYZEb5m/kdeVtZjUfs1qwkMa8+r rI6mu6/P+JPLLuX19Y38QzkyFWSja3vuRgiXoC1FvqGtJWwX1VQn6hU6QDjltoyIZHLI TjGkP5ZjHS6/srJ6n+GsQomvG4XAgF0MxfCSh9Wr3uk3oaLhyUnt/Kn+RT/0FVeZQ6k/ QLvd03fzzOH8MlQFe9G4bS8lY5V+/QfRa7DdgOmVn3GPfbWgQoTKx3Y4jNZ96LWlr/Jv PC10pYDvlIngj5tiPVP8tCCeec3Rbc569dkHgg2vdz6K/7M1ie9JZPjS5JSe3GYQV24m EUmQ== 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=P1bc9Ru1sFymcgf333A8ocQ8iZmoWRrqjgO4/yjqCvk=; b=hLN0kjV9scmmlRbwg9LIf+5RqBPewq1S/FR1m7aWlQDZPSKl1dlgK5k2XhBggoKRBA wr9po/7faThsfOad+/9UfA/p1yXy2kQBAISJ6tIwCg2Ji8OjrfLJtmoV66v3F431Or5H ME9Fv6Jqzv7Q1YxSHBrWNDYo9kp9cSabO88T2AVK1xDhOJJ61Boe0YKitBISorj6V0wk Tf4leojJDz5l6gtbXL+kjbqAx/Ag0Cv0puGqmnggoAoJJ69guFWWuwjmgmnxU44t54c8 uEI93NLyWDTeQiG7qU0h2j2qJyrwPySWV1X8HQBAmGy3+ATkBzhE0PI6ZPlI2NQcDSZG 3c6g== X-Gm-Message-State: ALoCoQnkIGWEKktyPkKyhdSYY3Qb22WrktgJoYGSHealt3rITBnMxOlpLVb9+uMpY4PgB4qnaIeh X-Received: by 10.50.142.106 with SMTP id rv10mr3452283igb.18.1422631946147; Fri, 30 Jan 2015 07:32:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Fri, 30 Jan 2015 07:32:05 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Sat, 31 Jan 2015 00:32:05 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a11c3d13acc0394050de04f5a Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 15:32:34 -0000 --001a11c3d13acc0394050de04f5a Content-Type: text/plain; charset=UTF-8 On Fri, Jan 30, 2015 at 9:21 PM, wrote: > With all due respect, I'm afraid we are not discussing whether the > document is needed or not but (as I see it) whether the new version does > not break the WG consensus that was declared for the version sent to the > IESG. Er, wait. Are you're saying that if the WG re-reads this document and there is no longer consensus in the WG that it should be published, it gets published anyway? --001a11c3d13acc0394050de04f5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 30, 2015 at 9:21 PM, <mohamed.boucadair@orange.com= > wrote:
With all due respect, = I'm afraid we are not discussing whether the document is needed or not = but (as I see it) whether the new version does not break the WG consensus t= hat was declared for the version sent to the IESG.

Er, wait. Are you're saying that if the WG re-reads this docume= nt and there is no longer consensus in the WG that it should be published, = it gets published anyway?
--001a11c3d13acc0394050de04f5a-- From nobody Fri Jan 30 07:48:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852FA1A90B1 for ; Fri, 30 Jan 2015 07:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dOGkMNWaHdc for ; Fri, 30 Jan 2015 07:48:15 -0800 (PST) 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 D3A341A90B0 for ; Fri, 30 Jan 2015 07:48:13 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP; 30 Jan 2015 16:48:11 +0100 X-IronPort-AV: E=Sophos;i="5.09,492,1418079600"; d="scan'208,217";a="205841149" Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 30 Jan 2015 16:48:12 +0100 Received: from HE113605.emea1.cds.t-internal.com ([10.125.65.122]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Fri, 30 Jan 2015 16:48:10 +0100 From: To: , Date: Fri, 30 Jan 2015 16:48:09 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AdA8ohqCI/KLc3oXRCqDj2ANZZQjkQAAcRmg Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_FFD91DE61362694C94B174BB03CFDCDD0102408FA8ACHE113605eme_" MIME-Version: 1.0 Archived-At: Cc: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 15:48:17 -0000 --_000_FFD91DE61362694C94B174BB03CFDCDD0102408FA8ACHE113605eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywgZG8geW91IHdhbnQgdG8gc3RhcnQgYW5vdGhlciBXR0xDIGZvciB0aGlzIGRvY3Vt ZW50PyBXaHkgZG8geW91IGFzc3VtZSB0aGF0IFdHIHBvc2l0aW9uIGhhcyBjaGFuZ2VkIHNpbmNl IHRoZSBsYXN0IFdHTEM/DQoNCi1vYg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IEZyZWl0YWcs IDMwLiBKYW51YXIgMjAxNSAxNjozMg0KVG86IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Pg0KQ2M6IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLmFsbEB0b29scy5p ZXRmLm9yZzsgVjYgT3BzIExpc3QNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZv cHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbA0KDQpPbiBGcmksIEphbiAzMCwgMjAx NSBhdCA5OjIxIFBNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KV2l0aCBhbGwgZHVlIHJlc3BlY3QsIEkn bSBhZnJhaWQgd2UgYXJlIG5vdCBkaXNjdXNzaW5nIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIG5l ZWRlZCBvciBub3QgYnV0IChhcyBJIHNlZSBpdCkgd2hldGhlciB0aGUgbmV3IHZlcnNpb24gZG9l cyBub3QgYnJlYWsgdGhlIFdHIGNvbnNlbnN1cyB0aGF0IHdhcyBkZWNsYXJlZCBmb3IgdGhlIHZl cnNpb24gc2VudCB0byB0aGUgSUVTRy4NCg0KRXIsIHdhaXQuIEFyZSB5b3UncmUgc2F5aW5nIHRo YXQgaWYgdGhlIFdHIHJlLXJlYWRzIHRoaXMgZG9jdW1lbnQgYW5kIHRoZXJlIGlzIG5vIGxvbmdl ciBjb25zZW5zdXMgaW4gdGhlIFdHIHRoYXQgaXQgc2hvdWxkIGJlIHB1Ymxpc2hlZCwgaXQgZ2V0 cyBwdWJsaXNoZWQgYW55d2F5Pw0K --_000_FFD91DE61362694C94B174BB03CFDCDD0102408FA8ACHE113605eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg Mi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xh c3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PkxvcmVuem8sIGRvIHlvdSB3YW50IHRvIHN0YXJ0IGFub3RoZXIgV0dMQyBmb3IgdGhpcyBkb2N1 bWVudD8gV2h5IGRvIHlvdSBhc3N1bWUgdGhhdCBXRyBwb3NpdGlvbiBoYXMgY2hhbmdlZCBzaW5j ZSB0aGUgbGFzdCBXR0xDPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3Nw YWNlOm5vbmUnPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LW9iPC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gdjZvcHMgW21haWx0 bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkxvcmVuem8gQ29s aXR0aTxicj48Yj5TZW50OjwvYj4gRnJlaXRhZywgMzAuIEphbnVhciAyMDE1IDE2OjMyPGJyPjxi PlRvOjwvYj4gJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mZ3Q7PGJyPjxiPkNjOjwv Yj4gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYu b3JnOyBWNiBPcHMgTGlzdDxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0 Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gRnJpLCBKYW4gMzAsIDIwMTUgYXQgOToyMSBQTSwgJmx0 OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9i bGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5XaXRoIGFsbCBkdWUgcmVzcGVjdCwgSSdtIGFmcmFp ZCB3ZSBhcmUgbm90IGRpc2N1c3Npbmcgd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgbmVlZGVkIG9y IG5vdCBidXQgKGFzIEkgc2VlIGl0KSB3aGV0aGVyIHRoZSBuZXcgdmVyc2lvbiBkb2VzIG5vdCBi cmVhayB0aGUgV0cgY29uc2Vuc3VzIHRoYXQgd2FzIGRlY2xhcmVkIGZvciB0aGUgdmVyc2lvbiBz ZW50IHRvIHRoZSBJRVNHLjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkVyLCB3YWl0 LiBBcmUgeW91J3JlIHNheWluZyB0aGF0IGlmIHRoZSBXRyByZS1yZWFkcyB0aGlzIGRvY3VtZW50 IGFuZCB0aGVyZSBpcyBubyBsb25nZXIgY29uc2Vuc3VzIGluIHRoZSBXRyB0aGF0IGl0IHNob3Vs ZCBiZSBwdWJsaXNoZWQsIGl0IGdldHMgcHVibGlzaGVkIGFueXdheT88bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_FFD91DE61362694C94B174BB03CFDCDD0102408FA8ACHE113605eme_-- From nobody Fri Jan 30 08:35:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0356F1A1B71 for ; Fri, 30 Jan 2015 08:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tImU3AIXrUGY for ; Fri, 30 Jan 2015 08:35:15 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1490C1A1A7C for ; Fri, 30 Jan 2015 08:35:14 -0800 (PST) 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.9) with ESMTP id t0UGZ7Q7090658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2015 16:35:09 GMT (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: <54CBB2BB.9010608@foobar.org> Date: Fri, 30 Jan 2015 16:35:07 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Olaf.Bonness@telekom.de, lorenzo@google.com, mohamed.boucadair@orange.com References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 16:35:18 -0000 On 30/01/2015 15:48, Olaf.Bonness@telekom.de wrote: > Lorenzo, do you want to start another WGLC for this document? Why do you > assume that WG position has changed since the last WGLC? the WG position hasn't materially changed; the document has. Nick From nobody Fri Jan 30 08:41:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB791A1EFF for ; Fri, 30 Jan 2015 08:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP1wKPro3SR3 for ; Fri, 30 Jan 2015 08:41:28 -0800 (PST) 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 591F01A1AF0 for ; Fri, 30 Jan 2015 08:41:28 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6D65F60B8F for ; Fri, 30 Jan 2015 17:41:26 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 26E44609D6 for ; Fri, 30 Jan 2015 17:41:26 +0100 (CET) Received: (qmail 39502 invoked by uid 1007); 30 Jan 2015 17:41:26 +0100 Date: Fri, 30 Jan 2015 17:41:26 +0100 From: Gert Doering To: Nick Hilliard Message-ID: <20150130164126.GO34798@Space.Net> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CBB2BB.9010608@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54CBB2BB.9010608@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 16:41:30 -0000 Hi, On Fri, Jan 30, 2015 at 04:35:07PM +0000, Nick Hilliard wrote: > the WG position hasn't materially changed; the document has. To some extent, reality has changed. There are a number of large scale production wireless 3G/4G deployments out there, so the claim "it cannot be done because handsets sucks" is most definitely no longer true. And, as Lorenzo stated, none of these handsets (that work well in practice!) fulfills the shopping list in this draft... which gives that the requirements are not needed for successful deployment, and *that* makes the whole document slightly... superfluous. 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 Fri Jan 30 08:57:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349EF1A6EFE for ; Fri, 30 Jan 2015 08:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH6ZMjzMY9hW for ; Fri, 30 Jan 2015 08:57:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497991A19F4 for ; Fri, 30 Jan 2015 08:57:35 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 64D921B8116; Fri, 30 Jan 2015 17:57:33 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4406F38404A; Fri, 30 Jan 2015 17:57:33 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 17:57:29 +0100 From: To: Gert Doering , Nick Hilliard Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgACFfYCAAOoGUIAACBcAgAAccoCAADVUgIAAInzW///w5ACAABGMAA== Date: Fri, 30 Jan 2015 16:57:28 +0000 Message-ID: <8909_1422637053_54CBB7FD_8909_6553_1_5adce3e7-c0d1-4493-b88f-a20a0d4e3c9b@OPEXCLILH03.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CBB2BB.9010608@foobar.org> <20150130164126.GO34798@Space.Net> In-Reply-To: <20150130164126.GO34798@Space.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.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.30.122720 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 16:57:37 -0000 Hi, >=20 > Hi, >=20 > On Fri, Jan 30, 2015 at 04:35:07PM +0000, Nick Hilliard wrote: > > the WG position hasn't materially changed; the document has. >=20 > To some extent, reality has changed. There are a number of large scale p= roduction > wireless 3G/4G deployments out there, so the claim "it cannot be done bec= ause > handsets sucks" is most definitely no longer true. [DB] Whatever the IPv6 deployment status in a given country, we can't say t= hat IPv6 deployment is ready everywhere. In some countries lack of IPv6 sup= port in some mobile devices is still an issue.=20 >=20 > And, as Lorenzo stated, none of these handsets (that work well in > practice!) fulfills the shopping list in this draft... which gives that = the requirements > are not needed for successful deployment, and *that* makes the whole docu= ment > slightly... superfluous. [DB] The document does not mandate some support of every feature present in= the document as it is the case for RFC 7084 (CPE can be connected to IPv6 = networks without any 6rd or DS-Lite features). The document does not mandate CLAT feature but in some situations, mobile d= evices should implement this feature.=20 David >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jan 30 09:45:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8D1A212D for ; Fri, 30 Jan 2015 09:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSCx50TeJ4Ty for ; Fri, 30 Jan 2015 09:45:28 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B63B1A1BFE for ; Fri, 30 Jan 2015 09:45:27 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 533cbc45.0.7226673.00-2171.20233481.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 30 Jan 2015 17:45:28 +0000 (UTC) X-MXL-Hash: 54cbc33848a77371-8c69a1772d96b49135d3e584e3e8d7038c7e30e3 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0UHjLvK012000; Fri, 30 Jan 2015 12:45:25 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0UHjAYB011043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jan 2015 12:45:16 -0500 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 30 Jan 2015 17:44:54 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.10]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 12:44:54 -0500 From: "STARK, BARBARA H" To: "mohamed.boucadair@orange.com" , "James Woodyatt" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzXWAcAgACD64CAAMlUAIAAF8PwgAANrZCAACKoAA== Date: Fri, 30 Jan 2015 17:44:54 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F0D53E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61130F0D3B0@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.156.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=BpYqN/r5 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=tXTwz62Y0oYA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YNv0rlydsVwA:10 a=SqHAGK2ZE] X-AnalysisOut: [RW6ytXJafcA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 17:45:30 -0000 PiBBcyBwZXIgUkZDNzA4NCwgd2UgZGlkbid0IGluY2x1ZGVkIGl0IGJlY2F1c2UgaXQgaW5jbHVk ZWQgc29tZSBJUHY0DQo+IGNvbnRpbnVpdHkgc2VydmljZSBmZWF0dXJlcyB0aGF0IGFyZSBub3Qg dmFsaWQgZm9yIHRoZSBtb2JpbGUgY29udGV4dC4gVGhlDQo+IGRvY3VtZW50IGFscmVhZHkgbWVu dGlvbnMgdGhlIGZvbGxvd2luZzoNCj4gDQo+ICAgICAgICAgICAgICAgICAiTm90ZSwgZXZlbiBp ZiBSRkM3MDg0IG9ic29sZXRlcyBbUkZDNjIwNF0sIHRoaXMgcHJvZmlsZQ0KPiAgICAgICAgICAg ICAgICAgZG9lcyBub3QgcmVxdWlyZSBSRkM3MDg0IGJlY2F1c2UgSVB2NCBzZXJ2aWNlIGNvbnRp bnVpdHkNCj4gICAgICAgICAgICAgICAgIHRlY2huaXF1ZXMgdXNlZCBpbiBtb2JpbGUgbmV0d29y a3MgYXJlIG5vdCB0aGUgc2FtZSBhcw0KPiAgICAgICAgICAgICAgICAgaW4gZml4ZWQgbmV0d29y a3MuIg0KDQpSZXF1aXJpbmcgY29tcGxpYW5jZSB0byBhbiBvYnNvbGV0ZWQgUkZDICg2MjA0KSBp cy4uLnVtLi4udW51c3VhbC4gRXNwZWNpYWxseSBzaW5jZSBSRkMgNzA4NCBmaXhlZCBzZXZlcmFs IGl0ZW1zIGluIDYyMDQgdGhhdCBuZWVkZWQgZml4aW5nLiBJLCBwZXJzb25hbGx5LCB3b3VsZCBu b3QgcmVjb21tZW5kIGFueXRoaW5nIGJlIGNvbXBsaWFudCB3aXRoIFJGQyA2MjA0Lg0KDQpBbHNv IG5vdGUgdGhhdCBEUy1MaXRlIGFuZCA2cmQgYXJlICJTSE9VTEQiIHJlcXVpcmVtZW50cyBpbiBS RkMgNzA4NC4gSXQgaXMgdG90YWxseSBwb3NzaWJsZSBmb3IgYSBkZXZpY2UgdG8gYmUgMTAwJSBj b21wbGlhbnQgd2l0aCBSRkMgNzA4NCBhbmQgbm90IGRvIGVpdGhlciBEUy1MaXRlIG9yIDZyZC4g U3VyZWx5IG1vYmlsZSBkZXZpY2UgbWFudWZhY3R1cmVycyBhcmUgaW50ZWxsaWdlbnQgZW5vdWdo IHRvIHJlY29nbml6ZSB0aGF0IHRoZXJlIGlzIGEgdmVyeSBnb29kIHJlYXNvbiBmb3IgdGhlbSBu b3QgdG8gZG8gRFMtTGl0ZSBvciA2cmQgKGJlY2F1c2UgdGhlc2UgYXJlbid0IHVzZWQgaW4gM0dQ UCBuZXR3b3Jrcyk/IEl0IHdvdWxkIGFsc28gYmUgcG9zc2libGUgdG8gZXhwbGljaXRseSBub3Rl IHRoYXQgdGhlc2UgdGVjaG5vbG9naWVzIGFyZSBub3QgdXNlZCBvciBuZWVkZWQgZm9yIGNvbm5l Y3RpbmcgdG8gM0dQUCBuZXR3b3Jrcy4NCg0KSXQncyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgd2hl biBhbiBSRkMgaXMgb2Jzb2xldGVkIGJ5IGFub3RoZXIgUkZDLCByZWFkZXJzIGFyZSBzdXBwb3Nl ZCB0byBjb25zaWRlciB0aGUgbmV3IFJGQyBhcyBhIHJlcGxhY2VtZW50IGZvciB0aGUgb2Jzb2xl dGVkIFJGQywgZXZlcnkgdGltZSB0aGV5IHNlZSBhIHJlZmVyZW5jZSB0byB0aGUgb2Jzb2xldGVk IFJGQy4gU28gYSBicmFuZCBuZXcgcmVmZXJlbmNlIHRvIGFuIG9ic29sZXRlZCBSRkMsIGZvciBt ZSwgaXMgcmF0aGVyIGJpemFycmUuIEl0J3MgYm9nZ2xpbmcgbXkgbWluZC4gSSdtIG5vdCBjb252 aW5jZWQgdGhhdCB0aGlzIHJlZmVyZW5jZSB0byBhbiBvYnNvbGV0ZWQgUkZDIHdpbGwgYmUgdW5k ZXJzdG9vZCBpbiB0aGUgbWFubmVyIHlvdSBpbnRlbmQuDQpCYXJiYXJhDQo= From nobody Fri Jan 30 10:05:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE58F1A8788 for ; Fri, 30 Jan 2015 10:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJbZKrAeTxhR for ; Fri, 30 Jan 2015 10:05:24 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597A21A00BE for ; Fri, 30 Jan 2015 10:04:59 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0136A62D24 for ; Fri, 30 Jan 2015 19:04:56 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9A7AB60B4E for ; Fri, 30 Jan 2015 19:04:56 +0100 (CET) Received: (qmail 51723 invoked by uid 1007); 30 Jan 2015 19:04:56 +0100 Date: Fri, 30 Jan 2015 19:04:56 +0100 From: Gert Doering To: david.binet@orange.com Message-ID: <20150130180456.GP34798@Space.Net> References: <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CBB2BB.9010608@foobar.org> <20150130164126.GO34798@Space.Net> <8909_1422637053_54CBB7FD_8909_6553_1_5adce3e7-c0d1-4493-b88f-a20a0d4e3c9b@OPEXCLILH03.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mNGKFxWlKa8RVqLf" Content-Disposition: inline In-Reply-To: <8909_1422637053_54CBB7FD_8909_6553_1_5adce3e7-c0d1-4493-b88f-a20a0d4e3c9b@OPEXCLILH03.corporate.adroot.infra.ftgroup> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 18:05:32 -0000 --mNGKFxWlKa8RVqLf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 30, 2015 at 04:57:28PM +0000, david.binet@orange.com wrote: > > > the WG position hasn't materially changed; the document has. > >=20 > > To some extent, reality has changed. There are a number of large scale= production > > wireless 3G/4G deployments out there, so the claim "it cannot be done b= ecause > > handsets sucks" is most definitely no longer true. > [DB] Whatever the IPv6 deployment status in a given country, we can't say= that IPv6 deployment is ready everywhere. In some countries lack of IPv6 s= upport in some mobile devices is still an issue.=20 This is a global world, and (maybe except for the chinese market), handset vendors ship globally - so I bet that an Android handset that works well in T-Mobile USA's and Verizon Wireless' network has enough IPv6 support to work on your network as well... OTOH, I have a number of Telco-branded devices here that can *not* do IPv6, even if the original vendor firmware *does* IPv6. So this is really a matter of the Telcos telling their handset / USB / router vendors to enable IPv6 in the build shipped to them. So that wishlist makes sense to have as a Telco, but I'm not convinced it's a useful IETF document (I don't see Telcos following IETF or 3GPP recommendations in other=20 fields either if they don't want to. Like, implementing IPv6, which is mandatory in the 3GPP specs since ever...). 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 --mNGKFxWlKa8RVqLf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVMvHyN9WwGXkzn/FAQJfdA//UGqv36ExfJmLHlGTx8UnpKDOSaOLGu3+ jcaqz2xp9gxiX+hL67bunMCidwomUVQvo6sOGoJNUsl4RZ/NrGhr2K3z5b2iVi+3 CR4mspr8vkPe0X2SvThvuWOOkOoQOEDQAoBgPBgq8H/0IYp+ez5mLY1XHmBv8kYq G8Pl5h2VPqYk4CGE2IXsJOoBYMEXjKCORf6nyAWd3tQNh2OwMT4NHORnIQdD9Pdl YnKZt0hEgYpUmsM+aCfJ3TRjtrw3SfTtFjoT7boY/2dPyKa8LqreHjRN+z9nWVgd d/aSskmroaIZB4lgDcu+kz+TxbPimmzOfbkm1blqzsqLq0NHyZFHpkixBxPdeLc0 TcNiAf6z1rJg6kkPGFYhZqgh/kWV06cMDmJHGFEMpM9CnA8SbG9b4xd/8qhCzntv HVIg/tNDr7UAqw9c1bylEUXlXKuAHFPsXCRr49lqnyqzR/Hd2pGQMzypvc41pbXW lmds4qVMdWtGG1dUeKFN/9cWlP0L4genjdRXUpMnfMuiI6ZC2eIdi1F/+QmpqnvS IiLbp9/40bV/poSpoJRc73WlE0ORoE61LbLxAEoDFmHn9zM5+pPn/SOEM2ElB7DQ ilgom4A9PQ/Us8c2l3dOMDAM5mSX+rj+fH8BSWlK3iZpXxfkw/o9bAVVrGClwbzz j7VA2cZIzew= =eywq -----END PGP SIGNATURE----- --mNGKFxWlKa8RVqLf-- From nobody Fri Jan 30 11:51:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2D81A1BBD for ; Fri, 30 Jan 2015 11:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRPK8aAeRMQ8 for ; Fri, 30 Jan 2015 11:51:10 -0800 (PST) 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 1BB5E1A1BDA for ; Fri, 30 Jan 2015 11:50:33 -0800 (PST) Received: (qmail 70435 messnum 326912 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 30 Jan 2015 19:50:31 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail19.svc.cra.dublin.eircom.net (qp 70435) with SMTP; 30 Jan 2015 19:50:31 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id mKqU1p00C4BK5ly01KqXdT; Fri, 30 Jan 2015 19:50:31 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ross Chandler In-Reply-To: <20150130180456.GP34798@Space.Net> Date: Fri, 30 Jan 2015 19:50:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7D4F2458-B559-4F9E-A142-D1C0880C9A79@eircom.net> References: <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CBB2BB.9010608@foobar.org> <20150130164126.GO34798@Space.Net> <8909_1422637053_54CBB7FD_8909_6553_1_5adce3e7-c0d1-4493-b88f-a20a0d4e3c9b@OPEXCLILH03.corporate.adroot.infra.ftgroup> <20150130180456.GP34798@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jan 2015 19:51:15 -0000 > On 30 Jan 2015, at 18:04, Gert Doering wrote: >=20 > This is a global world, and (maybe except for the chinese market), = handset > vendors ship globally - I know of one Android based vendor that isn=E2=80=99t shipping IPv6 = support in Europe yet (they plan to) for devices known to work with = IPv6. We take a regional image from them at present. > so I bet that an Android handset that works well > in T-Mobile USA's and Verizon Wireless' network has enough IPv6 = support > to work on your network as well=E2=80=A6 I just tested bug fixes from another vendor to make 464xlat work with = IPv4 tethering when a shared handset data & tethering APN is used. The software developed I assume to meet the requirements of T-Mobile US = didn=E2=80=99t work for the above case although that case works in = stock android. > OTOH, I have a number of Telco-branded devices here that can *not* do > IPv6, even if the original vendor firmware *does* IPv6. =20 There=E2=80=99s an original vendor that lets APN protocol be edited to = IPv6 but the devices don=E2=80=99t include the necessary support. Another vendor hasn=E2=80=99t said that they=E2=80=99ll support 464xlat = and it doesn=E2=80=99t look like they=E2=80=99ve any plans to. BR Ross From nobody Sat Jan 31 14:28:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492151A011B for ; Sat, 31 Jan 2015 14:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJycGLBHBxAa for ; Sat, 31 Jan 2015 14:28:29 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A371A1BE0 for ; Sat, 31 Jan 2015 14:28:28 -0800 (PST) Received: from mb-aye.local ([172.56.15.117]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t0VMSL49056843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Jan 2015 22:28:25 GMT (envelope-from joelja@bogus.com) Message-ID: <54CD3FB7.3020402@bogus.com> Date: Sat, 31 Jan 2015 12:48:55 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Gert Doering References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bhcTQ9DcUcTpUl0rSV137uV9xWiA8w0tE" Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jan 2015 22:28:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bhcTQ9DcUcTpUl0rSV137uV9xWiA8w0tE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/30/15 4:21 AM, mohamed.boucadair@orange.com wrote: > Re-, >=20 > With all due respect, I'm afraid we are not discussing whether the > document is needed or not but (as I see it) whether the new version > does not break the WG consensus that was declared for the version > sent to the IESG. I recall that both the WG and IETF consensus were > declared for the version sent to the IESG. One point on that. Part of the reason we are engaged canvasing, is that Brian's discussed questioned my interpretation of the consensus call. Given that I conceded from the outset that the call is somewhat narrow, one of the questions before us as a w.g. and the ietf community is, is that consensus more unequivocal? Brian I believe is willing to extended the benefit of the doubt. So am I, but it's the working groups document..= =2E thanks joel > Thank you. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : Gert Doering [mailto:gert@space.net] > Envoy=E9 : vendredi 30 janvier 2015 11:39 =C0 : BOUCADAIR Mohamed > IMT/OLN Cc : Gert Doering; Ole Troan; Fred Baker (fred); > draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops > List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last > call >=20 > Hi, >=20 > On Fri, Jan 30, 2015 at 09:12:16AM +0000, > mohamed.boucadair@orange.com wrote: >> Can you please help us identifying technical flaws that you think >> need to be fixed in the document? >=20 > I don't think there is a need for this document, and I can't truly > see it reflecting WG consensus. So it's more fundamental than just > individual technical issues. >=20 > For the specifics, everything that Lorenzo said. >=20 > Gert Doering -- NetMaster >=20 --bhcTQ9DcUcTpUl0rSV137uV9xWiA8w0tE 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 iEYEARECAAYFAlTNP7gACgkQ8AA1q7Z/VrJ8vQCdFODGTsmuTPRjNDpEdDrwkpju 3EIAnRJcpFl0EAcLvipOyOEJq5ZywhdP =swET -----END PGP SIGNATURE----- --bhcTQ9DcUcTpUl0rSV137uV9xWiA8w0tE-- From nobody Sat Jan 31 21:06:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898231A8709 for ; Sat, 31 Jan 2015 21:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.535 X-Spam-Level: *** X-Spam-Status: No, score=3.535 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBPcFSQfcBB8 for ; Sat, 31 Jan 2015 21:06:08 -0800 (PST) Received: from nm41-vm8.bullet.mail.gq1.yahoo.com (nm41-vm8.bullet.mail.gq1.yahoo.com [67.195.87.95]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A5C1A86FE for ; Sat, 31 Jan 2015 21:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1422767167; bh=icoQae5zeFChOKdpX301VaXBUEERCHJCqQbYYzFN+ME=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=T3sQt2Z64rItKFeoDZpnUrHfbiG/jm8WRj5aJqQQy+VjQ3PAcVcFyJ3ko4baNk/AHYs3D9XthnFgnrWucvU3AJEmaEB17ZHtcxyOfyFdRV1O2GfAXYmtUqYVdGMUcKS5+xBy0FFP0K5fGGTTKrw9m09/Q9aSAqOEfcC3yuFSh56p9iFdgb23S6jBaOEgWHeN4DbKZ8GJ0IVxM8Axq9emwjIiXbPSAmMN2p9LlbHecgJeGNLG41kTaAG4C+UX30zDEr7zQSebUwSUfU/lMdVVWdZ5zch0jQTSOVYzRHTEe/ocHcgZvID12OqMlEBJAQq+QkoEZAbAEhhZSRw5v8KGYA== Received: from [127.0.0.1] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 01 Feb 2015 05:06:07 -0000 Received: from [216.39.60.180] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 01 Feb 2015 05:03:25 -0000 Received: from [98.139.215.143] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 01 Feb 2015 05:03:25 -0000 Received: from [98.139.212.230] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2015 05:03:24 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 01 Feb 2015 05:03:24 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 942891.97741.bm@omp1039.mail.bf1.yahoo.com X-YMail-OSG: BEKhgjUVM1nQAy4HqSxAQ3vQCyJf_mrGVfH.Fl9DdmMc.vqlM4UqSCAzpQtwfFD Dc0idg5SWOsB_BZet4SDlE6JpIit9dts2qw1rru9EcrBZHs2xG4hB7Rm3KIEs7sLPpNJ7t2WFur4 UVEU4NENeUMuEn60D0iALHEaz4hVc2ju7RsVuP4r8BlISgRBM2Pg2eRVEve25oQS4DI1QgIDzT6C er.MreiJvu5bHpkN73ugaM7O1G0y25epjjTCyP1joNJ_EfIkEOAocTa6Ld7knsrp7T_AFSXoeL2F 0LkAC2v3mTBr.JD.kF1Fb8Jnzmy9Fp63k_ftLexqpV5H3SIXN9NlR0vLHNAE7vn6.wR6IH.KoeLa 110WUJ_LQM3PQy8qx2s0kAbwLTcY0TcJg2ewzSiwZcsvIxqQ22rV0k6OtVvFbrDahKPsKgR217f4 wB6tIvx8d8GVep4se09Qbx.Tjq_4GOUkCI8407s5ZTP.uycMs.7yT1OGIohhxElRN4qkOjA4P_zV IrsTYBN3J5U8Ng6KApU5lDhUe97NU.lZckCXkU1O1jYodB688nA8pbwJmmi56T572mzLU0flB41l i5z8R7G.pSy24TQYMqKmetks8S0SkIBsnatcu648OuFusIsa1STOMSrEhb9V4PwU8tdfsIhF_Mtr 7QVEXMCJOJ7PVoLFsvMc- Received: by 76.13.26.156; Sun, 01 Feb 2015 05:03:24 +0000 Date: Sun, 1 Feb 2015 05:03:21 +0000 (UTC) From: Mark ZZZ Smith To: Mikael Abrahamsson , IPv6 Ops WG Message-ID: <17182367.376035.1422767001332.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 05:06:09 -0000 ----- Original Message ----- From: Mikael Abrahamsson To: IPv6 Ops WG Cc: Sent: Wednesday, 28 January 2015, 21:30 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Wed, 28 Jan 2015, Lorenzo Colitti wrote: > some CPE manufacturers included it and turned it on by default, and c) some > OSes prefer it to IPv4. That was all long ago, but old hardware dies hard. I have a datapoint here. For instance at least one software version (the one that was on the one I used at the time) on the Linksys EA4500, if IPv6 is set to the default "automatic", it'll do nothing unless it gets a DHCPv6-PD or other signalling. If you however turn it to "off" (I believe, this was two years ago), it'll start to do 6to4 and send out RAs on the wifi/LAN ports with the derived IPv4-GUA 6to4 IPv6 prefix. So there might very well be plenty of people out there who changed something on their home gateway, didn't know what they did, but now they're running 6to4 and they have no idea about it and it's not something they want to do. * It's quite a while since I had access to one, however the FrizBox CPE were perceived to be a good IPv6 CPE in around 2010, yet they tried to do some 'interesting' things with IPv6/IPv6 access (ULAs with all zeros random part, dynamically *switch* between ULA and GUA prefixes based on the state of the ADSL interface). I have a very faint glimpse of memory that they also might have tried to do something like enabling 6to4 if native IPv6 wasn't available (perhaps if IPv6 was globally enabled). Here is my email about this I found from two years ago: http://lists.cluenet.de/pipermail/ipv6-ops/2013-February/008520.html -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops